In my case, I was completely locked out of the admin screens and could do nothing with the blog apart from post comments!
This post is going to take you on a journey, one that starts with following standard debugging techniques that I’ve learned from years of experience in the IT industry and ends in a discovery so surprising, it’s made me question the fundamental quality of the whole blogging phenomena that is WordPress (WordPress is the blogging software this crossfit blog uses and is arguably one of the most popular). I started off as anyone should when faced with a new and unfamiliar problem, by doing some research:
What I found was that this appears to be a common WordPress problem suffered by many bloggers and can arise in many possible situations e.g.:
After writing a comment and clicking Submit.
Accessing any of the main blog screens.
Accessing any of the administrator screens.
After *doing* something in the administrator screens.
During the upgrade, I noticed I was suffering from (4) above. I could access the admin pages no problem, but whenever I tried to do anything adminy I’d get the Blank Screen of Death e.g. change a plugin setting or write a post or change anything. The action I was performing worked ok, but I’d have to hit the back button and do an F5 Refresh to see the results of it. At the time I figured I’d deal with it later.
It was made worse because there were no error messages: No errors on the wordpress white screen of course; nothing in the main wordpress error.log; nothing in the plugin error log; and nothing in the webserver apache error log. And in the absence of any information it’s a tough problem to debug. However, with my advanced Google Foo skillz, I was pretty confident of finding the answer. I did in the end, but it took me hours!
Here are all the causes and working solutions I found on the net that others have specified:
A partially complete upgrade – Solution: Re-upload the upgrade files.
FTP Client making a mess of the upgrade – Solution: Get a better FTP client and re-upload the upgrade files.
Something failed running /wp-admin/upgrade.php upgrade script – Solution: Find out what failed (check logs), fix it and re-upgrade.
Incompatible Plugin Enabled – Solution: Disable all plugins, then add them back one at a time to see which one causes the problem.
Adding the new define(‘SECRET_KEY’,… parameter into wp-config.php – Solution: Don’t put it at the end of your file, put it before the line that says /* That’s all, stop editing! Happy blogging. */
Working down this list posed a problem: How could I disable the plugins without access to the admin screens?!? In the end I had to manually hack the MySQL database directly via the back end. In short, here’s what I did:
Accessed my webserver admin screens, cPanel in this case.
Accessed the phpMyAdmin MySQL user interface.
Browse the wp_options table.
Find the field called: active_plugins.
If you just want to look without the risk of cocking it up, here’s the SQL you need:
SELECT option_value FROM wp_options WHERE option_name = ‘active_plugins’ LIMIT 1;
First things first before you go fiddling: BACK UP THE VALUE OF THIS FIELD by copying to a text file on your PC.
Then either use phpMyAdmin to blank the value of the active_plugins field, or use this SQL:
UPDATE wp_options SET option_value = ” WHERE option_name = ‘active_plugins’;
Just to be clear here, if you don’t know what you’re doing, then don’t do it! I’m not responsible for you messing up your blog even more. You should have regular backups and have proven to yourself that they work and you are competent enough to restore from those backups.
Anyway, that will disable all your plugins… great. Just one problem: it didn’t fix my Blank Screen problem!
I’ll cut a long story short, as it did take me another hour or 2 to finally find the solution. Now what I’m about to say is a complete shocker to me. As an experienced IT person, someone who has been messing around with and programming computers and working on IT projects in every possible role up to IT Director for over a decade, I am completely dumb founded by what I’m about to describe, because how the human race has got to 2008 with all the technologically related advances we have made, and yet still introduce a hugely powerful and popular program like WordPress, that is brought to it’s knees by the most innocuous of things… it’s just completely beyond me.
Anyway here is the answer: it lies in the wp-config.php file, this is the file where you set your database password etc (so you’ll forgive me for not using my own real one. ;) ). This is the example file that comes with the installation:
— File Starts —
— File Ends —
That is a perfectly fine, normal and working wp-config.php. Now I’m going to show you a broken one. One so terribly horrendously broken, that it causes you to be locked out of your workdpress blog for half a week and lose 1/2 a day trying to solve it. See if you can spot the difference:
— File Starts —
— File Ends —
What do you think, can you see it the mistake that breaks the whole blog? No? Go back and look closely…
Still no? Ok ok, I’ll give it to you, here’s the problem:
What? You can’t see that either? Let me show it to you again, look carefully this time:
You getting it yet? Yep, it’s an empty line. That’s all it is. 1 single solitary NewLine at the bottom of the file, right after that ?> a Carriage Return & Line Feed in programmers speak. That’s it. You hit the Enter key in one wrong place and the whole pack of cards comes tumbling down! Shocking, just shocking. Let me be crystal clear, it’s this bit here:
?>
— File Ends —
Now of course, the Analyst in me wants to know how this happened and I’ll tell you. The issue was the the new define(‘SECRET_KEY’… entry I mentioned before. That should have been my warning, because when I was following the upgrade instructions, they don’t tell you where to put it, so naturally I first put it at the end of the file…. yep you guessed it: AFTER the ?> . I realise now of course that was stupid and it didn’t work. What was the symptom of it not working? You guessed it: the WordPress Blank Screen of Death.
But when I moved it to the correct place, I was still sporadically getting problems, then I commented the line out and basically with all the changes I made I seemed to have got myself into the situation where I was getting the problem, but only half the time. I reckon the currently open admin session I had going was probably masking half of the issue from me. But in putting it at the end of the wp-config file and then moving it, I must have left behind an empty line. How silly of me! So just make sure you have no extraneous characters after the ?> I’d recommend checking for those evil and nefarious spaces too. ;)
Anyway, that’s the fix and probably the most comprehensive study of getting wordpress blank screens anywhere on the net. If you find this post useful, please consider linking to this post from your blog, it will help others find this article who may have the same problem.
Cheers.
Wednesday, June 15, 2011
Tuesday, June 14, 2011
A Basic guide to HTAccess and few tips
Introduction to .htaccess..
This work in constant progress is some collected wisdom, stuff I've learned on the topic of .htaccess hacking, commands I've used successfully in the past, on a variety of server setups, and in most cases still do. You may have to tweak the examples some to get the desired result, though, and a reliable test server is a powerful ally, preferably one with a very similar setup to your "live" server. Okay, to begin....a win32 Apache mirror of corz.org
.htaccess files are invisible There's a good reason why you won't see .htaccess files on the web; almost every web server in the world is configured to ignore them, by default. Same goes for most operating systems. Mainly it's the dot "." at the start, you see?
If you don't see, you'll need to disable your operating system's invisible file functions, or use a text editor that allows you to open hidden files, something like bbedit on the Mac platform. On windows, showing invisibles in explorer should allow any text editor to open them, and most decent editors to save them too**. Linux dudes know how to find them without any help.
that same folder, as seen from Mac OS X
In both images, the operating system has been instructed to display invisible files. ugly, but necessary sometimes. You will also need to instruct your ftp client to do the same.
By the way; the windows screencap is more recent than the mac one, moved files are likely being handled by my clever 404 script.
** even notepad can save files beginning with a dot, if you put double-quotes around the name when you save it; i.e.. ".htaccess". You can also use your ftp client to rename files beginning with a dot, even on your local filesystem; works great in FileZilla.
What are .htaccess files anyway?
Simply put, they are invisible plain text files where one can store server directives. Server directives are anything you might put in an Apache config file (httpd.conf) or even a php.ini**, but unlike those "master" directive files, these .htaccess directives apply only to the folder in which the .htaccess file resides, and all the folders inside.This ability to plant .htaccess files in any directory of our site allows us to set up a finely-grained tree of server directives, each subfolder inheriting properties from its parent, whilst at the same time adding to, or over-riding certain directives with its own .htaccess file. For instance, you could use .htacces to enable indexes all over your site, and then deny indexing in only certain subdirectories, or deny index listings site-wide, and allow indexing in certain subdirectories. One line in the .htaccess file in your root and your whole site is altered. From here on, I'll probably refer to the main .htaccess in the root of your website as "the master .htaccess file", or "main" .htaccess file.
There's a small performance penalty for all this .htaccess file checking, but not noticeable, and you'll find most of the time it's just on and there's nothing you can do about it anyway, so let's make the most of it..
** Your main php.ini, that is, unless you are running under phpsuexec, in which case the directives would go inside individual php.ini files
Is .htaccess enabled?
It's unusual, but possible that .htaccess is not enabled on your site. If you are hosting it yourself, it's easy enough to fix; open your httpd.conf in a text editor, and locate thisYour DocumentRoot may be different, of course..# This should be changed to whatever you set DocumentRoot to.
#
#
..locate the line that reads..
AllowOverride None
..and change it to..
AllowOverride All
Restart Apache. Now .htaccess will work. You can also make this change inside a virtual host, which would normally be preferable.
If your site is hosted with someone else, check your control panel (Plesk. CPanel, etc.) to see if you can enable it there, and if not, contact your hosting admins. Perhaps they don't allow this. In which case, switch to a better web host.
What can I do with .htaccess files?
Almost any directive that you can put inside an httpd.conf file will also function perfectly inside an .htaccess file. Unsurprisingly, the most common use of .htaccess is to..Control access..
.htaccess is most often used to restrict or deny access to individual files and folders. A typical example would be an "includes" folder. Your site's pages can call these included scripts all they like, but you don't want users accessing these files directly, over the web. In that case you would drop an .htaccess file in the includes folder with content something like this..NO ENTRY!# no one gets in here!
deny from all
which would deny ALL direct access to ANY files in that folder. You can be more specific with your conditions, for instance limiting access to a particular IP range, here's a handy top-level rule for a local test server..
NO ENTRY outside of the LAN!# no nasty crackers in here!
order deny,allow
deny from all
allow from 192.168.0.0/24
# this would do the same thing..
#allow from 192.168.0
Generally these sorts of requests would bounce off your firewall anyway, but on a live server (like my dev mirror sometimes is) they become useful for filtering out undesirable IP blocks, known risks, lots of things. By the way, in case you hadn't spotted; lines beginning with "#" are ignored by Apache; handy for comments.
Sometimes, you will only want to ban one IP, perhaps some persistent robot that doesn't play by the rules..
post user agent every fifth request only. hmmm. ban IP..# someone else giving the ruskies a bad name..
order allow,deny
deny from 83.222.23.219
allow from all
The usual rules for IP addresses apply, so you can use partial matches, ranges, and so on. Whatever, the user gets a 403 "access denied" error page in their client software (browser, usually), which certainly gets the message across. This is probably fine for most situations, but in part two I'll demonstrate some cooler ways to deny access, as well as how to deny those nasty web suckers, bad referrers, script kiddies and more.
Custom error documents..
I guess I should briefly mention that .htaccess is where most folk configure their error documents. Usually with sommething like this..the usual method. the "err" folder (with the custom pages) is in the root# custom error documents
ErrorDocument 401 /err/401.php
ErrorDocument 403 /err/403.php
ErrorDocument 404 /err/404.php
ErrorDocument 500 /err/500.php
You can also specify external URLs, though this can be problematic, and is best avoided. One quick and simple method is to specify the text in the directive itself, you can even use HTML (though there is probably a limit to how much HTML you can squeeze onto one line). Remember, for Apache 1; begin with a ", but DO NOT end with one. For Apache 2, you can put a second quote at the end, as normal.
measure twice, quote once..# quick custom error "document"..
ErrorDocument 404 "NO!
There is nothing here.. go away quickly!
Using a custom error document is a Very Good Idea, and will give you a second chance at your almost-lost visitors. I recommend you download mine. But then, I would.
Password protected directories..
The next most obvious use for our .htaccess files is to allow access to only specific users, or user groups, in other words; password protected folders. a simple authorisation mechanism might look something like this..a simple sample .htaccess file for password protection:AuthType Basic
AuthName "restricted area"
AuthUserFile /usr/local/var/www/html/.htpasses
require valid-user
You can use this same mechanism to limit only certain kinds of requests, too..
only valid users can POST in here, anyone can GET, PUT, etc:AuthType Basic
AuthName "restricted area"
AuthUserFile /usr/local/var/www/html/.htpasses
require valid-user
You can find loads of online examples of how to setup authorization using .htaccess, and so long as you have a real user (or create one, in this case, 'jimmy') with a real password (you will be prompted for this, twice) in a real password file (the -c switch will create it)..
htpasswd -c /usr/local/var/www/html/.htpasses jimmy
..the above will work just fine. htpasswd is a tool that comes free with Apache, specifically for making and updating password files, check it out. The windows version is the same; only the file path needs to be changed; to wherever you want to put the password file.
Note: if the Apache bin/ folder isn't in your PATH, you will need to cd into that directory before performing the command. Also note: You can use forward and back-slashes interchangeably with Apache/php on Windows, so this would work just fine..
htpasswd -c c:/unix/usr/local/Apache2/conf/.htpasses jimmy
Relative paths are fine too; assuming you were inside the bin/ directory of our fictional Apache install, the following would do exactly the same as the above..
htpasswd -c ../conf/.htpasses jimmy
Naming the password file .htpasses is a habit from when I had to keep that file inside the web site itself, and as web servers are configured to ignore files beginning with .ht, they too, remain hidden. If you keep your password file outside the web root (a better idea), then you can call it whatever you like, but the .ht_something habit is a good one to keep, even inside the web tree, it is secure enough for our basic purpose..
Once they are logged in, you can access the remote_user environmental variable, and do stuff with it..
the remote_user variable is now available..RewriteEngine on
RewriteCond %{remote_user} !^$ [nc]
RewriteRule ^(.*)$ /users/%{remote_user}/$1
Which is a handy directive, utilizing mod_rewrite; a subject I delve into far more deeply, in part two.
Get better protection..
The authentication examples above assume that your web server supports "Basic" http authorisation, as far as I know they all do (it's in the Apache core). Trouble is, some browsers aren't sending password this way any more, personally I'm looking to php to cover my authorization needs. Basic auth works okay though, even if it isn't actually very secure - your password travels in plain text over the wire, not clever.If you have php, and are looking for a more secure login facility, check out pajamas. It's free. If you are looking for a password-protected download facility (and much more, besides), check out my distro machine, also free.
500 error..
If you add something that the server doesn't understand or support, you will get a 500 error page, aka.. "the server did a boo-boo". Even directives that work perfectly on your test server at home may fail dramatically at your real site. In fact this is a great way to find out if .htaccess files are enabled on your site; create one, put some gibberish in it, and load a page in that folder, wait for the 500 error. if there isn't one, probably they are not enabled.If they are, we need a way to safely do live-testing without bringing the whole site to a 500 standstill.
Fortunately, in much the same way as we used the
only if PHP is loaded, will this directive have any effect (switch the 4 for a 5 if using php5)
php_value default_charset utf-8
..which placed in your master .htaccess file, that would set the default character encoding of your entire site to utf-8 (a good idea!), at least, anything output by PHP. If the PHP4** module isn't running on the server, the above .htaccess directive will do exactly nothing; Apache just ignores it. As well as proofing us against knocking the server into 500 mode, this also makes our .htaccess directives that wee bit more portable. Of course, if your syntax is messed-up, no amount of if-module-ing is going to prevent a error of some kind, all the more reason to practice this stuff on a local test server.
** note: if you are using php5, you would obviously instead use.
Groovy things to do with .htaccess..
So far we've only scratched the surface. Aside from authorisation, the humble .htaccess file can be put to all kinds of uses. If you've ever had a look in my public archives you will have noticed that that the directories are fully browsable, just like in the old days before adult web hosts realized how to turn that feature off! A line like this..bring back the directories!Options +Indexes +MultiViews +FollowSymlinks
..will almost certainly turn it back on again. And if you have mod_autoindex.c installed on your server (probably, yes), you can get nice fancy indexing, too..
show me those files!
IndexOptions FancyIndexing
..which, as well as being neater, allows users to click the titles and, for instance, order the listing by date, or file size, or whatever. It's all for free too, built-in to the server, we're just switching it on. You can control certain parameters too..
let's go all the way!
IndexOptions FancyIndexing IconHeight=16 IconWidth=16
Other parameters you could add include..
NameWidth=30
DescriptionWidth=30
IconsAreLinks SuppressHTMLPreamble (handy!)
I'm not mentioning the "XHTML" parameter in Apache2, because it still isn't! Anyways, I've chucked one of my old fancy indexing .htaccess file onsite for you to have some fun with. Just add readme.html and away you go! note: these days I use a single header files for all the indexes..
HeaderName /inc/header.html
.. and only drop in local "readme" files. Check out the example, and my public archives for more details.
custom directory index files
While I'm here, it's worth mentioning that .htaccess is where you can specify which files you want to use as your indexes, that is, if a user requests /foo/, Apache will serve up /foo/index.html, or whatever file you specify.You can also specify multiple files, and Apache will look for each in order, and present the first one it finds. It's generally setup something like..
DirectoryIndex index.html index.php index.htm
It really is worth scouting around the Apache documentation, often you will find controls for things you imagined were uncontrollable, thereby creating new possibilities, better options for your website. My experience of the magic "LAMP" (Linux-Apache-MySQL-PHP) has been.. "If you can imagine that it can be done, it can be done". Swap "Linux" for any decent operating system, the "AMP" part runs on most of them.
Okay, so now we have nice fancy directories, and some of them password protected, if you don't watch out, you're site will get popular, and that means bandwidth..
Save bandwidth with .htaccess!
If you pay for your bandwidth, this wee line could save you hard cash..save me hard cash! and help the internet!
php_value zlib.output_compression 16386
All it does is enables PHP's built-in transparent zlib compression. This will half your bandwidth usage in one stroke, more than that, in fact. Of course it only works with data being output by the PHP module, but if you design your pages with this in mind, you can use php echo statements, or better yet, php "includes" for your plain html output and just compress everything! Remember, if you run phpsuexec, you'll need to put php directives in a local php.ini file, not .htaccess. See here for more details.
Hide and deny files..
Do you remember I mentioned that any file beginning with .ht is invisible? .."almost every web server in the world is configured to ignore them, by default" and that is, of course, because .ht_anything files generally have server directives and passwords and stuff in them, most servers will have something like this in their main configuration..Standard setting..
Order allow,deny
Deny from all
Satisfy All
which instructs the server to deny access to any file beginning with .ht, effectively protecting our .htaccess and other files. The "." at the start prevents them being displayed in an index, and the .ht prevents them being accessed. This version..
ignore what you want
Order allow,deny
Deny from all
Satisfy All
tells the server to deny access to *.log files. You can insert multiple file types into each rule, separating them with a pipe "|", and you can insert multiple blocks into your .htaccess file, too. I find it convenient to put all the files starting with a dot into one, and the files with denied extensions into another, something like this..
the whole lot# deny all .htaccess, .DS_Store $hî†é and ._* (resource fork) files
Order allow,deny
Deny from all
Satisfy All
# deny access to all .log and .comment files
Order allow,deny
Deny from all
Satisfy All
would cover all ._* resource fork files, .DS_Store files (which the Mac Finder creates all over the place) *.log files, *.comment files and of course, our .ht* files. You can add whatever file types you need to protect from direct access. I think it's clear now why the file is called ".htaccess".
parse file.css and file.style with the php machine..# handler for phpsuexec..
SetHandler application/x-httpd-php
Any files with a *.css or *.style extension will now be handled by php, rather than simply served up by Apache. And because you can use regexp, you could do stuff like
More stuff..
At the end of my .htaccess files, there always seems to be a section of "stuff"; miscellaneous commands, mainly php flags and switches; so it seems logical to finish up the page with a wee selection of those..php flags, switches and other stuff..# let's enable php (non-cgi, aka. 'module') for EVERYTHING..'
AddType application/x-httpd-php5 .htm .html .php .blog .comment .inc
# better yet..
AddHandler php5-script .php
# legacy php4 version..'
AddType application/x-httpd-php .htm .html .php .blog .comment .inc
# don't even think about setting this to 'on'
php_value register_globals off
# no session id's in the URL PULEEZE!
php_value session.use_trans_sid 0
# should be the same as..
php_flag session.use_trans_sid off
# using both should also work fine!
# php error logs..
php_flag display_errors off
php_flag log_errors on
php_value track_errors on
php_value error_log /home/cor/errors/phperr.log
# if you like to collect interesting php system shell access and web hack scripts
# get yourself a SECURE upload facility, and just let the script-kiddies come …
# in no time you will have a huge selection of fascinating code. If you want folk to
# also upload zips and stuff, you might want to increase the upload capacities..
php_value upload_max_filesize 12M
php_value post_max_size 12M
# php 5 only, afaik. handy when your server isn't where YOU are.
php_value date.timezone Europe/Aberdeen
# actually, Europe/Aberdeen isn't a valid php timezone, so that won't work.
# I recommend you check the php manual for this function, because many crazy places ARE!
Note: For most of the flags I've tested, you can use on/off and true/false interchangeably, as well as 0/1, also php_value and php_flag can be switched around while things continue to work as expected! I guess, logically, booleans should always be php_flag, and values, php_value; but suffice to say, if some php erm, directive isn't working, these would all be good things to fiddle with!
Of course, the php manual explains all. The bottom line is; both will work fine, but if you use the wrong type in .htaccess, say, set a php_flag using php_value, a php ini_get() command, for instance, would return true, even though you had set the value to off, because it reads off value as a string, which of course evaluates to not-zero, i.e. 1, or "true". If you don't rely on get_ini(), or similar, it's not a problem, though clearly it's better to get it right from the start. By the way; one of the values above is incorrectly set. Did you spot it?
Most php settings, you can override inside your actual scripts, but I do find it handy to be able to set defaults for a folder, or an entire site, using .htaccess.
Few cool tips and tricks about .htaccess and URL re-write in PHP
One of the more powerful tricks of the .htaccess hacker is the ability to rewrite URLs. This enables us to do some mighty manipulations on our links; useful stuff like transforming very long URL's into short, cute URLs, transforming dynamic ?generated=page&URL's into /friendly/flat/links, redirect missing pages, preventing hot-linking, performing automatic language translation, and much, much more.
Make no mistake, mod_rewrite is complex. This isn't the subject for a quick bite-size tech-snack, probably not even a week-end crash-course, I've seen guys pull off some real cute stuff with mod_rewrite, but with kudos-hat tipped firmly towards that bastard operator from hell, Ralf S. Engelschall, author of the magic module itself, I have to admit that a great deal of it still seems so much voodoo to me.
The way that rules can work one minute and then seem not to the next, how browser and other in-between network caches interact with rules and testing rules is often baffling, maddening. When I feel the need to bend my mind completely out of shape, I mess around with mod_rewrite!
After all this, it does work, and while I'm not planning on taking that week-end crash-course any time soon, I have picked up a few wee tricks myself, messing around with web servers and web sites, this place..
The plan here is to just drop some neat stuff, examples, things that have proven useful, and work on a variety of server setups; there are Apache's all over my LAN, I keep coming across old .htaccess files stuffed with past rewriting experiments that either worked; and I add them to my list, or failed dismally; and I'm surprised that more often these days, I can see exactly why!
Very little here is my own invention. Even the bits I figured out myself were already well documented, I just hadn't understood the documents, or couldn't find them. Sometimes, just looking at the same thing from a different angle can make all the difference, so perhaps this humble stab at URL Rewriting might be of some use. I'm writing it for me, of course. but I do get some credit for this..
Make no mistake, mod_rewrite is complex. This isn't the subject for a quick bite-size tech-snack, probably not even a week-end crash-course, I've seen guys pull off some real cute stuff with mod_rewrite, but with kudos-hat tipped firmly towards that bastard operator from hell, Ralf S. Engelschall, author of the magic module itself, I have to admit that a great deal of it still seems so much voodoo to me.
The way that rules can work one minute and then seem not to the next, how browser and other in-between network caches interact with rules and testing rules is often baffling, maddening. When I feel the need to bend my mind completely out of shape, I mess around with mod_rewrite!
After all this, it does work, and while I'm not planning on taking that week-end crash-course any time soon, I have picked up a few wee tricks myself, messing around with web servers and web sites, this place..
The plan here is to just drop some neat stuff, examples, things that have proven useful, and work on a variety of server setups; there are Apache's all over my LAN, I keep coming across old .htaccess files stuffed with past rewriting experiments that either worked; and I add them to my list, or failed dismally; and I'm surprised that more often these days, I can see exactly why!
Very little here is my own invention. Even the bits I figured out myself were already well documented, I just hadn't understood the documents, or couldn't find them. Sometimes, just looking at the same thing from a different angle can make all the difference, so perhaps this humble stab at URL Rewriting might be of some use. I'm writing it for me, of course. but I do get some credit for this..
# time to get dynamic, see..
RewriteRule (.*)\.htm $1.php
beginning rewriting..
Whenever you use mod_rewrite (the part of Apache that does all this magic), you need to do..
..before any ReWrite rules. note: +FollowSymLinks must be enabled for any rules to work, this is a security requirement of the rewrite engine. Normally it's enabled in the root and you shouldn't have to add it, but it doesn't hurt to do so, and I'll insert it into all the examples on this page, just in case*.
The next line simply switches on the rewrite engine for that folder. if this directive is in you main .htaccess file, then the ReWrite engine is theoretically enabled for your entire site, but it's wise to always add that line before you write any redirections, anywhere.
* Although highly unlikely, your host may have +FollowSymLinks enabled at the root level, yet disallow its addition in .htaccess; in which case, adding +FollowSymLinks will break your setup (probably a 500 error), so just remove it, and your rules should work fine.
Important: While some of the directives on this page may appear split onto two lines in your browser, in your .htaccess file they must exist completely on one line. If you drag-select and copy the directives on this page, they should paste just fine into any text editor.
you only need to do this once per .htaccess file:Options +FollowSymlinks
RewriteEngine on
..before any ReWrite rules. note: +FollowSymLinks must be enabled for any rules to work, this is a security requirement of the rewrite engine. Normally it's enabled in the root and you shouldn't have to add it, but it doesn't hurt to do so, and I'll insert it into all the examples on this page, just in case*.
The next line simply switches on the rewrite engine for that folder. if this directive is in you main .htaccess file, then the ReWrite engine is theoretically enabled for your entire site, but it's wise to always add that line before you write any redirections, anywhere.
* Although highly unlikely, your host may have +FollowSymLinks enabled at the root level, yet disallow its addition in .htaccess; in which case, adding +FollowSymLinks will break your setup (probably a 500 error), so just remove it, and your rules should work fine.
Important: While some of the directives on this page may appear split onto two lines in your browser, in your .htaccess file they must exist completely on one line. If you drag-select and copy the directives on this page, they should paste just fine into any text editor.
simple rewriting
Simply put, Apache scans all incoming URL requests, checks for matches in our .htaccess file and rewrites those matching URLs to whatever we specify. something like this..
Handy for anyone updating a site from static htm (you could use .html, or .htm(.*), .htm?, etc) to dynamic php pages; requests to the old pages are automatically rewritten to our new urls. no one notices a thing, visitors and search engines can access your content either way. leave the rule in; as an added bonus, this enables us to easily split php code and its included html structures into two separate files, a nice idea; makes editing and updating a breeze. The [NC] part at the end means "No Case", or "case-insensitive"; more on the switches, later.
Folks can link to whatever.htm or whatever.php, but they always get whatever.php in their browser, and this works even if whatever.htm doesn't exist! But I'm straying..
As it stands, it's a bit tricky; folks will still have whatever.htm in their browser address bar, and will still keep bookmarking your old .htm URL's. Search engines, too, will keep on indexing your links as .htm, some have even argued that serving up the same content from two different places could have you penalized by the search engines. This may or not bother you, but if it does, mod_rewrite can do some more magic..
This time we instruct mod_rewrite to do a proper external rewrite, aka, "redirection". Now, instead of just background rewriting on-the-fly, the user's browser is physically redirected to a new URI, and whatever.php appears in their browser's address bar - search engines and other spidering entities will automatically update their links to the .php versions; everyone wins. You can take your time with the updating, too.
Note: if you use [R] alone, it defaults to sending an HTTP "MOVED TEMPORARILY" redirection, aka, "302". But you can send other codes, like so..
Okay, I sent the exact same code, but I didn't have to. For details of the many 30* response codes you can send. Most people seem to want to send 301, aka, "MOVED PERMENENTLY".
Note: if you add an "L" flag to the mix; meaning "Last Rule", e.g. [R=302,NC,L]; Apache will stop processing rules for this request at that point, which may or may not be what you want. Either way, it's useful to know.
all requests to whatever.htm will be sent to whatever.php:Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.*)\.htm$ $1.php [NC]
Handy for anyone updating a site from static htm (you could use .html, or .htm(.*), .htm?, etc) to dynamic php pages; requests to the old pages are automatically rewritten to our new urls. no one notices a thing, visitors and search engines can access your content either way. leave the rule in; as an added bonus, this enables us to easily split php code and its included html structures into two separate files, a nice idea; makes editing and updating a breeze. The [NC] part at the end means "No Case", or "case-insensitive"; more on the switches, later.
Folks can link to whatever.htm or whatever.php, but they always get whatever.php in their browser, and this works even if whatever.htm doesn't exist! But I'm straying..
As it stands, it's a bit tricky; folks will still have whatever.htm in their browser address bar, and will still keep bookmarking your old .htm URL's. Search engines, too, will keep on indexing your links as .htm, some have even argued that serving up the same content from two different places could have you penalized by the search engines. This may or not bother you, but if it does, mod_rewrite can do some more magic..
this will do a "real" external redirection:Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.+)\.htm$ http://corz.org/$1.php [R,NC]
This time we instruct mod_rewrite to do a proper external rewrite, aka, "redirection". Now, instead of just background rewriting on-the-fly, the user's browser is physically redirected to a new URI, and whatever.php appears in their browser's address bar - search engines and other spidering entities will automatically update their links to the .php versions; everyone wins. You can take your time with the updating, too.
Note: if you use [R] alone, it defaults to sending an HTTP "MOVED TEMPORARILY" redirection, aka, "302". But you can send other codes, like so..
this performs the exact same as the previous example RewriteRule.RewriteRule ^(.+)\.htm$ http://corz.org/$1.php [R=302,NC]
Okay, I sent the exact same code, but I didn't have to. For details of the many 30* response codes you can send. Most people seem to want to send 301, aka, "MOVED PERMENENTLY".
Note: if you add an "L" flag to the mix; meaning "Last Rule", e.g. [R=302,NC,L]; Apache will stop processing rules for this request at that point, which may or may not be what you want. Either way, it's useful to know.
not-so-simple rewriting ... flat links and more
You may have noticed, the above examples use regular expression to match variables. What that simply means is.. match the part inside (.+) and use it to construct "$1" in the new URL. In other words, (.+) = $1 you could have multiple (.+) parts and for each, mod_rewrite automatically creates a matching $1, $2, $3, etc, in your target (aka. 'substitution') URL. This facility enables us to do all sorts of tricks, and the most common of those, is the creation of "flat links"..
Even a cute short link like http://mysite/grab?file=my.zip is too ugly for some people, and nothing less than a true old-school solid domain/path/flat/link will do. Fortunately, mod_rewrite makes it easy to convert URLs with query strings and multiple variables into exactly this, something like..
would allow you to present this link as..
http://mysite/files/games/hoopy.zip
and in the background have that transparently translated, server-side, to..
http://mysite/download.php?section=games&file=hoopy
which some script could process. You see, many search engines simply don't follow our ?generated=links, so if you create generating pages, this is useful. However, it's only the dumb search engines that can't handle these kinds of links; we have to ask ourselves.. do we really want to be listed by the dumb search engines? Google will handle a good few parameters in your URL without any problems, and the (hungry hungry) msn-bot stops at nothing to get that page, sometimes again and again and again…
I personally feel it's the search engines that should strive to keep up with modern web technologies, in other words; we shouldn't have to dumb-down for them. But that's just my opinion. Many users will prefer /files/games/hoopy.zip to /download.php?section=games&file=hoopy but I don't mind either way. As someone pointed out to me recently, presenting links as standard/flat/paths means you're less likely to get folks doing typos in typed URL's, so something like..
would be a neat trick, enabling anyone to access my blog archives by doing..
http://corz.org/blog/2003-nov
in their browser, and have it automagically transformed server-side into..
http://corz.org/blog/index.php?archive=2003-nov
which corzblog would understand. It's easy to see that with a little imagination, and a basic understanding of posix regular expression, you can perform some highly cool URL manipulations.
Here's the very basics of regexp (expanded from the Apache mod_rewrite documentation)..
Even a cute short link like http://mysite/grab?file=my.zip is too ugly for some people, and nothing less than a true old-school solid domain/path/flat/link will do. Fortunately, mod_rewrite makes it easy to convert URLs with query strings and multiple variables into exactly this, something like..
a more complex rewrite rule:Options +FollowSymlinks
RewriteEngine on
RewriteRule ^files/([^/]+)/([^/]+).zip /download.php?section=$1&file=$2 [NC]
would allow you to present this link as..
http://mysite/files/games/hoopy.zip
and in the background have that transparently translated, server-side, to..
http://mysite/download.php?section=games&file=hoopy
which some script could process. You see, many search engines simply don't follow our ?generated=links, so if you create generating pages, this is useful. However, it's only the dumb search engines that can't handle these kinds of links; we have to ask ourselves.. do we really want to be listed by the dumb search engines? Google will handle a good few parameters in your URL without any problems, and the (hungry hungry) msn-bot stops at nothing to get that page, sometimes again and again and again…
I personally feel it's the search engines that should strive to keep up with modern web technologies, in other words; we shouldn't have to dumb-down for them. But that's just my opinion. Many users will prefer /files/games/hoopy.zip to /download.php?section=games&file=hoopy but I don't mind either way. As someone pointed out to me recently, presenting links as standard/flat/paths means you're less likely to get folks doing typos in typed URL's, so something like..
an even more complex rewrite rule:Options +FollowSymlinks
RewriteEngine on
RewriteRule ^blog/([0-9]+)-([a-z]+) http://corz.org/blog/index.php?archive=$1-$2 [NC]
would be a neat trick, enabling anyone to access my blog archives by doing..
http://corz.org/blog/2003-nov
in their browser, and have it automagically transformed server-side into..
http://corz.org/blog/index.php?archive=2003-nov
which corzblog would understand. It's easy to see that with a little imagination, and a basic understanding of posix regular expression, you can perform some highly cool URL manipulations.
Here's the very basics of regexp (expanded from the Apache mod_rewrite documentation)..
Escaping: \char escape that particular char For instance to specify special characters.. [].()\ etc. Text: . Any single character (on its own = the entire URI) [chars] Character class: One of following chars [^chars] Character class: None of following chars text1|text2 Alternative: text1 or text2 (i.e. "or") e.g. [^/] matches any character except / (foo|bar)\.html matches foo.html and bar.html Quantifiers: ? 0 or 1 of the preceding text * 0 or N of the preceding text (hungry) + 1 or N of the preceding text e.g. (.+)\.html? matches foo.htm and foo.html (foo)?bar\.html matches bar.html and foobar.html Grouping: (text) Grouping of text Either to set the borders of an alternative or for making backreferences where the nthe group can be used on the target of a RewriteRule with $n e.g. ^(.*)\.html foo.php?bar=$1 Anchors: ^ Start of line anchor $ End of line anchor An anchor explicitly states that the character right next to it MUST be either the very first character ("^"), or the very last character ("$") of the URI string to match against the pattern, e.g.. ^foo(.*) matches foo and foobar but not eggfoo (.*)l$ matches fool and cool, but not foo
shortening URLs
One common use of mod_rewrite is to shorten URL's. Shorter URL's are easier to remember and, of course, easier to type. An example..
this rule would transform this user's URL..
http://mysite/grab?file=my.zip
server-side, into..
http://mysite/public/files/download/download.php?file=my.zip
which is a wee trick I use for my distro machine, among other things. everyone likes short URL's, and so will you; using this technique, you can move /public/files/download/ to anywhere else in your site, and all the old links still work fine; simply alter your .htaccess file to reflect the new location. edit one line, done - nice - means even when stuff is way deep in your site you can have cool links like this.. /trueview/sample.php and this; links which are not only short, but flat..
beware the regular expression:Options +FollowSymlinks
RewriteEngine On
RewriteRule ^grab /public/files/download/download.php
this rule would transform this user's URL..
http://mysite/grab?file=my.zip
server-side, into..
http://mysite/public/files/download/download.php?file=my.zip
which is a wee trick I use for my distro machine, among other things. everyone likes short URL's, and so will you; using this technique, you can move /public/files/download/ to anywhere else in your site, and all the old links still work fine; simply alter your .htaccess file to reflect the new location. edit one line, done - nice - means even when stuff is way deep in your site you can have cool links like this.. /trueview/sample.php and this; links which are not only short, but flat..
capturing variables
Slapping (.*) onto the end of the request part of a ReWriteRule is just fine when using a simple $_GET variable, but sometimes you want to do trickier things, like capturing particular variables and converting them into other variables in the target URL. Or something else..
When capturing variables, the first thing you need to know about, is the [QSA] flag, which simply tags all the original variables back onto the end of the target url. This may be all you need, and will happen automatically for simple rewrites. The second thing, is %{QUERY_STRING}, an Apache server string we can capture variables from, using simple RewriteCond (aka. conditional ) statements.
RewriteCond is very like doing if...then...do in many programming languages. If a certain condition is true, then do the rewrite that follows..
In the following example, the RewriteCond statement checks that the query string has the foo variable set, and captures its value while it's there. In other words, only requests for /grab that have the variable foo set, will be rewritten, and while we're at it, we'll also switch foo, for bar, just because we can..
would translate a link/user's request for..
http://domain.com/grab?foo=bar
server-side, into..
http://domain.com/page.php?bar=bar
Which is to say, the user's browser would be fed page.php (without an [R] flag in the RewriteRule, their address bar would still read /grab?foo=bar). The variable bar would be available to your script, with its value set to bar. This variable has been magically created, by simply using a regular ? in the target of the RewriteRule, and tagging on the first captured backreference, %1.. ?bar=%1
Note how we use the
You can use the [QSA] flag in addition to these query string manipulations, merge them. In the next example, the value of foo becomes the directory in the target URL, and the variable file is magically created. The original query string is then tagged back onto the end of the whole thing..
So a request for..
http://domain.com/grab/foobar.zip?level=5&foo=bar
is translated, server-side, into..
http://domain.com/bar/index.php?file=foobar.zip&level=5&foo=bar
Depending on your needs, you could even use flat links and dynamic variables together, something like this could be useful..
By the way, you can easily do the opposite, strip a query string from a URL, by simply putting a ? right at the end of the target part. This example does exactly that, whilst leaving the actual URI intact..
When capturing variables, the first thing you need to know about, is the [QSA] flag, which simply tags all the original variables back onto the end of the target url. This may be all you need, and will happen automatically for simple rewrites. The second thing, is %{QUERY_STRING}, an Apache server string we can capture variables from, using simple RewriteCond (aka. conditional ) statements.
RewriteCond is very like doing if...then...do in many programming languages. If a certain condition is true, then do the rewrite that follows..
In the following example, the RewriteCond statement checks that the query string has the foo variable set, and captures its value while it's there. In other words, only requests for /grab that have the variable foo set, will be rewritten, and while we're at it, we'll also switch foo, for bar, just because we can..
capturing a $_GET variable:Options +FollowSymlinks
RewriteEngine On
RewriteCond %{QUERY_STRING} foo=(.*)
RewriteRule ^grab(.*) /page.php?bar=%1
would translate a link/user's request for..
http://domain.com/grab?foo=bar
server-side, into..
http://domain.com/page.php?bar=bar
Which is to say, the user's browser would be fed page.php (without an [R] flag in the RewriteRule, their address bar would still read /grab?foo=bar). The variable bar would be available to your script, with its value set to bar. This variable has been magically created, by simply using a regular ? in the target of the RewriteRule, and tagging on the first captured backreference, %1.. ?bar=%1
Note how we use the
% character, to specify variables captured in RewriteCond statements, aka "Backreferences". This is exactly like using $1 to specify numbered backreferences captured in RewriteRule patterns, except for strings captured inside a RewriteCond statement, we use % instead of $. Simple.You can use the [QSA] flag in addition to these query string manipulations, merge them. In the next example, the value of foo becomes the directory in the target URL, and the variable file is magically created. The original query string is then tagged back onto the end of the whole thing..
QSA Overkill!Options +FollowSymlinks
RewriteEngine On
RewriteCond %{QUERY_STRING} foo=(.+)
RewriteRule ^grab/(.*) /%1/index.php?file=$1 [QSA]
So a request for..
http://domain.com/grab/foobar.zip?level=5&foo=bar
is translated, server-side, into..
http://domain.com/bar/index.php?file=foobar.zip&level=5&foo=bar
Depending on your needs, you could even use flat links and dynamic variables together, something like this could be useful..
mixing flat and dynamic links in a single ruleset..Options +FollowSymlinks
RewriteEngine On
RewriteCond %{QUERY_STRING} version=(.+)
RewriteRule ^grab/([^/]+)/(.*) /%1/index.php?section=$1&file=$2 [QSA]
By the way, you can easily do the opposite, strip a query string from a URL, by simply putting a ? right at the end of the target part. This example does exactly that, whilst leaving the actual URI intact..
The RewriteCond statement only allows requests that have something in their query string, to be processed by the RewriteRule, or else we'd end up in that hellish place, dread to all mod_rewriters.. the endless loop. RewriteCond is often used like this; as a safety-net.just a demo!Options +FollowSymlinks
RewriteEngine On
RewriteCond %{QUERY_STRING} .
RewriteRule foo.php(.*) /foo.php? [L]
cooler access denied
In part one I demonstrated a drop-dead simple mechanism for denying access to particular files and folders. The trouble with this is the way our user gets a 403 "Access Denied" error, which is a bit like having a door slammed in your face. Fortunately, mod_rewrite comes to the rescue again and enables us to do less painful things. One method I often employ is to redirect the user to the parent folder..
It works great, though it can be a wee bit tricky with the URLs, and you may prefer to use a harder location, which avoids potential issues in indexed directories, where folks can get in a loop..
Sometimes you'll only want to deny access to most of the files in the directory, but allow access to maybe one or two files, or file types, easy..
Here we take the whole thing a stage further. Users can access .css (stylesheet) and Javascript files without problem, and also the file called "special.zip", but requests for any other file types are immediately redirected back up to the main "/chat/" directory. You can add as many types as you need. You could also bundle the filetypes into one line using | (or) syntax, though individual lines are perhaps clearer.
Here's what's currently cooking inside my /inc/ directory..
they go "huh?.. ahhh!"# send them up!
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.*)$ ../ [NC]
It works great, though it can be a wee bit tricky with the URLs, and you may prefer to use a harder location, which avoids potential issues in indexed directories, where folks can get in a loop..
they go damn! Oh!# send them exactly there!
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.*)$ /comms/hardware/router/ [NC]
Sometimes you'll only want to deny access to most of the files in the directory, but allow access to maybe one or two files, or file types, easy..
deny with style!# users can load only "special.zip", and the css and js files.
Options +FollowSymlinks
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !^(.+)\.css$
RewriteCond %{REQUEST_FILENAME} !^(.+)\.js$
RewriteCond %{REQUEST_FILENAME} !special.zip$
RewriteRule ^(.+)$ /chat/ [NC]
Here we take the whole thing a stage further. Users can access .css (stylesheet) and Javascript files without problem, and also the file called "special.zip", but requests for any other file types are immediately redirected back up to the main "/chat/" directory. You can add as many types as you need. You could also bundle the filetypes into one line using | (or) syntax, though individual lines are perhaps clearer.
Here's what's currently cooking inside my /inc/ directory..
all-in-one control..RewriteEngine on
Options +FollowSymlinks
# allow access with no restrictions to local machine at 192.168.1.3
RewriteCond %{REMOTE_ADDR} !192.168.1.3
# allow access to all .css and .js in sub-directories..
RewriteCond %{REQUEST_URI} !\.css$
RewriteCond %{REQUEST_URI} !\.js$
# allow access to the files inside img/, but not a directory listing..
RewriteCond %{REQUEST_URI} !img/(.*)\.
# allow access to these particular files...
RewriteCond %{REQUEST_URI} !comments.php$
RewriteCond %{REQUEST_URI} !corzmail.php$
RewriteCond %{REQUEST_URI} !digitrack.php$
RewriteCond %{REQUEST_URI} !gd-verify.php$
RewriteCond %{REQUEST_URI} !post-dumper.php$
RewriteCond %{REQUEST_URI} !print.php$
RewriteCond %{REQUEST_URI} !source-dump.php$
RewriteCond %{REQUEST_URI} !textview.php$
RewriteRule ^(.*)$ / [R,NC,L]
Ban User Agents, referrers, script-kiddies and more..
There are many valid reasons to ban a particular request from sucking up your site's resources; resources that could be better served to valid, interested users. It might be some cross-site attack script, or inward link from a place you don't want to be associated with, or perhaps a web sucker or download manager, whatever; .htaccess + mod_rewrite provides ways to protect your content from unwanted "guests".The basic formula is standard if-then logic: if the request meets a particular CONDITION, then REWRITE the request. The "conditions" can be many things; perhaps the referrer header sent by their browser (the site they came from), or the page they asked for, or a particular query parameter, or the type of client (browser, etc.) they are using, or any other piece of information Apache has attached to the request. Here's an example which will deny access to "Teleport Pro", a download manager which is known to suck, hard..
Who need's a local copy, when I'm right here?..RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [NC]
RewriteRule . abuse.txt [L]
It's your site, and just like your home, you have every right to exert some control over who gets in. You may have a huge list of user agents you'd rather not have eating your bandwidth; so use the [OR] flag, and line 'em up..
A little garlic for the net vampires..RewriteCond %{HTTP_USER_AGENT} ^BackWeb [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Bandit [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^BatchFTP [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^BecomeBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [NC,OR]
# etc..
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [NC]
RewriteRule . abuse.txt [L]
This forms the basis of what often becomes a HUGE list of ban-lines. Remember, we aren't limited to user agent strings..
Suckers, h4x0rz, kiddies, cross-site scripters and more.. Bye now!# why not come visit me directly?
RewriteCond %{HTTP_REFERER} \.opendirviewer\. [NC,OR]
# this prevents stoopid cross-site discovery attacks..
RewriteCond %{THE_REQUEST} \?\ HTTP/ [NC,OR]
# please stop pretending to be the Googlebot..
RewriteCond %{HTTP_REFERER} users\.skynet\.be.* [NC,OR]
# really, we need a special page for these twats..
RewriteCond %{QUERY_STRING} \=\|w\| [NC,OR]
RewriteCond %{THE_REQUEST} etc/passwd [NC,OR]
RewriteCond %{REQUEST_URI} owssvr\.dll [NC,OR]
# you can probably work these out..
RewriteCond %{QUERY_STRING} \=\|w\| [NC,OR]
RewriteCond %{THE_REQUEST} \/\*\ HTTP/ [NC,OR]
# etc..
RewriteCond %{HTTP_USER_AGENT} Sucker [NC]
RewriteRule . abuse.txt [L]
Fortunately, mod_rewrite can parse enormous lists of ban-lines in milliseconds, so feel free to be as specific and comprehensive as required.
As ever, thorough testing is strongly recommended. Simply send requests matching your conditions and see what happens. And importantly; normal requests, too. Firefox, Opera, Konqueror, and most other decent browsers, allow you to alter the user agent string; though you would quickly find the process tedious in a testing situation. Far better to use some tool better designed to send fake HTTP requests..
It's not too difficult to mock up a web request on the command-line with any-old user agent using a scripting language like php or Perl, if you have these things available (read: most Linux/UNIX/BSD/etc. as well as many other OS). Many examples exist online. In fact, you could quickly create a suite of tests, designed to interrogate all your rewrite rules, with results logging and much more, if required. cURL is always useful for jobs like this, so long as you don't add a cURL ban-line!
On a Windows desktop, Sam Spade can send a single spoofed request with a couple of clicks, along with a stack of similarly handy tricks, and regularly proves itself invaluable.
Don't let just anyone hammer your site!
While I'm on the subject of abusive web clients, you will probably have noticed that many clients (bots, spiders, automated suckers and such) like to disguise their user agent information, in fact any information, in an attempt to bring your site to its knees, hammering your pages so-many times per second in the process. Oh dear.If you are interested in a way to defeat hammering web clients, regardless of who they pretend to be, or whether or not they accept cookies or any such malarkey, check out Anti-Hammer. It's free.
prevent hot-linking
Believe it or not, there are some webmasters who, rather than coming up with their own content will steal yours. Really! Even worse, they won't even bother to copy to their own server to serve it up, they'll just link to your content! no, it's true, in fact, it used to be incredibly common. These days most people like to prevent this sort of thing, and .htaccess is one of the best ways to do it.
This is one of those directives where the mileage variables are at their limits, but something like this works fine for me..
You may see the last line broken into two, but it's all one line (all the directives on this page are). Let's have a wee look at what it does..
We begin by enabling the rewrite engine, as always.
The first RewriteCond line allows direct requests (not from other pages - an "empty referrer") to pass unmolested. The next line means; if the browser did send a referrer header, and the word "corz.org" is not in the domain part of it, then DO rewrite this request.
The all-important final RewriteRule line instructs mod_rewrite to rewrite all matched requests (anything without "corz.org" in its referrer) asking for gifs, jpegs, or pngs, to an alternative image.
There are loads of ways you can write this rule; Google for "hot-link protection" and get a whole heap. Simple is best. You could send a wee message instead, or direct them to some evil script, or something. Mine is a simple corz.org logo, which I think is rather clever. Actually, these days, I do something even cleverer-er..
This is one of those directives where the mileage variables are at their limits, but something like this works fine for me..
how DARE they!Options +FollowSymlinks
# no hot-linking
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?corz\.org/ [NC]
RewriteCond %{REQUEST_URI} !hotlink\.(gif|png) [NC]
RewriteRule .*\.(gif|jpg|png)$ http://corz.org/img/hotlink.png [NC]
You may see the last line broken into two, but it's all one line (all the directives on this page are). Let's have a wee look at what it does..
We begin by enabling the rewrite engine, as always.
The first RewriteCond line allows direct requests (not from other pages - an "empty referrer") to pass unmolested. The next line means; if the browser did send a referrer header, and the word "corz.org" is not in the domain part of it, then DO rewrite this request.
The all-important final RewriteRule line instructs mod_rewrite to rewrite all matched requests (anything without "corz.org" in its referrer) asking for gifs, jpegs, or pngs, to an alternative image.
There are loads of ways you can write this rule; Google for "hot-link protection" and get a whole heap. Simple is best. You could send a wee message instead, or direct them to some evil script, or something. Mine is a simple corz.org logo, which I think is rather clever. Actually, these days, I do something even cleverer-er..
lose the "www"
I'm often asked how I prevent the "www" part showing up at my site, so I guess I should add something about that. Briefly, if someone types http://www.corz.org/ into their browser (or uses the www part for any link at corz.org) it is redirected to the plain, rather neat, http://corz.org/ version. This is very easy to achieve, like this..
You don't need to be touched by genius to see what's going on here. There are other ways you could write this rule, but again, simple is best. Like most of the examples here, the above is pasted directly from my own main .htaccess file, so you can be sure it works perfectly. In fact, I recently updated it so that I could share rules between my dev mirror and live site without any .htaccess editing..
beware the regular expression:Options +FollowSymlinks
RewriteEngine on
RewriteCond %{http_host} ^www\.corz\.org [NC]
RewriteRule ^(.*)$ http://corz.org/$1 [R=301,NC]
You don't need to be touched by genius to see what's going on here. There are other ways you could write this rule, but again, simple is best. Like most of the examples here, the above is pasted directly from my own main .htaccess file, so you can be sure it works perfectly. In fact, I recently updated it so that I could share rules between my dev mirror and live site without any .htaccess editing..
here's what I'm currently using:Options +FollowSymlinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.(.*) [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,NC,L]
multiple domains in one root
If you are in the unfortunate position of having your sites living on a host that doesn't support multiple domains, you may be forced to roll your own with .htaccess and mod_rewrite. So long as your physical directory structure is well thought-out, this is fairly simple to achieve.
For example, let's say we have two domains, pointing at a single hosted root; domain-one.com and domain-two.com. In our web server root, we simply create a folder for each domain, perhaps one/, and two/ then in our main (root) .htaccess, rewrite all incoming requests, like this..
All requests for the host domain-one.com are rewritten (not R=redirected) to the one/ directory, so long as they haven't already been rewritten there (the second RewriteCond). Same story for domain-two.com. Note the inconsistency in the RewriteCond statement; !^/dir-name and !^dir-name should both work fine.
Also note, with such a simple domain & folder naming scheme, you could easily merge these two rule sets together. This would be unlikely in the real world though, which is why I left them separate; but still, worth noting.
Other general settings and php directives can also go in this root .htaccess file, though if you have any further rewrite you'd like to perform; short URL's, htm to php conversion and what-not; it's probably easier and clearer to do those inside the sub-directory's .htaccess files.
For example, let's say we have two domains, pointing at a single hosted root; domain-one.com and domain-two.com. In our web server root, we simply create a folder for each domain, perhaps one/, and two/ then in our main (root) .htaccess, rewrite all incoming requests, like this..
All requests NOT already rewritten into these folders, transparently rewrite..#two domains served from one root..
RewriteCond %{HTTP_HOST} domain-one.com
RewriteCond %{REQUEST_URI} !^/one
RewriteRule ^(.*)$ one/$1 [L]
RewriteCond %{HTTP_HOST} domain-two.com
RewriteCond %{REQUEST_URI} !^two
RewriteRule ^(.*)$ two/$1 [L]
All requests for the host domain-one.com are rewritten (not R=redirected) to the one/ directory, so long as they haven't already been rewritten there (the second RewriteCond). Same story for domain-two.com. Note the inconsistency in the RewriteCond statement; !^/dir-name and !^dir-name should both work fine.
Also note, with such a simple domain & folder naming scheme, you could easily merge these two rule sets together. This would be unlikely in the real world though, which is why I left them separate; but still, worth noting.
Other general settings and php directives can also go in this root .htaccess file, though if you have any further rewrite you'd like to perform; short URL's, htm to php conversion and what-not; it's probably easier and clearer to do those inside the sub-directory's .htaccess files.
automatic translation
If you don't read English, or some of your guests don't, here's a neat way to have the wonderful Google translator provide automatic on-the-fly translation for your site's pages. Something like this..
You can create your menu with its flags or whatever you like, and add the country code to end of the links..
Although it is very handy, and I've been using it here for a couple of years here at the org, for my international blog readers, all two of them, heh. Almost no one knows about it, mainly because I don't have any links . One day I'll probably do a wee toolbar with flags and what-not. Perhaps not. Trouble is, the Google translator stops translating after a certain amount of characters (which seems to be increasing, good), though these same rules could easily be applied to other translators, and if you find a good one, one that will translate a really huge document on-the-fly, do let me know!
If you wanted to be really clever, you could even perform some some kind of IP block check and present the correct version automatically, but that is outside the scope of this document. note: this may be undesirable for pages where technical commands are given (like this page) because the commands will also be translated. "RewriteEngine dessus" will almost certainly get you a 500 error page!
Another thing you might like to try; rather than individual country flags; fr, de, etc., use the "u" flag, for "Universal". In theory, Google will check the client's location, and automatically translate to that language. One line in your .htaccess would cover all languages, and automatically cover new ones as Google adds them.
While I'm here, slightly related; if you are non-Englishman speaking, note, you can do a similar thing browser-side, create a "bookmarklet" (a regular bookmark, except that it "does something"), using this code for the location..
they simply add their country code to the end of the link, or you do..Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.*)-fr$ http://www.google.com/translate_c?hl=fr&sl=en&u=http://corz.org/$1 [R,NC]
RewriteRule ^(.*)-de$ http://www.google.com/translate_c?hl=de&sl=en&u=http://corz.org/$1 [R,NC]
RewriteRule ^(.*)-es$ http://www.google.com/translate_c?hl=es&sl=en&u=http://corz.org/$1 [R,NC]
RewriteRule ^(.*)-it$ http://www.google.com/translate_c?hl=it&sl=en&u=http://corz.org/$1 [R,NC]
RewriteRule ^(.*)-pt$ http://www.google.com/translate_c?hl=pt&sl=en&u=http://corz.org/$1 [R,NC]
You can create your menu with its flags or whatever you like, and add the country code to end of the links..
Although it is very handy, and I've been using it here for a couple of years here at the org, for my international blog readers, all two of them, heh. Almost no one knows about it, mainly because I don't have any links . One day I'll probably do a wee toolbar with flags and what-not. Perhaps not. Trouble is, the Google translator stops translating after a certain amount of characters (which seems to be increasing, good), though these same rules could easily be applied to other translators, and if you find a good one, one that will translate a really huge document on-the-fly, do let me know!
If you wanted to be really clever, you could even perform some some kind of IP block check and present the correct version automatically, but that is outside the scope of this document. note: this may be undesirable for pages where technical commands are given (like this page) because the commands will also be translated. "RewriteEngine dessus" will almost certainly get you a 500 error page!
Another thing you might like to try; rather than individual country flags; fr, de, etc., use the "u" flag, for "Universal". In theory, Google will check the client's location, and automatically translate to that language. One line in your .htaccess would cover all languages, and automatically cover new ones as Google adds them.
While I'm here, slightly related; if you are non-Englishman speaking, note, you can do a similar thing browser-side, create a "bookmarklet" (a regular bookmark, except that it "does something"), using this code for the location..
the same sort of thing, except browser-side..javascript:void(location.href='http://translate.google.com/translate?u='+location.href)
httpd.conf
Remember, if you put these rules in the main server conf file (usually httpd.conf) rather than an .htaccess file, you'll need to use ^/... ... instead of ^... ... at the beginning of the RewriteRule line, in other words, add a slash.
inheritance..
If you are creating rules in sub-folders of your site, you need to read this.
You'll remember how rules in top folders apply to all the folders inside those folders too. we call this "inheritance". normally this just works. but if you start creating other rules inside subfolders you will, in effect, obliterate the rules already applying to that folder due to inheritance, or "decendancy", if you prefer. not all the rules, just the ones applying to that subfolder. a wee demonstration..
Let's say I have a rule in my main
Here's my updated
Spot the difference in the subfolder rule, highlighted in red. you must add the current path to the new rule. now it works again, and all the osx/ subfolders will be covered by the new rule. if you remember this, you can go replicating rewrite rules all over the place.
If it's possible to put your entire site's rewrite rules into the main .htaccess file, and it probably is; do that, instead, like this..
Note, no full URL (with domain) in the second example. Don't let this throw you; with or without is functionally identical, on most servers. Essentially, try it without the full URL first, and if that doesn't work, sigh, and add it - maybe on your next host!
The latter, simpler form is preferable, if only for its tremendous portability it offers - my live site, and my development mirror share the exact same .htaccess files - a highly desirable thing.
By the way, it perhaps doesn't go without saying that if you want to disable rewriting inside a particular subfolder, where it is enabled further up the tree, simply do:
You'll remember how rules in top folders apply to all the folders inside those folders too. we call this "inheritance". normally this just works. but if you start creating other rules inside subfolders you will, in effect, obliterate the rules already applying to that folder due to inheritance, or "decendancy", if you prefer. not all the rules, just the ones applying to that subfolder. a wee demonstration..
Let's say I have a rule in my main
/.htaccess which redirected requests for files ending .htm to their .php equivalent, just like the example at the top of this very page. now, if for any reason I need to add some rewrite rules to my /osx/.htaccess file, the .htm >> .php redirection will no longer work for the /osx/ subfolder, I'll need to reinsert it, but with a crucial difference..this works fine, site-wide, in my main .htaccess file# main (top-level) .htaccess file..
# requests to file.htm goto file.php
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.*)\.htm$ http://corz.org/$1.php [R=301,NC]
Here's my updated
/osx/.htaccess file, with the .htm >> .php redirection rule reinserted..but I'll need to reinsert the rules for it to work in this sub-folder# /osx/.htaccess file..
Options +FollowSymlinks
RewriteEngine on
RewriteRule some rule that I need here
RewriteRule some other rule I need here
RewriteRule ^(.*)\.htm$ http://corz.org/osx/$1.php [R=301,NC]
Spot the difference in the subfolder rule, highlighted in red. you must add the current path to the new rule. now it works again, and all the osx/ subfolders will be covered by the new rule. if you remember this, you can go replicating rewrite rules all over the place.
If it's possible to put your entire site's rewrite rules into the main .htaccess file, and it probably is; do that, instead, like this..
it's a good idea to put all your rules in your main .htaccess file..# root /.htaccess file..
Options +FollowSymlinks
RewriteEngine on
# .htm >> .php is now be covered by our main rule, there's no need to repeat it.
# But if we do need some /osx/-specific rule, we can do something like this..
RewriteRule ^osx/(.*)\.foo$ /osx/$1.bar [R=301,NC]
Note, no full URL (with domain) in the second example. Don't let this throw you; with or without is functionally identical, on most servers. Essentially, try it without the full URL first, and if that doesn't work, sigh, and add it - maybe on your next host!
The latter, simpler form is preferable, if only for its tremendous portability it offers - my live site, and my development mirror share the exact same .htaccess files - a highly desirable thing.
By the way, it perhaps doesn't go without saying that if you want to disable rewriting inside a particular subfolder, where it is enabled further up the tree, simply do:
handy for avatar folders, to allow hot-linking, etc..RewriteEngine off
cookies
conclusion
In short, mod_rewrite enables you to send browsers from anywhere to anywhere. You can create rules based not simply on the requested URL, but also on such things as IP address, browser agent (send old browsers to different pages, for instance), and even the time of day; the possibilities are practically limitless.The ins-and outs of mod_rewrite syntax are topic for a much longer document than this, and if you fancy experimenting with more advanced rewriting rules, I urge you to check out the Apache documentation.
Wednesday, June 8, 2011
Magento 1.3 How to get configured values
User can modify the configured values at Backend > System >
Configuration and Magento stores the configured values in the table
core_config_data
Have fun 
Checked at:
Table core_config_data
You can retrieve that value by the path of
configured value. Here is the code if you want to get custom email 1 at
System > Configuration > General > Store Email Address >
Custom Email 1 > Sender Email
1
| $custom1_email = Mage::getStoreConfig('trans_email/ident_custom1/email'); |
Checked at:
- Magento 1.3.1+
Thursday, June 2, 2011
Joomla! Plugins in VirtueMart
Joomla! plugins (mambots) are great! Show a video, play some music, protect an email address, or format that nifty quote. Unfortunately, content plugins don't work by default in VirtueMart 1.0.x. This hack lets you run Joomla! plugins in VirtueMart pages
-------
Note:
The files modified in this tutorial are available for download in the Projects section of this site for those of you who just want the results but are not interested in the details. The modifications are marked with the text, gregdev. All modifications are done with respect to VirtueMart 1.0.9.
------
Calling Joomla! Plugins
There are three main steps required to call a Joomla! plugin:
Get access to the global $_MAMBOTS object.
Load a plugin group (in our case, content plugins).
Trigger an event.
Thus, the code for running some text, say $text_to_process, through the Joomla! content plugins would look like this:
global $_MAMBOTS;
$_MAMBOTS->loadBotGroup( 'content' );
$tmp_row = new stdClass();
$tmp_params = new mosParameters('');
$tmp_row->text = $text_to_process;
$_MAMBOTS->trigger( 'onPrepareContent', array( &$tmp_row, &$tmp_params ), true );
$text_to_process = $tmp_row->text;
So, to make plugins work in VirtueMart pages, we just need to add this code to the VirtueMart files where we'd like the plugins to be called.
NOTE: Be sure to back up the files before making any changes. All the files that you'll need to edit are located in the /administrator/components/com_virtuemart/html directory.
Product Details Pages
To show plugins on your product details pages, you'll need to edit shop.product_details.php. Look for the following line, near the bottom of the file (line 394):
$template = preg_replace("/{vm_lang:([^}]*)}/ie", "\$VM_LANG->\\1", $template);
Right after that line, add the plugin calling code:
global $_MAMBOTS;
$_MAMBOTS->loadBotGroup( 'content' );
$tmp_row = new stdClass();
$tmp_params = new mosParameters('');
$tmp_row->text = $template;
$_MAMBOTS->trigger( 'onPrepareContent', array( &$tmp_row, &$tmp_params ), true );
$template = $tmp_row->text;
Notice that the text we are running the plugins on is contained in the $template variable.
Now just call the plugin from your product description (the long description) in VirtueMart.
Shop Browse Pages
You might also want to run a plugin on the shop browse pages - for example, on a category description or a product's short description. To do this, you'll need to modify shop.browse.php.
Near the top of the file, look for this line (19):
mm_showMyFileName( __FILE__ );
Right after this add just the code that loads the plugins:
global $_MAMBOTS;
$_MAMBOTS->loadBotGroup( 'content' );
$plug_row = new stdClass();
$plug_params = new mosParameters('');
Notice that we're loading the plugin group at the beginning of the file, but not actually triggering the plugins yet. We'll trigger the plugins later on the category descriptions and short product descriptions separately.
Now, to run plugins on category descriptions, look for these two lines (83-84):
echo '
';
echo $desc;
Right between those two lines, add this code to trigger the plugins:
$plug_row->text = $desc;
$_MAMBOTS->trigger( 'onPrepareContent', array( &$plug_row, &$plug_params ), true );
$desc = $plug_row->text;
The variable $desc contains the category description.
Let's also make plugins work for the short product descriptions that appear on the shop browse pages. In the same file, shop.browse.php, look for this line (476):
echo $product_cell;
Right before it, add the following plugin code:
$plug_row->text = $product_cell;
$_MAMBOTS->trigger( 'onPrepareContent', array( &$plug_row, &$plug_params ), true );
$product_cell = $plug_row->text;
The variable $product_cell contains the short product description.
Now just add the appropriate plugin call to a category description or short product description in VirtueMart, and you'll have Joomla! plugins displayed in VirtueMart's shop browse page
Subscribe to:
Posts (Atom)