Take a look at the two friendly URLs below:

www.example.com/controller/action
www.example.com/controller/action/

For Google’s crawler, these are two different URLs. Links to one of them don’t improve the link popularity of the other. And you’ll also get a lot of “duplicate title tags” in Google’s webmaster tools. Which is not good for business. Literally!!!

The obvious solution is to just redirect all URLs that don’t end with a / caracter with a HTTP 301 Permanent Redirect. Easily done via .htaccess:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1/ [L,R=301]

But as soon as I did it, an old nemesis of mine came back to haunt me. The server discards the POST data when redirecting and half the site stopped working. #FAIL

After thinking on a suitable solution to redirect all the POST data without bothering the user with security alerts and against all specifications, it hit me: I don’t have to. Web crawlers don’t post data so I just need to redirect the GET requests. Easily done by adding just one more line to the .htaccess file:

RewriteCond %{REQUEST_METHOD} ^(GET)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1/ [L,R=301]

Voila! The solution is up and running on StoreBeez.

/home/{your-username}/public_html/

…and a Cpanel account to manage your share of the server, emails, databases and so on. And…that’s about it. You can’t point your webroot to the public directory as taught in Zend Framework’s manual, all your library files will be exposed to the public and so on. What to do then? The answer is simple: .htaccess and mod_rewrite. Usually, hosting companies install mod_rewrite and set AllowOverride to true, so this solution will work in the vast majority of cases.

Upload via FTP or SSH your content into your public_html, wwwroot or www directory (the webroot directory, whatever its name may be). Then add 4 htaccess files, one directly in the web root, one in the public directory and one in all other folders. It should look something like this (without the numbers, of course).

public_html/
     /public
       .htaccess (2)
     /application
        .htaccess (3)
     /library
        .htaccess (3)
    .htaccess (1)

Now, the first htaccess file – #1 – should contain the following:

RewriteEngine On
RewriteRule ^(.*)$ public/$1 [L]

…this will redirect the traffic from this folder to the public/ sub-folder. The second .htaccess – the one in the public folder – should be the .htaccess file shipped with Zend Framework. It usually looks like this:

SetEnv APPLICATION_ENV production 

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

And the .htaccess files located in all other directories – #3 – should simply forbid access to their respective folders, like such:

deny from all

Worked for me

But at work I’ve always used SVN and I also wanted to use it at my current workplace. So I had to install it. Since we’re using Debian and all the components are in the repositories, things went pretty smooth:

sudo apt-get install subversion libapache2-svn
sudo a2enmod dav
sudo a2enmod dav-svn

And basically that’s it. It works. But since I’m lazy, I wanted a simple way to create repositories, manage the users’ rights and so on. That “svn admin create” stuff just doesn’t cut it for me. Thus I looked over the web in search of a suitable web interface for SVN. And I’ve found one developed by some French guys, called User Friendly SVN. It’s built on Zend Framework, it’s simple, very simple for that matter – just the essentials – but it gets the job done. It really easy to use and easy to install. If you want a SVN management tool, give it a try.

Now I’m looking for a way to tie – as simple as possible – the system user accounts with SVN’s user account. Use password to rule them all

A very simple way to achieve this is by using Apache’s mod_expires. For instance, if you add the following example, taken from the manual, to your .htaccess file – assuming of course that mod_expires is properly installed and configured – it will tell the browser to cache all the files for a month.

ExpiresDefault "access plus 4 weeks"

So, every time the client returns in the following month to the site, the browser won’t download all the static content again, but load it locally from the cache, thus minimising the loading time. Of course, there are some issues that usually appear after updates. Particularly after updates of the cached files

For instance, you add a new Javascript functionality to the site or make some changes in the css or swf files and the user doesn’t hit at CTRL+F5 to fully refresh the page and clear its cache, then he will see the old version of the site. Of course, one can take the short road to LamerVille and post a message on the site, asking the user to refresh the page. But that’s a little too lame to be taken into consideration, especially when dealing with respectable sites.

But there’s another way, much more elegant. First of all, place all the static, cache-able files in a separate folder. The browser will cache all the files based on their URL. If you want the browser to reload all the static data on every new request, you need to change the URLs on every new request.

Let’s say, the site resides at www.example.com and that all the static information will be served from www.example.com/static/. Now, a good idea is to make the links look like this:

http://www.example.com/static/(release-number)/css/style.css

http://www.example.com/static/(release-number)/js/cool-ajax-app.js

Where release-number is a number that increments with every new release. This way, the URLs will be different after each release thus forcing the browsers to fetch the new files. You don’t need to go through lots of files and increment the release number by hand, you can just use the following python script:

#!/usr/bin/python
"""
Read more about what this script actually does on 

http://blog.motane.lu/2009/09/21/caching-problems-with-mod_expires/

Usage:
	python increment_release.py start_directory static_prefix

Author:
	Tudor Barbu http://blog.motane.lu
"""
import sys, os, re

REGEX = ''
CACHED_DIR = ''

def main():
    global REGEX, CACHED_DIR 

    if sys.argv is not None:
        length = len( sys.argv )
        if length < 3:
            print 'Read the comments in the source code'
            exit()
    start_folder = sys.argv[1]
    CACHED_DIR = sys.argv[2]

    REGEX = re.compile( '=(\'|")' + re.escape( CACHED_DIR ) + '\/((\d+)\/|)([^\'|"]+)(\'|")' )

    parse_files( start_folder )

def parse_files( dir ):
    basedir = dir
    subdirectories = []
    for item in os.listdir( dir ):
        if os.path.isfile( os.path.join( basedir, item ) ):
            perform_replace( os.path.join( basedir, item ) )
        else:
            subdirectories.append( os.path.join( basedir, item ) )
    for subdir in subdirectories:
        parse_files( subdir )

def perform_replace( file ):
    global REGEX
    f = open( file, 'r' )
    contents = f.read()
    f.close()
    if REGEX.search( contents ):
        f = open( file, 'w' )
        f.write( REGEX.sub( handle_match, contents ) )
        f.close()

def handle_match( matches ):
    global CACHED_DIR
    if matches.group(3) is not None:
        revision_number = int( matches.group(3) ) + 1
    else:
        revision_number = 1
    return '=%s%s/%s/%s%s' % ( matches.group(1), CACHED_DIR, revision_number, matches.group(4), matches.group(5) )

if __name__ == '__main__':
    main()

…and, of course, there’s no need to create lots of directories either. A simple .htaccess rewrite rule will do. Just redirect all the URLs like /static/(number)/css/style.css to point to /static/css/style.css, by adding these 2 lines in the /static/.htaccess file:

RewriteEngine On
RewriteRule ^\/static\/(\d+)\/(.*)$ $2 [NC,L]

This should solve all your caching related problems. If you want to look savvy, you can use the version number of the head revision from subversion of whatever versioning system you might be using instead of a simple incremental number.

Yes, I know that the script is a little bit buggy but it works for me. If you have an improved version, post a comment below. Credits will be given.

Well, upon investigation, this exception is thrown by suhosin when a client application sends too many variables to the server. In my case, via HTTP POST.

The solution is simple, just increase the maximum number of allowed variables in php.ini. If you don’t have a suhosin section, just create one. Like such:

[suhosin]
suhosin.request.max_vars = 1000
suhosin.post.max_vars = 1000

I’m not a particularly good system administrator and I don’t want to become one. Programming is my thing. But, in order to put bread on the table, we sometimes have to do things we don’t like that much. For me, today was one of those days. And, after spending about two hours browsing Apache’s gargantuan documentation, I’ve finally figure it out and decided to share it with the world, in hope that will save somebody else’s time.

With a disclaimer that this might not be the best solution out there and I’m sure that are better, more elegant way to achieve this. But it works!

First of all, the main vhost looks something like this:

<VirtualHost *>
    ServerName www.my-site.com
    ServerAdmin webmaster@my-site.com

    DocumentRoot /var/www/my-site
    <Directory /var/www/hosted/my-site>
         Options FollowSymLinks
         AllowOverride All
         Order allow,deny
         Allow from all
    </Directory>
   #bla bla bla
</VirtualHost>

Apache queues all the virtual hosts and on each request it iterates through this queue in searching for a suitable virtual host definition. The first one that matches the request’s parameters is used, so the above definition must be first in the /etc/apache2/sites-available/my-site.com. This definition will serve the “www” sub-domain and all other sub-domains will be redirected here.

After the “main” virtual host, just add a definition for another virtual host, like such:

<VirtualHost *>
    ServerName my-site.com
    ServerAlias *.my-site.com
    RedirectMatch permanent (.+)$ http://www.my-site.ro$1
</VirtualHost>

This way, all URLs that look like

http://any-subdomain.my-site.com/whatever-file.php

or

http://my-site.com/whatever-file.php

will be redirected to

http://www.my-site.com/whatever-file.php

Aside from correcting some spelling mistakes, like ww.my-site.com this will boost link popularity, because the crawlers usually consider www.my-site.com and my-site.com as two different sites (and, in fact, they are, but anyway), so incoming links to one will not be taken into consideration when computing the link popularity index of the other one. But, with a 301 permanent redirection, the crawler will consider both URLs to be the same site.

Another good idea is to also buy the “non-dash” spelling form of the domain – aka mysite.com – and redirect it to the original address. Like such:

<VirtualHost *>
    ServerName mysite.com
    ServerAlias *.mysite.com
    RedirectMatch permanent (.+)$ http://www.my-site.ro$1
</VirtualHost>

Got the job done for me. And remember: Linux is like a wigwam: no windows, no doors, Apache inside