In the previous two installments of this series we discussed the target audience for Joomla! 4 and beyond and the vision for the end user. In this third installment we’ll see things from the developers’ perspective, defining a vision for the PHP code’s architecture and design goals.
In the first post of this series we explored the unified marketing message for Joomla! 4 and beyond. Armed with this result let’s see how we can turn this into an actionable vision, starting with the improvements that affect our end users. The common theme behind all the improvements in this vision can be summed up as “Don’t make them think”.
Over the last year I’ve collected my thoughts on Joomla! the CMS, the project and the community. We’ve finally all come to the conclusion that Joomla! needs a revamp. The time is ripe to discuss the future. This is a very big subject so I’m going to present this as a series of blog posts. In this first installment we’ll talk about Joomla!’s target audience and a unified marketing message to frame our vision.
With the vote on the Joomla! restructuring coming to a conclusion pretty soon I would like to take a moment to reflect on what is the problem and how (or if) it’s being fixed.
A few months ago Jisse Reitsma of Yireo told me about a book he had just written, called Programming Joomla! plugins. He asked me if I was interested in reviewing it. I did, mostly because I was curious what a book on plugins would look like. Once I started reading it I couldn’t put it down. By all accounts, it’s one of the best Joomla! development books I’ve read and one I highly recommend to anyone who’s serious about doing heavy customizations in Joomla! or writing extensions for it.
Debugging email sending can be notoriously difficult. There are too many moving parts: the extension you are using, Joomla!’s mail setup in Global Configuration, your web server, your mail server, the other party’s mail server and their mail client. Between them it’s nigh impossible to know where a problem occurs. It would be of immense help being able to isolate just the code running on your web server when debugging email. This is done with MailCatcher.
I am the happy owner of an Intel NUC dual booting Windows 8.1 and Ubuntu, hooked up to a great-looking Apple LED Cinema Display. The only problem is that the Apple display comes with no physical controls for brightness and Ubuntu doesn’t seem to be able to adjust it either. Being a geek I was anything but content with this situation. I finally found a solution to control the brightness using keyboard shortcuts.
As much as I love Joomla!, there is a shortcoming compared to the other two major Open Source PHP CMS, WordPress and Drupal: it doesn’t come with a command-line interface like wp-cli or drush. This is a bit of a problem when you’re in need of mass-provisioning sites with extensions or updates in an unattended manner. Using a CLI tool is the only way to provide a scriptable, efficient and unattended method of doing so. In this post we’ll see a practical way to overcome this limitation.
Hello, I’m Nicholas. Most of you know me as the author of popular components like Akeeba Backup and Admin Tools. Some of you know me as a frequent code contributor to Joomla!. I’m very outspoken to the point that people think I’m an asshole. Most likely I am. I was working as a business consultant long before I turned to full time software development and, as you know, business consultants are always seen as assholes, usually ranking lower in being well-liked than accounting and legal departments. But you know what else business consultants do besides being assholes? They know how to make an organisation do more with the same people (or even less, which is why people think we are assholes). So there you have it, I was refactoring businesses before I got to refactoring code. This is my take on refactoring Joomla!’s organisation structure. It’s a long read, ideal for a Sunday morning.
You’re wrong. Some rudimentary A/B testing led me to a counter-intuitive result about e-commerce.