nathanwright

Thanks Jeff, it really does look like you have tried every way and I can see what you mean now about the matching which could cause a massive overhead. Thanks again for the explanation and a great plugin, it makes a huge difference to front end and back end page loading and processing times especially when you have a large number of plugins.

Jeff, why should this addition add overhead to the plugin loading. I have not looked at your code but assume you are hooking in to the page init event or some other event that occurs very high up and then comparing if it matches a URL in your list of plugin filters pages which I guess you probably hold as a transient array for speed.

So if in the page filter you had two input URL fields instead of the current one. In the current one you put the page checking in exactly the same way you do now so no additional overhead.

If the page matches then you check to see if the string in the second input field is contained within the parameter part of the url.

With this method you would only get an increased overhead on a page matching the url and I can’t see how this additional check on these pages can increase any load time.

For example:

Lets say the page I want to have a plugin filter on has a url of:

http://www.aaaaa.com/wp-admin/admin.php?page=content-ready&id=12

So in the current url field I would enter:

http://www.aaaaa.com/wp-admin/admin.php

And in the second (new) input field I would enter:

page=content-ready

You would then have to simply do a check for the “page=content-ready” only when the page being loaded is “http://www.aaaaa.com/wp-admin/admin.php”

Maybe I am missing something but I can’t see how the above can put extra overhead on the page loading and would then allow people to do parameter checking. I guess if you wanted to be really clever you could add a checkbox to the second input field to allow entry of a regex match string which would then enable people to do complex parameter matching but again this would not add a huge overhead as the checking would only occur for the specific page being requested and if you documented the fact that the regex “might” add overhead then I am sure people would accept the overhead for the gain in added benefit from not loading plugins that screw things up and really slow things down.

Just trying to give an alternative view on the idea 😉

I can now reproduce the problem very effectively using the a3rev.com WP Email Template plugin but it also does the same thing with other plugins.

If you set up your global order and save, check that the global order is saved by reloading the page. All is good.

Now install the a3rev.com WP Email Template plugin but don’t activate it. Go to your global order and the plugin order is fine as when you saved them.

Now go to plugins and activate the plugin, validate authorisation code, go back to the global order and you will see that the previously saved order has been reset to the default order and if you now try and change and save the order it doesn’t get saved.

As I said at the outset this is happening with a number of plugins (but by no means all) and not specifically just with the WP Email Template plugin.

Jeff, if you want to get access to login to my install so you can see and debug etc let me know and I will provide login details etc.

Doing some more digging it would appear that the same thing happens if you set all your global order and then install and activate the plugin “Duplicate Page” the global order gets reset. The weird thing is if you disable the “Duplicate Page” plugin then the global order returns to how you set it. I mention this as it may help you locate the problem.

I will explain some more.

1) In Global Order have WooCommerce and another plugin that requires WC to be active.

2) For the sake of example put the WC plugin below the other plugin that requires WC so that the other plugin will not activate because the WC plugin is not yet active. Now if you create a Page Filter where you disable the WC plugin and the other plugin that needs the WC plugin.

3) Now navigate to the page (the one above) and everything looks great. Now navigate to another page and then go to the Plugins page and you will see that all the plugins that you have that require WC have become deactivated.

4) Reactivate all of the WC plugins and then go to the Global Order page and you will see that the plugins are now all loading in the wrong order and not the order specified in step 2 above.

The issue also occurs with plugins like Yoast and EventOn where an error occurs when they are reactivate and try to load a summary page of new features.

Nathan

Thanks of the information I will have a play with that tomorrow. Really love the product, it also appears to be stable and reasonably easy to get to grips with. The only downside I have seen so far is that because it all works from a single class you can’t chop the PHP code up into different files very easily so you do end up with a rather large PHP file which can become a bit of a pain to maintain. This might be my misunderstanding of the documentation. Is it possible to create a separate class extend for say each menu item so that everything related to a menu item could be held in the same PHP file or does everything have to come off of a single class extend?