Built in plugin management and removing idle scripts

Great point that you bring up here. I’ve been coding a few rather large WordPress extensions in the past month with the goal of making them as ‘smart’ and responsible as I possibly can. This is not as easy as I would have hoped it to be, but I’ve managed to work my way through the tough parts and am pretty happy with the solutions that I have been able to produce.

This being said, I believe that it is the sole responsibility of the plugin author to produce code that functions responsibly by cutting down on database calls and unnecessary http requests.

I think that the system that you are proposing may be too broad in scope to successfully deploy. This is just my opinion based off of a semi-educated guess, but I believe that you said it best:

…it can be frustrating at best trying to incorporate something into your site that can and will remove all these unnecessary calls on pages that don’t require them, and doing it in such a way as to not have the site break next time the plugin is upgraded and some of the codebase changes.

I think that it would be just as frustrating to build such functionality into the core without changing the plugins api drastically.

The solution that I would set forward would be to educate plugin authors on best practices by siting specific examples. This is the only way that I learn.

Another, more direct, method would be to actually fix the plugin and email the code back to the plugin author with a request to add the changes in their next public release. I’ve found this to be a great way to get what you need while contributing to the community and giving props to the plugin author. I know that it has really made my day when people write me about updates they would like to see in my code and I am almost always happy to add their changes.

Just my thoughts…

I think that it would be just as frustrating to build such functionality into the core without changing the plugins api drastically.

I don’t know, it’s all being queued right, so the ‘list’ is already in there, it’s just a matter of when each part will fire. I guess I was picturing a thin layer where you could intercept everything in the list and rearrange it or remove it.

I’m still familiarizing myself with the codebase as I go, she’s no small task. I definitely agree edumacation is the way to go, but if you think about it, there’s a lot of resources out there to learn from already. Books, blogs, big wooden sticks that you can hit people with. Despite all that, it’s still happening.

What I’m picturing might not be the right method, but it would be convenient to have a more focused approach. Unhooking everything and writing new functions to overlay the old is tedious at best.

I don’t know, it’s all being queued right, so the ‘list’ is already in there, it’s just a matter of when each part will fire. I guess I was picturing a thin layer where you could intercept everything in the list and rearrange it or remove it.

Actually, your right and it’s much easier then I originally thought to access all of this. To find the “list”, I ran this code in header.php of the default theme with a few minimal plugins installed:

global $wp_filter;
print '<pre>' . print_r( $wp_filter, true ) . '</pre>';

Although you can easily create a function that will loop over this array and add or remove filters if certain conditions exist, you will never successfully avoid the risk of the plugin author changing their code in a new release that will circumvent your logic.

there’s a lot of resources out there to learn from already. Books, blogs, big wooden sticks that you can hit people with.

Agreed, it’s getting better all the time, but specific tasks are sometimes hard to come by… I struggled for a while with being able to figure out how to en queue scripts or styles only when necessary and only was able to nail last week… problem is there were no available resources that focused on this and no one in the forums seemed to know… which led me to believe that it was either really hard or not possible.

This is why I believe that direct education is the best way to deal with this sort of problem. If the plugin’s broke, fix it and email the author. More times than not, your code will get included + you will probably spend the same amount of time making the changes as you would hacking around them. In the event that the plugin author is unresponsive, there is always the option of releasing the changes yourself – provided it is licensed properly.

Best of luck to you!
Would love to hear what path you take with this,
-Mike

I just stumbled across a couple of things that I think are good resources as far as this topic of conversation goes.

The first is on Ozh blog (how came I haven’t been subscribed there until now? geebus), and is a little more in depth on the code you posted: https://planetozh.com/blog/my-projects/wordpress-hooks-filter-flow/

It’s oldddddd, but it still does the trick, I ran it on a local copy with absolutely no quirks. This, and what you wrote, proves my assumption that there was probably a way to retrieve this list easily enough.

The second, relating more to what you’ve been mentioning, was just recently posted on WordPress Tavern: https://www.wptavern.com/is-a-plugin-validation-team-a-pipe-dream

Definitely worth checking out if anybody is out there looking at this thread.

Thanks for linking to the article on WPTavern.com. I seriously doubt any centralized plugin validation team or process will be put into place as no one likes putting walls around anything. I’m guessing that perhaps in the future, once a large selection of plugins hosted on the WordPress plugin repository give way to terrible security vulnerabilities that take down sites left and right is the only time we’ll see drastic measures taken to not only educate plugin authors, but protect users of these plugins as well.

The validation process insures that the guidelines for writing plugins that are found here https://codex.www.ads-software.com/WordPress_Coding_Standards and here https://codex.www.ads-software.com/Writing_a_Plugin are being adhered to instead of allowing other stuff into the repo. If a plugin is rejected, there should be good feedback as to why and in this process, the plugin author should learn of mistakes and hopefully, become a better developer through this method, eventually submitting a plugin that passes.

As a user, I end up installing plugins that give me the functionality I wish WordPress has by default. If those plugins work, great! But I’m not smart enough to dig through the code and notice what might be a XSS vulnerability. All I care about is that the plugin works and works well with decent support.

If one of the most important issues here is educating developers, how does WordPress go about doing that without having them go through a peer review of each plugin they submit to the repo? Right now, the guidelines are in place, there are a bunch of 3rd party resources that have been noted in a previous post, all of those are based on the volunteering efforts of the plugin developer to read them and abide by them. Is this actually happening though?

@delayedinsanity – Thanks for the link to Ozh’s script. That looks really helpful, and sorry for the slow response, it’s rare that I look at old posts past the first page.

@jeffr0 – I agree that a validation team or a gated directory are not really good solutions to poorly written/outdated plugins. One thing that the WordPress team has implemented that I am really excited about is the new “Compatibility” feature for each plugin’s page. Hopefully this feature will become a trusted resource that users will check before installation.

Another interesting idea might be a General Housekeeping Contest which could serve to get many developers digging through the plugins directory, locating non-standard code and bringing it up to par. I’d be down to participate in this. I recently suggested a similar idea that revolves around themes here:
https://www.wptavern.com/forum/general-wordpress/1069-you-joining-premium-mod-competition.html#post9282

I am creating a theme that actually does much of the work that several common plugins do; common to my sites that is.

In doing so, I have begun experimenting with ways to allow the Theme Options page to provide a series of checkboxes that the site owner would use to determine where (single, archive, home, etc) they want the functions deployed.

I am using the remove_action & add_action functions to accomplish this.