Joomla! 3.2 includes an abundance of new features appealing to end users and developers alike. One of these new features is two factor authentication. In this tutorial you will learn what two factor authentication is and how you can use it in your components to enhance the security of potentially dangerous or important operations, just like most banks do.
As I’ve said many times, I am an avid user of Zend Server for local development on my Mac. It has pretty much everything you need, including a simple to use back-end for viewing issues occuring on your server which make debugging easier. Well, on the debugging front it has a major shortcoming: it comes with Zend Debugger which only works with the very expensive Zend Studio IDE. All other IDEs (Eclipse, NetBeans, phpStorm, …) only provide support for XDebug. Every time I update Zend Server I have to install and enable XDebug instead of Zend Debugger. It’s easy and will help you debugging your PHP applications easily on your local environment. This article describes how to do it.
As you all know, Joomla! 1.7 brought a major change in the direction of the project. The self-developed libraries upon which the Joomla! CMS is built on are now spun-off as a separate project, called Joomla! Platform. The goal of this split is to allow developers to built applications on the Joomla! Platform without having to install the Joomla! CMS and all the unnecessary cruft this brings with it. The vision is to have a standalone framework, much like Zend Framework, CakePHP, CodeIgniter or Symphony, with a twist. It will be equally easy to create a component for the Joomla! CMS, a standalone web application or a CLI (command-line) application without much changes in the source code or, at least, reusing big portions of it. A mighty, noble goal. Is it possible? Are we there yet? Is it worth it?
There has been a lot of controversy over a number of changes introduced in Joomla! 1.6. One of the top ones (in my humble opinion, the least significant one nonetheless) is about the changes in the language files in Joomla! 1.6. People argue that the new scheme provides less flexibility and doesn’t allow using a single extension installation package for Joomla! 1.5 and 1.6. To cut a long story short, this is utter bullocks and I’m going to tell you why. If you are a Joomla! developer, you’d better read this post. After all, I do offer unified Joomla! 1.5/1.6 packages for all of my extensions for the last nine months.
I’ve written in the past about the various tool I had been using to produce the web software I publish. I have recently converted to Mac OS X. I had promised you that I’d evaluate my web development experience on that platform and come back with a blog post about it. Here you go! This post is about all the tools I am using day after day and how they improved my productivity as a web developer.
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!