ClassicPress Plugin Development: To Use Namepsaces or Not

ClassicPress PluginsThis 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.

Click to show/hide the ClassicPress Plugin Development Series Index

ClassicPress Plugin Development: Coding Standards

ClassicPress PluginsThis 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, I covered using semantic versioning or (semver) when developing plugins for ClassicPress.

When developing plugins, ClassicPress largely uses the same coding standards as WordPress:

From the coding standard links above, I do follow the ones for HTML and CSS pretty much 100%, but the PHP one has a few items for which I take a slightly different approach. The idea behind coding standards is to make code readable to other people, so I largely take the view that if there is part of the standard you don’t like, then as long as you’re consistent in how you break the standard, code will still be readable.

The above opinion on adhering to coding standards is in reference to greenfield development; if contributing to an existing plugin, code to the standards used for that plugin. If contributing to core, then adhere to the standards as written.

Click to show/hide the ClassicPress Plugin Development Series Index

ClassicPress Plugin Development: Semantic Versioning 2.0

ClassicPress PluginsThis 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.

When developing plugins for ClassicPress, you need to develop using semantic versioning (or semver) as this will be a requirement of the ClassicPress Directory.

Semantic Versioning is a versioning scheme for using meaningful version numbers which can be used to avoid incompatibilities.

semver version numbering works using three segments:

  1. MAJOR version when you make breaking changes where users will need to take some action during an upgrade.
  2. MINOR version when you add functionality in a backwards compatible manner which users can simply apply without taking any other action.
  3. PATCH version when you make backwards compatible bug fixes which, like MINOR versions users can apply without taking any other action.

One key point to note when using semver, is that when a versioned release has been made, nothing in that release can be changed; a new version with incremented number must be released instead.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format; pre-release versions often have a MAJOR version number of 0. When a plugin is ready for release to production it should be released as version 1.0.0.

Continue reading “ClassicPress Plugin Development: Semantic Versioning 2.0”

ClassicPress Plugin Development: Coding Paradigms

ClassicPress PluginsThis post is part of the ClassicPress Plugin Development series.

There are two code paradigms that can be used when developing for ClassicPress:

  • Procedural Programming
  • Object Oriented Programming

There has been many a flame war fought over which is better and which is worse, but in all honesty I believe that both can have their place and there is no one true way of coding.

I was going to cover the differences between the two types, but when I was researching for good definitions I came across an article by Tom McFarlin linking to articles he and Stephen Harris wrote on the coding paradigms which can be used with WordPress, and therefore ClassicPress, plugins.

I am not that old, but my programming career (short as it was and now a few years in the past after I moved into being a consultant) tended to be with older languages such as Pick Databasic and Visual Basic; I also self-taught myself Lua and later PHP.

In all of the programming/scripting languages I have worked with professionally, to any great extent, the code has been procedural; I’m not saying all of these languages are only procedural, just that virtually all of the code I worked with was written as procedural. As such I am far happier in a procedural world and so I have used this for writing my plugins. At least where I can; plugins with widgets are the exception as ClassicPress require the widget elements to be object orientated.

How you choose to develop for ClassicPress is exactly that; your choice. The examples I will be posted will, except when talking about widgets, be procedural code.

Click to show/hide the ClassicPress Plugin Development Series Index

ClassicPress Plugin Development: Series Index

ClassicPress PluginsI started developing plugins for WordPress almost eight years ago and moved to ClassicPress just over two years ago; I now have 47 plugins available for ClassicPress.

I am creating this series to show how certain aspects of development for ClassicPress plugins are done, partly to benefit others who take up developing for ClassicPress but also as a quick reference for myself including detailed examples.

This series index will automatically update to show new posts as they are published:

ClassicPress Plugin Development
Coding Paradigms
Semantic Versioning 2.0
Coding Standards
To Use Namepsaces or Not
Using Namespaces
Structure of a Plugin
Format of a Plugin readme.txt
Format of a Plugin Header
Add an index.php to Every Folder
Develop for Translation
Develop for Accessibility
Create a Plugin Update Server Using Code Potent's Update Manager
Integrating Code Potent's Update Manager into a Plugin
Create a Plugin Update Endpoint Using Code Potent's Update Manager
Create a Custom Image Path and URL for Code Potent's Update Manager
Loading Front-End Stylesheets
Loading Back-End Stylesheets
Loading Front-End Scripts
Loading Back-End Scripts
Best Practice for Loading Styles and Scripts
Create a Plugin Action Link
Add Plugin Options Page to Settings Main Menu
Add Plugin Options Page to Security Main Menu
Create Custom Top Level Menu
Create Submenu on Custom Top Level Menu
Create Custom Post Type
Create Submenu for a Custom Post Type
Rename First Sublevel Menu of a Custom Top Level Menu
Load and Save Options
Load Options with Defaults
Load Multilevel Options with Defaults
Get Options Page Title
Create an Options Page
Save an Options Page

azurecurve ClassicPress Plugins: Check Plugin Status

ClassicPress PluginsThis 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; Check Plugin Status.

Functionality

This plugin allows you to check the status of plugins on your site:
* Are they in the WordPress Repository.
* Do they use a 3rd party update mechanism such as Update Manager from Code Potent.
* Are they supported on ClassicPress or on WordPress 5+.
* Are they up-to-date.

Exception handling has been built in for Contact Form 7 and Google Sitemap Generator which report a different slug in the API to the slug on the Wordpress Repository.

Download

The plugin can be downloaded via my Development site.

Click to show/hide the azurecurve ClassicPress Plugins Series Index

azurecurve ClassicPress Plugins: SMTP

ClassicPress PluginsThis 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; SMTP.

Functionality

Simple Mail Transport Protocol (SMTP) plugin will intercept the standard wp_mail and send emails via an SMTP server using PHPMAILER.

This plugin is multisite compatible; each site will need settings to be configured in the admin dashboard.

Download

The plugin can be downloaded via my Development site.

Click to show/hide the azurecurve ClassicPress Plugins Series Index

azurecurve ClassicPress Plugins: Maintenance Mode

ClassicPress PluginsThis 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; Maintenance Mode.

Functionality

Enable maintenance mode to disable the front-end of your ClassicPress site for non-administrators.

Users will only see the configured message; administrators will have full access to the site, but a prominent configurable warning that maintenance mode is enabled will be displayed at the top of every page.

This plugin is multisite compatible with each site having its own settings.

Download

The plugin can be downloaded via my Development site.

Click to show/hide the azurecurve ClassicPress Plugins Series Index

azurecurve ClassicPress Plugins: Update Admin Menu

ClassicPress PluginsThis 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; Update Admin Menu.

Functionality

Allows the reorganisation of the ClassicPress admin menu allowing you to move more often used menu entries to the top of the menu.

Download

The plugin can be downloaded via my Development site.

Click to show/hide the azurecurve ClassicPress Plugins Series Index

azurecurve ClassicPress Plugins: From Twitter

ClassicPress PluginsThis 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; From Twitter.

Functionality

Automate the retrieval of tweets from Twitter and create posts on your ClassicPress site

From Twitter includes the following functionality;

  • Search Twitter and create tweets as posts or as a Tweet custom post type.
  • Specify the title and content in posts for retrieved tweets.
  • Choose whether to save tweet data.
  • Choose cron frequency (hourly, twice daily or daily).
  • Choose how many tweets to return each time the cron runs (max 100 as per Twitter api).
  • Choose whether Tweet images should be downloaded.

Make sure that once all the settings have been configured, you enable the cron job to run on the Cron Settings tab.

Download

The plugin can be downloaded via my Development site.

Click to show/hide the azurecurve ClassicPress Plugins Series Index