Currently is WordPress version 3.6 in Beta status. But new nice features are available and ready to test. One of this features is the new UI for the post formats. Post formats is a nice chance for more possibilities to declare a post to your readers. But sometimes we don’t need post formats. The default for hide the Post Format UI is user specific and is an option in the screen options, see the screenshot.
Continue reading …
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 …
To embed custom CSS styles and scripts in WordPress you should use the
wp_register_style() functions. Each of these functions allows you to define a version. By default it's the version of WordPress. The version identifier will be in the URL to the script as a query string.
The version identifier is used to expire the URL. Since the browser detects the new URL as a new resource, it will use the new instead of the cached resource.
Sadly not all endpoints respect the query string. From Google Developers:
Most proxies, most notably Squid up through version 3.0, do not cache resources with a "?" in their URL even if a
Cache-control: public headeris present in the response. To enable proxy caching for these resources, remove query strings from references to static resources, and instead encode the parameters into the file names themselves.
So the goal is to encode the version identifier into the filename without renaming the resource on the filesystem. This is where the following plugin comes in.
Continue reading …
If you deactivate plugins you can access them some time under the "Recently active" link in the plugin list table.
"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:
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.
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.
// 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
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
|File||Type of Dropin||Active since||Context|
||Advanced or Alternative Cache||Constant
||Own database class||Always||Single installation|
||Own database error alert||At DB Error||Single installation|
||Own installation routine||At installation||Single installation|
||Own maintenance message||At updates, maintenance||Single installation|
||External Object Cache||Always||Single installation|
||Before the WP Multisite Installation gets loaded||If constant
||Own message, when a blog gets deleted||If a blog gets deleted||Multisite installation|
||Own message, if a blog is set inactive||If a blog becomes inactive||Multisite installation|
||Own message, if a blog got suspended||When a blog gets marked as archive or spam||Multisite installation|
||functions at active language key||When language key set in constant
||Single & multisite installation|
Update: see the current solution for a custom maintenance mode on the post from Christopher.