Tags give the ability to mark specific points in history as being important
  • 0.5   Widget Bonus

    Advanced Hooks Enable Minimal Code

    Building on the autoloader, the files are loaded automatically but by using dynamic hooks and filters with a few conditional checks where it isn't possible to use a dynamic hook.

    This allows for the code to be well abstracted with the least amount of code on a given page load.

    Advantages

    • Class based files are automatically loaded so you don't have to check if a class exists before loading it
    • Code is extremely simple
    • Even bigger gains in efficiency over the previous autoload method
    • Continues to encourage properly abstracted code which can improve testability and keep code more streamlined
    • Ensures JS and CSS files are loaded only when needed with the fewest conditional statements to reduce potential for code conflict and logic errors.

    Disadvantages

    • Requires planning and research
    • Not all dynamic hooks are documented
    • Not all dynamic hooks are intended to be used (they aren't being used for this example plugin so it requires some additional work arounds)

    Test Notes

    Compared to all previous versions this is the most efficient loading method. On any given page load no extraneous files are loaded, but when needed the files are automatically loaded with minimal conditional logic.

    The scripts and styles are loaded only on the intended pages.

    With the reduced loading, average page load speeds and page size is dramatically improved. While much of this size and time is intentionally added through a loop, it is intended to simulate load in a medium complex plugin.

    Because some hooks and filters do not have dynamic equivalents some code has to be added with conditional logic. With care, even this code can be minimized so it is run as seldom as possible.

    There are still some ways the code can be improved. DRY code, views, small units, and other improvements can always be used. The goal is not perfect code, but continually perfecting code.

    Bonus!

    All the above is the exact same as version 0.4. This adds a widget. The only trick is the widget is done by putting the form and widget method content into separate classes so that code is only loaded when it's actually used. While the content of this widget is really simple so there are no gains, most plugins have some complicated code to handle this. It's a bonus because it's not using hooks for any of it, just a nice little extra.

  • 0.4   Advanced Hooks
    76cd2bbb · Switch to advanced hooks ·

    Advanced Hooks Enable Minimal Code

    Building on the autoloader, the files are loaded automatically but by using dynamic hooks and filters with a few conditional checks where it isn't possible to use a dynamic hook.

    This allows for the code to be well abstracted with the least amount of code on a given page load.

    Advantages

    • Class based files are automatically loaded so you don't have to check if a class exists before loading it
    • Code is extremely simple
    • Even bigger gains in efficiency over the previous autoload method
    • Continues to encourage properly abstracted code which can improve testability and keep code more streamlined
    • Ensures JS and CSS files are loaded only when needed with the fewest conditional statements to reduce potential for code conflict and logic errors.

    Disadvantages

    • Requires planning and research
    • Not all dynamic hooks are documented
    • Not all dynamic hooks are intended to be used (they aren't being used for this example plugin so it requires some additional work arounds)

    Test Notes

    Compared to all previous versions this is the most efficient loading method. On any given page load no extraneous files are loaded, but when needed the files are automatically loaded with minimal conditional logic.

    The scripts and styles are loaded only on the intended pages.

    With the reduced loading, average page load speeds and page size is dramatically improved. While much of this size and time is intentionally added through a loop, it is intended to simulate load in a medium complex plugin.

    Because some hooks and filters do not have dynamic equivalents some code has to be added with conditional logic. With care, even this code can be minimized so it is run as seldom as possible.

    There are still some ways the code can be improved. DRY code, views, small units, and other improvements can always be used. The goal is not perfect code, but continually perfecting code.

  • 0.3   Autoloader

    Files Loaded Automatically as Needed

    This is an advanced method that requires classes to use. Instead of requiring files manually they are required automatically whenever a given class is invoked. Because it does require classes, many developers never use or even learn about this method of loading files but it can have significant gains with minimal effort, especially if code is already abstracted correctly and using an OOP approach.

    There are several ways to setup the autoloader. The basic approach used here is to compare to an array using in_array. Other methods include having a library or even using file_exists to check if the file needed is in the folder.

    One limit is that files need to be abstracted and named correctly. The class has to be part of the file name and in general the file should contain only the one class.

    More complex plugins may have the class files broken into multiple folders. This method can still work but may require more than one library or methods based on the class name (for example include admin in the class names in the admin folder) to require files from the correct folder.

    Advantages

    • Class based files are automatically loaded so you don't have to check if a class exists before loading it
    • Code is extremely simple
    • Huge gains in efficiency and prepares for even bigger gains
    • Encourages properly abstracted code which can improve testability and keep code more streamlined

    Disadvantages

    • Since this is not yet using the advanced hooks the code still has high potential for conflict. This is especially true with JS and CSS because those files are always being loaded

    Test Notes

    Compared to the 0.1 Least Efficient and 0.1 is_admin the number of HTML comments generated by the WCDC_Advanced_Hooks objects are reduced even more. On a given page load in the dashboard you will see a reduction to 5,000 HTML comments, nearly half. The front end gets an another 1000 fewer to 4000 HTML comments, which is over half.

    While this does mean any given plugin would see some very big gains, it should be noted that there is still a lot of room for improvement, especially considering the css and js is still being loaded everywhere.

    At this point we can start adding a lot of conditional statements to control loading code. This works and can solve the code conflict potential, but using advanced hooks instead reduces the need for complex conditional code which can break and be difficult to diagnose. The next step will see the biggest improvements and solve the conflict issues, at least as much as we can from our plugin.

  • 0.2   is_admin

    Files Loaded based on is_admin

    Generally this is the first efficiency improvement developers learn. If a file is needed for the admin part of the site is_admin() is used to control and load those files verses files that are loaded on all pages and files that are loaded only on the front end of the site. Depending on the plugin, this can have big improvements in efficiency over loading all the files all the time.

    Advantages

    • It is an easy improvement to implement and can make a big difference, potentially 50% or better reduction in files loaded from the plugin on any given page load.

    Disadvantages

    • It will still become a fat, bloated pig. The plugin may be a simple tool but if it grows at all then the code will grow which makes it big and slow
    • It still has high potential for conflict. This is especially true with JS and CSS because those files are always being loaded
    • It can still make refactoring more difficult
    • It can still become extremely difficult to test, especially as it grows into an unmanageable pile of spaghetti
    • It gives a false sense of confidence in the efficiency of the code

    Test Notes

    Compared to the 0.1 Least Efficient plugin the number of HTML comments generated by the WCDC_Advanced_Hooks objects are reduced. On a given page load in the dashboard you will see a reduction of 1,000 HTML comments. The front end gets an even bigger reduction down to 5000 HTML comments, which is nearly half. For some plugins this simple change could make a huge difference in the amount of code loaded on any given page, which means big improvements in efficiency.

    However, notice how any page using the p.description class is still having the styles overridden to match the plugin style because the admin.css file is still being loaded on every page of the dashboard.

    Also note that every single admin page still triggers the admin.js and post-meta.js alert messages.

    This means there is a huge potential for plugin conflict and extremely inefficient loading of scripts and styles.

  • 0.1   Least Efficient

    All Files Loaded

    This is the initial state. Many developers start with their code in this state and never move beyond it. All files are loaded all the time.

    Advantages

    • The code is always there so you don't have to worry about making sure a file is required before attempting to use it
    • This approach works for static functions or object oriented programing methods equally well
    • Files can be abstracted or condensed so it doesn't require any particular planning

    Disadvantages

    • It will become a fat, bloated pig. The plugin may be a simple tool but if it grows at all then the code will grow which makes it big and slow
    • It has high potential for conflict. This is especially true with JS and CSS because those files are always being loaded
    • It can make refactoring more difficult
    • It can become extremely difficult to test, especially as it grows into an unmanageable pile of spaghetti

    Test Notes

    Each file that could be simplified and many methods that can be loaded less often include the WCDC_Advanced_Hooks object which will output HTML comments in the page footer. This is to help demonstrate how weighty the plugin can become. Notice how thousands and thousands (about 9,000 to be specific) of comments are output on every single page load.

    Also notice how any page using the p.description class is having the styles overridden to match the plugin style.

    Finally, and most noticeably, note that every single admin page triggers the admin.js and post-meta.js alert messages. In real life this isn't something a plugin would do, but it serves to show just how annoying it is to load scripts on every single admin page when they aren't needed.