Paul Menard

@morganhvidt

We are in the process of reviewing the changes needed. So no need for you to patch the LearnDash code. But thanks.

Anyone having issues with LearnDash core can contact our support and reference our tracking ID LEARNDASH-5145.

Just some observations about how the Conditional Blocks plugin works and possibly way to minimize the effect you are having on other plugins.

First, within the Conditional Blocks plugin code, in file methods/core/core-render-blocks.php the filter priority for ‘render_block’ seems to too high a priority ‘999’.

add_filter( 'render_block', 'conditional_blocks_render_html', 999, 2 );

Since the purpose of the Conditional Blocks plugin is meant to filter all blocks it should call the filter function conditional_blocks_render_html before the normal plugin handler function is called. Otherwise, the other plugins render functions get called then ends up not getting displayed by the Conditional Blocks plugin logic. I would suggest changing the 999 to 1. OR maybe consider using the two other filters below.

In the WP core in wp-includes/blocks.php within the function render_block()is the start for the ‘render_block’ filter call. Before that point, there are two other filters you should consider using.

/**
  * Allows render_block() to be shortcircuited, by returning a non-null value.
  *
  * @since 5.1.0
  *
  * @param string|null $pre_render The pre-rendered content. Default null.
  * @param array       $block      The block being rendered.
  */
  $pre_render = apply_filters( 'pre_render_block', null, $block );

Seem this would be a better filter to hook into since it lets you abort the normal block rendering logic.

/**
  * Filters the block being rendered in render_block(), before it's processed.
  *
  * @since 5.1.0
  *
  * @param array $block        The block being rendered.
  * @param array $source_block An un-modified copy of $block, as it appeared in the source content.
  */
  $block = apply_filters( 'render_block_data', $block, $source_block );

This filter would let you remove your own block attributes so they don’t get passed down to the real plugin render logic where they are causing issues.

This was brought up to LearnDash support. We are looking into it. Should be patched soon. Thanks.

Closing.

Ha never mind. I just realized who you are.

@davewarfel

Thanks for the reply. and I agree this can be handled by other options. I know Jetpack does this. The down-side is you have to install Jetpack. :<>

And I agree this is not something LD is looking to get into. It is my general belief this is best handled by the theme or other plugins.

And yeah that is my plan to change the logic so the wrapper div is always present and we use a data-* attribute to target the one needing progression process. But this might be a while. We are working on the LD 3.0 changes. Speaking of we should probably connect so we can ensure you get a beta and can adjust your plugin accordingly. You can email [email protected]

LearnDash Developer here.

The information above is true. When using the Video Progression logic we wrap a div <div class="ld-video"> around the video <iframe></iframe>. This is how the associated JavaScript knows to process these elements on the page and apply the video progression rules.

Once the lesson/topic is completed there is no need for video progression logic since the step have been completes. So the wrapper <div class="ld-video"> is not included around the <iframe></iframe>.

I can’t promise any immediate fix but will look into changes to the core logic to include the div wrapper after the step is completed. This way the Design Upgrade CSS can still be applied.

But that brings up another issue. If I take the same URL I’m adding to the Video Progression field and add it to the post content. The video showed there is not 100%. It will be whatever size is determined by the WordPress video embed logic. My point is should all videos within the LearnDash content be made 100%?

Thanks for the quick fix.

Actually I question your answer. Doing some investigation in the same error and found a bug in your plugin. you are calling current_user_can() incorrectly.

In version 6.2.7 of your plugin. In the file class-am-notifications.php in the function get_remote_notifications() line 92 you have the following:

if ( ! current_user_can( apply_filters( ‘am_notifications_display’, is_super_admin() ) ) ) {

In the inner command you have a filter which will return true or false.
apply_filters( ‘am_notifications_display’, is_super_admin() )

Then you are passing this true/false into the current_user_can() as the first parameter. This is wrong. You should be passing a string like ‘manage_options’ or ‘edit_posts’ etc. a capability.

Down the line when other plugins who are subscribed to the ‘map_meta_cap’ filter receive true or false as the $cap parameter (second) instead of a string.

Never mind. I’m a moron. I didn’t notice I was using ‘wp_deregister_script()’ instead of ‘wp_dequeue_script()’.

Trapping of using the auto-complete from my editor and not paying attention.

Changed the call and no error.

Apologies.

Yeah that is coming in a future release. Soon.

@euthelup,

Not sure I follow what you are seeing. All registered post-types should be available for all the Simply-Exclude actions like is_archive, is_home, is_search and is_feed.

Can you tell me how these custom posts are being registered? Maybe there is some parameter in that registration preventing the posts from showing within the SE options.

If you go to wp-admin then into the Simply-Exclude menu options. Then the Post-Types tab do you not see the post types listed?

@symon83,

Can you provide details on your exact issue, please.

@mokhtar-taha,

Waiting to here about your PHP version. I’m not sure. The beta should fix that issue. Almost appears as though the option store for Simply-Exclude is corrupt or something. Might need to manually clear out the setting from your wp_options table. This is not currently something within SE.

@mokhtar-taha,

Can I get you to please download and install the following plugin. This should replace the current version of Simply-Exclude you have installed.

https://dl.dropboxusercontent.com/u/2616987/projects/wp-plugins/simply-exclude/beta/simply-exclude-2.0.6.7-BetaA.zip

To be clear do the following:

1. Log into your Dashboard (wp-admin).
2. Go to Plugins listing.
3. Deactivate the Simply Exclude plugin.
4. When the page reloads click the ‘Delete’ option on the Simply Exclude plugin.
5. Next to go Plugins > Add New. Then at the top look for the ‘Upload Plugin’ button. Click this.
6. On the upload form select the Beta plugin I provided from your local system.

This may or may not solve your issue. For some reason your system things the configuration array used by Simply Exclude is a string not an array. This means you may need to manually reset the plugin settings. At the moment there is not an option to do this. It would require a direct database option.