Category Archives: Blogging

Working with Weaver II–Part 2

A Pipe and a Keyboard Posted on by

I mentioned before that I had rejigged my three blogs to use Weaver II.

I am currently in the process of designing another (for a friend of a friend) and am once again using Weaver II.

It has become a real challenge to see just how far I can go without changing any code whatsoever in the core Weaver II files.  So far I am really impressed.

One of the big features is the ability to insert snippets of additional HTML, CSS or Javascript into parts of the site just by entering those snippets in at the Admin area. 

WeaverDash

So far I have been able to add CSS animation, customise a plugin’s display and to layout a complete page using CSS.  The latter was done by entering the various blocks (DIVs) on the page itself and then using custom CSS to handle those blocks.

I did come across a couple of areas though where in the bad old days I would have modified the raw code.  In particular I wanted to be able to place my own code in specific areas on pages.  For example, I wanted to insert some additional text onto the Comment form and also some Javascript (for Google Ads) onto posts.  The way around this was to install another plugin – Code Insert Manager – which does exactly what I want.  I realise there are plugins for Google Ads, but the Insert Manager does this and a lot more besides.

So far, I have managed to do everything without any file editing with one small exception – I use the CKEditor plugin for WYSIWYG comment editing and I wanted to modify the available buttons.  This isn’t possible from the admin area so I finally had to resort to tweaking the plugin’s file.

Weaver II also has its own plugin (Weaver II Theme Extras) which is essential as it contains an excellent backup feature.  All non-default settings and code additions to Weaver II are backed up to a small file which can be stored locally.  In the event of catastrophic failure the entire site can be restored using the standard installation files and then retoring all the various modifications using the backup file.

That’s assuming you have a backup of the database and images, of course!

Working with Weaver II – Part 1

A Pipe and a Keyboard Posted on by

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!

WordPress Admin Security

A Pipe and a Keyboard Posted on by

For some unknown reason, Head Rambles is frequently targeted by hackers trying to crack the admin password.

I should point out that most will have a very hard time, as the user “admin” doesn’t exist.

I have two plugins in place – Limit Login Attempts and No Soup.  While the first automatically locks hackers out after the first few attempts, the second is a more permanent fix, whereby any IP address I get from Limit Login Attempts can be entered and thereby permanently redirected to another site. 

I decided to introduce a little bit of extra security however.  What I wanted was to block access to the wp-admin directory and also to the wp-login.php file.

In fact this is extremely easy BUT there is one proviso – this will only work if you have a static IP supplied by your ISP.  If you have a dynamic IP then do not try these.

All I did was to create a little .htaccess file for my wp-admin directory –

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "Access Control"
AuthType Basic
order deny,allow
deny from all
#IP address to Whitelist
allow from 123.123.123.123

Obviously 123.123.123.123 should be replaced with your own IP address.

In theory, this is all that is required, as even if the password is hacked then entry is forbidden into the Admin directory.  I decided to go one step further, just to stop all those warnings about attempted logins and to protect the wp-login.php file.  Again this was simple.  All I had to do was to add a few lines to my root .htaccess file –

<Files "wp-login.php">
    Order deny,allow
    Deny from all
    Allow from 123.123.123.123
</Files>

With those two in place, hacking will be be considerably more difficult.

One advantage of this method is that you can update WordPress without destroying your protection.

One disadvantage is that the site can only be updated from the one location, so if you are accessing the site from some different location [for example, on holidays] then you will be locked out.  In that event either you forgo updates until you are back at base, or you FTP into the site and rejig the .htaccess file.

Changing WordPress defaults

A Pipe and a Keyboard Posted on by

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.

Dead blogs

A Pipe and a Keyboard Posted on by

I thought I would try a little exercise today.

There is a list of the top 100 Irish blogs at Justin Mason’s site.  Now this list is old, but unfortunately I don’t know just how old.  However I reckon it dates back to some time in 2008.  For my little exercise, I thought I would test those sites to see just how many are still active.

The vast majority are indeed still there .  Some however came up completely blank or are restricted access.  I decided to test the sites I could access and see how recently they had been updated.

How do you define a redundant blog?  I decided that if it hadn’t been updated in the last 60 days then it was probably dead.  The result is a little disappointing.

Of the 100 blogs, over half [53%] haven’t been updated.  If I use a tighter figure of fourteen days, then 60% are gone.

Now the list claims to give the top 100 sites by Technorati Rank so it is not a comprehensive list of all blogs.  However one would assume that to gain a listing, the blog would have to be fairly popular, and the author would have to be reasonably dedicated, to the 60% death rate is a little surprising.

Maybe they are right.

Maybe Irish blogging is terminally ill?!