I’ve tried to implement the ability to manage multiple urls with one filter but it never worked right. It would be nice to have the ability to wildcard the url arguments but that poses an efficiency problem when trying to match in the database and the whole point of this plugin is to speed up page load time.
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 😉
The point at which I’m hooking in is before any post types are registered. So a post/page/post type does not exist. Transients also don’t exist. There is no such thing as post meta. It is purely a string match in the database on the url being visited. To do a match on the arguments to a url I would have to allow for any combination of strings to the limit of the Web server you are using. This is a text field in a database. And that database table could have thousands or even millions of rows. So if I tried to do an sql query with this:
url-arguments LIKE '%page=content-ready%'
And your database contains a lot of records then your page load time increases a lot. If the query didn’t simply shut down before it completes. Doing thousands of these queries per second, as some of my sites would do, even if the table wasn’t big would kill mysql. Plus it’s not the arguments that you enter in the field that are being used for the matching. It’s the arguments that are received in the url at page load time that have to be matched to the database. And there could be several of these. Each resulting in a separate like statement. So I can’t simply take what you put in the database and use it. Or I would have to try matching by pulling every row from the database and that would also kill the server.
Hi Jeff, thanks for the explanation, my comments were not meant as a criticism, was just trying to offer and alternative view in case it hadn’t been considered. I can now see why you would get the overhead and agree that the slowness could be massive.
Using your example, the like clause will indeed cause a massive overhead but you could always do it a different way. So have a new table that you hold the two fields, “path” and ‘params” which gets updated from the main database whenever a hook is triggered where a new post/page etc is created or changed etc. Then when you start your hooked event before anything else you could get the path e.g. http://www.aaa.com/abc which you would then do an exact match. In the params field you would hold an array of different parameters therefore doing a memory search down the array for the parameter the plugin filter is trying to match against. This would then remove the need for you to do a like match across the database etc,.
That would also slow down the response time and possibly kill the server. To save an array to the databse a longtext field is required and it would need to be pulled into php and converted to an array to be usable. So lets take this url for example.
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CC4QFjAA&url=http%3A%2F%2Fthelongestlistofthelongeststuffatthelongestdomainnameatlonglast.com%2Fwearejustdoingthistobestupidnowsincethiscangoonforeverandeverandeverbutitstilllookskindaneatinthebrowsereventhoughitsabigwasteoftimeandenergyandhasnorealpointbutwehadtodoitanyways.html&ei=40egUo2MGI3xoATQtIKwDQ&usg=AFQjCNHbBa5Fk4YutdUOj_D8IwpJLu7hGw&sig2=8P4ew1Yie72Ps_OQ-L5cXw&bvm=bv.57155469,d.cGU
My code would need to split the arguments on the & character. That takes processing time. Then the url would need to be matched which takes time and there could be multiple urls that match it. Then each argument field would need to be converted to a php array and searched. Each argument would need to be used to search every array that was returned. So that is a lot of processing time. And this could be happening multiple times per second. There is no way to do it. I’ve been working on this for years and I’ve tried just about every solution you can think of. My hashed search is the best solution that I’ve come up with. It isn’t very flexible but it uses an index and it works in an efficient way. This plugin is limited but it is limited because it needs to be quick. Or it will not accomplish any benefit for sites line CNN or the high traffic sites I run.
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.
One last thought that may be able to be done without you changing any code.
Lets say you have a link as follows:
http://www.aaaa.je/wp-admin/tools.php?page=the-page-name&name=fred&id=23
So the part that you want to match on is:
http://www.aaaa.je/wp-admin/tools.php?page=the-page-name
What if you could do something that happened before you do the hook e.g. in apache or elsewhere so that the incoming url looked like:
http://www.aaaa.je/wp-admin/tools.php/page/the-page-name/name=fred/id=23
The in your plugin you could do a match on:
http://www.aaaa.je/wp-admin/tools.php/page/the-page-name
And enable the child pages option which you already have. Ok this would only work when the parameters are in the set order but would handle many cases like this.
This would not effect the processing of your plugin as the matching would still be the same as it is doing now just what is being presented to your plugin would be preformatted.
