I have a home network that contains a mixture of devices, some of which that receive a...
Just shortly after hitting the 100,000 downloads milestone at WordPress.org, today brings us a maintenance release of Background Manager, version 18.104.22.168.
The main reason for this release was to address a bug that appeared in WordPress 3.7, which caused a background image to appear on all pages/posts, even if the settings specified otherwise. I believe the bug has now been addressed, and would likely have been due to a change in WordPress’ wp_guess_url() function.
In addition, an option to disable Background Manager on mobile browsers was introduced. That is considered an experimental feature at the moment, and is purely an on-off switch. That is, it isn’t a feature that will download a smaller images based on the mobile screen resolution, for example — that is still something to be considered at the moment.
Under the hood there are quite a number of changes, not fully described in the changelog. The one change that relates to Background Manager directly, is that the body tag override, used for the background colour or non-full-screen backgrounds, has been moved into a class instead (namely, myatu_bgm_body). The main reason for this is that it is easier to remove the background changes, should this be required. Background Manager itself does this in when a mobile browser was detected and the ‘active on’ setting for mobile browsers is set to off.
The other changes primarily relate to the Pf4wp framework that this plugin uses. For example, it has a new handler for fatal errors, providing the user a better to understand feedback in case the error happened in the WordPress administration area, including details that can be passed to the plugin developer (me!). If the fatal error occurred on the public side, then the plugin will automatically disable itself – if possible – to prevent it from causing further problems with the website. Any of these errors are also logged in the plugin’s main directory for easy retrieval and debugging at a later time.
Additionally, the Pf4wp plugin does an additional check when the APC cache is enabled, by verifying if it can store in the cache. In the past it assumed it could if APC was available, potentially causing the infamous WordPress white-screen-of-death. This was also a reason for the introduction of the fatal error handler.
Edit: Murphy’s Law has reared its ugly head, and 1.2.5 contained a bug that affected < PHP 5.4 installations. Hopefully this has been addressed in full now.