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

Oh no! You get this message on every single page of your WordPress site including the Admin area.

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

It’s likely you were doing an update of WordPress or a WordPress plugin/theme and something went wrong or maybe you interrupted the process by closing your browser window.

Simply login to your server and in the root of your WordPress directory you’ll see a file called `.maintenance`. Delete it… yes, just delete the file called `.maintenance`.

Now your site is back up and you’ll be able to access the WordPress Admin area again. Just remember that when you’re doing a WordPress software updates, wait for the confirmation screen before clicking on something else or leaving the page.

WordPress turning “next” into “previous”

One of my favorite WordPress themes is Twenty Thirteen and I’ve been using it as the parent of my child themes lately. However, on my most recent project, Illinois Doberman Rescue Plus, I discovered a weird little thing with how this theme’s archive pagination function is operating. (Also true for this website‘s theme. However, I’m keeping it here as my post sorting is always chronological descending.)

No matter how you sort your postings, when you get to the bottom of the page, the link that is supposed to take you to the next page of posts is labeled “Older posts”, it’s in the lower-left corner and pointing towards the left (just like the browser’s “back” button). This only makes sense for one narrow case, when the newest post is at the top of page 1. (Even then I could argue that the link to next page of results should not be displayed like a “back” button.)

← Older posts

So for cases when the sorting is different depending on the type of archive page, let’s simply change the “Older posts” and “Newer posts” labels to something more generic… but to what? Hmm, how about “Next page” and “Previous page”? Yes, that makes sense. Err wait, the link pointing to the next page (page 2) is down in the lower-left corner and pointing to the left (just like our browser’s “back” button). This is getting goofy… a link called “Next page” but it’s pointing backwards.

← Next page

I suppose we could redesign all the templates and re-work the CSS but I think we need to take a closer peek at the workings of the `twentythirteen_paging_nav()` function which is located in Twenty Thirteen’s `functions.php` file. This function is called by the various archive template files to automatically create these pagination links as needed. Ignore the “older/newer” labels for now.

<div class="nav-links">

    <?php if ( get_next_posts_link() ) : ?>
        <div class="nav-previous">
            <?php next_posts_link( __( '<span class="meta-nav">&larr;</span> Older posts', 'twentythirteen' ) ); ?>
        </div>
    <?php endif; ?>

    <?php if ( get_previous_posts_link() ) : ?>
        <div class="nav-next">
            <?php previous_posts_link( __( 'Newer posts <span class="meta-nav">&rarr;</span>', 'twentythirteen' ) ); ?>
        </div>
    <?php endif; ?>

</div><!-- .nav-links -->

Did you catch that? They’ve place the `next_posts_link()` function inside of a `div` with the `nav-previous` class. And conversely, the `previous_posts_link()` function is contained within the `nav-next` class. This certainly explains a lot.

In defense of Twenty Thirteen, the context of the newest post being on top, the “next” page would be “older” posts. In this theme, the link to the “next” page is labeled “Older posts” and it’s pointing to the left signifying “back”. I call it “goofy” because it will break when posts are sorted in any other fashion. When oldest posts are on top or when they’re sorted alphabetically, etc., the “older” label is rendered totally meaningless. Since it, technically, always goes to the next page of the results query, it should be labeled as “next” and indeed the `next_posts_link()` function is how it’s created. However, simply re-labeling it as “next” is not good enough as it’s in the lower-left corner and pointing backwards towards the left.

My fix is simple. I copied this entire function into my child theme’s `functions.php` file. Since the original is wrapped inside `if ( ! function_exists( ‘twentythirteen_paging_nav’ ) )`, the version in the child theme will take precedence. Then I rearranged the function a bit…

<div class="nav-links">

    <?php if ( get_next_posts_link() ) : ?>
        <div class="nav-next">
            <?php next_posts_link( __( 'Next page <span class="meta-nav">→</span>', 'twentythirteen' ) ); ?>
        </div>
    <?php endif; ?>

    <?php if ( get_previous_posts_link() ) : ?>
        <div class="nav-previous">
            <?php previous_posts_link( __( '<span class="meta-nav">←</span> Previous page', 'twentythirteen' ) ); ?>
        </div>
    <?php endif; ?>

</div><!-- .nav-links -->

Now using this slightly modified version, I get a “Next page” link that always points to the right and it always goes to the next page in the results. The link in the lower-left corner is labeled as “Previous page” and always goes to the previous page in the results. This is the most logical way as that it breaks all dependance on the sorting order.

                                               Next page →

As you can see my proposed arrangement perfectly corresponds to more traditional numbered pagination with “previous” on the left and “next” on the right…

← Prev      1  2  3  4  5  6  7  8      Next →

You’ll still need to adjust your CSS a bit as Twenty Thirteen makes the “previous” link in the lower-left corner (formally called “Older posts”) about 60% larger than its mate. I think their idea was to make the button going to the next page larger. Since their positions and labels are flipped, you must adjust the CSS sizes.

Since you’re over-riding the parent theme, you’ll need to over-ride everything dealing with spacing and size. The following is the bare minimum required in the child theme to flip the sizes to correspond with our previous changes.

.paging-navigation .nav-previous {
	padding: 13px 0;
}
.paging-navigation .nav-next {
	padding: 0;
}
.paging-navigation .nav-previous .meta-nav {
	padding: 3px 0 8px;
	width: 50px;
}
.paging-navigation .nav-next .meta-nav {
	padding: 17px 0 23px;
	width: 80px;
}

jQuery Nivo Slider has broken effects within WordPress

I’m using the jQuery Nivo Slider plugin on a WordPress project. Keep in mind that this is the free jQuery plugin version, not the WordPress plugin version, so I’m doing the integration myself into a child theme of the stock Twenty Thirteen WordPress theme.

To make it align properly with the other page entries, I used the standard WordPress classes on the wrappers…

<div class="hentry">
    <div class="entry-content">
        <div class="slider-wrapper theme-default">
            <div id="slider" class="nivoSlider">
            ....

The problem is, although the slider is nicely positioned on the page, the transition effects are broken. The slider is still working but just before each transition animation is supposed to start, you get a flicker of a tiny thumbnail in the upper-left corner and then the new slide appears… no slicing, no boxing, no wiping… nothing but sadness.

I was able to recreate my exact slider code in a jsFiddle and it worked flawlessly. After much troubleshooting, I discovered that the WordPress class `.entry-content` in the parent theme was the culprit.

However, the removal of `.entry-content` fixes Nivo slider, it also breaks the layout. By the time I figure out how to recreate the necessary parts of `.entry-content` to fix the layout, I’ve a whole bunch of unnecessarily redundant CSS.

Another look at the default CSS for the parent Twenty Thirteen theme reveals line #659…

.entry-content img {
    max-width: 100%;
}

Yes, this is it. This one CSS rule is completely breaking Nivo slider’s animation effects.

The fix is to simply un-set `max-width` to the default value of `none` by very specifically targeting the slider `img` elements. I placed this rule in my child theme’s `style.css` file.

.entry-content #slider img {
    max-width: none;
}

Since `.entry-content #slider img` is more specific than the original selector, `.entry-content img` in the parent theme, it will automatically take precedence.

Nivo slider is now working as designed.

Prevent Akismet plugin from auto-deleting comments

If you’re using the Akismet plugin on your WordPress site, you love its ability to identify spam comments and automatically block them from appearing on your blog… that’s something we all should appreciate greatly.

The little issue here is that Akismet will always automatically delete any flagged comment that’s older than 15 days. There is no option to disable or change this interval.

What’s the problem with that?

  • Nothing is perfect and false positives are a possibility; in fact, it’s already happened. This means that a legitimate comment is flagged as spam.
  • Maybe you’re being stalked or harassed and you need to keep these comments as a research aid or as evidence.

If you neglect to take action within 15 days, these flagged comments are permanently deleted by the plugin.

What’s the cause?

A function within the Akismet plugin called `akismet_delete_old` checks the age of flagged comments and just proceeds to delete anything older than 15 days.

function akismet_delete_old() {
	global $wpdb;
	$now_gmt = current_time('mysql', 1);
	$comment_ids = $wpdb->get_col("SELECT comment_id FROM $wpdb->comments WHERE DATE_SUB('$now_gmt', INTERVAL 15 DAY) > comment_date_gmt AND comment_approved = 'spam'");
	if ( empty( $comment_ids ) )
		return;
		
	$comma_comment_ids = implode( ', ', array_map('intval', $comment_ids) );

	do_action( 'delete_comment', $comment_ids );
	$wpdb->query("DELETE FROM $wpdb->comments WHERE comment_id IN ( $comma_comment_ids )");
	$wpdb->query("DELETE FROM $wpdb->commentmeta WHERE comment_id IN ( $comma_comment_ids )");
	clean_comment_cache( $comment_ids );
	$n = mt_rand(1, 5000);
	if ( apply_filters('akismet_optimize_table', ($n == 11)) ) // lucky number
		$wpdb->query("OPTIMIZE TABLE $wpdb->comments");
}

You could edit it yourself from 15 days to whatever. Or you could remove the call to this functionality entirely.

However, I don’t recommend editing plugins as every time a plugin is updated to a new version, you’ll lose your edits. That, among other reasons, makes it not a good practice.

What’s the real solution?

Use WordPress’s `remove_action()` function to remove the function in the Akismet plugin that deletes old comments.

Simply place this line in your theme’s `function.php` file…

`remove_action(‘akismet_scheduled_delete’, ‘akismet_delete_old’);`

However, any time you switch themes, you’ll also lose this custom function. Instead, you can easily break this dependance by saving the following code in a `php` file uploaded to your WordPress plugin directory. It will automatically show up in the plugins section of your WordPress Dashboard. I named mine `Akismet Keep Comment` and it’s saved in a file at `/wp-content/plugins/Akismet_keep_comment.php`. Yes, you just created a real WordPress plugin.

<?php
/*
Plugin Name: Akismet Keep Comment
Plugin URI: https://www.johnkieken.com
Description: This plugin removes any comment deletion ability of the Akismet plugin.
Author: John Kieken
Version: 1.0
Author URI: https://www.johnkieken.com
*/

remove_action('akismet_scheduled_delete', 'akismet_delete_old');

?>

What about this checkbox option in the Akismet plugin?

“Auto-delete spam submitted on posts more than a month old.”

It doesn’t mean what you might think. Upon first reading, I thought it simply meant “auto-delete blog spam that’s more than a month old”. So by leaving it un-checked, I erroneously thought no comments would ever be deleted.

Okay, so what does “Auto-delete spam submitted on posts more than a month old.” really mean?

It means that if your posting is more than a month old, spam comments will be deleted instantly (rather than being held for 15 days). This part is in parenthesis because you have to dig through the php code to determine that comments are being auto-deleted after 15 days- no matter what.

I’ve discussed this issue with the developer and the possibility of the Akismet plugin having user controlled options for comment deletion. Unfortunately, they are very adamant about not allowing the user to have any control whatsoever over this automatic comment deletion. I guess you better hope there’s never a false positive. They are concerned about your server filling up with comments. Really? Many blogs are plagued with much bigger problems like hundreds of posts and thousands of images. What bothers me the most is the total lack of disclosure or documentation explaining that flagged comments will be auto-deleted, and after only 15 days.

I firmly believe this is an issue best left to the site admin, his webmaster and hosting provider to manage. No plugin should be blindly deleting comments, even those flagged as spam, without some admin control or knowledge.

WordPress tags and categories cannot share slugs

There is a very frustrating bug in WordPress that seems to not allow you to use the same slug for both a Category and a Tag.

http://www.mysite.com/category/computers
http://www.mysite.com/tag/computers

When creating Categories or Tags, WordPress will automatically append a `-2` to any duplicate slug. In other words, if you try to create a Category and a Tag both named “Computers”, WordPress will make sure one of the slugs is spelled `computers-2`. If you then try to edit the slug for the Category or Tag to remove the `-2`, it will not allow it and give you an error.

Since Categories and Tags are two different things, duplication of a slug should not be an issue. If you Google search “wordpress category and tag slug”, you will find a lot of complaining going back a very long time, and a lot of closed support threads at wordpress.org without any official responses.

However, there is a workaround to this issue.

Example:

– desired Category and Tag name: “Computers”
– desired slug: `computers`

1. Make sure no Categories or Tags already exist with a slug spelled `computers`.

2. Create the “Computer” Category first and if you leave the “Slug” field blank, WordPress will automatically create the slug `computers`. You can also type “computers” into the Slug field when creating this Category. The important thing here is to make sure your slug is spelled correctly before moving on.

3. Create the “Computer” Tag. At this step, you must manually create the slug `computers` by typing “computers” into the “Slug” field. Otherwise, if you leave the “Slug” field blank, WordPress will create the slug automatically, it will be spelled `computers-2`, and WordPress will not allow you to remove the `-2` through edits. You would have to delete the Tag entirely and start over.

That’s it. There are other workarounds to this issue which involve creating Tags on the fly when the corresponding Category already exists. However, the steps I’ve outlined above are the simplest. Good luck!