Increasing the economic cost of WordPress logins to bad client browsers

With the recent attack on Workpress sites it struck me that if all logons were more expensive in CPU to the clients and if this CPU burden was used to generate crypto currency then whilst normal logon demands would not impact any one legitimate user, a distributed brute force attack would be slowed and at the same time financially aid the attacked web sites. This would thus offset the economic cost to sites that are brute force attacked.

This is a very different strategy from plugins which mine visitors. A logon is a client solicited  request whereas a mining plugin that mines visitors is unsolicited use of the client CPU.

Most human users of WordPress sites stay logged on through  cookies so a one-off load (which could be dynamically adjusted to only kick in inversely proportional to the attack rates) would not be noticed. An attacking client though would suddenly find that WordPress logons become ever increasingly more expensive in client side CPU. The greater the attack rate then the more crypto currency mined for the benefit of the attacked web site.

This would not create a new opportunity for attackers as any attacker that has control of client machines would just mine crypto currency locally on the machine without all the hassle of attacking other machines.

No posts in WordPress after server/php migration due to obsolete/broken plugin

The scenario is that you restore you files and database to a new host and then when you access the dashboard (as well as the front end) you see no posts. They are listed i.e. All (nnn) Published (x) Draft (y), but there are none displayed.

Equally, you upgraded the current server to a new version and this upgrades the php version.The site may work (with blank list of posts) or the site may break and the frontend or administration cannot be accessed.

We had this and for us it was a very stale plugin that should have deleted years ago (Psychic Search) !.

If this happens to you and you have back-end access to the administration interface then deactivate all plugins that are old until the site comes back correctly.

If the site is so broken that you do not have access to the administration interface then you can use FTP to go to wp-content/plugins and then go through the change date and from the oldest dated plugin, download it (to take a backup) and then delete the plugin. When WordPress tries to load the now-deleted plugin then it can’t and the plugin becomes deactivated. This should get you back into the site and you can then use the administration interface to either install a updated version of the broken/obsolete plugin or an equivalent that does have support for your host/php version.

WordPress HTML markup breaks plugin shortcodes

I was extending a WordPress plugin (I don’t think the actual plugin matters but it was the very useful posts-in-page plugin). It has a loop (posts_loop_template.php) that displays the posts on a page. We need this for a web shop.

On the page I had the plugin shortcode, [ic_add_posts thumbnail=’thumbnail’ showposts=’5′ postlink=’1′ layout=’0′ metacats=’0′ metacomments=’0′] as shown and in bold (for no particular reason).

I noticed that my code changes had stopped working.  An hour or so ago they had worked but after adding some of the new options they stopped working. I removed the plugin and added it back (it started working) and then I added back my edits and managed to trigger the problem again. This time I had more data and it was obvious what had gone wrong. When I added in the shortcode options then when you look at the “Text” version I saw that the new option had html markup around it,

<strong><strong>[ic_add_posts thumbnail='thumbnail' showposts='5' postlink='1' 
layout='0' metacats='0' <strong>metacomments='0'</strong>]</strong>

This caused the option arguments to be parsed wrong by WordPress – or perhaps correctly but it wasn’t what I wanted. The options array ended up like this and you can see the “metacomments” option was not parsed but is in the array as [0] => metacomments=’0′ and not [metacomments] => 0

Array ( [post_type] => post [post_status] => publish [orderby] => date 
[order] => DESC [template] => [posts_per_page] => 5 [thumbnail] => thumbnail 
[showposts] => 5 [postlink] => 1 [layout] => 0 
[metacats] => 0 [0] => metacomments='0' [post__not_in] => Array ( ) ) 

When I removed the html formatting from around the plugin shortcode then it worked perfectly. As a guess WordPress should strip tags but that may have backward compatibility issues.

Site Landing Page fronting WordPress

A client wanted a site-wide landing page with some basic images and a few navigation buttons to front-end their WordPress site and other places like their Etsy shop and Social media links.  Out of the box WordPress allows you to define a home page (see under the admin options for Settings->Reading) but that isn’t exactly what they wanted as that is still within WordPress and so has the header, menus and footer and all the other stuff related to a WordPress site unless the theme allows for all of these to be turned off.

When you connect to the URL without any path or a resource file name e.g. rather than for example then (using Apache) the file that will be presented if a file is not specified in a URL is decided by the mod_dir  DirectoryIndex directive (or in IIS the <defaultDocument> elements).

WordPress by default has an index.php file in its root and usually this is what is normally used. If your hoster has setup their DirectoryIndex similar to the above then the index.html file will override the index.php If so then you are good to go. If not then you will have to get your hoster (or it may be you) to get index.html being dished out in preference to index.php. The two options open to my client are to,

a) move the WordPress out of the site root e.g. move the files to /blogging or similar subdirectory and then add a static web page e.g. index.html
b) or add an index.html with static code in it that will be run first before index.php

The option a) is obvious but I wanted to avoid that for the moment so I picked b) to see if that would work. Please read the “quirks” at the bottom and test this on your own test beds before playing with a client site !

Step 1) On WordPress create a new page with any name and slug (we’ll called it My Home and have a slug of my-home )
Step 2) Copy the contents of the existing Home page to this new page (use control-C and control-V or similar)
Step 3) There is usually no need to change anything in Settings->Reading for the front page displays but you cannot set it to a Static page that is navigable in the menu. The reason being is that whatever you set as the WordPress Static front page is given a slug of /. If it is already set to posts of Home then you can leave it as that.
Step 4) Edit your Theme menu in Appearance -> Menus and remove the existing “Home” or whatever has a slug of your site root (/) and replace it with your new copied home page (in my example “My Home”)
Step 5) You can add the original Home page back but give it a different name e.g. “Site Root” as it will jump you back to the non-Wordpress file.
Step 6) Test that your tweaked WordPress site still works OK. You won’t notice many problems yet.
Step 7) Create an index.html file and have at least the one link to your new “My Home” WordPress slug e.g. <a href=”./my-home”>My Blog Site</a>
Step 8) Upload and check the new file gets priority. If not then check the Apache mod_dir  DirectoryIndex directive is set correctly e.g.

<Directory /> 
DirectoryIndex index.html index.php 

That is all is needed. Now when web visitors hit your web site they will get the index.html and they can then navigate from there. When they click any WordPress link slug from that landing page then they then go to your WordPress site and will stay there unless you have given them a menu option to escape back up to the index.html.


  • You MUST set Permalink Settings to something other than the default of …site/?
  • When you are in Media Manager then when you try and view an attachment then it will go to the attachment page and not the media file link.
  • When you insert an image into a post or page then do not use the attachment post ID but the media file link.
  • This may not work on other web servers – I have only done this on Apache

Enabling anchor for Disqus comments on WordPress site

When you add Disqus to your site e.g. as I did with then make sure that the following Disqus plugin advanced option is set,

Comment Counts   [ * ] Output JavaScript in footer

If it is not checked then when you click the post and then click the (theme dependant) link that is usually at the top of a post to jump to the comments at the bottom of the post, it does nothing. The default WordPress anchor tag is #comments but with Disqus it is #disqus_thread

When this disqus plugin advanced option is checked then the correct anchor is used and you will jump to the Disqus comments as expected.


Enabling WordPress comments

I just enabled WordPress comments on my own personal pages. For the moment I’ve enabled the SI Captcha plugin and to remove the default website link in the comment form I added the urlfilter.php file trick that I found here.

You do not need to be registered to logon but you need a name and email but all comments are moderated.

To retrofit enabling comments to older posts then you go into the All Posts dashboard option, check the box next to the title to select all the posts and then in the Bulk Actions you select Edit and then Apply. This will open a lot of selection and options. Pick the Comments option of Allow and then do Update.

Needed to add SMTP support with WordPress 3.4

Using Contact form 7 Version 3.2 fine on my personal blog web site and then upgraded to WordPress 3.4. The contact form stopped working with the usual red administration error message.

I found that I had to add WP-Mail-SMTP (latest version Version 0.9.1 ) plugin and set SMTP to defaults of localhost and then it worked again.

Rather odd. Take care if you are upgrading to WP 3.4 to check your contact forms still work.

wp-super-cache stale cache due to Apache permissions

This may happen to you in that web pages for anonymous users (i.e. not logged on) stay stale even when you use “Delete Cache” in WordPress dashboard and clear the data from your browser. The page contents stay stale and menus (if they were changed) stay on the old layout.

If this happens to you and you are pulling your hair out in testing and unable to get the pages to display on the new content then ssh into your server and check the permissions (ownership) of the /wp-content/cache is actually owned by the web server and has not been changed..

After a Plesk/Parallels upgrade (automatic I think) the user that Apache ran in changed and this meant that files that were previously created by Apache using the old user account were now not able to be deleted by the new Apache account user (www-data). This is probably never going to be seen on shared hosting but could be seen on virtual or dedicated servers.

The WordPress site would have kept dishing out the old file not matter what I did because the old cache files couldn’t be deleted.

The fix is easy (assuming your Apache installation is going to remain stable) and that is to ssh shell into your account and delete using the file owner (or root) the contents of the /wp-content/cache directory (which will have a “meta” and  supercache” subdirectories.

You may also be able to use your FTP client to do the same but probably the cache directory won’t actually be visible at all.

Once you have deleted all of that old stuff then go back into the wp-super-cache plugin settings and remove and then re-enable the cache settings.

Non-logged on browsers will now correctly display the site and the supercache/… files correctly build up with the ownership being the Apache web server.

To test this I use Firefox and Opera: Firefox is logged in and Opera is used to display the web site as an anonymous user. Opera has a nice feature in Opera -> Settings -> Delete private data that you can quickly clear the browser cache of everything.

Adding WP 3.0 custom menus to older templates

For our web site we have used a nice template by called Creative by Nature.

Recently we wanted to add a link in the navigation menus so we opened up the Custom Menus for the site and then saw that it did not support the new WordPress 3.0 custom menus.

All is not lost – it is easy to add in the same functionality to this older template without doing many changes and with no CSS style changes.

Here is how I changed the Creative By Nature v0.1 template to use the WordPress 3.0 custom menus,

1) Open your site and select the menu in a browser and then right-mouse and view selection text. Print this out. This is to just get an idea on the div, ul, il, a and spans that are used.

The template we’re using had a div wrapper that was an id of “navigation” and then a ul and then all the a hrefs but the link text was in a span. Now this navigation ID and the span is important as you need to mimic this in the new WordPress 3.0 custom menu unless you plan on changing the CSS style sheet.

2) Firstly find where the navigation menu is located. It will probably be in your template in a file called header.php or a similar name and now find where the menu is generated. It will be a function that is echoed or something similar e.g. we had,

<div id="navigation">
 <?php echo _generate_navigation(); ?> 

The “_generate_navigation” is in the theme’s functions.php file. The menu generation will be between these two files i.e. your theme layout code file and your theme functions code file.

3) Now comment or remove the old code that generated the navigation menu and add in your replacement as below, setting the container_id to be the same as the div ID and if needed also wrapping the link text in a <span></span> by setting the link_before and link_after variables e.g.,

<?php wp_nav_menu(array('menu' => 'header_menu',
 'container_id' => 'navigation', 
 'link_before' => '<span>',
 'link_after' => '</span>' )); ?>

In our example that mimics the html that is generated for the same CSS to be used thus no need to change the CSS stylesheet for the theme. For the defaults for this wp_nav_menu() function see here –

4) In the functions.php file for this template you will have to add the following code,

add_action('init', 'register_custom_menu');

function register_custom_menu() {
register_nav_menu('header_menu', __('Header Menu'));

You can add as many menus as you like though you would use register_nav_menus() e.g.

register_nav_menus( array( 'header_menu' => 'Header Menu', 
 'footer_menu' => 'Footer Menu'));

and you can edit out the old _generate_navigation() function if you want. Note that if you want to keep both < 3.0 navigation menus and 3.0 custom menu features at the same time then keep everything and in the header file or in the functions.php you could add a test e.g. if ( function_exists( ‘wp_nav_menu’ ) ) and then use the new 3.0 menus or else use the theme’s old code if that function_exists() returns false.

Getting Plesk default domain page and not your WordPress install ?

If you have uploaded the WordPress files to a new site and are still getting the Plesk Default domain display then you have probably forgotten to delete the old Plesk skeleton site especially the index.html file. By default a site will pick the index.html before index.php and so the WordPress index.php file is never read.

You should ideally delete all of the files in this httpdocs location before uploading and installing a new site.

Using WP-Mail-SMTP if host provider has disabled PHP Mail

One of our hosting companies that we have a reseller account on has disabled PHP Mail function for security reasons. This causes the WordPress sites that use Contact Form 7 (with Really Simple CAPTCHA) to fail with,

“Failed to send your message. Please try later or contact administrator by other way.”

To fix this you need to enable the WP-Mail-SMTP  plugin. To install this download the plugin and upload to your site as normal and then activate this on a per-site basis (not Network activate).

You will now have new options in the Settings -> Email on your site dashboard of which the most important is “Send all WordPress emails via SMTP.”  (checked by default).

Set these parameters as per your hosting provider recommendation though you usually can just specify one of your own email addresses on your domain as the From Email and set it to localhost and no authentication and it should work.

It is usually only when the from email domain is not a local domain on that server that you will have problems and need to authenticate your connection or if the SMTP server is not “localhost”.

If you have it right then you will get the message “Your message was sent successfully. Thanks.”



Choosing WordPress

You’ll probably recognise that this and others that we use are WordPress based blogs. Why have we settled on this CMS ?

It is just easy to use. You don’t get many shocks or surprises with the layout of your posts (i.e. your articles). Sure, it hasn’t the sheer quantity of functionality of our other favourite, Joomla, but if you just want to be able to get your message onto the Internet without a steep learning curve nor with onerous support requirements then you can’t go wrong with WordPress.

If you want to create many users and have a much more complex set of permissions then you need to look towards something like Joomla. In the end it will depend upon your requirements. If those are not clear then you could end up with the right solution but it’s fixing the wrong problem !