Ever wanted posts to be removed from a menu when deleted? Maybe. Ever wanted them removed when set to draft? Less likely but I’ll tell you how to do both anyway!

The first is really easy and I pulled the solution from an open ticket on WordPress Trac.

add_action( 'wp_trash_post', '_wp_delete_post_menu_item' );

and that’s it. that line can go into a plugin or your functions.php file (plugin is more appropriate). It’s hooking into the action of putting a post in the trash (which carries with it the post ID) and calling the function to remove any corresponding menu items from any custom menu. easy.

If you’d like to have published posts (even custom post types) that get set back to draft taken out of the menu, you can use a function like this:

function pype_remove_draft_from_menu($post) {
   _wp_delete_post_menu_item($post->ID);
}
add_action( 'publish_to_draft', 'pype_remove_draft_from_menu');

also easy! This uses one of the post transition hooks, which takes the form of $oldstatus_to_$newstatus So if you wanted to catch posts moving from draft into published you would name the hook draft_to_publish

Related, a useful post status to use is the “auto-draft” which is the status given when you click “add new” and haven’t saved anything yet. This can be used to set up default content or settings for a post. In the past I’ve used it to set comments off by default for a particular post type. I might as well show you how:

function pype_default_comments_off( $data, $postarr ) {
   if( $data['post_type'] == 'post' && $data['post_status'] == 'auto-draft' ) {
      $data['comment_status'] = 'closed';
   }
   return $data;
}
add_filter( 'wp_insert_post_data', 'pype_default_comments_off', 99, 2 );

I’ve been doing a ton of work with RSS feeds lately, using them to sync data across nearly 2000 sites. I was running into an issue with WP caching of feeds. There’s a filter to change how long WP holds the RSS feed information in cache and is easy to use (link):


function lower_feed_cache_time() {
return 3600;
}
add_filter( 'wp_feed_cache_transient_lifetime', 'lower_feed_cache_time' );


This lowers the time it caches feeds for to 1 hour (3600 seconds), down from a default of 12 hours. This didn’t really work well for me though because I only wanted to have the cache dumped when I was manually syncing my RSS feeds. So instead I wrote a function that uses an SQL query to delete the feed transients in the options table. It looks like this:


function clear_feed_cache() {
global $wpdb;

$num = $wpdb->query($wpdb->prepare("DELETE FROM $wpdb->options WHERE option_name LIKE %s ", '_transient_feed_%'));
error_log($num.' feed transients deleted by');
}

This function gets the global $wpdb variable, holding the database information for your site. This functions works in multisite because $wpdb->options holds the name of the options table for the current site you are on. It’s looking for options that have the name like _transient_feed_% – the % being a wildcard. The error_log line comes in handy because it lets me know how many rows were deleted (or if something went wrong and no rows got deleted). Using the error log and running tail -f on it from the command line can be a great help during development. ‘tail -f error_log’ will track the error_log as errors happen, you can see them scroll by. I keep it open a lot.

I hope this helps solve your RSS feed cache problems!

The first one to show me most of this was my friend Topher and I added an extra command.

It’s the fastest way to install a fresh version of WordPress on an empty server just waiting for it. You’ll need SSH access enables for the server, and you’ll need to connect to the server using a Terminal window.

First, open your terminal and connect to the server over ssh like so:

ssh -l yourusername yoursite.com

and hit enter. It will ask if you’re sure you want to accept the connection, and as long as you know what you’re connecting to, type yes (the whole word) and hit enter.

Once you log in, type ls to list the files and folders you can see currently. Use the command

cd foldername

to move into (change directory) that folder. You want to get to where WP needs to be installed. Once there, we’re at the fun part. Enter the following commands one at a time:

wget http://wordpress.org/latest.tar.gz
tar xvzf latest.tar.gz
mv wordpress/* ./
rmdir wordpress
rm latest.tar.gz

Here’s what it does:

• Download the latest version of WordPress from wordpress.org
• unzip what was downloaded
• move all the files out of the “wordpress” folder and into your current directory
• delete the now empty wordpress folder
• delete the zipped file we downloaded in step one

This all happens much faster than it would using FTP, and much more securely (FTP isn’t very secure at all).

Continue your WP install as usual. This is the fastest way to get it onto your server. Have fun!

First, let’s define when you’d use this. Here’s where I as at.

I was pulling in a most recent post into a page that was not the blog. Not just onto a page, but into a custom post type (for displaying small content on the home page) that only had a couple of fields available to me for use. These posts have PodPress podcasts attached to them, and I needed that information. I needed to make it simple for the user, so I wanted to make a shortcode to pull the most recent post.

If you’re in the loop and you call the_content() you get everything you’d expect to. When you’re making a shortcode and need to return all of your data instead of just echo or print it, you need to use get_the_content(). Normally this isn’t a problem, but if you’ve got plugins or other things filtering their data in using add_filter(‘the_content’), then that data won’t be pulled in.

Looking back, I can see that the following important step is included in the bottom of the codex’s get_the_content page, but here is the magic code to get your plugin data included:

apply_filters( 'the_content', get_the_content() );

so my use looked something like this:

$output .= apply_filters( 'the_content', get_the_content() );
return $output;

with that, all of my fancy PodPress functionality was included.

This is an add-on to my last post about customizing the login page. My client wanted to (very slightly) change the text a user sees on the Forgot Password page.

It took me way too long to come across the login_message filter.

here’s my function:

function forgotpass_message() {
 $action = $_REQUEST['action'];
 if( $action == 'lostpassword' ) {
 $message = '<p class="message">Please enter your email address. Then check your email inbox for instructions to reset your password.</p>';
 return $message;
 }
}
add_filter('login_message', 'forgotpass_message');

The url on the forgot password page includes the query string “action=lostpassword” so that’s what I’m checking for with my $_REQUEST call. If we’re on the forgot password page, then make a new message and return it.

Some other possible values of the action query string (taken from wp-login.php):

• logout
• retrievepassword
• resetpass
• rp
• register
• login

I think “rp” is another form of reset password.

Happy WordPress login page customizing! Hopefully someone who is looking for this comes across it quicker than I did.

So the plugin I wrote about last post didn’t handle everything like I thought it did. If a user entered their password incorrectly, they were brought straight to the default wp-login.php page with the WP logo staring them right in the face. Exactly what my client did not want. It turns out this was a conflict with other functions that I had running so I had to work around it.

After searching through many half-helpful articles on how to customize the WordPress login page without a plugin, I finally got my most helpful information straight from the wp-login.php file. Whodathunk eh?

Hook: login_head
Use: add_action('login_head', 'yourfunctionname');

This will hook you into the <head> tag of the login page. I used it to throw in some CSS to alter the login page. Only to change the button color and replace the WordPress logo image (it’s a background-image). So I used:

function v_login_logo() {
 echo '';
}

Great. But the logo is still linked to WordPress.org. For that, wp-login.php tells us there’s a filter for that:

Filter: login_headerurl
Use: add_filter('login_headerurl', 'yourfunctionname');

While you’re at that, you might as well change the title tag of the image so it isn’t wordpress.org by using:

Filter: login_headertitle
Use: add_filter('login_headertitle', 'yourfunctionname');

So using those two filters and one hook, I replaced the login logo image, image url, and image title attribute. You can change any other CSS you’d like using that hook too.

I learned a neat php trick from one of the articles I found (long forgotten which of the many) with a command called create_function. I used it with my filters like this:

add_filter('login_headerurl', create_function(false, "return 'http://wwwmysiteurl.com';"));

As you can see, it created my function within my filter call. Handy. I have no idea what the “false” is for at the beginning. Maybe someone else can tell me.

Happy login customizing. More and more lately I like to avoid plugins where I can and sharpen my skills interacting with WordPress on my own. Time consuming, but eventually I can make my own plugins. There’s value in always knowing what’s going on under the hood.

Plugin can be found on the WP plugin repository here.

This morning I found myself needing to quickly make the standard WP login page not look like the standard WP login page. Then I realized I also needed the same for the password recovery page and also to redirect the logout page away to the site homepage. The project I’m working on already had this plugin installed so I thought “why not?”

Now I know how to use

 wp_logout_url( home_url() );

to send a user to the homepage on logout. That’s  all fine and dandy but doesn’t change the look of anything. I figured the Theme My Login plugin would let me change up the styling of the WP pages I needed, using a different logo and such. Nope. I think the plugin would more appropriately be called Move My Login Page to the Front End of My Site.

How it works: You add a “login” page and enter that page ID into the plugin settings. That page is now used for all your logging needs. You won’t even see the WP login page again unless you manually point your URL to /wp-login.php (I usually use /wp-admin).

My problems were solved faster than I could have hoped for. I no longer had to restyle the WP login with a new logo and look, my login fields were now on a page in my website and looked totally integrated.

The plugin also supports redirecting (based on user level!) for logging in and/or out. Custom emails (I assume for new users or password recovery), custom passwords, custom user links, security, themed profiles, and user moderation. I didn’t touch anything but the redirection.

Worked for me!

It sure doesn’t look great to have a “blog” section with two posts and no new ones for months and months huh?

I think getting too ambitious about it is part of the problem, at least for me.

Look for some short reviews on stuff I’m doing or have done, plugins I’m using or wish I’d avoided. That sort of thing. Let’s keep it brief and unambitious. I’ve gotta have time to build sites and play with by daughter.

-Jarrod