Question

I’m building a custom mini-cms using PHP. I’m currently using the common technique of redirecting all requests of non-existent files to a single PHP index and outputting content based on the path. This works fine for ‘pages’.

Apache mod_rewrite rules;

   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

Resource files (images, css, javascript etc) that actually exist as physical files are served directly. My problem here is that this exposes the true server path to these files e.g.

“/mycms/websites/google/themes/blue/css/styles.css”

I would prefer this example to be masked as;

“/themes/blue/css/styles.css”

Since this request wouldn’t exist, using my current architecture it would be redirected to my PHP index handler. I can’t realistically start adding Apache mod_rewrite rules for each website and each theme. So I’m currently assuming the only way to solve this is to handle all resource files through my PHP handler, using it to read the files on the server and spit out the correct content type.

Firstly, if this is the only solution do I need to be careful I’m not destroying any performance enhancements apache provides such as request caching?

Secondly, in the words of Status Quo, is there a better way?

Answer 1

If you are building a new CMS try to add right now, at the start, the ability to store static assets in the web root, and your php libraries outside of that web root. Keep only the index.php in the web root.

So that gives at first this tree:

path/
  \-to/
      \-cms/
         \-www/
             \-index.php
              -static\
                  \-js/ /* cms shared js */
                   -css/ /* cms shared css */
                   -images/ /* cms shared images */
          \-lib/
              \-cms.php /*lots of php files related to the cms*/

Now you want to handle several websites inside of the same cms, and hide the website name of the static resource… That lead 2 questions:

• why handling several websites with the same cms installation, deploying the cms several time, one for each website is usually better, IMHO. But anyway, why not.
• why hiding the site name on the static resource url?

To the second question I can see only one reason to do that, it’s to optimized cache policy of theses assets. You want to say that www.example1.com/static/images/foo.png is the same image as www.example2.com/static/images/foo.png. Something a well configured reverse proxy can do. But a good cms could also handle s shared domain for shared static resources, something like: cdn.example.com/static/shared/images/foo.png.

Now you are maybe actually having ugly url like: http://www.example2.com/cms/www.examples2.com/static/images/foo.png. And yes this is quite ugly, simply because you could try to check some static assets from example1.com while browsing example2.com, by altering the link manually. So someone could send an url http://www.seriouswebsite.com/static/images/adultcontent.com/foo.png claiming that seriouswebsite.com is storing some ugly picture, simply because adultcontent.com is handled in the same server with the same cms. Now that’s something not very important, done in other cms, like in Drupal multidomain default managment for example. I assume you have this situation, that you do not want, and you would like it to be handled by an url in this form : http://www.example2.com/images/foo.png.

Forget about handling static files management with PHP. Static files are really fast to be handled by webserver, and even more by reverse proxy cache. PHP will kill your performances.

So you multi domain cms tree is now:

path/
  \-to/
      \-cms/
         \-www/
             \-index.php
              -static\
                  \-js/ /* cms shared js */
                   -css/ /* cms shared css */
                   -images/ /* cms shared images */
              -domain1.com/
                  \-static\
                        \-js/
                         -css/
                         -images/
              -domain2.net/
                  \-static\
                        \-js/
                         -css/
                         -images/
          \-lib/
              \-cms.php /*lots of php files related to the cms*/

One of solutions is a rewriteRule for static content, prefixing static url with the domain name, but you will loose the possibility to load the cms shared assets. You could still do that if domain specific resources are prefixed with a keyword, like ‘local’.

So to get :

# private image
/path/to/cms/www/domain1.com/static/images/foo.png => http://domain1.com/static/local/images/foo.png
# shared by the cms
/path/to/cms/www/static/images/foo.png => http://domain1.com/static/images/foo.png

The rewriteRule must now detect the ‘static/local‘ part and rewrite it to ‘static/domain1.com‘ when the current domain is domain1.com.Something like that (untested):

RewriteRule ^static/local/(.*)$ %{HTTP_HOST}/static/$1 [QSA,L]

This solution add several limits:

• You should have a dedicated virtualHost (better) or rewriteRule (for .htaccess fallbacks) rewritting all alternate domain name access to a canonical domain name for handled domains. It’s also better for SEO. as http://domain1.com/static/images/foo.png will be ok but not http://www.domain1.com/static/images/foo.png or http://foo.domain1.com/static/images/foo.png, and http://DOmaiN1.com/static/images/foo.png should be checked.
• The subdirectory storing assets must be named exactly like the HHTP_HOST, no liberty on that.
• this rule does not prevent usage of domain1.com/static/images/foo.png direclty, so users could still build bad links, some other rewriteRule with 301 redirects could be added.