It’s popular because it promises that strange SEO voodoo at the click(s) of a mouse and a few taps of a keyboard through the magic of the WordPress plugin.

It’s easy to install and relatively easy to setup if you already know all your SEO terminology.

So, I’m not a big fan of the plugin. From what I could work out, 98% of the features it provides really should be baked-in to any half-decent website.

The value is no doubt for those that either don’t have the tech-savvy to build such features into their websites or maybe because of shared or limited hosting access can’t tinker with the raw HTML/CSS/PHP of their website.

After installing the All-in-One SEO Pack (v1.6.13.8) plugin on WordPress v3.3.1 for the first time, I get this error message on the front-end:

Notice: Undefined index: aiosp_ex_pages in /var/www/wp-content/plugins/all-in-one-seo-pack/aioseop.class.php on line 118
Notice: Undefined index: aiosp_ex_pages in /var/www/wp-content/plugins/all-in-one-seo-pack/aioseop.class.php on line 118

Travelling to line 118 in aioseop.class.php I get to see:

110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129

	function aioseop_mrt_exclude_this_page(){
			global $aioseop_options;
			$currenturl = trim($_SERVER['REQUEST_URI'],'/');
	/*		echo "<br /><br />";
			echo $aioseop_options['aiosp_ex_pages'];
			echo "<br /><br />";
*/
 
			$excludedstuff = explode(',',$aioseop_options['aiosp_ex_pages']);
			foreach($excludedstuff as $exedd){
				//echo $exedd;
			    $exedd = trim($exedd);
			            if($exedd){
			                if(stristr($currenturl, $exedd)){
			                    return true;
				}
			}
		}
		return false;
	}

From a quick look it seems like there is no check to see whether or not they index/key aiosp_ex_pages existing within the $aioseop_options variable, which it most likely would not following a fresh install.

Quick fix, should be just to add a conditional statement to check if that index/key is in fact set before looping over it.

See fixed code below:

110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132

	function aioseop_mrt_exclude_this_page(){
			global $aioseop_options;
			$currenturl = trim($_SERVER['REQUEST_URI'],'/');
	/*		echo "<br /><br />";
			echo $aioseop_options['aiosp_ex_pages'];
			echo "<br /><br />";
*/
			// check for existence of key.
			if ( isset( $aioseop_options['aiosp_ex_pages'] ) )
			{
				$excludedstuff = explode(',',$aioseop_options['aiosp_ex_pages']);
				foreach($excludedstuff as $exedd){
					//echo $exedd;
					$exedd = trim($exedd);
							if($exedd){
								if(stristr($currenturl, $exedd)){
									return true;
					}
				}
			}
		}
		return false;
	}

That should silence those notice errors. Of course you could bury your head in the sand and just turn all error messages off so you don’t even see this, but that wouldn’t be good web development, would it?

Any questions/comments, drop a line below.

Normally, you can handle this in one of two ways. The first is do a fresh install of WordPress at the new location, exporting your old data from the previous site and then re-importing into the fresh install. This carries with it it’s own set of issues but is a viable option. The main problem though is the concurrency of the two databases when it comes time for fixing or maintenance.

The second is you can copy the whole site and transplant it, database, files and all. The problem with this approach is unless your previous environment was identical to the location you were moving it to, your links would now be broken.

The easiest way to fix this (I’m found so far) is to execute a few SQL statements on the database in question. It’s effectively a find and replace. The main tables to take note of (as of WordPress 3.3.x) is wp_posts and wp_options.

Note: I’m assuming you’ve backup anyway before running these statements on your database.

UPDATE wp_posts SET guid = REPLACE(guid, 'http://localhost/', 'http://example.com/');
UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://localhost/', 'http://example.com/');
UPDATE wp_posts SET post_excerpt = REPLACE(post_excerpt, 'http://localhost/', 'http://example.com/');
UPDATE wp_options SET option_value = REPLACE(option_value, 'http://localhost/', 'http://example.com/');

Any questions? Drop a message below.

More often than not, upgrading your WordPress platform can be a pain because it will involve various steps to ensure you don’t accidentally screw-up your entire site and database. And there is nothing wrong with it because backing-up your important data is always a good idea.

The annoying part is downloading the latest version of WordPress and then uploading those files to your server, ensuring you don’t accidentally overwrite your themes or plugins etc.

Using the built-in support for auto-upgrading via FTP is quite slick within WordPress 3.x and I’m sure will only improve.

I managed to be able to update WordPress from within the admin area using the following commands:

In this example I’m using VSFTPd as my FTP server and I’ve chosen to create a new user called ‘wordpress’.

sudo apt-get install vsftpd
sudo useradd wordpress
sudo passwd wordpress # set password for wordpress when prompted.
sudo usermod -g www-data wordpress
sudo chmod -R g+w /var/www
sudo chown -R www-data:www-data /var/www
sudo vi /etc/passwd # change wordpress home to be: /var/www
sudo service vsftpd restart
sudo service apache2 restart

Hopefully those commands should be self-explanatory but if you need clarification, drop a comment and I’ll try and make it plain.

The problem was that we had a never ending redirect loop on the homepage after upgrading from WordPress 3.0 to 3.1.

The hosting environment seems be the cause of the issue as after the upgrading on a local development environment which is effectively a WAMP stack (Windows XP running Apache etc.), there were no visible problems.

When making these changes to the live site, there would be a never ending redirect loop.

The production environment is a Windows Server 2003 (R2 Standard x64 Edition) running IIS6 with an ISAPI filter called WordPress URL Rewrite (v1.0) which gives us search engine friendly (SEF) URLs on IIS.

We eventually stumbled upon this thread in the WordPress forums:
Windows server infinite redirect after upgrading to 3.1

At the moment there is no clear solution other than to disable the redirecting feature which appears to be the canonical redirect feature. The ISAPI filter must interfere with this process causing the perpetual redirecting.

A simple fix, you can add the following snippet to disable the canonical URL redirect features of WordPress 2.3 and above. All credit to Mark Jaquith (@markjaquith) for coming up the original idea.

If you have a custom theme, the best place for this snippet would be at the top of your functions.php so that you can remove it once WordPress releases an update that fixes this issue.

If you are really lazy or not sure what your doing, there is a WordPress plugin by Nick Schalk and Chris Cheney that will pretty much do this for you. You can grab it here: Permalink Fix & Disable Canonical Redirects Pack

Keep in mind that this fix worked for the environment we experienced this problem on, but it may be relevant if have a similar setup and you are seeing a similar issue.

If you have come across a better solution, please do let us know.

As a result I’ve resorted to extending WordPress and the results have been pretty encouraging already. I have to say, for the record, that the WordPress team has made extending the WordPress platform a breeze through custom plug-ins and hooks.

OK. Enough WordPress appreciation and on to the reason for the post.

I recently needed a quick and easy way to get the slug for a post parent.

The site I’m working on has a series of sub/mini-sites under the root directory, meaning that there will be multiple homepages for each of the sub-sites and each sub-site will have it’s own navigation options.

As a result, I needed a quick way of determining which sub-site a ‘home’ slug returned for the current page belonged to. Now, the way I had structured the pages in WordPress was by creating a separate ‘home’ page for each sub-site as a page of the root site so the URL’s would be:

[root directory] http://artofsimplicity.co.uk/
[sub-site 1] http://artofsimplicity.co.uk/sub-site-1/home/
[sub-site 2] http://artofsimplicity.co.uk/sub-site-2/home/

The way I went about doing this was to retrieve the slug for the parent page, which would either return ‘sub-site-1′ or ‘sub-site-2′.

Achieving this was quite straightforward with the following snippet of PHP code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<?php
 
	// retrieve the page slug.
	function get_post_slug($post_parent = false){
		global $post; // WordPress global $post
 
		if($post_parent){
 
			$parent = get_post($post_parent, OBJECT); // get the post data.
 
			$slug = $parent->post_name; // get the post_name/slug
 
		}else{
			$slug = $post->post_name; // if not a post_parent the post_name/slug for the current page will already be accessible.
		};
 
		return $slug;
	};
 
	// same function as above but wrapped up in a new function for convenience.
	function get_post_parent_slug(){
		global $post; // WordPress global $post
 
		return get_post_slug($post->post_parent); // once the current post data is loaded you can retrieve the post_parent ID to retrieve that posts post_name/slug.
	};
?>

Maybe this simple little snippet will help those trying to achieve a similar effect in WordPress.

At the time of writing WordPress 3.0 has just been released so we’ll see if it’s no longer needed in new version.

I have great admiration for the WordPress auto-upgrade feature particularly as it saves you loads of time especially if you administer a number of WordPress based websites not to mention your own blog.

The convenience of the auto-upgrade is obvious, although most people quite rightly would prefer to manually upgrade a WordPress installation particularly if the installation is heavily customised. Needless to say, the auto-upgrade feature does not negate the usually and very necessary manual backup of your database and your wp-content folder if you’ve installed a number of themes and plugins, but once you’ve done so it’s nice to let WordPress do the rest of the hard work.

For a while on this blog, when I attempt to do the automatic WordPress upgrade I am greeted with the FTP login details screen, asking me for my username and password to allow the download and upgrade of the WordPress installation to happen. On other websites (some running on a Windows server) this is interstitial page doesn’t even show up and the upgrade happens virtually instantly, no FTP login details screen, just straight to the downloading and upgrade. So’ve I’ve been wondering how to get this working for my own blog on a Linux distro.

I stumbled across this well written blog post on ‘Why WordPress Asks for Connection Info‘, the main problem is a ownership/permissions issue and this can be quite quickly corrected if you know what process Apache runs as on your server.

Some blogs have mentioned it to run as www or httpd, but for me and I’m guessing other 1and1 users it is most likely running as apache but there is a quick and easy way of finding out, by running the following PHP script:

1

<?php echo(exec("whoami")); ?>

Once you know what name Apache goes by, you need only login to your server via SSH as root and change the ownership of the WordPress installation directory to Apache, but wait – there is a catch, going ahead and changing the ownership of the directory to just Apache will prevent you from making any changes to the directory if your not Apache, so if you login via FTP and you want to upload some new plugins or themes, you won’t be able to.

To ensure you and Apache have the correct permissions you need to know what your username is and this can be easy if you login by FTP as any decent FTP client, such as FileZilla, will show the owner of the directory when you login.

In case your not sure, you can find all the usernames within /etc/passwd but once you know you then need to navigate from the root directory to your website directory where the actual files and the WordPress installation directory is found. In case your not sure it would most likely be something like /var/www/vhosts/mywebsite.co.uk/httpdocs/ for 1and1 Linux VPS users.

Once you know where you are and what your username is, you can run the following command via SSH as root:

1

chown -R yourusername:apachegroupname wordpressdirectory

What this line does is it changes the file owner and group for all files and folders in subdirectories of the directory wordpressdirectory, i.e. recursively. So for me, assuming I’m already in the website folder at /var/www/vhosts/artofsimplicity.co.uk/httpdocs/ it would be something like:

1

chown -R artofsimplicity:apache blog

That should be it. WordPress may still ask you for the FTP password but it should have no problems upgrading the installation or upgrading any plugins that have updates without you needing to do anything else (I’m assuming you’ve already backed up anything you wouldn’t want to lose).

If you’re still having issues, drop a line below and I’ll try and help or let me know if the above has been helpful for you.

A problem or annoyance that I come across is when I need to move a development site from my local development environment to an online test area/server where clients can view their website in an online environment, which will operate very differently to just running the same set of files on your own computer which more than likely has a perfectly tuned settings so you can do just about everything.

A very basic tip is for moving your database from your local database to an online database. WordPress already makes this pretty easy and so you could quite easily get away with creating a fresh install each time but after a while even that becomes time consuming as then you need to set the same settings as you have on your local development site.

This becomes even more problematic, doing a manual/fresh install, when you use WordPress as a CMS more than just blogging software as sometimes you may build pages that retrieve information based on a specific post ID. With the ID’s being automatically assigned, you cannot always guarantee you’ll get the same ID’s even if you set up all the pages and all the content in the same order. In part, this is because of the WordPress auto-saving feature which will save a draft, taking up another ID. This will quickly lead to a mismatch in your preconfigured code which cites specific ID’s for specific pages and the actual ID’s that are assigned to the content you are creating.

The way I like to avoid this is by importing the whole MySQL WordPress database from my local development site into my online MySQL database where my live test site will be running.

The main problem with doing this is that all the URLs in the database will refer to ‘http://localhost/’ but now with the site being online, I need to change the base of the URL across all the content and especially in the settings of the website, otherwise the website will not work or the results may be unpredictable.

A quick way to rectify this is directly via the database using the SQL Update statement. While using phpMyAdmin is highly recommended for doing this it is equally possible to do this via the command line if you have the necessary know-how!

The three main SQL queries you’ll be needing are the following:

SQL Query 1: Updating your WordPress Posts Permalinks

1

UPDATE wp_posts SET guid = REPLACE(guid, 'http://localhost/', 'http://mydemosite.com/')

The above query will update all you post content for your WordPress install changing every occurrence of ‘http://localhost/’ in your post guid to ‘http://mydemosite.com/’. You may argue that if you are using WordPress as a straight CMS you won’t need to worry about this, which is partly true, but should you use it for both a CMS and to provide a blogging platform, your going to need to change the permalinks for all the posts across the entire site. After all if your using RSS you want people to be redirect to actual post and not some 404 page on some other website.

SQL Query 2: Updating your WordPress Options/Settings

1

UPDATE wp_options SET option_value = REPLACE(option_value, 'http://localhost/', 'http://mydemosite.com/')

This query is necessary for the main running of the website. It is where you main homepage URL is stored along with a few other important fields that help index your website correctly. If your sending indexing services the wrong URL it’s not going to help your chances of your website in the search engine stakes at all. There may be additional rows in this table if you have certain plugins installed.

SQL Query 3: Updating the installation path

1

UPDATE wp_options SET option_value = REPLACE(option_value, 'C:\htdocs\mywebsite\news/wp-content/uploads', '/homepages/1/a123456789/htdocs/mywebsite/wp-content/uploads')

If like myself you work on a Win32 platform but prefer to host your websites on a Linux server, you’ll definitely need to do this. If your development environment and your server are both Win32 platforms you’ll have to worry about this a little less if you’ve configured them identically, but more often than not, they won’t be identical.

This path is crucial for your WordPress cache and for uploading and storing content like images to accompany your posts as you need to get the absolute installation directory of the folder as it is on the server. This will be different between a Win32/Windows XP and a Linux or Mac environment.

While the basic principle is simple, effectively using the UPDATE SQL statement for updating whole tables, it will save you a lot of time if its something your likely to do on a regular basis.

Once you get a few projects under your belt, and especially where using fully featured Content Management Systems (CMS) like Joomla! or WordPress, where you can make 60-70% of the changes you need directly through the back-end administration, you’ll find your local/development version of your website quickly becomes out of date in comparison to the live site.

This is the point I discovered myself at recently (again) and what I normally do at this point is do a quick update to my local site by copy all files directly from the live site to my testing server but that’s the easy bit. The hard part to all this is copying the database from the live site to the local site which is where much of the configurations are stored, rather than the static files which you’ve already copied to your hard drive.

If you have been working with MySQL for any length of time, I hope you’ve come accross phpMyAdmin, which for the uninitiated, is quite possibly the best  open source tool written in PHP and it allows you to handle the administration of MySQL databases over the Internet in a web browser.

Well, using phpMyAdmin, you can quite easily export the entire database to a .SQL dump file, which for my particular project was well over 50MB of pure data. This will take a few minutes to download, depending on your connection speed, but the problem is importing any large file into your local MySQL database where you do all your testing. Now, I don’t have exact limits, but uploading large files through web browsers is fraught with problems, most notably because most have a tendency to timeout after a specified period of time, and for files much larger than 50MB, that presents a real problem.

I’ll admit that there are ways around this, such as altering timeout settings on the script running the upload or changing the browser settings itself but there is an easier way to this, and I’m going to explain how (hopefully).

The easiest way to do it is via the command line on your computer. Now I know many beginners will at that moment freak out but it’s easier than you might think.

Step 1: Fire up the Command Prompt through: Start > Run and then type ‘cmd‘ and hit Enter/Return.

Step 2: Navigate to the directory where MySQL.exe is running. For XAMPP users, it’s probably C:\xampp\mysql\bin\

Step 3: Copy SQL file (lets call it dump.sql) that you exported (from your live database) to the same folder as where MySQL.exe is running. Copying it to any folder is fine but if it’s in the same folder it makes the commands easier.

Step 4: Type the following and hit Enter/Return: mysql -u [USERNAME] -p -h [HOSTNAME] [DATABASE] < [FILE]

As an example, the command for Step 4, may look something like this:  mysql -u root -p -h localhost employees_database < new_employees.sql

Step 5: Once you hit Enter/Return, you’ll be prompted for the password associated with the [USERNAME] you gave in the command.

Step 6: Wait. If it’s a large file you won’t see anything happen but what you’re waiting for is a new command line to appear which is when you know the command has been processed. e.g.: C:\xampp\mysql\bin>

Well, that’s pretty much it. Head over to your local installation of phpMyAdmin to check all the tables are there. Remember to make backups of backups before you export or import or change anything. It costs nothing to be a little more cautious when handling large volumes of data.

I think these simple touches help to keep the frontpage clear, digestable and tidy in general and encourages users to go further investigate the site.

Thanks to Skeedio for their helpful blog post showing exactly how its done.

Anyone know of how you can enable this by default after reaching a threshold of certain number of characters?

I found a list of 10 Best Twitter Tools for WordPress Blogs from Quick Online Tips.

Essentially, I was looking for a WordPress plugin that would allow me to automatically publish new posts to my Twitter status.

What was interesting about Twitter Tools is that it is able to give bi-directional integration with Twitter and allows me to create posts from my Twitter statuses — or so I’m told.

I’ll be sure to let you know how things work out.

I’m fairly new to the WordPress plugin arena so if there is a Twitter Tool beater, drop me a comment to let me know about it.