cybmeta

Does it keep all other LazyLoad instances running?

I think so.

Well, while they answer, you can use:

new LazyLoad(window.lazyLoadOptions);

It is supposed to be automatically triggered by the plugin itself, but something is going wrong in new versions. Let’s see what the support team has to say.

On wp_head I use post’s content to build json-ld data. I need some plugins that affect the content be active and other plugins be inactive. For example, I need original images src attribute, so I need to deactivate your plugin. That is the use case and the proposed solution seems to work.

Thank you.

I think I’ve found it:

add_filter( 'do_rocket_lazyload', '__return_false' );

// ...

add_filter( 'do_rocket_lazyload', '__return_true' );

Is it right?

Thank you, it works!!

I tried that filter with the default priority value (third argument) and didn’t work. It would be nice to update the docs in class.jetpack.php to say that the priority must be 99 or higher, or it’s me?

Yes, but they are detected after WordPress has handled them and has performed the old-slug redirection itself, and so your plugin doesn’t break it because it enters in the scene only in case of “true” 404s that WordPress couldn’t handle itself and not before.

I hope it makes sense.

I’m still testing that change and still everything seems to work as expected, please, give a try. I really think you should leave the core functionality untouched unless you are going to introduce a improvement or something different from the core, which doesn’t seem to be the case. Correct me if I’m wrong.

I’ve made a very quick test modifying ‘redirection/modules/wordpress.php`, lines 26-30, from:

add_action( 'template_redirect', array( $this, 'template_redirect' ) );

// Remove WordPress 2.3 redirection
remove_action( 'template_redirect', 'wp_old_slug_redirect' );

To:

add_action( 'template_redirect', array( $this, 'template_redirect' ), 11 );

// Remove WordPress 2.3 redirection
// remove_action( 'template_redirect', 'wp_old_slug_redirect' );

By hooking your functions with priority of 11 in template_redirect, they will be triggered after the core wp_old_slug_redirect() function (it is hooked with a default priority of 10), it seems that the core old slug redirection works as expected and your plugin still work as expected too, have you tried this? Could you?

You have one post that change the slug:

example.com/old-post-slug to example.com/new-post-slug

Then you need to redirect
example.com/old-post-slug/amp to example.com/new-post-slug/amp
AND
example.com/old-post-slug/some_attachmet to example.com/new-post-slug/some_attachmet
AND
example.com/old-post-slug/other_attachmet to example.com/new-post-slug/other_attachmet
AND
example.com/old-post-slug/feed to example.com/new-post-slug/feed
AND so on

I hope you understand now what I mean.

Can your plugin automatically redirect a modified post and all its children paths?

I’m actually handling this by adding a regex redirection, post by post, but it should be handled by your plugin automatically the same way it is handled by WordPress core, otherwise I see a broken core functionality when your plugin is active.

Yes, I have that option activated. But it doesn’t work for child paths. I see there is another option to asociate a child path, i.e. “/amp”. But what if it needs to be dynamic or if there are more than one, i.e. for amp and for all attachements of the parent post?

This situations are handled by WordPress, why your plugin replace this core functionality? Is there any reason?

I see that your plugin does not use any core object to store information, and so, when it changes, it does not trigger any core action hook used by LiteSpeed. For now, I’ve excluded /wp-json/redirection/ path from LiteSpeed cache until I have time to investigate further.

Caching REST API is a must for me, as I’m using an app and the performance is really much better when the REST API is cached.

I could configured LiteSpeed to not cache privately, so the admin backend of your plugin would not be affected, but I would lost the performance gains for logged in users in all other areas (including back and frontend parts of the site).

I really don’t like none of the those options.

So, I’m thinking about integrating both plugins. Your plugin provides some actions hooks where LiteSpeed Cache API can be integrated. I think I can do it.

Litespeed is caching the REST API responses from your plugin (privately; I have it configured to do so, and it is awesome for logged in users and wp-admin), but it seems that your plugin does not trigger any of the action hooks used by LiteSpeed to clean up the cache.

It seems both plugins need to support each other specifically.

I’m actually investigating it. I’m using LiteSpeed with private caching activated (it caches privately for each logged in user). I can see X-LiteSpeed-Cache: hit,private in the Redirection API endpoint. Let’s me check what happens if I deactivate that option in LiteSpeed.

Yes, but where, why, when?