Hans Schuijff

I added this this to my core-functionality plugin and will rename the_content in this plugin for now, so it will use this hook. It’s a drag to have to do that for every update, but it’s the least impact. In that way all core callbacks are fired and no extra’s.

/**
 * Adds a clone 'the_content' filter hook that will only fire the WordPress core callback functions.
 *
 * This hook is used so that plugins that prepend or append content to the_content will not add them.
 *
 * @return void
 */
function setup_custom_the_content_filter() {
	global $wp_embed;
	add_filter( __NAMESPACE__ . '\the_content', array( $wp_embed, 'run_shortcode' ), 8 );
	add_filter( __NAMESPACE__ . '\the_content', array( $wp_embed, 'autoembed' ), 8 );
	add_filter( __NAMESPACE__ . '\the_content', 'do_blocks', 9 );
	add_filter( __NAMESPACE__ . '\the_content', 'wptexturize' );
	add_filter( __NAMESPACE__ . '\the_content', 'convert_smilies', 20 );
	add_filter( __NAMESPACE__ . '\the_content', 'wpautop' );
	add_filter( __NAMESPACE__ . '\the_content', 'shortcode_unautop' );
	add_filter( __NAMESPACE__ . '\the_content', 'prepend_attachment' );
	add_filter( __NAMESPACE__ . '\the_content', 'wp_filter_content_tags' );
	add_filter( __NAMESPACE__ . '\the_content', 'wp_replace_insecure_home_url' );
	add_filter( __NAMESPACE__ . '\the_content', 'do_shortcode', 11 );
	add_filter( __NAMESPACE__ . '\the_content', 'capital_P_dangit', 11 );
}
add_action( 'init', __NAMESPACE__ . '\setup_custom_the_content_filter' );

This issue was already reported 1.5 years ago too, and I like the solution that was proposed in the first report there more.

The problem with the_content filter is that it is both used to prepend en append content to the content as it is used to sanitize and preprocess the content itself. One wants the preprocess steps to be executed, but not everywhere the prepending an appending of content should be done.

To prevent any problems like this, it would probably be the best to make a custom the_content filter for the plugin and just hook the core functions in that. Doing it like that would mean that it doesn’t matter if it is used to process a block, a widget or the content as a whole. That would prevent problems.

I’m not sure why this issue isn’t acknowledged at all by the plugin dev. Why are users forced to change parts of the source code to solve a problem that has been known for so long and can be fixed? Bill Erickson seems to have the correct structural answer here.

https://www.billerickson.net/code/duplicate-the_content-filters/

In the end it just means prepending the the_content filtername and adding an init function that hooks the needed core filters on it. It doesn’t seem that difficult to implement.

Hi @seebz ,

thanks for the addition. I think this plugin isn’t maintained anymore, or at least not frequently anymore. So we seem to be on our own, solving this. This bug hasn’t been addressed, although it was reported a long time ago, and the last update is already 3 months ago.

I have tested today what is going on and found that when plugins follow the advice of the dev docs about the_content hook, that it still doesn’t work. So there is no problem in the other plugins, it is just something that needs to be solved in this plugin.

Both the shortcode and the widget fail when there are other plugins that use filtering with the_content hook both in the main content and in sidebars. I tested with the genesis framework and a single blog post and there I added a simple reusable block, both in the content and in several sidebars both as block, widget and shortcode.

When using the shortcode, even in the main content of the post the related posts-links of yarpp where added, as well as at the end of the post. All widgets got the related posts links too, both the reusable block widget as the shortcode widget. They all added the yarpp links after it.

The reason that yarpp and other plugins can’t determine correctly when to not to add their content block, is because of the WordPress conditionals.

The codex says to use is_main_query() and in_the_loop() and is_singular(), but all three will return true, both in the actual post content, as in every sidebar on that single post.

I have an “after content” widget area and a sidebar, and both had all three conditionals set to true. That means that every widget I added had it’s own related posts links added to it.

Completely removing the apply_filters() would also not work correctly, since than shortcodes in the reusable block wouldn’t be processed correctly and also the gutenberg comments in the source are not removed. WordPress adds a lot more corrective functions in that hook, that all could be relevant depending on the content of the reusable block and the options in WordPress, so it is practical to use the hook instead of wrapping 10 wordpress functions around the reblex_get_block() call.

convert_smilies(
  do_shortcode(
    capital_P_dangit(
      wp_replace_insecure_home_url(
        wp_filter_content_tags (
          prepend_attachment(
            shortcode_unautop (
              wpautop ( 
                wptexturize( 
                  do_blocks( 
                    reblex_get_block( 150 )
                  ) 
                ) 
              )
            )
          )
        )
      )
    )
  )
);

But we just don’t want other plugins adding content and need to do something so the adviced conditions will fail for the added blocks and widgets.

Your function solves that, since it sets the in_the_loop() conditional to false (helas will the is_main_query() and the in_the_loop() conditional still return true, but it is enough for well written plugins).

I found that to solve the shortcode the apply_filters needs to be replaced by your function call in reblex_shortcode().

function reblex_shortcode( $atts ){
	extract( shortcode_atts( array( 'id' => '' ), $atts));
	$content = reblex_get_filtered_block_content( $id );
	return $content;
}

To solve the widget, the widget method needs to use your function instead of calling apply_filters…

public function widget( $args, $instance ) {
	echo $args['before_widget'];
	if ( ! empty( $instance['title'] ) ) {
		echo '<h3>' . esc_html( $instance['title'] ) . '</h3>';
	}
	$block_id = '';
	if ( isset( $instance['block_id'] ) ) {
		$block_id = $instance['block_id'];
	}
	echo reblex_get_filtered_block_content( $block_id );
	echo $args['after_widget'];
}

The apply_filters(‘the_content’ call in reblex_display_modal() doesn’t seem a problem, as far as my test showed.

the same seems for reblex_display_block().

So only two statements need to be changed and your function added.

I hope the plugin author will solve this now. On the other hand, when this plugin is no longer maintained, the changes I made in my copy will not be overwritten by updates anyway.

Well, that seems to be it than. Thanks again.

regards,

Hans

• This reply was modified 3 years, 2 months ago by Hans Schuijff.

I just installed and my log is filling up with this error too. I’ve checked and you can just change the code and make all methods in the OWA_Block class static (file \organic-widget-area-block\src\class\class-widget-area.php ).

Is there no support anymore on this plugin, that this bug is still there?

• This reply was modified 3 years, 2 months ago by Hans Schuijff.

Thank You!

@cena thinking about an implementation, I could imagine that a student could be directed to his/her current lesson directly after logging in, but that is not that easy since he or she could already be logged in, courses could be free, students may have multiple courses (which should we then select?) and our course implementation is part of an integrated website where courses are only part of the functionality. That path would probably be a bit complex to figure out all possible scenarios.

What I’m asking is just to reduce the number of steps a student has to take to get to where he or she probably needs to go (normally the next unfinished lesson according to the course progress of the student).

Right now, a student first needs to navigate to the course page and then scroll through the course page content (or use a button) and then scroll through the lessons list and then click on the appropriate lesson. Especially on a mobile device with a small screen that can be a nuisance.

One way to skip steps would be the My courses page. There Sensei LMS shows already a course results button, which brings students to the course results page, but there could also be a “continue with the course” button/link, or something like that, bringing the student directly from the archive page to the appropriate lesson.

In that case the student can just bookmark the my courses page and the next unfinished lesson/quiz is just a click from there. And course developers could make that archive something like a student profile page.

Also the same button/link/functionality would be nice to have as a gutenberg block (a shortcode would work too), so it can be placed at the top of the course page. Then a student can bookmark the course page and at the top will find a way to navigate to the next unfinished lesson/quiz.

I could also imagine a query-var in the course pages url results in a redirect to the next unfinished lesson/quiz. That would give developers an easy way to implement any way they want to direct students, by just linking to this special URL.

Something like that. Having said that… Is there a right direction for you to point me in?

Thanks, Regards, Hans

@talldanwp Thank you!

Thank you very much, Luke @lukecarbis, for pointing me in the right direction. I was able to manipulate the button now and understand why button size is a string value instead of an integer. ??

I will look further in the workings of RichText controls too and if your devs have some further tips, I will be glad to get more pointers. Perhaps in future the documentation will be more complete for people needing to do such things. It is all still a bit new.

Luckily I learned on another thread how to insert reusable blocks in a template too, so I will be able to get some progress in my project.

Thanks,

Hans

@talldanwp Hi Daniel,

I’ve added my bit to the issue 22178 discussion. Thanks for directing me.

I like the proposal too, as a way to easily access the menu. But it would not be enough.

Thank you,

Hans

@talldanwp Hi Daniel,

I love it, it your solution works. I didn’t know how to address an existing block by post_id, so now I know.

In testing this, I have noticed another problem that makes using templates a bit risky.

I had a non-core block in my template. It was part of a plugin and when I didn’t have that plugin activated on my system, the response was just an empty blank page with no further messaging.

Only after I went to console, I understood the problem (a none existing block type), but that is only for developers to find and understand. And since I find that often the console has a lot of messaging concerning react and Gutenberg anyway, it might not be that noticeable when not looking for it.

Gutenberg should perhaps just be able to skip/ignore non-existing blocktypes that are mentioned in the blokc-template array instead of just crashing the entire page, or at least it should offer a response that is clear for a user and doesn’t rely on using the browser’s go back key to return to return to WordPress.

Is that an know issue?

Again, thanks for the help. Great to know how I can use reusable blocks in templates. It makes the other challenge of prefilling the more complex blocktypes perhaps redundant.

Regards,

Hans

Hello @aweissinpsyde ,

It seems solved now, and I know what was the problem and how to rule it out now. I understand how closing due to time works, but this problem made the plugin unusable, what is a BIG problem when it is your shops gateway.

I don’t depend on QueryMonitor to test my loadtime, finding out that the page needed 4 times the pageload time was clear enough without it. We were getting user-responses that said the page didn’t work at all, something you don’t want to have happen in the checkout especially.

13-20 seconds or more for a add to cart with version 5.8.2 is crazy long and basically blocks the checkout entirely.

If I was the developer I now would take a good long look at my testing environment and why that quadrupling of the response-time wasn’t noticed before issuing this release. You cannot say performance is important and at the same time let such a thing go through to production.

Perhaps you need a testing setup that also simulates servers that run far from where the server mollie is run and need more time to receive data from mollie.com. Or something that shouts problem when you again add something like this, adding a second to the users response time per icon for something more or less trivial as an icon.

QM has been a very useful source in finding out what was causing the problem and in finding out if the solution worked.

Thanks for solving it in the current version. It has been a long wait.

Hans

@aweissinpsyde Thank you.

Hi @niklasinpsyde Thanks for the new version. If I read the html correctly you now load the image files on the frontend instead of server-side, so that is great.

The result, on my end, in page generation time (with or without the images) reported by Query monitor is almost the same (.4 seconds difference), so that’s fine for me.

Also the pageload is now in the normal range, and can use caching and lazyload. I haven’t checked in the code, but I imagine the problem that other pages than the checkout page also read the svg’s is now automatically also solved.

Thank you. Great that it is solved now!

Hans

@niklasinpsyde

Looking at github, I see issue #450 also pinpoints the same problem. I just took me some more time to get there.

https://github.com/mollie/WooCommerce/issues/450

@niklasinpsyde @domirvana

I’ve taken it upon myself to compare the software of both versions (luckily it was a small update) and think I found the problem. I’ve pinpointed it to a single statement and just now send it with some test outcome to the mollie support outside this forum. The problem was in the way the plugin loads svg icons as of version 5.8.2.

Hope Mollie will quickly solve this, since Niklas said it is now top priority. At least, now we know what is the problem and a solution shouldn’t be that difficult now.

Regards,

Hans