One of the big problems with customising themes is that the theme’s core files have to be modified.

So you spend a happy few hours modifying style.css and you get the site looking just as you wish.  Then along comes an update to the theme which nicely overwrites your customised style.css and you are back to where you started. 

Of course you should have a backup of your customised file, but suppose the update included the theme author’s updates to style.css? 

As I have already pointed out, Weaver has the facility to insert your own code (CSS or HTML) into the header or footer of the site without any file editing.

An example of this is in the layout of the nested comments on the theme.  I felt that the reply to a comment wasn’t indented enough, and could lead to some confusion, as it wasn’t immediately obvious whether a comment was a new comment in its own right, or a reply to a previous comment.

The obvious way was to modify the style.css file but I went the route of adding an insert of some CSS into the Header in the (Advanced) Admin area –

.commentlist li.comment, #respond  {
margin-left: 15px !important;
}

This had the desired effect.  The effect is small but significant enough to improve readability –

Since I made that modification, there has been an update to the Weaver theme.  I applied the update and all my modifications remained intact.

Another hugely significant feature is that in the event of catastrophic failure I only need three things –

1. A database dump (mailed to me daily via a plug in)
2. A copy of the images I have created
3. A tiny XML file which Weaver creates and which contains all the modifications I have applied to the theme, including code inserts.

Every other item I need can be downloaded from the Internet.

Not many themes can do that?!

I started writing blogs back in 2006.

After a bit of searching at the time I found a template I liked, that was simple and easily adaptable, and have been using that template ever since.  In fact I started a second blog and used the same template (heavily modified) on that too.

Over the years, both the CSS and PHP files in the template were extensively modified, particularly as in the early days (pre-widget) I had hard coded a lot of items straight into the template files.

A couple of weeks ago I decided it was time for a bit of an overhaul.  The first thing I did was to “widgetise” Head Rambles.  That was fairly painless and the result looked almost identical to the original.  However I still had a load of modified template files and the CSS was in a bit of a mess.  I decided on a change of the core theme and template.

My good friend Kirk pointed me in the direction of Weaver II, which is a template he has been using.

My first impression was that it looked a bit daunting.  I set up a local server on my laptop and installed it there.  Sure enough, there was a bit of a learning curve.  The Admin area is quite large with a lot of options.

My first project was to create a theme to match the Rambles one as closely as possible.  The further I went the more impressed I became.  There is virtually no aspect of the design that couldn’t be changed from the Admin area.

Rambles is now running the new Weaver template and the original design.  The main aspect is that I haven’t touched a single PHP or CSS file so updates/upgrades won’t destroy anything.  As a bonus, I have been able to remove several plugins as their functions are built into Weaver. 

The only drawback, if you can call it that is that the theme is three times slower that the old one.  Does that sound bad?  If I say that the old one took 0.07 seconds to load while Weaver takes 0.2 seconds?  Not bad considering all the additional bonuses.  The new site is mobile friendly (previously I had to install a plugin and a clatter of extra themes).  It has a much better comment area, with nested comments.  And I can make any changes to the theme with a couple of clicks of the mouse, with no FTP or file editing at all.

Since then I have also redesigned this site and Smoking so all three sites are now updated.

I have a feeling I will be writing a bit more about Weaver!

If there is one thing a hacker likes, it’s default settings.

Two of the settings in WordPress that originally were unchangeable were the default user – admin, and the database table prefix – wp_.

Nowadays both these can be changed at the time of installation but many people fail to do so and they remain at the default.

Changing them on an established site is not too difficult.  Once you have a tool like phpMyAdmin then it is pretty straightforward.

Changing the default username is the simplest job of all – simply open the ‘wp_user’ table and change the user_login to something other ‘than admin’.  The password and permissions will remain the same.  From experience, hackers trying a brute force attack will always use admin because a)  that’s the default and b) because trying to crack a username as well as a password is exponentially more difficult.

Changing the database table names is a little more time consuming.

First of all, the site needs to be taken off line, as any changes (such as comments) made during the fix will more than likely be lost.  I use the Ultimate Maintenance Mode plugin for this.

Next you need to check the maximum upload filesize allowed by your server.  A simple way to check is to select “Import” in phpMyAdmin and it will tell you.  A typical value would be around 10 to 15 Mb.  The reason for this check is that it is easy to download a database dump. but you may not be able to upload it again if the file is too big.  Most small sites will give little trouble, but a larger, well established site with thousands of posts and tens of thousands of comments will generate a dump well in excess or the limit.  The simple way around this is to export the database in batches of groups of tables.  Compression is another way around this, but for the sake of simplicity it’s best to use a SQL dump rather than a compressed one.

Once the file (or files) has been downloaded it is a simple matter of opening it (or them) in a text editor and doing a Search and Replace.  Note however that within the dump file there are two types of single quote.-

DROP TABLE IF EXISTS `wp_posts`;

CREATE TABLE IF NOT EXISTS `wp_posts` (

`ID` bigint(20) unsigned NOT NULL auto_increment,

`post_author` bigint(20) unsigned NOT NULL default ‘0’,

Both types are shown in the above example.  The oblique quote appears before wp_… and the straight quote at ‘0’.  Doing the Find and Replace, it is essential to use the oblique version.  Cut and paste is the simple solution.

Decide on a new table prefix (I’ll call it ‘fixed_’ and then do the Find (`wp_) and Replace (`fixed_). on each and every SQL dump file.  Once that is complete, import the file(s) back into the database.  You should now have doubled the number of tables, half with the old prefix and the rest with the new.

Now open up the file wp-config.php and change the value  of $table_prefix to the new one .

The site is now ready for public viewing, but you will find one rather nasty looking problem – when you try to access the Dashboard. or the Admin area you will get a message –

“You do not have sufficient permissions to access this page”

To fix this, (using phpMyAdmin) open up the table  ‘fixed_usermeta’ and modify any data in the ‘meta_key’ field that starts with the old ‘wp_’ to the new prefix ‘fixed_’.  You should end up with fields containing the likes of ‘fixed_capabilities’ and ‘fixed_userlevel’.

Lastly, open the table ‘fixed_options’.  You will see an entry under ‘option_name’ called ‘wp_user_roles’.  Change that to ‘fixed_user_roles’.

That’s it.

The site should now be happily running with a new administrator user name and a non-default database.