WordPress And Backwards Compatibility

If you ask a developer why WordPress has so much more success compared to other CMS like Drupal or Joomla, one concept will pop up for sure: Backwards Compatibility. Since the beginning of WordPress, its developers focused on one issue: Not to break functionality from one version to another.

One example are deprecated functions: Functions which aren’t used no more in one version won’t be simply kicked out. They remain in the core and will be marked as deprecated. They remain quite a while till they are finally kicked out. Long before this happens, developers can inform themselves on this page, which of the WordPress functions are deprecated. And also by using WP_DEBUG they will be informed.

Another example is the database. The wp_links table is currently of no use in WordPress. It sounds simple: WordPress doesn’t need this table no more and deletes it. But nobody knows, which data is stored in this table by single installations and how this data is used. To simply delete this table would have drastic consequences. Data, which WordPress users have collected with a lot of effort would simply disappear. Instead of keeping a consistent structure and remove this table, WordPress still keeps it, although it has no current use for it.

Related to this topic: Did anyone wonder, why the Post ID in the table wp_term_relationship is called object_id and not, like in any other table post_id? Even rows of wp_links used to be connected to terms. So back then, the developers decided to call this column object_id, since it contained not only post IDs. But nowadays the column basically contains only post IDs. Still the name remains. Why? How many plugins are out there, who access this table via SQL and are using object_id in their syntax? All these plugins would break! WordPress has a history and you can read its history by reading its inconsistencies.

Even in revised functions you will find examples: Take the second parameter of load_plugin_textdomain() as one. You always have to set this parameter to false. Until version 2.7 this parameter was carrying the relative path to the directory with the translations. Today the relative path is defined starting from WP_PLUGIN_DIR and not from ABSPATH. So the second parameter is deprecated and you define the relative path by the third parameter. But still, the second remains since old plugins might still use it. If you would remove this parameter, plugins would break.

From the user’s point of view, this all might look different. With every update the forums are floated with questions like “I just made an update and I can’t reach my admin no more/ I don’t see my pictures no more/ I can’t reach my site no more”. But all these questions lead us only towards two insights:

  1. How important backwards compatibility really is and
  2. how difficult it is, to realize backwards compatibility in an environment like WordPress.

For developers backwards compatibility is a double-edged sword, because it bloat your code. For some out of proportion. But if you consider the recent debate about security and the necessity to keep your system up to date, most developers conclude: there is no other way than backwards compatibility. Everything else would lead to a disproportionate effort especially for small bloggers and businesses or – if you consider almost 20 percent of the internet sites are run on WordPress – to a much more insecure Internet.

But: Is the concept of backwards compatibility only a topic for the core developers or do we plugin and theme developers have to be alerted too? Of course it has to concern us too. To update a plugin has to be a secure process which doesn’t break things.* Exactly like updating WordPress. This is the reason why Pippin Williamson, author of Easy Digital Downloads, gave a great speech on the Loopconf 2015 addressing backwards compatibility. I think every developer should watch this:

*) I have to admit, I need to do some work on one of my plugins as well to match the criteria of backwards compatibility. Well, not now, but this post shall be a reminder for me too 🙂

BuddyPress Desktop Notification

My latest plugin has just been released on wordpress.org: “BuddyPress Desktop Notification“. If you are running a BuddyPress community, you can use this plugin in order to display new messages, activities and friendship requests for your users.

BuddyPress Desktop Notification
A notification, which is displayed, while the browser is open

How this works? After a user logged in, the browser will ask for the permission to display desktop notifications. This works with most modern browsers (see a list here). While usually notification plugins show a pop-up or something similar, which are displayed only in the browser, desktop notifications also pops up, if the browser is minimized:

Desktop notification works also with minimized browsers
Desktop notification works also with minimized browsers

It’s quite a lightweight plugin, but it might cause some traffic because it produces an ajax request every five seconds for every logged in user who enabled the notifications. I decided to make this plugin configurable via filters and not using another admin menu page, since – to be honest – I am not such a fan of overloaded admin menus. If you are using this plugin and it produces too much load, you can reduce the request interval with the following piece of code:

More information on my latest plugin can be found on the website.

Four ways to hide the WordPress admin bar

If you are logged in, WordPress usually displays the admin bar on the top of your page. But there are situations, where you don’t want to display the bar. Sometimes, it is ruining your site layout or you want to hide the bar for certain groups of users.

There are different ways to hide the admin bar. The first way is of course, to uncheck the corresponding checkbox in the admin itself.

You can disable the adminbar.
You can disable the admin bar for certain users.

If it’s just about one or two users this is probably the quickest way to solve this issue. It will be less comfortable, when you are handling dozens of users or when you have to repeat this procedure for each new user by hand.

So it is interesting to know, where the information is saved. It is a meta information for users, saved in the wp_usermeta table of the database. The corresponding key, which is used to save this setting is 'show_admin_bar_front'. The value 'true' displays the admin bar, while the value 'false' will hide it. So you could set this value to 'false' during the registration:

But maybe you want to hide the toolbar only in specific sections of your site. Responsible for the rendering of the bar are the functions _wp_admin_bar_init() and wp_admin_bar_render() which reside in wp-includes/admin-bar.php. Before these functions start to render the bar, they check by using is_admin_bar_showing(), if the bar is supposed to show up. This function can be found in admin-bar.php too. is_admin_bar_showing() just returns a boolean, whether the bar is supposed to show up or not. By using the filter hook 'show_admin_bar' you can intervene in the process. So you could tell WordPress to suppress the rendering of the bar on blog posts:

Of course, there remains the possibility to hide the bar by using CSS. The admin bar has the ID '#adminbar', which you can simply hide:

#adminbar{ display: none; }

But by doing this, the native layout is not restored yet. By using margin WordPress creates some space for the admin bar on the top of the page by moving the whole HTML-element 32 pixels down. Since all this takes place in the 'wp_head' action, you have to load your definitions later. One option is, to use the 'wp_footer'-action and move the HTML-element back on the top again. You have to consider, WordPress is using !important, so we have to do so too:

As you can see, there are a lot of ways to hide the admin bar. It depends on your needs, which of these ways is the best for you.

Choose different header images on different posts

Together with the WordPress Customizer a nice feature was introduced into WordPress: The header image. If a theme supports header images with add_theme_support() you can choose an image, which will be displayed in the header. I’ve read now an interesting question in a forum:

Can someone please tell me if it is possible to alter the header image in the theme Twenty Eleven (2.1) for every page?

I liked this question and thought to myself, there must be a nice filter function, you could use for this. So I started my search. The image gets output by get_header_image(), which can be found in wp-includes/theme.php. Of course, this function is using get_theme_mod(), which is located in the same file. get_theme_mod() expects the name of the mod as a parameter, in our case “header_image”.

Before get_theme_mod() outputs its result, the function filters it with the filter “theme_mod_{name}”. For the image, which is displayed in the header, the filter would be called “theme_mod_header_image”. Basically we are done here. We write a small function which filters our header image. In a first step the function checks with is_singular() if we are on a single page or post. If that’s the case, we check if the current page has the custom field “current-background”. If this field contains a valid URL, this URL will be returned. In every other case, our filter will return the standard header image, which the administrator defined in the Customizer:

Add additional links on the plugins overview page – part 2

A few days ago I already published an article on how to add additional links on the plugins overview page. Yesterday I run again into the plugin “Cleaner Plugin Installer” and saw, David adds for his plugin also links under the plugin description:

Cleaner Plugin Installer with additional links under the description
Under the description of David Deckers plugin are a lot of links.

Usually you just find the version number, a link to the authors webpage and a link to the plugins info. As you can see, the author also placed a link to the FAQ, the support and some other pages.

How did he do this? This line is filtered by plugin_row_meta. The single elements of this line are passed to filter as an array. In contrast to the filter plugin_action_links, which needs to be adjusted to the own plugin this filter is more general. This means: Since we just want to alter the line for our plugin, we have to check, if the current execution of the filter is for our plugin or for another plugin. As a second parameter the name of the plugin file is passed to the filter. So we can use plugin_basename( __FILE__ ) to check, whether our plugin line is filtered right now or another.

To add another element to this line, the code could be something like the following: