April 12, 2008
URL Encode / Decode Script
I just created and uploaded a new little script to help people sort out what URL Encoded characters mean. It works both ways. It'll encode plain ASCII text into text strings like you would see in encoded URLs, and it'll also decode strings into plain ASCII text. I've even incorporated plus signs (+) and %20 encoded strings, which equate to a space character in urls.
I made it mainly for those who need to figure out which encoded characters mean what when needing to account for them in rewrites. I don't know about others, but I get tired of having to look at ASCII conversion tables to figure out what an encoded character string means, so this tool will come in handy for yours truly. Regardless of why I made it, the tool will work just fine for lots of different things having to do with encoding or decoding urls.
There's a link to the new tool in the "links" nav menu to the left under URL Encoder/Decoder, or you can simply click here to go to the new tool.
Enjoy!
Posted by Randy at 08:48 AM | Comments (0) | TrackBack
March 17, 2008
301 Redirects on IIS Servers
As most of you know, I don't do IIS. It's a personal choice I've made for reasons that I won't bother going into now. That said, setting up redirects in IIS is a completely animal than it is with a *nix/Apache server.
One way to accomplish the task on an IIS server is to install ISAPI Filters. The ISAPI Dyanmic Link Library functions much the same .htaccess does in an Apache environment, to the point that many .htaccess rewrite syntax can be used without alteration in ISAPI.
The main issue with ISAPI being that unlike .htaccess many ISAPI extensions are going to cost you real money. Since ISAPI runs as an application on IIS there is often a cost involved for the webmaster in order to utilize them. The other issue being that if you're on a shared IIS server you often won't have enough control to install ISAPI filters yourself. And many hosts balk at installing them for reasons of their own.
A classic catch-22 situation.
Just because you're on an IIS server doesn't necessarily mean you cannot employ rewrites and redirects though. Though I don't dabble in IIS rewrites personally, Chris Hirst --who I hang out with over at the HR Forums-- is an IIS guru and has come up with several differnt ways one can accomplish what I do with .htaccess on IIS servers. For completeness, here are some links to his ideas.
Tweaking the Application Mappings in IIS - This will allow you to have pages with one extension treated as if they were files carrying another extension. So if you need .htm pages to be parsed as if they were .asp, this is the one you'll want.Handling www/non-www issues in ASP - This snippet of code is something Chris developed to deal with www and non-www requests when you have a .asp site. It is code that is run at the Script or File level, but is dynamic. One note: The original code Chris posted in reply #4 does not account for variables in the URL string. If you have a dynamic ASP site that needs help with www/non-www issues, look a bit farther along in the thread. In post 22 on page 2 Chris provides a code snippet that will take care of query strings.
Using a Smart 404 Page - A Smart 404 is basically a method you can use when you have pages that are changing location and you want to make sure the link pop the old page had accrued gets passed along to the new page. What happens is everyone (spiders included) initially gets sent to the custom 404 page when they request a file that no longer exists. Then the custom (smart) 404 runs through a small bit of code to decide if it should really deliver a 404 Not Found response or if it should instead deliver a 301 Moved Permanently response, sending the visitor on to the correct page. This can be very, very effective regardless of the extension your site files use, because you can always set your IIS server to display an asp file as your custom, smart 404 page. All it requires is that you enter your page uri's (relative path from root) at the top of the code. The script then does all of the heavy lifting for you.
If the above references do not address your specific situation or if you have an IIS redirect problem that you can't sort out, by all means feel free to post your question in the Technology & Coding > Redirects portion of High Rankings Forum and someone will be by to help you sort it out.
Posted by Randy at 07:12 AM | Comments (0) | TrackBack
January 22, 2008
Database Backup Script
Just a quick note today to let you know I've just uploaded a modified version of the Database Backup script that I first released some 2 1/2 years ago. It's not a critical update or anything, just a couple of useful tweaks.
The need arose for me to have the ability to make a backup of a database that lives on a separate MySQL Database Server. So rather than back it up on the db server itself via a shell script I chose to use the php database dumper script to create the backups on the main server that runs Apache, mail and everything by the MySQL server.
The additions allow one to specific either localhost (for local dbs), and IP number of a remote server or a hostname. It also allows one to set the port to use in case you're using something other than the standard MySQL port 3306.
While I was tweaking the script I added a --lock-tables option to the mix, which will cause the script to lock a table before starting its dump. This was done to fend off the rare cases of potential data corruption if the db was changing at the exact moment a table was being updated.
If you need to make any other changes to how mysqldump works in the script you can simply edit the three appropriate lines to add them. For instance, if you wanted to add a --add-drop-table so that the dumps would automagically drop existing tables when performing a restore it's a trivial edit. Just remember there are 3 places in the script to make such edits (they're easy to find) and also be careful about leading spaces with the concactenation. In other words, to insert --add-drop-table it should look like " --add-drop-table" as opposed to "--add-drop-table".
Cheers!
Posted by Randy at 05:18 AM | Comments (0) | TrackBack
September 23, 2007
Header Checker Script
Yes, I know it's been forever since I've been here to author anything. Sorry, but life and work have both been a little bit hectic. Sorry 'bout that, but that's the way it goes sometimes.
Anyway, just a quick note today to let everyone (anyone left! LOL) know that I've just created and uploaded a little HTTP Header Checker tool. I normally use a little freebie called WebBug that has been out there for years. But some people don't want to download and/or install it, it's a Windows only tool and it defaults to HTTP Version 1.0, which was incredibly buggy. So I cobbled together a quick little PHP script to do the same thing WebBug does, only better in some ways.
Better in that is doesn't force everything to HTTP Ver 1.0 by default and also in that it'll show each users browser details as the User-agent string rather than something else. (Some folks block WebBug at their firewall, so you might get a false return.)
Anyway, it's there if you want to use it.
Posted by Randy at 09:19 AM | Comments (0)
April 25, 2007
.htaccess and mod_rewrite (continued)
Note: To make this easier for you, here are direct links for Part 1 and Part 2 of this brief .htaccess tutorial.
Let's jump right in and move on to some of the single character pre-defined modifiers we can use with mod_rewrite to make it do its magic.
^ (Caret) - The character is one of those pre-defined modifiers that actually has two meanings and purposes, depending upon where it's being used.
Most of the time you use it you can remember it as being equal to Starts With. Such as below.
Example: RewriteCond %{HTTP_HOST} ^domain\.com [NC]
As already discussed, the above equates to saying in English The HTTP_HOST variable starts with domain.com
The other use for a ^ caret is when it's inside of an Expression grouping, which we covered in the last section. The way to remember an Expression Grouping is that it's going to be enclosed inside square brackets. ala [0-9]
When a caret appears inside an expression grouping the ^ means Not. It's easier to explain with an example.
Example: RewriteRule ^store/[^0-9] /store/index.php?prodid=$1
In the above the first caret (before "store") means Starts With. The second caret (preceeding the zero) means Not. So in English it will test as true --or match-- if the request is to www.domain.com/store/a or any other version where the last character is Not a number between 0 and 9. Most think this would mean any letter, but it really means any single character. So something like www.domain.com/~ and www.domain.com/& would also match.
The caret is about the only one to remember this dual meaning. 99% of the time you'll be using it to mean Starts With, but there are those rare occasions (I'll cover some later) where it can be useful to mean Not inside an expression grouping.
! (Exclamation Point) - The exclamation point is one of those that is really cool. It means Not during normal mod_rewrites. You'll sometimes see these instances referred to a Negative Match. Meaning you're trying to test true for everything but one very specific instance.
Many times it's much easier to use a negative match because you know what you don't want to happen, whereas it could be difficult or impossible to imagine every possible positive match.
Example: RewriteCond %{HTTP_HOST} !^www\.domain\.com [NC]
The above simply says The HTTP_HOST variable does not start with "www.domain.com" Clean and simple. In its normal use the ! will be at the very beginning of your conditional statement. Generally it is not allowed in the center of an equation, because there is already the [^a-z] Not expression option.
One different way an exclamation can be used is when it appears on the Right side of the equation. In this case it stands for No Rewrite. I'm not going to go into it much here because frankly it's not used often. When it is used on the right side it's usually done to see if a file or directory exists.
| (Pipe) - The Pipe character equates to the word or and can be used to match alternate text or expressions that are grouped inside a set of parentheses. (see below for parens grouping.)
Example: RewriteCond %{REQUEST_URI} ^/(index|home|default)\.php
The above would test true for www.domain.com/index.php, www.domain.com/home.php and www.domain.com/default.php.
( ) (Parentheses) - Parentheses provide something of a dual role. Mainly they are used to create a variable that gets stored and can later be recalled. However it is also used as a compliment to the Square Brackets [] mentioned before, since parens can be used to group characters for use with the ?, + and * special quantifiers we'll discuss in just a moment.
\ (Backward Slash) - The backslash character is one you'll need to use whenever you need to escape another character that has special meaning in Regex so that it is treated literally rather than as a special character. The main time you will use this is when you have a conditional statement (the Left side of a RewriteRule or in the conditional of a RewriteCond) that contains either a dot (.), a question mark (?) or a space character.
Example: RewriteRule ^index\.php\? /store/index.php
. (Dot or Period) - This is one of those you have to watch out for a bit. In Regex the dot does have a special meaning --that being a match of any single character excluding the end of a line-- however dots are also used in URls. The best basic rule I can tell you is to make sure you Escape any dots in your URLs when you're constructing RewriteCond's. If you don't, they're going to be seen as something other than what you intend and your rules will not perform as expected.
FTR, the way to escape dots or any other special character you need to is to slap a backslash character ( \ ) in front of it. See the syntax I used above for an example of escaping.
Now we get into the really fun (and sometimes confusing) stuff. Pre-defined regex characters that introduce the ability to Wildcard your conditionals.
? (Question Mark) - In Regex-speak the question mark can be used to test 0 or 1 of the characters --or set of characters enclodsed in brackets or parentheses-- that immediately preceeds it.
Regex-speak is confusing isn't it? It's no wonder people don't get it. But this is really easier than it appears. Some examples will help.
Example 1: RewriteRule ^store/a? /store/index.php?prodid=$1
The above example would match www.domain.com/store/ and would also match www.domain.com/a However it wouldn't match anything else. All you're telling the server is that the lowercase "a" character is completely optional.
Example 2: RewriteCond %{HTTP_HOST} ^(www\.)?domain\.com [NC]
In the above example you're telling the server you want a match no matter if the HTTP_HOST variable in the request is www.domain.com or simply domain.com
Got it? The question mark is simply a way for you to give possible matches an extra out.
+ (Plus Sign) - This is the one you'll be using often with some of the expression groupings we covered earlier. The Plus syntax means it will match 1 or more of the character preceeding it. Or alternatively match 1 or more of a group of characters that are enclosed in square brackets or parentheses. This one will require a few examples because we'll want to see how it works in conjunction with the [] Square Bracket and () Parens groupings. This is where Regex starts to stretch its legs and show you how powerful it can be.
Example 1: RewriteRule ^store/a+ /store/index.php?prodid=$1
The above would match www.domain.com/store/a and www.domain.com/store/aaa and www.store.com/aaaaaaaa As long as the base URL is there and it's followed by one or more a's it'll match. That's all that will match though.
Example2: RewriteRule ^store/ape+ /store/index.php?prodid=$1
The above is a trick question. What do you think it would match as being true?
The answer is that it will match www.domain.com/store/ape and www.domain.com/store/apeeeeee but it will not match www.domain.com/store/apeape
Remember, these special wildcard quantifiers will only test true for the character that immediately preceed them. If you want them to work on more than one character, you need to make sure they're Grouped them together with brackets or parens.
Example 3: RewriteRule ^store/(ape)+ /store/index.php?prodid=$1
This is the one that would group the three letter together. It would match www.domain.com/store/ape and www.domain.com/store/apeape It would not match something like www.domain.com/store/apebigape
Example 4: RewriteRule ^store/([a-zA-Z]+) /store/index.php?prodid=$1
Take a close look at that syntax and specifically the use of grouping. This is one that comes in really handy, so you'll probably be using it a fair amount.
I'm using the Parens to create a group so that the + sign can work on the whole thing, and with the square brackets I'm telling the server to look for anything that is a letter, no matter whether it's lower- or uppercase.
So in essence this section of the rewrite rule will test True if any letter is in the appropriate place in the URL, but it would test false if any numbers or any other character (like a forward slash) appears there. It will match for www.domain.com/store/yonkers and www.domain.com/store/AbCdEfG but will return False for www.domain.com/store/yonkers1961 or even www.domain.com/store/anything/ (because of the trailing slash)
* (Asterik) - The asterik is a true Wildcard, as most people are familiar with it being. Up to a point anyway. Technically it matched 0 or more of the character preceeding it, or in the case of grouped characters one or more of the set. Examples are just easier, so you can see the usage.
Example 1: RewriteRule ^store/a* /store/index.php?prodid=$1
The above would match www.domain.com/store/ (because there are zero a's) and www.domain.com/store/a and www.domain.com/aaaaa
Example 2: RewriteRule ^store/(ape)* /store/index.php?prodid=$1
The above would match www.domain.com/store/ and www.domain.com/ape and www.domain.com/apeapeape
Example 3: RewriteRule ^store/(.*) /store/index.php?prodid=$1
Okay, I'm really not trying to confuse you. This one (.*) is one you'll see a lot of. Do you remember what the Period or Dot means? It means any single character. Any letter, any number or any other character.
So when we group it in parens with * --which matches 0 or more any single character-- we end up with a true Wildcard. The above would mach www.domain.com/store/abc and www.domain.com/store/abc123 and even www.domain.com/abc/123/big/old/ape
Obviously, you'll want to be a bit careful with this one, but it comes in really, really handy in a lot of situations.
Let's see, what others do we need to cover. There are so many to choose from!
$ Dollar Sign - The dollar sign is another of those that has a dual purpose. The best way to remember which is which is to think Left Side and Right Side. I assume that you've noticed there is a Left and Right site to rewriterules.
In RewriteRules the $ on the left side defines the End of your pattern, or more correctly in Regex-speak and Ending Anchor. So if you had something like:
RewriteRule ^store/index.htm$ /store/index.php?prodid=$1
It would match www.domain.com/store/index.htm but not match www.domain.com/store/index.html or www.domain.com/store/index.htm?var=something
Think of the $ in this instance as being a way to gain greater control over what will and will not match.
Now on the right side of a RewriteRule the $ has a completely different meaning. If you are familiar with coding in PHP it'll make complete sense because it's just a way to retrieve a previously declared variable. A quick example would be
Example: RewriteRule ^store/(.*) /store/index.php?prodid=$1
In the above the $1 at the end is going to be replaced by whatever the server read in the (.*) variable previously. These always start with the number one and count up for there. Though you don't always need to reference them in the right hand half if you don't need that partcular variable.
Example 2: RewriteRule ^store/([a-zA-Z]+)/(0-9)+ /store/index.php?categoryid=$1&prodid=$2
In the above example our Category Id is going to be letters, both capital and lowercase, then our Product ID is a number that can be 1 or more digits long. So the Category ID turns into variable $1 and the Product ID turns into variable $2.
Or if you didn't need the Category ID to pull up a product page in your database, but it the category would still be there in the URL you could simplify things by doing it simply as
Example: RewriteRule ^store/([a-zA-Z]+)/(0-9)+ /store/index.php?prodid=$2
Go it? Just because a variable is there in the original URL doesn't mean you always have to use it in your dynamic URL.
I'm glad you got it, because now I have to confuse you a bit on the Left/Right thing. In a RewriteCond and only in a RewriteCond a $ can't really be used on the left side of the equation since it's always going to be filled with one of the pre-defined conditionals. But on the Right side in RewriteCond's the $ is used to signify the ending anchor, just like it is on the Left side of RewriteRules.
Hopefully that little quirk doesn't cause anybody any pain. You won't be using a lot of $'s in RewriteCond's anyway. So remembering the Left/Right rule above is your best bet.
% (Percent Sign) - The Percent sign is another of those fun ones, though not quite as bad. You'll always use a % on the left side of your RewriteCond statements since it's there to tell the server that you want to access some server variable. For example %{HTTP_HOST} or %{HTTP_REFERER} or %{REQUEST_URI} or %{THE_REQUEST} That one is simply a given. It's part of the required syntax.
The other way you can use a % is if you have set/captured a variable in a RewriteCond that you need to use in your RewriteRule. Basically, instead of using $1 and the like when a variable is captured in the RewriteRule you can use %1 to instead insert the variable as it was captured in your RewriteCond.
Example: Options +FollowSymlinks
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/index\.php
RewriteCond %{QUERY_STRING} ^productid=(.*)
RewriteRule ^(.*)$ http://www.domain.com/store/%1/ [R=301,L]
Say hunh?
Okay, the above is a completely made up situation, but one many run across. In this case we used to have a shopping cart installed where it used dynamic URLs and everything was keyed off of the default index.php file. When someone went to a product page in the old cart there was always a "productid" in the query string part of the dynamic URL.
We've recently changed the shopping cart we use. The new one is already constructed to have so-called Search Engine Friendly URLs, showing the URLs in folder/subfolder mode instead of showing dynamic URLs with query strings.
Since we know that our new cart only needs the Product ID to display the correct page we can key to that. So in our second RewriteCond we variablize it an use %1 to drop it into our resulting URL, issuing a 301 Moved Permanently status code while we're at it so that the spiders can find the path to our new shopping cart pages.
That's enough for now. I'll let you chew on this much for a bit before going on. There are lots of ways you can mix, match and combine the various Regex syntax we've covered so far. Next we'll start using them in some real world examples.
Don't worry about trying to memorize it all. It's impossible to memorize it all. Trust me. I've been dabbling with mod_rewrite and Regular Expressions for years and I still have little cheater files I refer to many if not most times.
There are some basic things you'll want to become familiar with since they get used a lot. We'll drum those into your brain in the real world examples to follow, so don't worry about it. I'll take the time with each of those to explain what's happening, referencing the syntax that makes it happen.
Note: To make this easier for you, here are direct links for Part 1 and Part 2 of this brief .htaccess tutorial.
Posted by Randy at 08:36 PM | Comments (1)
.htaccess and mod_rewrite tutorial
Note: To make this easier for you, here are direct links for Part 1 and Part 3 of this brief .htaccess tutorial.
In this section we'll review some of the tools and syntax we can use to create instructions the server will process for us. First, some important syntax items. You'll use these over and over.
The syntax used in mod_rewrite is what is known as Regular Expression, or Regex in geek-speak. Regular Expressions is nothing more than bits of text characters, some of which have a special meaning for the server. Those with a special meaning are basically pre-defined terms.
When you're talking about Regex and .htaccess most of these special pre-defined characters/terms will be the same globally. However there are a few of them that can have a (often totally) different meaning depending upon how and where they're used.
Here are the ones you'll use the most.
RewriteCond - This tells the server to parse through and interpret the conditions you set forth, and to apply the RewriteRule that follows it if the test is proven true. If you use a RewriteCond there must always be a RewriteRule tied to it.
Example: RewriteCond %{HTTP_HOST} ^domain\.com [NC]
RewriteRule - A RewriteRule is simply the instruction you want to server to interpret and carry out. A RewriteRule doesn't not require a preceeding RewriteCond, but a RewriteCond does require a RewriteRule.
Example: RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]
While we're at a nice stopping place let me tell you right now that there are often many, many ways to construct rewrite rules that in many cases will do the same or similar things. Which way to choose is almost always up to the individual situation you're confronted with. As an example, let say you're trying to control the old www/non-www canonical issue so that the search engines can only find one version of each of your pages.
One way to accomplish this task is:
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^domain\.com [NC]
RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]
Another way to accomplish the task would be:
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\.domain\.com [NC]
RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]
What's the difference?
The RewriteCond in the first example says (in English) If the HTTP_HOST variable begins with "domain.com" no matter what the case, the RewriteCond tests true.
Whereas the RewriteCond in the second example says If the HTTP_HOST variable does not begin with "www.domain.com" no matter what the case the RewriteCond tests true.
So on the average site they would do the exact same thing.
But there are situations where one might be preferrable to the other.
For instance, if you had additional domains parked or aliased on top of your main domain the second instance would be a better choice. Because then even if someone arrived by going to www.someotherdomain.com it would still test true and trigger the redirect.
But by the same token if your site had subdomains (eg shop.domain.com) that were hosted in the same space as your main domain you'd want to use the first example. Because the second one would fire off when you didn't want to, sending traffic to your shop back to the www version of your domain.
Okay, enough of that. Let's cover some more common syntax.
[ ] (Square Brackets) - These are used around an expression or part of an expression. Basically it's a way to define a character or several characters that you would like to match against.
Example: RewriteRule ^store/([a-zA-z]+) /store/index.php?prodid=$1
letter-letter - This matches any single lowercase letter that matches the first or last character given, plus any letter between then.
Example 1: RewriteRule ^store/[a-z] /store/index.php?prodid=$1
The above would match any request for a url that reads like www.domain.com/store/a through www.domain.com/z Note that with this syntax it would not match www.domain.com/aa because there are two a's in the string and it is constructed to match only one a. There are ways to expand this that we'll cover in a bit.
Example 2: RewriteRule ^store/[c-g] /store/index.php?prodid=$1
The above would match any request for www.domain.com/c through www.domain.com/g however it would not match www.domain.com/b since "b" is not included in the expression.
LETTER-LETTER - This is the same as above, only it will match against capital letters instead of lowercase letters.
Example: RewriteRule ^store/[A-Z] /store/index.php?prodid=$1
number-number - This works on the same principle as the letter-letter and LETTER-LETTER do. It will match any single number in the range you specify.
Example 1: RewriteRule ^store/[0-9] /store/index.php?prodid=$1
The above will match www.domain.com/store/0 through www.domain.com/9 It will not match www.domain.com/13
Example: 2: RewriteRule ^store/[3-6] /store/index.php?prodid=$1
The above will match www.domain.com/3 through www.domain.com/6 however will not match www.domain.com/8
Characater List - This will match any single character from those you provide.
Example: RewriteRule ^store/[donkey678] /store/index.php?prodid=$1
An important note for you to wrap your head around here... The above would match if any single character that makes up the string d, o, n, k, e, y, 6, 7, 8 is in the correct place in the request. So it would match for www.domain.com/store/d and it would match for www.domain.com/k and it would match for www.domain.com/8 It would however not match if the request was for www.domain.com/store/donkey678
The important thing to remember is when your Character List Expression is enclosed in square brackets the server does not see Words in the way we mere humans do. The server simply sees a list of characters, each of which is an entity unto itself.
Okay, there's the basics on Expressions and how to include them inside square brackets. Next we'll start covering some of the most important pre-defined characters you'll be using most often.
Note: To make this easier for you, here are direct links for Part 1 and Part 3 of this brief .htaccess tutorial.
Posted by Randy at 07:37 PM | Comments (0)
.htaccess and mod_rewrite primer
Note: To make this easier for you, here are direct links for Part 2 and Part 3 of this brief .htaccess tutorial.
I've been meaning to do this forever because I often get questions about how to construct mod_rewrite statements to do redirects and such. It's such a powerful tool with so many possible permutations that it's tough to break it all down into simple language. I'm going to give it a whirl though, if for no other reason than to give folks a starting point of reference.
First things first, let's cover some basics.
When I talk about using mod_rewrite, or even mod_alias, I'm talking specifically about doing so with sites that are hosted on a Unix/Linux (often referred to as simply *nix) environment that is running Apache. I don't even dabble with Windows servers anymore, so if that's what you've got you'll need to find help elsewhere.
Let's talk just a bit about what mod_rewrite is all about. The below assumes your server has mod_rewrite installed and enabled. If it's not, you'll need to have a chat with your host.
Basically mod_rewrite is a way to tell a server how you want it to handle certain situations. It can be as simple as instructing the server to merge together the www and non-www versions of your site so that visitors and spiders alike can only reach one version or the other. Or it can be as simple as telling the server to tell all visitors to a page that has been removed that they can find it in a new location.
There are also some quite complex things you can do via mod_rewrite.
Normally when I'm discussing mod_rewrite I'm talking about using it in a .htaccess file that is placed at the root level of your site's web space. This .htaccess file (yes, it's really dot followed by htaccess) is the standard Apache location to put such instructions.
For the record, a .htaccess at the root level will have the ability to affect every page/file on a site. You may also place a .htaccess in lower level directories if you need something special done at a lower level but not at the root level. However this is a little atypical.
Also note that you may or may not be able to see the .htaccess file when you log into your site via FTP. The reason for this has to do with how your host has the FTP handler on your server configured. Normally Dot files (files that start with a period as the first character in the file name) are Hidden files. This is because normally they are sysetm files that people shouldn't be editing anyway, unless they know what they're doing.
Because I run my own servers and because I'm basically one of 3 people who have any access via even FTP I have my FTP set to show Dot files. If your server isn't configured this way you may have to use a special command to see the file. This special command is ls -al
When you're creating an .htaccess file you'll want to take care to use a plain text editor. For example, if you're on a Windows PC you'll want to use Notepad or something similar, not Word. You don't want anything to insert special characters, so use a plain text editor.
More basics...
When a server reads an .htaccess file it reads and processes it from top to bottom. Thus when you have more than one rule that might apply you need to put some thought into which you'll want to fire in which order. If you don't you could end up with conflicting rules or rules that don't perform the way you want them to.
Okay, so there are the basics. Next up we'll start to get into the different syntax you can use and what it does.
Note: To make this easier for you, here are direct links for Part 2 and Part 3 of this brief .htaccess tutorial.
Posted by Randy at 07:15 PM | Comments (0)
December 04, 2006
Installing ImageMagick with JPEG, TIFF and PNG Support
I really like ImageMagick, as I think I've mentioned before. It produces much better images than GD does and still isn't a resource hog, which puts it on my Must Have list. I use ImageMagick on several of my own sites via PHP so it's on all of my servers. This means people I host get the advantage of having it available too.
The only problem is that the default installation of ImageMagick will usually only support converting .gif images. Many times this is because of what the server itself supports natively. So every time I get a new server I have to remember what to install and how to install ImageMagick so that it'll support more image formats. I just had to do that (again) and suspect that others run into the same issue all too often, so following is a quick and dirty tutorial how to do it.
Note: This is for a *nix system (RedHat Enterprise to be more exact) but should work with almost any installation, excepting a Windows server.
First, if it's a new server that's never had ImageMagick installed before, you're likely going to need some additional files. Otherwise it simply won't work.
Second, I'm assuming you have Root access to the server via SSH.
Third, if you've previously tried to make or install ImageMagick, you're going to want to undo that. If you don't, you'll run into problems. Trust me on this one. So if you've already tried to install ImageMagick before finding these instructions navigate to the Source directory where you downloaded IM and type in: make uninstall
Okay, now we're ready to start.
The additional files you'll need are the libs for jpeg, png, tiff and lzw compression. You can check if they're already installed, or you can just install them. On a *nix system the header files should be stored in /usr/include and/or /usr/local/include. The files you'll be looking for are named:
tiff.h
png.h
jpeglib.h
If you have 'em all already you can skip some of the downloads below, though you may also choose to re-install them to make sure your libs are resonably up to date. The files you'll need are uploaded to my server here. They are:
ImageMagick-6.2.3-0.tar.gz (Though you should also be able to use the most recent version from ImageMagick's site)
jpegsrc.v6b.tar.gz
libpng-1.0.6.tar.gz
libtiff-lzw-compression-kit-1.1.tar.gz
tiff-v3.5.5.tar.gz
If you download these to your computer and then upload them to your server via FTP make sure you do so in Binary mode. ASCII transfers will break the files.
Or, if you would prefer to download them directly to your server, SSH in and go to the directory where you keep stuff you've downloaded (/usr/local/src for me) and run the fullowing:
wget http://www.randycullom.com/ImageMagick/ImageMagick-6.2.3-0.tar.gz
wget http://www.randycullom.com/ImageMagick/jpegsrc.v6b.tar.gz
wget http://www.randycullom.com/ImageMagick/libpng-1.0.6.tar.gz
wget http://www.randycullom.com/ImageMagick/libtiff-lzw-compression-kit-1.1.tar.gz
wget http://www.randycullom.com/ImageMagick/tiff-v3.5.5.tar.gz
Next we need to unzip and uncompress each of the files. So:
tar -zxvf ImageMagick-6.2.3-0.tar.gz
tar -zxvf jpegsrc.v6b.tar.gz
tar -zxvf libpng-1.0.6.tar.gz
tar -zxvf libtiff-lzw-compression-kit-1.1.tar.gz
tar -zxvf tiff-v3.5.5.tar.gz
Now let's start installing stuff.
Type:
cd libpng-1.0.6/scripts
Now do an "ls" to look for the makefile that matches your operating system. On all of my systems this is going to be one called makefile.linux, but choose the one that matches your system. If you don't see a file included for your operating system --and it's not a *nix system-- your best bet is to try to makefile.gcc file.
Let's copy our makefile to a location we can use it. So in my case I would type:
cp makefile.linux ../makefile
And install libpng by typing:
cd ..
make
make install
Now let's move on to jpeg support. Type:
cd ..
cd jpeg-6b
./configure --enable-shared
make
make install
Next up is lzw compression support. Type:
cd ..
cd libtiff-lzw-compression-kit
We need to make a small edit to the Makefile to make our lives easier. Normally you would do this either with nano, pico or vi. If you use nano or pico make sure you always use the -w option. I use nano, like:
nano -w Makefile
Change the line that reads:
TIFF_SRC_DIR = /tmp/libtiff
so that it reads:
TIFF_SRC_DIR = ../tiff-v3.5.5
Exit your editor, saving the changes. Then type:
make install
cd ..
cd tiff-v3.5.5
./configure
Answer yes to the TIFF Configuration Parameters. When it's done type:
make
make install
Finally, let's install ImageMagick. Type:
cd ..
cd ImageMagick-6.2.3
./configure --enable-lzw=yes --enable-shared=yes --disable-static --without-perl
make
make install
That's it! You should now have ImageMagick installed, with support for .gif, .jpg/jpeg, .png and .tiff file types. You can test it right from your SSH command line. ImageMagick comes with a test image that will produce an error if it experiences a problem. To test things out type the following:
/usr/local/bin/convert logo: logo.gif
/usr/local/bin/convert logo: logo.jpg
/usr/local/bin/convert logo: logo.png
/usr/local/bin/convert logo: logo.tiff
You shouldn't see any errors. And when you do an ls you should see your four new files listed.
[Added for Nick's question in the comments below.]
The currently available original source(s) of the image library files can be found at:
The Independent JPEG Group
The LibPNG Reference Library
The LibTIFF/TIFF Library
and of course...
The ImageMagick site for the IM source files
I keep them all here because it's easier than directing people to multiple places so that one ends up with a final application that works. Plus I use 'em myself when I need to install IM on a new server. But by all means feel free to grab the updated versions from the above places, as long as you don't mind the possibly of having to work through a few niggling issues to get it all working properly.
Posted by Randy at 03:58 AM | Comments (14)
September 26, 2005
Database Backups
I just uploaded a little php script that will make a backup copy of your database if anyone needs one. A friend of a friend had a little issue the other day where a database managed to get messed up a bit, and the backups being made automatically by the server were corrupted.
That's not terribly unusual, since full site backups take a lot longer than just a database backup, and normally hosts will not stop a site during the backup procedure. So if the database gets hit during the full site backup it can corrupt the backup.
Breaking it out in a little script like this brings the possibility of it happening down considerably. Even with rather large databases the entire process will typically complete in just a few seconds, instead of many minutes.
It can be downloaded (as a zip file) at: Dababase Backup
There are just a few variables you'll need to configure, such as you database name, user and password, whether you want the backups to be compressed to save disk space, etc. I've included complete instructions via comments, commented the entire file, and of course it's released as GPL licensed.
If you want to automate it, simply set up a little cron job to run it daily or whenever you need it to run. An example of this, to get you started would look something like the following if you wanted it to run at 3:15AM Server Time each night:
15 3 * * * wget -q http://user:password@www.yourdomain.com/sqldump/dbdumper.php -O /dev/null
With the "user:password" indicating whatever username and password you set up to restrict web-capable entrance to the directory where your MySQL dumps are going to be stored.
Enjoy!
Posted by Randy at 02:28 PM | Comments (0)
July 22, 2005
Server Stuff
I've been getting a number of enquiries lately about how to do certain things with servers. So I've decided to start a new series and section that will deal exclusively with these types of questions. Part of it will be in the blog, when it's just commentary You know, the general Q&A type of thing.
However some things just don't lend themselves well to blogging, or specifically the way I have my blog set up. So rather than fight with it I'm going to simply start a new directory to drop all of those "postings" into.
Mainly this will be stuff where code is required. It's simply easier for both of us is I put this code into form text area boxes. That way they can be set up to allow easy copying and pasting, and I don't have to concern myself with the blog software transforming some text into a link when I don't want it to be.
Plus by putting that type of thing into its own area I think it'll be easier for you to cross reference as new items are brought up and new answers provided.
So that's that. Expect to see a new Server Stuff entry in the navigation to the left in coming days. Any time I add something there I'll try to remember to announce it in the blog too. Even if that's the only thing I have to say that day.
Let it be known right off the bat that everything I'll be talking about will apply to *nix (eg Linux) based servers. I don't do Windoze servers. They're too susceptible to hacking IMO and simply aren't as stable as a well built and well maintained *nix machine.
Plus all of the script kiddies write virii specifically for 'doze machines. My guess is that's mainly because so many PC's out there are actually running server services, even if the users don't know that they are.
So if you're looking for information about how to do this or that with a Windows IIS Server, you're in the wrong place. I don't use 'em so have very limited experience working with them.
Posted by Randy at 03:38 PM | Comments (0)
December 28, 2004
Update Your PHP!
I meant to write about this one several days ago, but it completely slipped my mind what with the holidays and all.
There has been a serious PHP vulnerability reported earlier this month. This is a bad one in that it is serious enough that it would allow people to basically take over your web site and/or server. There are also many builds of PHP that are effected.
My understanding is that they vulnerability is there in both the Windows and *nix versions of PHP, however the can only be fully exploited on a Windows hosting environment. Play it safe though! Apply the patch that is available at PHP.net if the PHP on your server is one of those affected. Or get on your hosting company to tell them to install the patch right away. The script kiddies are already out there looking for vulnerable servers.
According to the reports, the affected versions of PHP include:
4.3.6
4.3.7
4.3.8
4.3.9
5.0 Candidate 1
5.0 Candidate 2
5.0 Candidate 3
5.0.0
5.0.1
5.0.2
5.0.3
More info on the vulnerability can be found at SecurityFocus.com.
We now return to your normal scheduled programming. ;-)
Posted by Randy at 08:28 AM | Comments (0)