I have recently published a new repository, which can be found here. It allows you to generate a .htaccess file from a CSV table. This post will help you use the tool.
Getting started
If you don’t have Git installed, now is the perfect time to do so. Just search for “<your operating system> install git” and you’ll find plenty of instructions. If you have Git installed, simply navigate to a folder of your choice and type in
git clone https://github.com/npasson/csv_to_htaccessto download the repository. In case you really don’t want to install Git, you can download the repo as a .zip/.tar.gz file from the website linked above.
You should have make and gcc installed. If you’re on Linux, type
sudo apt install make gccand on Windows, install the MinGW tool chain. (you need mingw32-gcc-g++ and its dependencies).
I will *not* provide a binary file for any of my repositories. The fatal flaw with open source is that nobody actually compiles things themselves, so developers can put anything in a binary. Therefore, to keep the trust of my users, I require all of my repositories to be compiled on their own.
In the root directory of the repo, either enter make (on Linux) or mingw32-make (on Windows). This will build the binary into a subfolder called bin.
Usage
There are three different possibilities of usage, each with a few modifications. For sake of argument, let’s assume we own the domain example.com.
Case 1: Simple Path
Let’s say you want to redirect from example.com/foo to example.com/bar. The CSV line for this redirect couldn’t be simpler:
| foo | bar |
That’s it. Note three things:
- This will catch the following requests:
- example.com/foo
- example.com/foo/
- The slashes for the FROM column do not matter.
foo,/foo,foo/and/foo/are treated the same. - This will redirect *exactly* to
example.com/bar. There will be no slash at the end. If you need it, add it in the CSV.
The resulting redirects are 100% portable, so you can use example.test locally and example.com in production and won’t need to change or regenerate the file.
Case 2: Full Paths
There’s a different way to generate the above redirects, if you don’t care about simplicity. You can copy-paste the full URL into the CSV, like so:
| https://example.com/foo | https://www.example.com/bar |
This will generate the exact same redirect as above. And even better, it’s still portable! This means if you discover a needed redirect in testing, you can copy-paste your example.test-URLs in-between the production URLs and it won’t hurt your result.
Case 3: External redirects
Sometimes, you want to redirect to a different page. Maybe you want to redirect people to the German site when visiting /foo/. This can be accomplished:
| foo | https://beispiel.de |
The rule for this is simple: If there’s no domain on the left and there’s one on the right, the redirect will be treated as external.
Warning: External redirect targets are hardcoded. If you’re redirecting to beispiel.test in your dev environment, you will have to regenerate the file for production release.
Warning: External redirects need a protocol. Otherwise they will be treated as documents. For example:
| foo | beispiel.de |
This will redirect example.com/foo to example.com/beispiel.de.
Mixed Case 1: Full Path + External
You can easily use full paths for external redirects:
| https://example.com/foo | https://beispiel.de |
The rule for this is: If the domains (+protocol!) are different, the redirect is treated as external.
This will generate exactly the same redirect as in case 3. The FROM field will also be portable (example.com/foo works just like example.test/foo), like in case 3.
Mixed Case 2: Simple + Full Paths
Sometimes you just want to redirect many paths to the root page, but still use full paths for convenience. This works:
| https://example.com/badsite | root/ |
The target field can be a simple path, which yields the same results as in case 1 and 2.
Pre– and Suffixes
In many development environments, the actual redirects aren’t the only thing in a .htaccess file. That’s why you can import pre– and suffixes.
Note: If a prefix is given, the generator will omit RewriteEngine On from the generated file as it assumes it to be in the prefix.
Prefixes and suffixes are simply blocks of text that are inserted before/after the generated redirects, and are extracted from files. The files to extract them from are given with the optional --prefix <file> and --suffix <file> parameters. They’re enclosed by #BEGIN PREFIX and #END PREFIX (or the suffix equivalent) comments.
Support
There is no official support. If you think you found a bug, please raise an issue on GitHub.