Custom error pages using .htaccess0
We’ve all seen the dreaded Error 404 message – the result of broken links and mistyped URLs. You’ve probably been on some websites where the error pages are customised with their own logo and message, and I’m sure you’ll agree that it looks far more professional than the standard one.
In this article we’ll show you how to use Apache’s .htaccess file to make your own customised error 404 pages.
Create a new text file on your computer, and call it “htaccess.txt”. Enter the following lines:
<Files .htaccess> order allow,deny deny from all </Files>
Now you need to create the 404 page. Make a new web page called “error404.htm” and enter “This is my 404 page”. Enter it a few dozen times, as Internet Explorer won’t display it unless the file is over 512 bytes.
Once it’s done, login to your webspace with your FTP client, and create a new folder called “errordocs”. Upload the file “error404.htm” to this directory. Upload “htaccess.txt” to the root of your webspace and rename it to “.htaccess” — there’s no .txt at the end, no name in front, just “.htaccess”. If the file seems to vanish don’t worry, some FTP clients don’t display it — the file’s still there.
ErrorDocument 404 /errordocs/error404.htm
The first part stops people viewing your .htaccess file. The second part tells Apache to redirect any 404 errors to the file “error404.htm”.
You do not have sufficient permissions to access this page” after WordPress upgrade1
If you’ve done a wordpress upgrade which included either copying another wp database or changing the current one’s table prefix (as well as changing the $table_prefix PHP variable in your config file,) you will most likely be met with this warning when you try to log in:
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:
_usermeta table and _options table