Category: PHP

This post is part of the ClassicPress Plugin Development series in which I am going to look at both best practice for developing plugins and how I approach some requirements as well as some of the functions I commonly use.

jQuery itself is automatically loaded by ClassicPress so we don’t need to do anything to load this ourselves in a plugin; it is just our own jQuery script which we need to register and enqueue. There is two ways in which scripts can be loaded in a plugin; I will cover them both, but will note first of all that I typically use the second approach; there is an argument that the first approach is the “correct” one.

The first thing to do when you are loading a script is to register it. This is done using the wp_register_script function which ClassicPress provides.

Continue reading “ClassicPress Plugin Development: Loading Back-End Scripts”

This post is part of the ClassicPress Plugin Development series in which I am going to look at both best practice for developing plugins and how I approach some requirements as well as some of the functions I commonly use.

jQuery itself is automatically loaded by ClassicPress so we don’t need to do anything to load this ourselves in a plugin; it is just our own jQuery script which we need to register and enqueue. There is two ways in which scripts can be loaded in a plugin; I will cover them both, but will note first of all that I typically use the second approach; there is an argument that the first approach is the “correct” one.

The first thing to do when you are loading a script is to register it. This is done using the wp_register_script function which ClassicPress provides.

Continue reading “ClassicPress Plugin Development: Loading Front-End Scripts”

This post is part of the ClassicPress Plugin Development series in which I am going to look at both best practice for developing plugins and how I approach some requirements as well as some of the functions I commonly use.

All of the plugins I have written have a settings page in the admin dashboard, either for settings to be configured or for instructions on how to use the plugin. I often have an admin stylesheet which needs to be loaded on the settings page. There is two ways in which stylesheets can be loaded in a plugin; I will cover them both, but will note first of all that I typically use the second approach. There is an argument that the first approach is the “correct” one.

The first thing to do when you are loading a stylesheet is to register it. This is done using the wp_register_style function which ClassicPress provides.

Continue reading “ClassicPress Plugin Development: Loading Back-End Stylesheets”

This post is part of the ClassicPress Plugin Development series in which I am going to look at both best practice for developing plugins and how I approach some requirements as well as some of the functions I commonly use.

Virtually all of the plugins I have written have output to the front end of a site, usually through use of shortcodes. As there is front end output, I have needed to create a stylesheet which means the plugin needs to load it. There is two ways in which stylesheets can be loaded in a plugin; I will cover them both, but will note first of all that I typically use the second approach. There is an argument that the first approach is the “correct” one.

The first thing to do when you are loading a stylesheet is to register it. This is done using the wp_register_style function which ClassicPress provides.

Continue reading “ClassicPress Plugin Development: Loading Front-End Stylesheets”

This post is part of the ClassicPress Plugin Development series in which I am going to look at both best practice for developing plugins and how I approach some requirements as well as some of the functions I commonly use.

Before you start developing a plugin, I’d recommend deciding on the plugin structure you want to use. At the simplest level, a plugin only actually requires the file which holds enough code for the plugin and the folder it sits within, but in reality you will have other files which are needed as well, such as style sheets, language files, images and so on.

Planning a structure for the plugin will ensure your plugin files are well organised which will make it easier to work with both now and again in future.

John Alarcon of Code Potent, did a blog post on this subject a while ago. I use a structure fairly similar to the one he described, and have used the same format for showing the structure I use.

Continue reading “ClassicPress Plugin Development: Structure of a Plugin”

This post is part of the ClassicPress Plugin Development series in which I am going to look at both best practice for developing plugins and how I approach some requirements as well as some of the functions I commonly use.

In the last post in this series, on whether to use namespaces, I discussed whether they should be used or not and noted that I do not currently use them, but am debating whether I should.

At present, the azrcrv_tt_post_tweet function in my To Twitter plugin is called from a few other plugins in order to send a tweet; the function calls looks like this:

$tweet_result = azrcrv_tt_post_tweet($parameters);

This calls this function:

function azrcrv_tt_post_tweet($parameters){

If I was to update my plugins to use namespaces, in the To Twitter plugin a namespace would be added to the top of the PHP file (only the opening PHP tags and any comments should be before the namespace declaration). If I do make this change, I would use a developer and plugin specific namespace:

namespace azurecurve\ToTwitter;

The function to post the tweet, and all other functions, could then be renamed to remove the current developer and plugin specific prefixes thusly:

function post_tweet($parameters){

The other plugins which call this function, would need the function call to be amended to include the namespace:

$tweet_result = \azurecurve\ToTwitter\post_tweet($parameters);

With namespaces, it is possible to use a function name which matches that in the global namespace. For example, the get_option function is a standard ClassicPress function used to get the options for a plugin. I can create a function with the same name in a plugin without a conflict.

Calling the below will call the function in the plugin:

$options = get_option('azrcrv-tt');

To call the standard ClassicPress version in the global namespace I would prefix the function call with a \:

$options = \get_option('azrcrv-tt');

The final point to handle, is if you are using a ClassicPress hook such as add_action you are passing a string which will be executed in the global namespace so you need to pass the namespace of your plugin as part of the hook:

add_action('admin_menu', 'azurecurve\ToTwitter\create_admin_menu');

There is a predefined PHP constant available which you can use to avoid putting your namespace in many parts of your plugin; this can be useful in future if you need to change your namespace, as you then ony need to change the declaration at the top of the plugin:

add_action('admin_menu', __NAMESPACE__.'\create_admin_menu');

The same principles would apply PHP classes as well, but as I said in the coding paradigms blog post, I am not developing using object oriented programming and so am not covering classes.

This post is part of the ClassicPress Plugin Development series in which I am going to look at both best practice for developing plugins and how I approach some requirements as well as some of the functions I commonly use.

Namespaces are a standard feature of PHP, post version 5.2. A namespace is a way of addressing the problem of isolation. For example, if you have a function called load_cs in one part of your code, then you cannot use the same name elsewhere. For ClassicPress this also means that having that function in one plugin, you cannot have the same name in another plugin.

To avoid this problem with ClassicPress, the common approach is to prefix function names (and class names) with a developer and plugin specific prefix; I typically use azrcrv_{nn}_ where the highlighted section is one to four letters to represent the specific plugin (e.g. e for Events, uam for Update Admin Menu or smtp for SMTP).

John Alarcon, Code Potent, uses namespaces in all of his plugins so does not need to use developer and plugin specific prefixes; instead he uses a developer and plugin name namespace. For example, the PHP Error Log Viewer uses the following namespace declaration:

// Declare the namespace.
namespace CodePotent\PhpErrorLogViewer;

I started developing plugins for WordPress (back in 2013) before namespaces were introduced to PHP and have never adopted them. I rewrote my WordPress plugins specifically for ClassicPress in 2019 after I migrated all of my sites, but did not adopt namespaces. Partly this was to maintain some backward compatibility as some of the plugins have functions which are intended to be called from outside the plugin (such as URL Shortener which is typically called to display the shortlink in a theme) and partly because at the time I didn’t especially see the benefit.

As time has passed and I’ve created more plugins, I am thinking that was a mistake and I should have introduced namespaces when I did the ClassicPress rewrite; if I make this change now to existing plugins, this would, under semver, be a breaking change necessitating a major version number increase.

If you are starting off developing for ClassicPress, I would encourage you to seriously consider using namespaces in your development of plugins.

This is part of the azurecurve ClassicPress Plugins which introduces the plugins I have available for ClassicPress.

The plugin I am going to cover in this post, is a brand new one written for ClassicPress; Events.

Functionality

Events allows events such as webinars or conferences to be created via a custom post type; categories, excerpt, details, start and end dates and times and a featured image are all supported.

In the options set defaults for the widget and shortcode.

Multiple widgets can be created, each assigned to display a category; settings for title, image size and limit for number of events to list can be set per widget.

The event shortcode accepts three parameters:
* slug to select specific event.
* width to set the size of the featured image.
* height to set the size of the featured image.

Shortcode usage is [event slug=”december-2021″ width=150 height=150]; all parameters are optional and will use the defaults set via the settings page.

The events shortcode accepts four parameters:
* category to restrict the output to the selected category.
* width to set the size of the featured image.
* height to set the size of the featured image.
* limit to restrict the number of events to display.

Shortcode usage is [events category=”webinars” width=150 height=150 limit=5]; all parameters are optional and will use the defaults set via the settings page.

Download

The plugin can be downloaded via my Development site.