Why Your WordPress Plugin Should Have Almost Nothing In The Main Folder

As we continue to roll out our Store Locator Plus SaaS service built on top of WordPress as our application foundation we continually refine our plugin, theme, and API architecture.    One of the issues I noticed while testing performance and stability is how WordPress Core handles plugins.    Though WordPress caches plugin file headers there are a lot of cases where it re-reads the plugin directories.

What do I mean by “read the plugin directories”?

WordPress has a function named get_plugin_data().   Its purpose is simple.  Read the metadata for a plugin and return it in an array.   This is where things like a plugin name, version, an author come from when you look at the plugins page.

However that “simple” function does some notable things when it comes to file I/O.   For those of you that are not into mid-level computer operations, file I/O is one of the most time consuming operations you can perform in a server based application.   It tends to have minimal caching and is slow even on an SSD drive.   On old-school rotating disks the performance impact can be notable.

So what are those notable things?

It is best described by outlining the process it goes through when called from the get_plugins() function in WordPress Core.

  • Find the WordPress plugins directory (easy and fast)
  • Get the meta for every single file in that directory using PHP readdir and then…
    • skip over any hidden files
    • skip over any files that do not end with .php
    • store every single file name in that directory in an array
  • Now take that list of every single file and do this…
    • if it is not readable, skip it (most will be on most servers so no saving time here)
    • call the WP Core get_plugin_data() method above and store the “answers” in an array , to do THAT, we need to do THIS for all of those files
      • call WP Core get_file_data() which does this..
        • OPEN the file with PHP fopen
        • Read the first 8192 characters
        • CLOSE the file
        • Translate all newline and carriage returns
        • Run WordPress Core apply_filters()
        • Do some array manipulation
        • Do a bunch of regex stuff to match the strings WordPress likes to see in headers like “Plugin Name:” or “Version:” and store the matching strings in an array.
        • Return that array which is the “answers” (plugin metadata) that WordPress is interested in.
    • take that array and store it in the global $wp_plugins variable with the plugin base name as the key to the named array.

In other words it incurs a LOT of overhead for every file that exists in your plugin root directory.

Cache or No Cache

Thankfully viewing a plugin page tends to fetch that data from a cache.   The cache is a string stored in the WP database so a single data fetch and a quick parsing of what is likely a JSON string and you get your plugins page listing fairly quickly.   However caches do expire.

More important to this discussion is the fact that there are a LOT functions in the WordPress admin panel and cron jobs that explicitly skip the cache and update the plugin data.  This runs the entire routine noted above to do that.

Designing Better Plugins

If you care about the performance impact of your plugins on the entire WordPress environment in which it lives, and you SHOULD, then you may want to consider a “minimalist top directory approach” to designing your plugins.

Best Practices on the Plugin Developer Handbook mentions “Folder Structure” and shows an example of having something like this as your plugin file setup:

However they don’t get into the performance details of WHY you should have an includes directory and what goes in there.

In my opinion, EVERYTHING that is not the main plugin-name.php or uninstall.php file should go in the ./includes directory.  Preferably in class files named after the class, but that is a discussion for another blog post.

If possible you may even want to try making plugin-name.php as minimalist as possible with almost no code. Even though the fread in WordPress Core get_file_data() only grabs the first 8192 characters, most of that content is “garbage” that it will not process because it is not part of the /* … */ commentary it is interested in.   If you can get your main plugin-name.php file to be something like 4K because it only includes the header plus a require_once( ‘./includes/main-code-loader.php’); or something similar the memory consumption, regular expression parser and other elements used by get_file_data() will have less work to do.

No matter what your code design, it is going to have some performance impact on WordPress.   My guess is it will be especially notable on sites that have 3,987 plugins installed and are running an “inline” WordPress update.   Ever wonder why that latest version of your premium (not hosted in the WordPress Plugin Directory) plugins don’t show up?   It could be because WordPress spent all the time granted to a single PHP process reading the first 8K of 39,870 files because all those plugins had a dozen-or-so files in the root directory.

Help yourself and help others.  Put the bulk of your plugin code in the includes folder.  The WordPress community will thank you.

 

Wiring WordPress Media Uploader Into Your Web App

As predicted, the “premium” theme I purchased to make things happen on the HereMusic.Live site needs more tweaking.  Today I am diving into the proper way to wire the WordPress media uploader into a plugin after learning the theme not only cannot handle a media file with parenthesis in the name but it also is dropping the media title into the URL field on the form.  Ugh.

Most of the magic for the WordPress Media interface is managed via JavaScript.    I’m going to focus on the JavaScript portion of the code, assuming an app already has a basic form on an admin page that needs media uploaded and gets the URL put into a form element.   I’m also going to assume you know how to attach basic “on click do this” to an HTML element using jQuery or inline onClick methods.

Rip Out Thickbox

The old-school method of attaching to the WordPress media uploader was to tie into the Thickbox-driven media interface.   If you look into an existing WordPress plugin or theme and see the JavaScript littered with tb_show() and window.send_to_editor references there is a very good chance it is using the outdated Thickbox model.

I’m not sure where this model is breaking down on my WordPress 4.7 site but somehow the html parameter on the send_to_editor() call is only receiving a string containing the file title.

Time to rip it out and replace it with the thinner and generally better-designed wp.media model.  It was introduced eons ago (in modern web app terms) and should be the go-to method for implementing this feature.

Insert wp.media

As with many of the “black magic” features of WordPress, wp.media is not well documented on the new developer guides and function references.   Most of the knowledge we’ll need has to come from the “old” Codex wp.media pages.

The basic concept is simple:  When the user clicks the add button create a new wp.media JavaScript object and open it.

wp.media Details

We start by defining a media_frame variable in JavaScript at a global scope so we can make it a singleton; in essence don’t fire up a new popup wp.media form every time someone clicks the button.

Next we attach an anonymous function to the click event on the button that will do some general maintenance, set some properties for the wp.media object, and tell that object what we want to do when the user selects a file.   Remember that whether the user has just uploaded a new file or picked from an existing file the application considers this a ‘select’ action in either case.    The last step of this click function is to open the wp.media object which fires up the standard WordPress upload/select window.

Example Details

The initial implementation:

Always preventDefault() on these actions to prevent conflicts with other things that may be attached to the click event stack in  your web app or browser.

Check if the media_frame global variable is active.  If it is then our media form is open somewhere.   Re-open it (show it) and leave.  This cuts down on the overhead of re-creating the window object every time we click the button.

Create the wp.media object and attach it to the media_frame variable.  This is a single instance of the media selector.  Pass in some attributes for the window title, button label, and multiple selection options.   Later we’ll use localize_script() in the PHP side of the code so we have an app that is gettext() , and thus i18n/l10n, compatible.

Before we get into the frame  processing ,  grab a sibling field on the HTML form that contains the add button we clicked to fire up the form.  My example HTML form has an input text field with the class mea_box_upload_file where we put the URL for the file we are selecting.

The select is processed with an .on( ‘select’ … ) trigger.    When the user clicks the “Use This” button (our label for the select button) it will fire the anonymous function defined here.   The details of the file they selected is retrieve in the media_frame.state().get(‘selection’).first().toJSON() call.    I then use the variable I set earlier that points to my URL field on my HTML form and set the value to the file’s url property.

With all the triggers and properties set for the media window I can now open the media selector as the last step of the button click process.

 

Follow Up Feb 1 2017

Additional notes and a complete code example.

First – wp.media has a frames property where you can (should?) attach your active frame instead of managing it “by hand” within your JavaScript.

Second – return false from the function that you invoke the media from.   Depending on where you call your modal open() you may get the entire stack of media windows opening.  In my plugin I was getting my custom modal plus a default modal provided by WordPress on an admin setting page.

Third – I’ve refactored the default code you see on nearly EVERY example of doing the frame open where it first checks to see if the frame exists, if it does return frame.open() and if it does not do the setup then return frame.open().   Nearly every time you call the same method twice within a few lines of code it can be refactored to be more efficient.  That is included in my example.

New Example

This is from my Store Locator Plus code.    I use a block scope variable that I change every time a user clicks a button so I know which setting to update with the image URL the user selected.    This allows the on(‘select’) code for the window frame itself to remain static.  Better caching and code compression can happen with this setup.

The class the creates the HTML code.  Obviously a partial example as this web app uses all kinds of objects and inheritance to manage oft-repeated code segments.

 

JavaScript: wp.media

The Codex says… JavaScript Reference wp.media.

wp_enqueue_media()

This magic WordPress function will enqueue all of the JavaScript elements needed to work with the media uploader provided by WordPress core.

Needs to be fired in/after admin_enqueue_scripts in the call stack.

The Codex says… wp_enqueue_media() 

The Code Reference says… wp_enqueue_media().

Hacking WordPress – Articles About Coding Plugins and Themes

Recently I’ve begun building a music directory site.    I purchased a premium theme and the accompanying premium plugins.    Sadly, premium does not necessarily mean well-written.   Turns out this theme and the associate plugins do a few good things, look great on the surface and do a lot of really horrid things in the background.   If I were launching a personal site, like this bio blog, I’d not worry about it.   However the long term goal is to build a music directory that handles hundreds-of-thousands of page loads every month.   It needs to be fast without having to run it on IBM’s Watson to do so.

I’ve decided to fork the theme and the plugins and start hacking them into shape.    Coming soon will be the first in a series of “hacking WordPress” articles.   The first article will be about how to now load your plugin code on every single admin page on the site.

If you are writing WordPress Themes or plugins and have a question or an idea for a post, please let me know.   If I can’t answer the question myself I will try to find a guru that can.

 

Stop Loading Your Code On Every Admin Page

I see it every day.   It comes with the territory of supporting thousands of Store Locator Plus customers around the world.   We login to a customer’s site to find the reason our plugin is not working is because some other plugin is pissing their code all over our admin pages.

There is seldom, if ever, a reason that your plugin should be loading your code on my pages.   But it is far easier to load your code everywhere on every page.    It is far, far easier to write something like “if this is an admin page, load my code” than “if this is one of MY admin pages, load my code”.    Sadly it is really not much more work to do the second option and every single WordPress site your plugin runs on will be that  much faster.    Now if the other dozen plugins and the theme itself would be that smart WordPress sites everywhere would be a lot happier.

This video blog discusses how the plugin “HMLive Extensions” that I’ve forked and renamed to protect the guilty is “doing it wrong”.    It is loading a huge block of HTML code on EVERY SINGLE ADMIN PAGE then hiding it when it can with CSS trickery.  That only makes it slower and more bloated.

The take-aways from this video should be:

  • Use classes and object oriented programming techniques.
  • Do not use is_admin() by itself to decide whether or not to load your huge chunks of code.
  • Use class_exists() to test a class exists before defining it.
  • Use a simple array with slugs , in this case $_REQUEST[‘post_type’] variable values, to determine which admin pages to run your code on.

No this is not the “be-all-end-all” fix for this type of issue.    The posts and videos in this series are meant to be a general guide to shed some light on ways to improve code implementation and hopefully make your plugins and themes better citizens within WordPress.   Incur overhead only when needed and don’t stomp on other people’s code.

Some jQuery Foo I Learned While “Leveling Up” This Weekend

I am the first to admit that I got on the JavaScript bandwagon a little late.   I was a bit hesitant because of my work with government projects a half-decade ago.   When you work with the US Government you quickly forget the “best of” when coding web apps and instead use their default protocol of using “the oldest crap possible”.   I would not be surprised if they are still using Internet Explorer 6 as their go-to standard.   For the non-geeks, that is the equivalent of setting the standard vehicle fleet to a Ford Model T.  Sure, it is a car that runs on petroleum but it sure as hell isn’t going to get you and your family ANYWHERE safely.

Just 2 years ago I started adding some JavaScript to my locator web app.    It helped bring my 2013 app up to 2001 web interface standards.  A little.   Then I learned about jQuery, a library of features and functions that does a lot of the heavy lifting for you.   It is like going from sawing your own lumber from trees to going down to the lumber yard and picking up 2x4s to build your home.   Much easier.

The Slightly Newer But Old Way

Then I learned jQuery and many of the pre-built “nice to have frills” come shipped with WordPress Core.  What?!?!  Why do 90% of the plugins and themes, from which I snarf a lot of code to make it look like I know what I’m doing, not know this?    During the past year I’ve been learning a lot of new code tricks from my friends at DevriX and teaching myself more by learning new things like advanced jQuery trickery.

New Themes

So now, way down here after my rambling, are my notes on what I learned about jQuery this weekend where I felt myself “level up” on that particular skill.

As you read these tips you’ll notice that I use jQuery “long form” vs. $ which is common practice. I have a good reason for that; lots of WordPress plugins are poorly written and assign no-conflict mode with the $ shorthand improperly and break my application.  When you have 15,000 installations you tend to do things “long form but less prone to others breaking it”.  When I write jQuery… in my examples you most likely see $ instead in “real world” code.

Cache Your Queries

When you want to work with an element on a page you can use jQuery to help find the element and make your changes.    You tend to see stuff like this:

That is not very efficient. This jQuery( <selector> ) reads the entire web page each time and makes a whole lot of JavaScript code run EVERY TIME it is processed UNLESS <selector> is a JavaScript object instead of a string.   Lots of code running = slower web apps.

Instead make jQuery “cache” the objects that it finds the first time around by assigning the selection to a variable.  The “lots of code” runs once in the example here and in the examples below it will create a subset of elements to look through versus your entire web page stack of elements.

In this mode jQuery reads the entire web page ONCE and stores the matching objects in the_dash.   It then can quickly modify just those elements at requested.

Extend Your Cached Queries

Now that you are caching your queries and making your site visitor’s laptop or mobile device work a lot less , which believe it or not can extend their battery life by a whole microsecond, you can extend those caches without doing the “whole read the page thing” again.

Here is how I used to find the sidebar, modify it, then find all the images in the sidebar and hide them:

Nice short code which is a little easier, maybe, to read, but this is horribly inefficient in the “350px” mode.   In this mode JavaScript is reading the entire web page, seeking the sidebar, and changing it.   Then it goes and reads the entire web page again, finds the sidebar, then reads everything in the sidebar and finds the images and changes them.    That is a lot of JavaScript code executing.  Executing code takes time. Time is money as they say.

And here is the far more efficient version:

In this mode it reads the entire page once, and keeps track of what it found in “help_sidebar”.   It then changes what it found without searching again because jQuery is working on help_sidebar which is an object.  If that were all we were doing with it  this would actually be a bit slower since we take the overhead of storing the object with an assigned memory pointer (variable assignment) as noted above.

However when we do the second “change all the images inside that object” we gain back that lost microsecond one-hundred fold.     The second jQuery(help_images)… that is used to modify the image within no longer has to search the entire web page.

BUT… there was a problem.    How do you add “extended selectors” to the cached jQuery?

Above we had ‘.dashboard-aside-secondary > IMG’  to find our images.  This is MORE than just the ‘.dashboard-aside-secondary‘ that we stored in our cache.    Uggh.

Find() To The Rescue

Luckily jQuery has a number of methods that extend your selectors and help you traverse the DOM.  You can find this under the Traversing jQuery docs page.

find() can take any selector or OBJECT, like the one we have containing our sidebar, and then look for any elements inside of it.   As a jQuery padawan I had only ever seen this used to find stuff within the entire DOM.   Being a slow-learner it never dawned on me that this could be extended to ANY part of the DOM not just the entire DOM.

jQuery(help_sidebar).find(‘IMG’) looks within the sidebar only to find images.  This is far faster than reading the entire page.   It then changes those images within.

Children() Is One Level of Find()

One of the incorrect paths I went down, but is very useful to know, is the use of children() in jQuery.    This finds only the matching elements just one level deep in the object stack.   Since you’ve read this far you are a code geek like me so I know that you understand that most web pages are many levels of nested elements and often you want something “deeper down” where you need your great-great-great grandson to be involved.    However there are plenty of cases where I can utilize children() to impact just the next level of menu divs, for example.

Summary

Truly understanding how jQuery selectors and “caching”works and how to modify those cached selections with the jQuery traversal methods is going to bring the efficiency of my apps up to a whole new level.    It may only save a half-second of processing time per page interaction, but it all adds up when you have 15,000 websites hosting millions of page views every day.

For my fellow code geeks out there I hope you learned something new and I’ve given you a shortcut to reaching the next level of your jQuery skill.s

Sidebar: Why “caching” in quotes? Because this doesn’t seem like caching to me but rather object-passing, but maybe I’m missing something I’ll learn at level 3.

%d bloggers like this: