I used to only test in Windows Live Hotmail using IE as I was resigned to the fact that it never worked properly in Firefox – until now! I finally got hassled into finding a solution for the only issue we had left – a 3 or 4 pixel gap appearing in between all the images.

It turns out the problem is the way the browsers in quirks and standards mode align images to the text baseline – the 3 or 4 pixel gap is there to allow room for the descenders of lowecase letters like “p” and “y” – even if there are no letters in the <td> with the <img> in it.

There are 2 things you can do to resolve the issue – force all the images to be aligned to the bottom of the <td> rather than the default (text baseline):

<img src="something.gif" alt="..." style="vertical-align: bottom;" />

Or you can take the issue out of the rendering engines hands and fool it by making all the images block-level rather than inline:

<img src="something.gif" alt="..." style="display: block;" />

I prefer the second option, but the first one should work fine too! ;)

You do not have sufficient permissions to access this page.

The reason for this is that everything in wordpress that accesses info in the db does so from PHP using the $table_prefix variable, and when you first installed your blog, a couple of options are set in the database that include that value, which makes it not really so dynamic! ;)

After rooting through my db, I found 5 or 6 values that still had the old table prefix in – mostly in the `usermeta` table, but also one in the `options` table. To make sure I got them all, I ran these simple SQL statements in phpMyAdmin to update all the values:

UPDATE `wp2_usermeta` SET `meta_key` = REPLACE(`meta_key`, 'wp_', 'wp2_');

UPDATE `wp2_options` SET `option_name` = REPLACE(`option_name`, 'wp_', 'wp2_');

(note: please be sure to backup your database before you execute any SQL on it – if something goes wrong, there’s not a lot you can do to recover it without a backup!)

In those two examples, assume the original prefix was “wp” and the new one is “wp2″.

With that done, I can now log in to my newly upgraded blog again! :)

Every time I pressed the “upgrade automatically” button, it told me it was downloading the latest file from WordPress, but it never got any further than that. I logged in to my site using my FTP client and found a 0KB sized file called wordpress2.8.zip in the wp_content folder, so I thought I’d found the issue – maybe the script can’t actually download the file and save it to disk because of permissions. I chmodded the file and then the folder to allow write access, but no joy.

Of course, I could have just downloaded the latest install from wordpress and done a manual upgrade, but there’s about 8 million files in the zip file and I didn’t want to have to upload that to 5 different sites! ;)

After a bit of research, it turns out that the problem is that the auto-upgrade script requires PHP5 to run, and as my sites are hosted on 1and1 servers which default to php4, the script was failing!

So if you’re having the same issue, all you need to do is make sure your wordpress is running on PHP5 instead of 4! If you’re on a shared server and you can’t change the server’s config, you can still tell apache to run your scripts as PHP5 rather than 4 by adding the following line to your .htaccess:

AddType x-mapp-php5 .php

All that does is tells apache to to parse all .php files with the PHP5 parser rather than whatever the server’s default is! So just throw that in the .htaccess you find in the root of your site – put it just after the “# END WordPress” line – save it, upload it and try doing the upgrade again – it worked first time for me! :)

If you’re still having trouble after that, or you’ve got a different solution, please post a comment here and let others know!

This happened to me a few days ago, so I did some searching – most people seem to think it’s only just started happening in the latest versions of iTunes and on iPhones/iPod Touches with the 2.2 firmware on – I didn’t notice it happening before I upgraded my firmware, but then I only noticed it happening now by chance, so I can’t really say if what these people are saying is true.

Anyway, it’s a solution you came here for, so here goes.

I tried resetting my iPod, incase it was just something dodgy going on on the file system, or another process interfering. No Joy. :(

I’ve tried clearing all my album artwork in iTunes and then finding the images again using a combination of the “Get Album Artwork” feature in the iTunes store and some Amazon.co.uk searches, then syncing the device again. Again, no joy.

Finally, I decided to just delete the offending albums from my iPod and upload them to it again. To do that without losing the albums from your iTunes library, just plug your iPhone/iPod in, start iTunes, click on the device name in the list on the left and tick the box that says “Manually manage music and videos”. That will allow you to browse the library on your device, select the albums in question and delete them. When you’ve done that, untick the box you just ticked, hit OK in whatever dialogue box iTunes pops up and let it sync your device again.

This should copy the songs/albums from your computer’s library back to the device, and hopefully send the album artwork along with them!

Well, that’s what worked for me – if anyone has any better method of restoring artwork on an iPhone/iPod Touch, please leave a comment and let me know what you did!

Let’s say the url looked like:

www.site.com/2009/1/is-this-a-legit-url?-i-don't-know?

and you wanted to rewrite that to:

www.site.com/2009/1/is-this-a-legit-url-i-dont-know/

You might think the rewrite would be simple, like so:

RewriteRule ^2009/1/is-this-a-legit-url\?-don%27t-know\?/?$ /2009/1/is-this-a-legit-url-i-dont-know/? [R=301,NC,L]

If you run that though, apache will throw a wobbly and tell you that “The requested URL /2009/1/is-this-a-legit-url was not found on this server.”

The reason for this is the server thinks everything after the first “?” is the querystring, so in this case, the apache is looking for a file/folder called “/2009/1/is-this-a-legit-url” and it will pass the querystring through as “-i-don’t-know?”

Of course, the simple solution would be to just match up to the first question mark in the rule, but that might not always be appropriate – e.g. if the string began with a question mark for whatever reason!

We came up with a cunning workaround for this by matching both the request url and the querystring like so:

RewriteCond %{QUERY_STRING} ^-i-don%27t-know\?/?$ [NC]
RewriteRule ^2009/1/is-this-a-legit-url$ /2009/1/is-this-a-legit-url-i-dont-know/? [R=301,NC,L]

Now, if a request like the original one above comes in, the query string will match the rewrite condition, and the requested URL will match the rewrite rule! :)

Note the extra question mark at the end of the rewritten rule “/is-this-a-legit-url-i-dont-know/? [R=301,NC,L]” – you need that in there to stop the server trying to push the original query string through.

Without it, your URL will be redirected to:

www.site.com/2009/1/is-this-a-legit-url-i-dont-know/?-i-don%2527t-know%3f

Unfortunately, using this method does mean that if you have any variable in the query string that you want to push through, you won’t be able to… Chances are though, that if you have 2 question marks, something’s gone wrong anyway, so this fix is better than nothing! ;)

Steve describes 14 rules that make up a ‘best practices for speeding up your website’: http://developer.yahoo.com/performance/rules.html

And there’s also a way to use the Firefox add-in, Firebug in combination with YSlow to analyse your sites based on the 14 rules: http://www.getfirebug.com/ and http://developer.yahoo.com/yslow/

We’ve been planning a css/js cache for a while now, but never got it off the ground, still seems that a few of the other rules could provide a good return on little investment.

That a familiar sight to anyone? :(

The .DS_Store is similar to the thumbs.db file Windows XP makes and is used to store “custom attributes of a folder such as the position of icons or the choice of a background image.”

The dot-underscore (._) files are pesky little buggers. It seems that when you use the Finder to transfer files to a non-Mac system–a Windows Server in this case–it splits the file into two parts – the data and the resource forks. When you copy the file back to the Mac, the Finder merges the two bits again. Windows can’t use the resource fork, so it’s not needed and you can delete it, but it’s a lot of hassle having to clean up after others! ;)

Ok, if you’re a home user, or if you don’t care about any hidden files, then you can safely just hide them all! To do that in Windows. go to: Control Panel > Folder Options > View > “Do not show hidden files and folders”. But if like me you do need access to some hidden files, then that’s not an option.

After searching for quite a while, I found a few resources that should help you get rid of the offending files, and stop the offending Mac users from creating new ones [as long as they're prepared to play along and adjust a few settings, that is!]

.DS_Store links:
http://support.apple.com/kb/HT1629 – You can stop the .DS_Store files being created using this command from the Terminal

http://www.bresink.de/osx/TinkerTool.html – For those of you less comfortable using the Terminal, this tool should let you stop the .DS_Store files being created from the control panel

http://www.macupdate.com/info.php/id/11163 – A handy bit of kit that will delete all the .DS_Store files on a drive

dot-underscore (._) links:
http://www.macworld.com/article/132556/2008/04/geekfactor2504.html – Using dot_clean on Leopard to get rid of the dot-underscore files

http://www.zeroonetwenty.com/blueharvest/ – This software is a godsend! It’s available as a 30 day trial, and then costs about 13 US Dollars, but it does the trick!

Oh well, hopefully these resources will save a couple of Mac users some black eyes from annoyed Windows users! ;)