Joomla!’s temporary off-line mode is a very handy option to temporarily take your site down while performing maintenance —e.g. updating the Joomla! core or an extension— and is even suggested by the official documentation for the unfortunate time that your site has been compromised. However, is this really off-line, or are there any pitfalls you should be aware of?

One of the most useful  extensions to PHP is suPHP which allows any PHP script to be executed under its owning user privileges. This helps in administering sites which need write access to their files (like, for example, Joomla! does for its tmp and log directories) without the need for an FTP layer or potentially dangerous permissions tweaking. Let's see how you can implement this functionality on a home brew server based on Mandriva Linux 2008.1

A few months ago I had presented one way of automatically assigning subdomains on a local testing web server, without having to edit your httpf.conf file all the time. For those who hadn't been following this blog, I'm talking about my “Holy Grail of local web development servers” article, achieving subdomain names in the format myapp.local.web by simply creating the folder myapp on your local web server's root. Even though the solution presented last time was elegant, it lacked that supernatural touch of a really great solution. I could never quite stomach those ugly URL rewriting rules. So, here it is: we revisit this issue and improve the solution!

If you are a serious web developer, you might have already figured out that performing experiments and untested upgrades on production servers is a disaster waiting to happen, bringing down the live site with them. Staging live servers (in the form of dev.example.com) usually don't cut it either, especially if you have a lot of file transferring or editing to do. However, local development is still a kludge, as you have to develop in a sub-directory, something like http://localhost/mysite. This has all sorts of implications, the most evident of which being that it breaks cross-content links if you try to pack it and deploy it back to the live site.

Ideally, you would need to develop in subdomains, something like http://mysite.localhost, which would mean that you have the flexibility of local development with the peace of mind of not having to develop in a sub-directory. But, face it. Setting up subdomains is an involving process, requiring hacking around your Apache configuration files. This is suboptimal if you want to do it regularly. Unless you come up with a way to turn http://mysite.localhost to automatically understand where it should find its files.

This article will explain you how to combine WampServer and BIND to create this kind of Holy Grail local web development server on Windows. You will configure a single DNS entry and a single virtual host in order to create a server which can handle infinite subdomains! The only pre-requisite is having a fixed IP address for your server. Well, even 127.0.0.1 will do if you can't do anything better than that!

Today I was reading Brian Teeman's blog post "Help my Joomla web site has been hacked!!". It outlines a pretty much scary story of site hacking. As we all know, security is a speed race. We have to upgrade our site software before a potential hacker gets wind of our outdated scripts, otherwise we run the risk of having our site compromised before we can react. What's more, the compromise might be exploited to the attacker's benefit long after we have upgraded the vulnerable site software, adding to our confusion. Quite a nightmare. But the hidden gem of this story, is a link back to Brian's "Are you a Dork?" post. He implies that attackers can easily guess the version of our site's extension, before breaking in our site. How can they? And what can we do to stop them? Read on for the full disclosure.

As a webmaster of several sites running on complex Content Management System solutions, I have regularly came accross the same issue: most CMS systems have some library directories which should be out of the reach of the random web visitor, yet they have to be on the same web-accessible location as the rest of the CMS. To top that, I also have the need to include some other private directories under the web server root, for example a downloads repository, just because PHP open_basedir restrictions won't let me do othewise. Is all lost, then? Is there no way to keep private directories really private?