Here’s one that many people are likely using a variation of the same functionality, but useful nonetheless. This is the autoloader that I use in most of the plugins that I create.

Edit: as pointed out by Francis Santerre on the Advanced WordPress group on Facebook, this snippet does not follow WordPress standards when it comes to file naming conventions. Personally, I’m not a fan of using the “class-” keyword to preface my class files as it would cause nearly every file to include it (and it doesn’t really affect code quality or WordPress plugin repo submissions), but it’s certainly worth mentioning. Francis has also included a link to his autoloader that he uses on his projects.

My autoloader:

<?php
if ( ! defined( 'ABSPATH' ) ) { exit; }

function example_autoload( $classname ) {
    $class     = str_replace( '\\', DIRECTORY_SEPARATOR, str_replace( '_', '-', strtolower($classname) ) );
    $file_path = WP_PLUGIN_DIR . DIRECTORY_SEPARATOR . $class . '.php';
    if ( file_exists( $file_path ) ) {
        require_once $file_path;
    }
}

spl_autoload_register('example_autoload');

To use this, drop it somewhere within your plugin. Usually, I include this within its own file and require it at the beginning of the main plugin file.

For your classes to utilize it correctly, your namespaces should look something like this:

// Filename: wp-content/plugins/example-plugin/class-name.php
namespace Example_Plugin\Class_Name;

Why autoloaders? It saves a hell of a lot of work in using require_once everywhere. Instead of manually requiring all the files you need, you can simply include the autoloader once, and call the namespaced classes that you need.

Have a snippet to share?

Submit your snippet!

Today’s code snippet is in the form of a shell script, allowing you to scrape WordPress plugin repository search results. I had reservations about releasing this because it can certainly be used in excess, so please be responsible with it as to not slam the repo to death.

#!/bin/bash
echo "Name, URL, Slug"
IFS=$'\n'       # make newlines the only separator
for j in `curl https://wordpress.org/plugins/search.php?page=[1-12]\&q=search+term | grep '<h4>.*</h4>'`

do
echo -n "$j" | awk 'BEGIN { FS = ">" } ; { print $3 }' | awk 'BEGIN { FS = "<" } ; { print $1 }' | sed 's/\&amp\;/\&/g' | tr -d "\n"
echo -n ,
echo -n "$j" | awk 'BEGIN { FS = "\"" } ; { print $2 }' | tr -d "\n"
echo -n ,
echo -n "$j" | awk 'BEGIN { FS = "\"" } ; { print $2 }' | awk 'BEGIN { FS = "\/" } ; { print $5 }' | tr -d "\n"
echo ""
done

Drop that in a file named WHATEVER.sh and run it on either MacOS or Linux, and it should correctly output data related to each of the plugins matching the search term. Of course, change the page range as well as the search term on line 4.

For more daily code snippets, feel free to subscribe below the post.

Not too long ago, I had a request through my contact form, regarding additional admin-ajax.php requests that currently are not covered by Heartbeat Control (since Heartbeat Control is meant to stop heartbeat requests, not AJAX requests). The requests he was referring to were caused by his cart fragments being updated and wanted them to stop.

Note: This will stop your cart items from being updated live on the page when adding an item to the cart. The items will be added successfully, but won’t update until the next page load.

add_action( 'wp_print_scripts', 'nuke_cart_fragments', 100 );

function nuke_cart_fragments() {
    wp_dequeue_script( 'wc-cart-fragments' );

    return true;
}

Once again, notice that the entire script is de-queued. See the above note for the consequences of doing this.