Escaping the maintenance mode trap

WordPress makes upgrading very easy . You simply click "Update now", wait for a minute or two and your system is up to date. If, well if everything works fine.
The most common problem during an upgrade is the Internet connection to drop unexpectedly or the user to shut down the browser unintentionally. In both situations the upgrade will stop instantly.
If you try to log in to your backend again you will receive the message

"Briefly unavailable for scheduled maintenance. Check back in a minute."

This message is useful to keep users away from your blog during the upgrade but right now it's keeping you from restarting the upgrade. To solve this problem we have to take a look at how WordPress determines that it's in maintenance mode.

WordPress is looking for a possible maintenance mode very early to prevent the system dying from any fatal error. So it using a very simple method by writing a file called .maintenance to the WordPress root directory. If the blog or backend is accessed it will check for the file and stop if it's present.

Knowing this the solution to our problem is quite simple: access your WordPress system via FTP and delete the file .maintenance.

If you're not able to log in to your server via FTP for some reason there is a second method for escaping from maintenance mode: simply wait 10 minutes!
The file .maintenance contains a timestamp of the time the file was created. If this time is less than 10 minutes ago WordPress will go into maintenance mode otherwise it will continue to work as usual and enable you to restart the upgrade unless something worse keeps it from starting.

WordPress Pulse? – Heartbeat API

With WordPress 3.6, there will be a new API - Heartbeat. On Ticket 23216 in Trac all discussions and information be gathered together. Because Heartbeat may also have influences for users, here are some words and clues. Heartbeat is introduced to various activities, such as Autosave, locks of articles and to handle logon and logoff notifications. In parallel, the API can also be used for own developments.
Continue reading …

the-customizer-wordpress-themes-gestalten-640x406

WordPress Theme Customizer Custom Controls

The Customizer is a relatively new way of WordPress Themes to provide you with options. Here is the visuality important, arrange the options directly in frontend for the Theme, play and save the settings.

We show you how to create your own classes to extend the controls, since not all fields and requests are in the core already. You can access existing solutions of the community or create your own classes. The first step is therefore a brief introduction for new classes and following an overview of some classes. Please extend this list via the comment form.
Continue reading …

How recent is “recently”?

If you deactivate plugins you can access them some time under the "Recently active" link in the plugin list table.

recentlyactive

"Recently" is not a very specific statement. So how long are deactivated plugins assumed to be "recent"? To find this out we have to take a look at the source code. In wp-admin/plugins.php line 166 the option "recently_activated" gets updated if a plugin is deactivated:

if ( ! is_network_admin() )
  update_option( 'recently_activated', array( $plugin => time() ) + 
  (array) get_option( 'recently_activated' ) );

The option contains an associative array containing the path to the main file of the plugin as the key and the time the plugins have been deactivated (as a unix timestamp) stored as a serialized value:

183 recently_activated a:1:{s:21:"hello-dolly/hello.php";i:1357900255;}

Before the plugin table is created the time stamp is used to determine the "recently active" plugins (wp-admin/includes/class-wp-plugins-list-table.php line 76):

$recently_activated = get_option( 'recently_activated', array() );

foreach ( $recently_activated as $key => $time )
  if ( $time + WEEK_IN_SECONDS < time() )
    unset( $recently_activated[$key] );
update_option( 'recently_activated', $recently_activated );

The code is walking through all plugin names stored in "recently_activated" and removes those which are older than one week and saves the others back in the options table.

So the answer to the question is: WordPress defines "recently" as one week.

WordPress Dropins

Plugins are pretty popular, since it is easy to adjust your blog or website to your liking with Plugins. Less popular are Dropins.

WordPress alows to replace some functions with Dropins. The list of possibilities isn't big and not well documented. But I like to use Dropins to enhance the possibilties of caching, especially APC and Memcache. But also to adjust uploads, permalinks and similar things are a typical scenario for Dropins.

Most of the Plugins are in the WP Content Folder, normally wp-content or via constant WP_CONTENT_DIR or the URL in WP_CONTENT_URL is defined.
Example:

// Custom content directory
define( 'WP_CONTENT_DIR',  dirname( __FILE__ ) . '/wp-content' );
define( 'WP_CONTENT_URL',  'http://' . $_SERVER['HTTP_HOST'] . '/wp-content' );

I use this in my dev environment or at my clients project for example, since I can access Plugins via FTP in different ways. See my WordPress Starter Repo on Github for more solutions and hints about this topic.

Only Dropins, which get loaded with a language key, aren't in this folder, instead they are in /wp-content/languages. Alternatively you can define the folder via the constant WP_LANG_DIR.
The Dropin for the German key de_DE takes that path. See the repo for read the source or find more information.

In Backend are Dropins listed since version 3.0, but only the following in the table and not the Dropin to the language key. Also you can not just deactivate or activate it via backend, that's why Plugins are preferred for some solutions.

Below is a table with all Dropins I know or I have found. The possible Dropins are echoing via the function _get_dropins() .

File Type of Dropin Active since Context
advanced-cache.php Advanced or Alternative Cache Constant WP_CACHE is TRUE Single Installation
db.php Own database class Always Single installation
db-error.php Own database error alert At DB Error Single installation
install.php Own installation routine At installation Single installation
maintenance.php Own maintenance message At updates, maintenance Single installation
object-cache.php External Object Cache Always Single installation
sunrise.php Before the WP Multisite Installation gets loaded If constant SUNRISE set Multisite installation
blog-deleted.php Own message, when a blog gets deleted If a blog gets deleted Multisite installation
blog-inactive.php Own message, if a blog is set inactive If a blog becomes inactive Multisite installation
blog-suspended.php Own message, if a blog got suspended When a blog gets marked as archive or spam Multisite installation
$locale.php functions at active language key When language key set in constant WP_LANG Single & multisite installation

Update: see the current solution for a custom maintenance mode on the post from Christopher.

Hide Welcome Panel for WordPress Multisite

With a major release update of WordPress, everytime all new functions will be displayed after updating. Basically a good idea, which displays all new features on one page. However, this is not always intentional. In the corporate environment, large groups of users aren't interested in it, so that this screen only provides additional work for the support team.
WordPress has implemented an option for every user. Therefore, a small function that suppresses the info screen and adjust the user settings, so this screen won't appear.

Continue reading …