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 have ever been a regular of the Joomla! forums you have most certainly come across some frustrated post of a paniced user whose site has been hacked. The truth is all web applications suffer from the same phenomenon, not because they are insecure by nature, but because most people don't have the slightest clue on what they are supposed to do to protect their site. Security isn't all that hard, but isn't all that straightforward, either. It's a bit like contraception. It's necessary, but no method is bulletproof. As a result, this article is not meant to be a complete guide to Joomla! security, but - very much like the Joomla! Security Checklist - it is just a set of guidelines you can easily follow, for that extra peace of mind.

This article was originally written in December with the intent of being volunteered to the Joomla Community Magazine. Three months down the road and things are still stagnating for JCM, mostly due to the unavailability of volunteers. I decided to post this article on my site for two reasons. First being, it would become irrelevant by the time JCM would finally be online. The second - and most important - being a call for volunteers. Joomla! needs you. Please, give some of your time to be part of this. Thank you!

This is an excerpt of my guest blog entry on osSupportDesk's blog. There's a link to the full article below.Web site backup comes with its own set of limitations and pitfalls. If you trust your web host for backup you might find your expectations fall short. Most hosts take daily backups – if any at all –on a secondary hard disk on the same server or, even worse, on a secondary partition of the same hard disk. If the server goes down due to a hardware fault, so does your backup. A few enlightened hosts also take backups on remote storage, for example NAS arrays. Even they do so on rather sparse intervals, for example twice per week. This means that on a complete catastrophe you will most assuredly lose a fair amount of data.

The solution is simple in concept. Take your own backups and store them on a cloud storage service, like Amazon S3. Taking your own backups means that you get to decide which data and how often has to be backed up, making sure that the crucial, regularly updated information routinely ends up in a backup archive. Using a cloud storage device adds a strong data safety clause to your procedure, while keeping costs low. Cloud storage is designed to be redundant and reliable, boasting a negligible risk of data corruption or data loss. Combined with its incredibly low cost, it is reasonably attractive to businesses of all sizes: from hobbyists and sole proprietorships up to large corporations and government agencies.

Read the full article on osSupportDesk