Extend WordPress Login Expiration

The default login session cookie is 48 hours. Although it’s usually enough for most users, it can be frustratingly short for developers and administrators. Here’s something useful for those who do not want the hassle of logging in now and then. Add this to your theme’s functions.php , or create a php file and load it in the Must Use Plugins folder:

add_filter( 'auth_cookie_expiration', 'new_login_session_period' );
function new_login_session_period( $expirein ) {
    return 31556926; // this equals to 1 year in seconds

But I guess you’ll also have to make sure that your browser settings does not expire your cookies within 1 year (or any figure that you’ve specified) for the above to work.

WordPress 3.1 and setup_postdata

After upgrading one of my websites to WordPress to version 3.1, the loops that contained setup_postdata() created a mess. After some testing, I realised that setup_postdata() will only return the correct data if the argument passed is $post, i.e. setup_postdata($post). I had used setup_postdata( $ancestor ) instead and it created a mess after the upgrade.

Now I had this running in my code:

foreach( $ancestors as $ancestor )  {
   setup_postdata( $ancestor );
   // Do things with the_title()
   // Do things with the_post_thumbnail()
   // Do things with the_permalink()
   // Do things with get_post_custom()
   // Do alot of other things with $ancestor

I could solve this mess by changing to the below code, but this required changing all $ancestor variables to $post

foreach( $ancestors as $post )  {
   setup_postdata( $post );
   // Do things with the_title()
   // Do things with the_post_thumbnail()
   // Do things with the_permalink()
   // Do things with get_post_custom()
   // Do alot of other things with $post 

But I reckoned it wasn’t as efficient, and also it might create more bugs due to the edit of so many variable calls. In the end I opted for a quick fix to pass $ancestor into the $post variable just before setup_postdata( $post ). In this way, I’ll still able to get the correct data from the_title(), the_post_thumbnail(), the_permalink() and get_post_custom(), without having to change all $ancestor calls to $post that come after.

foreach( $ancestors as $ancestor )  {
   $post = $ancestor;
   setup_postdata( $post );
   // Do things with the_title()
   // Do things with the_post_thumbnail()
   // Do things with the_permalink()
   // Do things with get_post_custom()
   // Do alot of other things with $ancestor

Ok, hope this might be useful if you faced the same issue. Anyone has alternative solutions?

Ways to load template files in WordPress

The below methods mostly uses get_template_directory() to retrieve the parent theme directory and get_stylesheet_directory() if you are using a child theme and retrieving the  of  child theme directory.

Using include() and require()

These are built-in PHP functions and you can use them to load template files like this. Note that they do not check file existence, and you’ll get an error if the file do not exist.

include( get_template_directory() . '/file.php' );
require( get_template_directory() . '/file.php' );
include( get_stylesheet_directory() . '/file.php' );
require( get_stylesheet_directory() . '/file.php' );
include( get_template_directory() . '/subdir/file.php' );
require( get_template_directory() . '/subdir/file.php' );
include( get_stylesheet_directory() . '/subdir/file.php' );
require( get_stylesheet_directory() . '/subdir/file.php' );

You can also use include_once() and require_once().

Using load_template()

load_template() is a WordPress function that works just like include() and require(). It does not check for file existence as well.

load_template( get_template_directory() . '/file.php' );
load_template( get_stylesheet_directory() . '/file.php' );

Using locate_template()

locate_template() checks for file existence. It searches files in both parent theme and child theme directory, and overloads from the child theme.

locate_template($template_names, $load, $require_once);
  • $template_names can be a single filename or an array of names.
  • $load is a boolean parameter. It defaults to false and when true, the searched file(s) are loaded.
  • $require_once is a boolean parameter and defaults to true – when true, it loads the file using php require_once() function, else it loads using php require().

You can code it like this

locate_template( 'file.php', true );
locate_template( 'subdir/file.php, true );
locate_template( array( 'file1.php', 'file2.php' ), true);

Using get_template_part()

get_template_part() (as of WordPress 3.0) loads a template part into a template (other than header, sidebar, footer). This makes it easier for a theme to reuse sections of code in an easy to overload way if using child themes. This function will load a file named “{slug}-{name}.php”. The $name is optional, and if it’s empty, the function will include file named “{slug}.php”.

get_template_part( $slug, $name );

If you want to load a file named options-general.php, you can code it like this:

get_template_part( 'options', 'general' );

If you want to load from a subdirectory, you can code it like this:

get_template_part( 'subdir/options', 'general' );

Best Practices

Although there are several ways to load files in WordPress, we have to consider carefully which methods are best for particular cases. Considerations might include whether we want to allow child themes to overwrite certain functions etc. Justin Tadlock has written a comprehensive article on how to load files within WordPress themes, and gives ample analysis for best practices.

WordPress Theme Features

Theme features are a must-know for wordpress developers. Theme Features are a set of features defined by theme authors that allows a theme to register support of a certain feature. As of WordPress 3.1, theme features are:

Theme support functions are typically called in the theme’s functions.php file. Read Theme Features codex to find out more.

Drop-ins Plugins

WordPress drop-ins are custom php Must-Use files related to some core files such as db.php, advanced-cache.php and object-cache.php that you can place in the wp-content directory to override the core file with new functionality.

List of WordPress Drop-Ins

File Type of Plugin Loaded Context
advanced-cache.php Advanced caching plugin. on WP_CACHE value Single
db.php Custom database class always Single
db-error.php Custom database error message on error Single
install.php Custom install script on install Single
maintenance.php Custom maintenance message on maintenance Single
object-cache.php External object cache always Single
sunrise.php ‘Executed before Multisite is loaded on SUNRISE value Multi
blog-deleted.php Custom blog deleted message on deleted blog Multi
blog-inactive.php Custom blog inactive message on inactive blog Multi
blog-suspended.php Custom blog suspended message on archived or spammed blog Multi

This list is extracted from global function _get_dropins() in wp-admin/includes/plugin.php.

Must Use Plugins

Must-Use plugins are standard wordpress plugins, just that they reside in the mu-plugins directory (wp-content/mu-plugins). Plugins residing in this directory are automatically activated. The only way to deactivate them is to delete the plugin files from the mu-plugins directory.

The plugin files do not need to contain plugin headers, so you just need to create a PHP file and that’s it. These MU plugins are listed as ‘Must-Use’ in the plugins page in the WordPress admin.

What’s so great about this when we can easily place our code in the theme’s functions.php? Well, I can find use for this when creating post types, taxonomies, or shortcodes. By separating such codes from functions.php, I’m saving myself the trouble of transferring the code, or breaking my WordPress site when I need to switch themes.

Also, this has advantage over regular plugins found in the plugins directory (wp-content/plugins). For developers, must-use plugins prevent clients from disabling codes that are crucial to their site.

However, take note that WordPress looks in the mu-plugins directory for php files and not in its subdirectories. So if you want to move regular plugins which reside in their own subdirectories into wp-content/mu-plugins, you’ll probably need to create a proxy php file that contains require_once() or include_once() to include the plugin’s main php file from its subdirectory. An easy way is to create a single php file to include all the plugins found in mu-plugins sub-directories.

© 2020 Bucket Press