WordPress Network (Multisite): Always Specify Full Path for Includes

Recently I’ve been working a lot on network installations of WordPress. During development I won’t always adhere to best practices from the go-get. I’ll use little short-cuts. They let me know if something is going to work or not.

One error that I have come across, is a weird little thing that only happens under certain circumstances:

This happens if you include a plugin file that requires() a file in the same directory, and then browse to network admin. So, it works in normal admin, and it works if you require() a file from a different directory. But not in the same directory. It’s simple to fix, and is something that should be done for any beta or production code anyway..






Change WordPress Admin Bar text ‘Widgets’ to ‘Sidebar Widgets’

The word ‘widgets’ is a little vague. To an every day person, it could be anything. For British of a certain age it might bring memories of an old advert. Even WordPress experts are aware that the word is often used to use different things.

So, renaming them to ‘Sidebar Widgets’ (because they go in the sidebar) is a small UI improvement that seems to make sense.


Should all WordPress Plugins have a Database Schema Version?

Should WordPress plugins that make any database schema changes have a local database scheme version number?

The plugin README file has tags for Requires at leastTested up to and Stable tag.

I’m suggesting that alongside defining the plugin version, and the three README tags, there should be a value for the schema. This means that plugin authors can explicitly note when their plugin is updating the schema.

Whether it goes in the main plugin file next to plugin version, or in the README file I’m not sure it makes any difference. But if we build in some hooks to trigger on schema version change then we gain two things. Firstly, developers like it as they can explicitly perform tasks based on schema versions and version changes. And secondly, users can be notified that the plugin is about to make schema changes. Which might encourage backups.

I think that’s a win-win!

WP Glossary WordPress Plugin Moves To GitHub

I’ve had a few enquiries about the ability to contribute to the WP Glossary plugin. No doubt this is due to my inactivity. Work, money, family, pets and all that stuff that makes up my simple life has meant there has been no time for any fun home projects. One thing suffering is WP Glossary.

It strikes me that, and probably many others, that GitHub is ideally suited for exactly such a thing as a WordPress plugin. I followed the instructions on a gist by kasparsd and viola, it is done.

GitHub Link: https://github.com/tcbarrett/WP-Glossary

I have never dealt with any kind of pull / clone / whatever requests. Nor have I played with branching on git. I dipped my toes in the subversion branch pool (does that scan?) and was frightened. So, please be kind.

If there’s still anyone out there who hasn’t lost patience with me and wants to add their bit, please do feel free. Just remember I’m still on a learning curve.