Author: John Alarcon

John Alarcon is a prolific creator of things. In late 2018, his attention turned to ClassicPress and, with more than a decade of WP experience already under his belt, he almost immediately began releasing plugins, articles, and tutorials created specifically for ClassicPress, solidifying his commitment to the project and establishing a role as a respected leader in the space. You can find John all over the web under the name "CodePotent".

Resolve Plugin Conflicts without Deactivating All ClassicPress Plugins

A common recommendation in the WordPress world when you’re having issues with a plugin is to disable all plugins. Don’t do it!

While we can employ best practices in our own code, we have no control over what other developers are doing. As a result, plugin conflicts will sometimes happen. What’s more, another developer’s plugin might be causing the issue, while it is my plugin that actually exhibits the symptoms.

When these types of issues arise, the most common thing a developer will recommend is to deactivate all your plugins, set your theme to TwentyWhatever, then try their plugin again. While this has been the standard advice for a decade, this is often a waste of time. There’s a better way.

About Deactivating Plugins

Consider what happens when you deactivate a plugin. Do you actually know? Yeah, me neither. Other than the plugin no longer working, it may not be clear what has changed. Were options deleted? Were settings lost? Is the site still working? The answer is: it’s up to each and every plugin developer, so, who knows.

Unless you dig into the code of each plugin, you never really know what may happen when you deactivate them. You just might get stuck having to reconfigure a bunch of plugins. This is why it is preferable to not deactivate all plugins as a first course of action – you just don’t know what may be lost. So, instead of deactivating all plugins at once, I take a more thoughtful approach to make the best use of my time.

Conflict Resolution Plan

The steps listed here will seem logical once you’ve gone through them. Indeed, they will probably even seem obvious once they’re pointed out.

  1. Do not disable any plugins or change the theme.
  2. Make a shortlist of any plugins that you think might be related to the conflict.
  3. Deactivate the first plugin on your shortlist and check to see if the conflict persists.

Does the conflict persist?

If so, reactivate that plugin and then repeat (step 3) with each plugin on your shortlist.

Is the conflict resolved?

If so, you now know which plugin is conflicting. There is usually no need to deactivate any remaining plugins.

If processing through your shortlist of suspected plugins does not reveal the conflict, start at the top of the main plugin list and repeat the process – deactivate, check for conflict, reactivate – until you find the conflicting plugin.

Wrapping Up

Deactivating all plugins in one quick action can be tempting when plugin conflicts arise, but, it’s often unnecessary. Without knowing exactly what every plugin does upon activation, it is very much a “shot in the dark” that mass-deactivation won’t actually create more work. Your gut instinct (which then becomes your shortlist) is often a very quick way to conflict resolution, and, if not, you have a more systematic approach to determine just where that conflict lies.

What do you think?

Are you in support of a thoughtful approach, or would you just deactivate them all and hope for the best? Have you ever had anything unexpected happen when you deactivated a plugin? I have my own opinion about what a plugin should do upon activation, but, what do you think? I’d love to hear your thoughts – let me know in the comments!

This tutorial has been provided by John Alarcon and was originally published on CodePotent.com. The original post can be found here.

Create a Static Widget in the ClassicPress Dashboard

A static dashboard widget is a great way to share information, important links, or action items with your clients when you hand-off a site. Very little code – very high user impact!

When handing off a ClassicPress website to a client, do you provide them with information or links to get them off to a good start? A static widget in the dashboard – just like the one pictured below – is a great solution for this! Wouldn’t it be cool to add something like this to the client’s dashboard? Well, we’re going to build it shortly.

Depiction of a Static Text Widget

The image above depicts what we’ll be creating here today. However, before moving on, let’s make a few quick distinctions about widgets, shall we?

Static Widgets vs Dynamic Widgets

Whereas a dynamic widget shows content that changes over time, such as latest posts or recent comments, a static widget shows the same content always. In the image above, the widget is simply inviting the user (ie, your client) to contact their project manager.

Of course, this is just a simple example of how you might use a static widget. Indeed, you might want to include your business address, hours of operation, helpful links, payment info, or any of those other things that you might typically include in a hand-off document.

Dashboard Widgets vs Front-end Widgets

One last distinction to make before starting this project is the difference between dashboard widgets and front-end widgets. It’s simple, but, bears repeating.

Dashboard widgets will appear in the main dashboard view. The site admin can collapse and expand the widget, as well as move it to a new position, or even hide it altogether.

Front-end widgets are those that are displayed to visitors on your site. Visitors cannot usually expand or collapse front-end widgets (although there are exceptions,) but, they will not likely be able to move or hide the widget content.

Where to Place the Code?

If you’re coming from the WordPress space, you will be familiar with placing code into your theme’s functions.php file. This is the “old school, quick ‘n dirty” way, and is no longer recommended. The code in this tutorial should be placed into an utility plugin. If your site already has a utility plugin, great, you can just add the code below to that plugin. If you don’t yet have such a plugin, go build one. I’ll wait for you here.

The Process of Creating a Static Widget

To create a dashboard widget, three objectives must be achieved. The three objectives are to:

  1. create a function that prints the widget content, and
  2. create a function that registers the new widget in the system, and
  3. use an action hook to specify when the widget should be registered.

Let’s work through these objectives now. Move through the following steps, adding the code examples to your utility plugin. There’s no need to make customizations as you go – let’s just get it working first and fine-tune later.

1. Print the Widget Content

This simple function populates the widget with your content. As you can see, PHP tags are used in the function to allow for neater HTML markup. Add the code to your utility plugin.

function codepotent_display_static_dashboard_widget() {
    ?>
 
    <h1>Hey, it worked!</h1>
 
    <?php
}

2. Register the New Widget

This function registers the widget in the system by calling the wp_add_dashboard_widget function with several arguments. These arguments tell the system your preferred id and title for the widget, as well as the name of the function that will ultimately output the widget content (from step 1 above.) Add the code to your utility plugin.

function codepotent_register_static_dashboard_widget() {
    wp_add_dashboard_widget(
        'my_static_dashboard_widget', // your own custom widget id
        'My Widget', // the widget box title
        'codepotent_display_static_dashboard_widget' // function that displays content
        );
}

3. Hook the New Widget in at the Right Time

In case you didn’t notice, those functions created in Steps 1 & 2 aren’t actually called anywhere. Yet. If they aren’t called, they can’t run. That’s where an action hook comes into play. The action hook tells the system exactly when to run the function that registers your widget, which, in turn, tells the system which function to use to display the content. Now, that was a lot of words, but, it really just boils down to a single line of code that says “run this function during the wp_dashboard_setup action.” Add the line to your utility plugin.

add_action('wp_dashboard_setup', 'codepotent_register_static_dashboard_widget');

Verify your Work

With the above objectives out of the way, take a moment to verify your work. Head over to the dashboard and find that you now have a new widget showing in all its glory. Collapse it. Expand it. Move it around. Hide it. It should work just like every other widget in the dashboard.

Initial Static Text Widget

Add Meaningful Content

With the widget now displaying in the dashboard, you can revisit the display function (from Step 1) and flesh it out with whatever content you like. In the final example below, I’ve combined the code from above and added some additional markup to make the widget look like the original example image.

// Step 1
function codepotent_display_static_dashboard_widget() {
    ?>
    <div style="display:grid;justify-content:space-between;grid-template-columns:repeat(auto-fit,minmax(48%,1fr));grid-template-rows:1fr;grid-gap:20px;">
        <div>
            <img src="https://codepotent.com/wp-content/uploads/2019/07/kelly-marks-avatar.jpg" style="border:1px solid #ccc;padding:2px;">
        </div>
        <div>
            <h2>Kelly Marks</h2>
            Your project manager, <strong>Kelly Marks</strong>, is committed to your success! If you need anything at all, drop Kelly a line!
            <ul>
                <li>(123) 456-7890 x 123</li>
                <li><a href="#">[email protected]</a></li>
            </ul>
        </div>
    </div>
    <?php
}
 
// Step 2
function codepotent_register_static_dashboard_widget() {
    wp_add_dashboard_widget(
        'my_static_dashboard_widget', // your own custom widget id
        'My Widget', // the widget box title
        'codepotent_display_static_dashboard_widget' // function that displays content
        );
}
 
// Step 3
add_action('wp_dashboard_setup', 'codepotent_register_static_dashboard_widget');

Extra Credit

The example above will show the widget to anyone who has access to the main dashboard. Can you think of a way to show the widget to only admin users? Or, how about limiting it to just a single user? I think you can figure it out!

Wrapping Up

Adding a static widget to the ClassicPress dashboard is actually quite easy. There’s no need to add a whole plugin just to show some information in the dashboard. With very little work, you can create your own great-looking dashboard widgets and show your clients that their site is on your mind. Add text, links, images – or anything else that might be helpful to your clients!

What do you think?

Did you realize dashboard widgets were so easy to create? Have you been using a plugin and are going to switch to this method instead? What other things might you include in a dashboard widget? I’d love to hear your thoughts – let me know in the comments!

This tutorial has been provided by John Alarcon and was originally published on CodePotent.com. The original post can be found here.

Convert a Code Snip into a ClassicPress Utility Plugin

A beginner’s guide to converting procedural PHP into namespaced or object-oriented PHP – with a very understandable apples-to-apples comparison! This will be a primer for a more in-depth article on using namespacing in ClassicPress plugins.

The Tutorial

If you’re like most, you will have searched the web and found code-snips for your ClassicPress website. Let’s say you wanted to change the footer text in the dashboard. After a quick search, you find the following code-snip with instructions to place it into your theme’s functions.php file.

function custom_footer_text($text) {
    return 'The best debugging tool is a good night\'s sleep.';
}
add_filter('admin_footer_text', 'custom_footer_text');

First off, code-snips should go into a utility plugin, rather than your theme’s functions.php file. This is achieved by adding a short comment at the top. Additionally, the function name is prefixed to prevent code collisions. Here’s what that looks like.

<?php
/**
* Plugin Name: My Utility
* Description: A safe place for code-snips.
*
* Note: save file to /wp-content/plugins/my-utility/my-utility.php 
*/
function yourownprefix_custom_footer_text($text) {
    return 'The best debugging tool is a good night\'s sleep.';
}
add_filter('admin_footer_text', 'yourownprefix_custom_footer_text');

Great! The code-snip is now held safely in a utility plugin that can be activated and deactivated in your dashboard. The above example is written in basic, procedural PHP and, because the function name has a prefix, it is nicely isolated from clashing with other code in the system.

Prefixing your code in this way is usually enough to prevent collisions, so, if that’s all you’re after, you can stop here. However, also note that, as you find new code snips, you can add them to this same utility plugin; there’s no need to create another. Now, git ta steppin’, … the rest of us want to namespace this thing! So, let’s!

<?php
/**
* Plugin Name: My Utility
* Description: A safe place for code-snips.
*
* Note: save file to /wp-content/plugins/my-utility/my-utility.php 
*/ 
namespace YourOwnPrefix\Utility;
function custom_footer_text($text) {
    return 'The best debugging tool is a good night\'s sleep.';
}
add_filter('admin_footer_text', __NAMESPACE__.'\custom_footer_text');

As you can see, the big difference is that the prefix is used in the namespace instead of the function name, and the __NAMESPACE__ magic constant is used when hooking the function into ClassicPress. This is handy when your plugin grows to contain a lot of functions; you can change the namespace in one single place, instead of changing a bunch of prefixes. Namespacing is the actual built-in PHP method for isolating, or encapsulating, our code, but, more often, you’ll see code being encapsulated with object-oriented PHP. Here’s that same code-snip as an object-oriented plugin.

<?php
/**
* Plugin Name: My Utility
* Description: A safe place for code-snips.
*
* Note: save file to /wp-content/plugins/my-utility/my-utility.php 
*/
class Yourownprefix_Utility {
    // Add your actions and filters to this method.
    public function __construct() {
        add_filter('admin_footer_text', [$this, 'custom_footer_text']);
    }
    public function custom_footer_text($text) {
        return 'The best debugging tool is a good night\'s sleep.';
    }
}
new Yourownprefix_Utility;

In the case of object-oriented PHP, you can simply use the __construct() (or similar initialization) method to hold your action and filter hooks. I quite like this style of keeping all the actions and filters together and is the method I tend to use most. And, the $this variable is extremely handy when you want to pass data back and forth between the various methods (functions) inside the class.

Wrapping Up

As you can see, a code-snip can be added to your ClassicPress site without having to add it to your theme’s functions.php file. Placing your code-snips into a utility plugin is a better practice and gives you a quick means of activating and deactivating all of them quickly. And, of course, there are various ways to encapsulate our code and achieve the exact same result. There’s no requirement to use one method or another. You decide. As long as you have at least used unique prefixes, as shown in the first plugin example, you can be reasonably sure your code will be safe from collisions…and safe from theme changes, too!

What do you think?

Was it helpful to see a simple code-snip converted into a plugin? Did it answer any questions to see that plugin converted into other styles of code? Do you have a preference over which style to write your code? I’m curious to hear your thoughts – let me know in the comments!

Note: the header comment used in the examples here was very basic. There are more fields that can be used.

This tutorial has been provided by John Alarcon and was originally published on CodePotent.com. The original post can be found here.