bobbingwide/oik-unloader

WordPress Must Use plugin to unload unnecessary plugins on demand

oik-unloader

• Contributors: bobbingwide, vsgloik
• Donate link: https://www.oik-plugins.com/oik/oik-donate/
• Tags: oik, plugin, unloader
• Requires at least: 5.8.1
• Tested up to: 6.4-RC2
• Stable tag: 0.3.1

WordPress Must Use plugin to unload unnecessary plugins on demand.

Description

Use the oik-unloader plugin to unload unnecessary plugins on demand.

Many websites have lots of plugins activated because the functionality is sometimes needed. But quite a few of these plugins:

• think they're needed all the time,
• do a lot of processing for each incoming request,
• only to find that there was no need for the work that they'd done.

These slow the server side processing of the site. This can increase the server response time; time to first byte. The plugins can also slow the front end of the site; delivering scripts, CSS and even HTML and images that are not actually needed.

Dynamically unloading a subset of plugins for certain requests could improve the overall performance of the site. This could help improve the Core Web Vitals which may lead to better rankings in Search Engine Results Pages ( SERPs ).

Installation

1. Upload the contents of the oik-unloader plugin to the `/wp-content/plugins/oik-unloader' directory
2. Activate the oik-unloader plugin through the 'Plugins' menu in WordPress
3. Visit the oik-unloader admin page
4. Use the admin interface to select which plugins to deactivate for selected URLs
5. Click on the link to activate/update the Must Use ( MU ) plugin
6. Disable the MU logic using the Deactivate link

• Note: In a WordPress Multi Site installation

• There will only be one version of the Must Use plugin ( oik-unloader-mu.php )
• There will be multiple unloader files; one per site.

Frequently Asked Questions

What is this plugin for?

Performance tweaking.

• It helps to reduce the number of activated plugins for a particular request.
• It dynamically removes the unwanted plugins from the list of plugins to be activated.
• The plugin temporarily deactivates plugins for the specific URL.
• It doesn't unload them, it prevents the plugins from being loaded.

Which plugins can I deactivate?

For certain URLs you should be able to deactivate a whole host of plugins that aren't actually required for the front end. You may find that some plugins are extremely well behaved and it won't make the slightest difference if they're left activated.

Why deactivate rather than activate?

By targetting specific URLs you can deactivate plugins that you're certain are not needed. For example, you may have a number of posts that display charts. For these you will need to ensure that the chart plugin is activated. For any other post, the plugin that displays the charts doesn't need to be activated. If it improves the performance, then you may consider deactivating the chart plugin for these other posts. The tweaking is intended to get the best performance for specific URLs. Concentrate on the most visited pages first and deactivate only those plugins that you know you can safely deactivate.

It's primarily the front end experience that we want to improve.

When using the WordPress admin interface you'll expect each of the plugins to operate correctly. Therefore you would expect the plugins to be activated. The REST API and AJAX requests should also produce the expected results.

Screenshots

1. oik-loader admin page - plugins
2. oik-loader admin page - oik-loader-mu not activated
3. oik-loader admin page - oik-loader-mu activated

Upgrade Notice

0.3.1

Upgrade for support for PHP 8.1 and PHP 8.2

0.3.0

Upgrade for an improved active-plugins block and some bug fixes.

0.2.0

Upgrade for the active-plugins block to load/unload plugins from the front-end.

0.1.1

Upgrade to avoid problems that may arise at shutdown.

0.1.0

Upgrade for WordPress Multi Site support.

0.0.1

Upgrade plugin selection using checkboxes.

0.0.0

Prototype version developed as part of a performance improvement project.

Changelog

0.3.1

• Changed: Support PHP 8.1 and PHP 8.2 #14
• Tested: With WordPress 6.4-RC2
• Tested: With PHP 8.1 and PHP 8.2
• Tested: With PHPUnit 9.6

0.3.0

• Fixed: Cater for post query arg array #13
• Fixed: Require bobbforms before calling bw_form() #12
• Changed: Reconcile shared library update
• Fixed: Avoid warning when query parms are an array #11
• Changed: Only display checkboxes for authorized users #7
• Tested: With WordPress 6.2.2
• Tested: With PHP 8.0

0.2.0

• Added: oik-unloader/active-plugins block #7
• Added: [active_plugins] shortcode #7
• Changed: Improve oik-unloader admin form #1
• Changed: Cater for when oik-loader is not available #7
• Changed: Prevent NextGEN Gallery from activating itself #6
• Tested: With WordPress 5.9.2
• Tested: With PHP 8.0
• Tested: With/without oik-loader v1.4.0

0.1.1

• Fixed: Deactivates unloading logic at shutdown. Fixes #6
• Tested: With WordPress 5.9

0.1.0

• Changed: Support deactivation of Network Activated plugins in WordPress Multi Site #4

0.0.1

• Changed: Plugin selection list implemented using checkboxes
• Changed: Create mu-plugins folder if required
• Changed: Respect WPMU_PLUGIN_DIR value locating mu-plugins folder

0.0.0

• Added: Brand new plugin. includes/oik-unloader-mu.php will only be installed in mu-plugins if the folder exists.
• Tested: With WordPress 5.8.1
• Tested: With Gutenberg 11.7.0
• Tested: With PHP 8.0

Further reading

See also oik-loader which adds plugins to the list of plugins to activate.

If you want to read more about oik plugins and themes then please visit oik-plugins

oik-unloader's Issues

Fatal error call to undefined function bw_form()

When attempting to view https://s.b/wp55/blog/ I got this error

Fatal error: Uncaught Error: Call to undefined function bw_form() in C:\apache\htdocs\wordpress\wp-content\plugins\oik-unloader\classes\class-oik-unloader-active-plugins-shortcode.php:259

Stack trace:
#0 C:\apache\htdocs\wordpress\wp-content\plugins\oik-unloader\classes\class-oik-unloader-active-plugins-shortcode.php(235): OIK_Unloader_Active_Plugins_Shortcode->form_tag()
#1 C:\apache\htdocs\wordpress\wp-content\plugins\oik-unloader\classes\class-oik-unloader-active-plugins-shortcode.php(64): OIK_Unloader_Active_Plugins_Shortcode->display_plugins_form(1)
#2 C:\apache\htdocs\wordpress\wp-content\plugins\oik-unloader\oik-unloader.php(97): OIK_Unloader_Active_Plugins_Shortcode->run('', '', 'active_plugins')
#3 C:\apache\htdocs\wp55\wp-includes\shortcodes.php(355): oik_unloader_active_plugins('', '', 'active_plugins')
#4 [internal function]: do_shortcode_tag(Array)
#5 C:\apache\htdocs\wp55\wp-includes\shortcodes.php(227): preg_replace_callback('/\\[(\\[?)(active...', 'do_shortcode_ta...', '<!-- wp:paragra...')
#6 C:\apache\htdocs\wp55\wp-includes\class-wp-hook.php(310): do_shortcode('<!-- wp:paragra...')
#7 C:\apache\htdocs\wp55\wp-includes\plugin.php(205): WP_Hook->apply_filters('<!-- wp:paragra...', Array)
#8 C:\apache\htdocs\wp55\wp-includes\post-template.php(431): apply_filters('get_the_excerpt', '', Object(WP_Post))
#9 C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\build\block-library\blocks\post-excerpt.php(29): get_the_excerpt()
#10 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(258): gutenberg_render_block_core_post_excerpt(Array, '', Object(WP_Block))
#11 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(244): WP_Block->render()
#12 C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\build\block-library\blocks\post-template.php(98): WP_Block->render(Array)
#13 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(258): gutenberg_render_block_core_post_template(Array, '<li class="wp-b...', Object(WP_Block))
#14 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(244): WP_Block->render()
#15 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(244): WP_Block->render()
#16 C:\apache\htdocs\wp55\wp-includes\blocks.php(1051): WP_Block->render()
#17 C:\apache\htdocs\wp55\wp-includes\blocks.php(1089): render_block(Array)
#18 C:\apache\htdocs\wp55\wp-includes\block-template.php(240): do_blocks('<!-- wp:templat...')
#19 C:\apache\htdocs\wp55\wp-includes\template-canvas.php(12): get_the_block_template_html()
#20 C:\apache\htdocs\wp55\wp-includes\template-loader.php(106): include('C:\\apache\\htdoc...')
#21 C:\apache\htdocs\wp55\wp-blog-header.php(19): require_once('C:\\apache\\htdoc...')
#22 C:\apache\htdocs\wp55\index.php(17): require('C:\\apache\\htdoc...')
#23 {main}
  thrown in <b>C:\apache\htdocs\wordpress\wp-content\plugins\oik-unloader\classes\class-oik-unloader-active-plugins-shortcode.php</b> on line <b>259</b><br />

Cater for non-permalinks URLs eg `https://example.com/?p=39`

Initially I didn't think it was necessary to support requests for a particular post ID but I discovered that it's necessary to detect when parameters are being passed to the URL since this affects the processing.

The requirement is to detect query params to deal with them differently

URL	Means
https://example.com/	display the home page
https://example.com/?p=39	display the post with post ID 39

Example scenario

• website: denisethatcher.com
• uses: WooCommerce
• if we deactivate WooCommerce on the home page then the link changes from https://denisethatcher.com/product/denise-thatcher-invades-britain/ to https://denisethatcher.com/?p=39
• Visiting this link leads to a 404

Aside: The [add_to_cart] shortcode doesn't work either but that's a separate issue to be addressed.

Possible workaround

• Register the product Custom Post Type using oik-types

Possible solution

• Add support for query parm detection. If the query parm is p=nn or page=nnn or even preview=nnn then don't treat this is a request for the home URL but find the URL using the ID.

Warning when viewing Customizer

When attempting to reproduce bobbingwide/bobbingwide#47
I came across another Warning from oik-unloader.

Warning: Array to string conversion in /home/customer/www/cwiccer.com/public_html/wp-content/mu-plugins/oik-unloader-mu.php on line 293

This is due to the query parameter being an array.
Reproduced using https://s.b/cwiccer/fref?autofocus%5Bsection%5D=title_tagline

Cater for `?wc-ajax` requests to the home page

The oik-unloader logic causes a major problem with requests such as if you unload WooCommerce on the home URL.

https://example.com/?wc-ajax=update_order_review
https://example.com/?wc-ajax=checkout
https://example.com/?wc-ajax=ppc-login-seller

This is a major problem with WooCommerce sites, if you unload WooCommerce on the home URL.

• It prevents WooCommerce from responding to these requests.
• They're supposed to return some JSON.
• When WooCommerce is deactivated the result returned to the browser is the HTML for the home page.
• This isn't expected by WooCommerce's checkout.js
• It never enables the Place order button.

Workaround

• Don't deactivate WooCommerce on the home page.

Originally posted by @bobbingwide in #5 (comment)

cwiccer.com - activating oik-bob-bing-wide doesn't last long

I've been trying to activate oik-bob-bing-wide in cwiccer.com but it doesn't seem to want to stay activated.
It worked for a short while since I was able to insert some of the blocks provided by it.
But when I viewed the page and edited it again the blocks weren't registered.
No idea why at present.

Updating to v2.1.1 didn't resolve the issue.

[bw_pages] - Permalinks not working properly on oik-plugins home page for downloads

https://www.oik-plugins.co.uk/

Link is expected to be

https://www.oik-plugins.co.uk/downloads/do-it-yourself-diy-shortcodes/

It's actually

https://www.oik-plugins.co.uk/?p=6015

The problem is due to Easy Digital Downloads being deactivated by oik-unloader.php

Support PHP 8.1 and PHP 8.2

Update code to run without problems in PHP 8.1 and 8.2

See bobbingwide/bobbingwide#103

Create [active_plugins] shortcode / block

Using oik-loader and oik-unloader in cwiccer.com I was able to improve or worsen the performance of a post or page by reducing the number of activated plugins to those essential for delivering the post or page.
Note:The logic isn't specific to single posts, but it's a lot easier to work on a single post than it is to work on an archive.

The admin interface for oik-unloader is better than the knocked up version for oik-loader but it could be improved significantly were it incorporated into the editor for individual posts and pages.

Requirement

• Easy to use UI for controlling activation or deactivation of plugins per URL
• Ability to select from active plugins and inactive ( but installed ) plugins
• Ability to override network activated plugins

Proposed solution

• Implement in oik-unloader - this already contains oik shared library logic.
• Merge oik-loader into oik-unloader
• Separate oik-loader logic for plugins and blocks into a separate module / plugin
• Automatic rebuild of the oik-loader and oik-unloader CSV file(s) on post update
• Develop an oik-unloader/active-plugins block
• Delivered as server side rendered
• Implement initial logic to display the [active_plugins] as a shortcode.

Can the output be altered depending on the URL's requester?

Are there times when the output from a plugin may not be necessary?

Questions:

• Are there situations where the same URL can be requested in different ways and the results could be adjusted to cater for the requester without adversely affecting the requester's experience?

Answer: Yes, I believe there are.

Question: And would the site be faster if we made this adjustment?
Answer: Yes, it could be... But cacheing is a consideration.

Fatal error attempting to activate multiple ACF field groups

Similar to bobbingwide/oik-loader#19, oik-unloader produces a Fatal error when the post query parm is an array.

/oikcom/wp-admin/edit.phps=
Fatal error: Uncaught TypeError: Illegal offset type in isset or empty in C:\apache\htdocs\oikcom\wp-content\mu-plugins\oik-unloader-mu.php:178 
Stack trace: 
#0 C:\apache\htdocs\oikcom\wp-content\mu-plugins\oik-unloader-mu.php(52): oik_unloader_mu_query_plugins(Array, Array) #1 C:\apache\htdocs\oikcom\wp-content\mu-plugins\oik-unloader-mu.php(31): oik_unloader_mu_loaded() 
#2 C:\apache\htdocs\oikcom\wp-settings.php(378): include_once('C:\\apache\\htdoc...') 
#3 C:\apache\htdocs\oikcom\wp-config.php(89): require_once('C:\\apache\\htdoc...') 
#4 C:\apache\htdocs\oikcom\wp-load.php(50): require_once('C:\\apache\\htdoc...') 
#5 C:\apache\htdocs\oikcom\wp-admin\admin.php(34): require_once('C:\\apache\\htdoc...') 
#6 C:\apache\htdocs\oikcom\wp-admin\edit.php(10): require_once('C:\\apache\\htdoc...') 
#7 {main} thrown in C:\apache\htdocs\oikcom\wp-content\mu-plugins\oik-unloader-mu.php on line 178

Test oik-unloader performance improvements on live sites

oik-unloader v0.0.1 is now available. I'm going to test it on a number of sites and collate the results.

• Run Lighthouse before
• Run Lighthouse after installing oik-unloader
• Run Lighthouse after deactivating plugins
• I'll also run slog for each stage

Originally posted by @bobbingwide in #1 (comment)

Implement a quick and dirty plugin unloader for performance improvements

Background

• Users install and activate plugins in order to provide additional functionality
• These plugins can slow the site down because:
  • They add processing in the server
  • They add processing in the browser
• It's often the case that for some URLs this work is unnecessary; the URL would work correctly even if the plugin is not active.
• We need a way to make the website faster while still providing the required functionality where it's needed.

Observations & assumptions

• Some websites are structured so that certain plugins can be deactivated on specific pages / URLs
• By not activating a plugin on these pages / URLs we can improve the performance of both the server and browser
• The main problem with deactivating a plugin is when it's definitely needed some of the time.
  eg WooCommerce is needed for shop/store, product display, product category display etc.
• It's probably just as easy to deactivate a plugin as it is to activate one

Requirement

• Fast server side processing for reduced Time To First Byte
• Fast loading in the browser
• Reduce number of bytes returned to the browser
• Reduce number of files to load
• Reduce JavaScript processing
• Highly configurable
• Should not affect cacheing

Proposed solution

Load the required plugins only

• Implement a WordPress Must Use plugin that will
• determine which plugins can be dynamically deactivated
• for a particular subset of URLs
• Implement a filter hook for the option_active_plugin filter to remove these plugins from list of plugins to activate

Administration

• Provide an admin interface to allow the plugins to be deactivated to be selected
• Allow the MU logic to be enabled and disabled

Considerations

• It will require an admin interface to allow the advanced user / developer to choose which plugins to deactivate for each particular URL.
• The interface will need to cater for different forms of archive URL.
• Whether or not the configuration is stored in the database or a flat file is to be determined.
• For ease of implementation a flat file will do the job initially.
• The logic will be a simpler version of the oik-loader plugin, performed in reverse; it will remove plugins from the active_plugins array rather than add them.
• The plugin should be a standalone solution; not dependent on other plugins or logic in the theme.

Cater for Network Activated plugins in WordPress Multi Site networks

When I looked at the plugins list in oik-plugins.uk I noticed that I was only offered a subset of plugins to deactivate.
For the prototype ( oik-unloader v0.0.1 )

• I hadn't implemented any code to intercept the sitewide active plugins filter
• nor written any code to list the Network activated plugins

I realise that there are some Network Activated plugins that I'd like to deactivate.

Requirement

• Support deactivation of Network Activated plugins

Workaround

• Network Deactivate a plugin and re-activate it for each site that does need it for at least something.

Notes

While there are some plugins that can only be Network Activated in a Multi Site network, it should still be possible to deactivate them for selected site URLs. It would be as if the plugin wasn't activated at all.

Cannot insert active-plugins block with supports.multiple set to false if it's already in the inactive widgets group

This looks like a Gutenberg bug to me.