The informal setting of the BarCamp, combined with the nice venue of Flanders DC and general awesomeness of Nooku’ers, made this jam the perfect place to discuss code, ideas, to show and tell or do networking. With a good host/crew/moderator on site, the result is an event with interesting topics being discussed at all times. Running an event in the BarCamp format is definitely something I’d recommend.

Where is Nooku headed

Nooku will in 2012 introduce 4 month release cycles. First release will be in approximately January 2012, and will be numbered 12.1 (year.release number). That’s right: No more alphas, just releases. Second release of 2012 will be 12.2, and so forth. I filmed him talking about this too:

There will be no backwards compatibility between releases, but there will be documentation on how to migrate your code from one release to another. There will also be an updating system in place that will make it easy to upgrade your Nooku powered extension. For this to work though, developers of publicly available extensions need to follow the release cycles of the framework and upgrade their extensions regularly. After all, a website can’t have for instance both Ninjaboard and Ohanah installed if they’re running different framework versions.

“If Google Chrome can do it, if Firefox can do it, if WordPress can do it, then so can we.”
- Johan Janssens

I think this is a great approach, because it forces us to stay up to date, and it removes old and outdated extensions from the mix on a regular basis. For the framework and Nooku Server, this also means that we can progress on the cutting edge parts, while not having to maintain 3-year old legacy code. Maintaining legacy code is expensive: For instance it requires resources that are better spent on moving the project forward, and it multiplies the amount of code you have to support.

“If the requirement to upgrade your extensions regularly is not to your liking, then Nooku Framework is not for you.”
- Johan Janssens

What features are on the roadmap

Under the hood of Nooku Server and Nooku Framework, there is of course also a lot happening. Nooku Server is almost completely refactored now, and almost all the old Joomla 1.5 code has been replaced with Nooku Framework code.

I already mentioned the automatic upgrades, and there are plenty of other goodies floating around too, like logging, totally reusable files management, and other stuff that was demoed during the jam. Which features that will make it into the next releases though, remains to be seen.

A good way to stay on top of things is to pay attention to what is happening in the Nooku development branches.

Collaboration and code sharing

Plenty of sessions this weekend concerned code and code collaboration. With the number of developers increasing more and more, it’s become obvious that we on some parts are duplicating our efforts. Without a central place to share code between ourselves, or at least a place to get an overview of where collaboration is happening, it’s hard for developers to join forces on mutually beneficial projects.

Since any Nooku component, or part of a Nooku component, can be reused and called from outside the component itself, it enables us to reuse code and functionality to a much larger degree than what was the case back in the Joomla days. The architecture of it just makes it desirable to write code that is DRY, general and reusable, and that makes the opportunities for code collaboration so much greater; two projects may have completely different products, but they may still share a lot of stuff like versioning, file management, image processing, and so on.

In other news: Nooku will start using Git soon, and the Google Groups mailing list will be replaced with something else. Joomlatools have been working on a forum/ticketing/ideas tool, which they are going to release into the wild in the foreseeable future. In my opinion they are really leading by example as far as code sharing goes.

David has taken it upon himself to try to create a public map of the different developers and projects out there in the coming weeks to make it easier for people to find one another and start collaborating in the short term.

Backend UI/UX

A topic of special interest to myself was the backend UX/UI talk. Leading the discussion was Tom Janssens, designer of Nooku Server backend, Nick Balestra, designer of Ohanah, and also the boss of templates and RocketTheme CEO, Andy Miller.

With Nooku constantly reducing the amount of PHP code you need to write, the amount of HTML and CSS in a project is an increasing percentage. We discussed and agreed upon that there should be guidelines for how component backends should be coded, and that ideally you should be able to use predefined classes to make your backend look sexy, without having to write CSS at all basically. A uniform backend HTML/CSS across components also allows us to easily add responsiveness if we decide to, and it ensures that the end user of components gets a consistent experience whenever using Nooku extensions.

Sexiness will not only be associated with Nooku code, but also with Nooku looks and workflow.

Expect a Git repository to appear on this topic shortly. I am guessing @janssenstom will announce it both on twitter under #Nooku, and on the Nooku mailing list.

Wiki/documentation

Another talk I participated in concerned the wiki and documentation efforts. The documentation is having a hard time keeping up with development at the moment, and the wiki is not very newbie friendly; there is no clear starting point for beginners. I have a phpDoc generator going that generates automatic documentation of the Nooku Framework trunk on a nightly basis, but that’s only useful to some, and not sufficient for all beginners.

What we want to do here is to organize and categorize the wiki content much better, and we want to cut back on wiki content to remove stuff that’s nice-to-have and place it somewhere else, so that the stuff that’s need-to-have gets a more prominent position.

Expect a mailing list call to action on this one from Fonny and/or Peter.

What I take home with me

Speaking and listening to presentations by other developers who eagerly share their code and experiences, and getting to know and being able to work together with skilled people in an informal setting like this, is highly inspirational and educational.

Nooku has a relatively small and agile group of developers, which allows for quick development iterations, faster development and early adoption of new concepts. Nooku is driven forward by Johan Janssens and the people of Timble, but it has a flat organizational structure and low barriers for contribution, making it all the more interesting for people like myself. Having learned from the history of the Joomla project is definitely not a disadvantage.

I’d like to thank all the people that helped made this event happen, and I’m looking forward to following the progress of a lot of different things in the months to come. There is so much new stuff happening, that it would be hard to list it all in one blog post, but feel free to toss in your experiences in the comments below. I only attended less than 1/3 of the talks at the event, so there’s a lot more that can be said :)

The best thing to do for now is to keep an ear to the ground and listen for #Nooku, because there’s a stampede coming.

Related links:

Flickr photo set by David (not updated with pictures from the last day at the time of this writing)

Table of contents

1. VMware Fusion: Partition table has changed
2. MAMP and OS X Lion
3. NAS (Network Attached Storage) issues with AFP/remote Time Machine
4. Lion install failed — Boot Camp issue
5. More OS X Lion tips

1. VMware Fusion: Partition table has changed

I could not start up my Windows 7 boot camp partition after the upgrade. The error message I got was something like this:

Cannot open the disk ‘/Users/torkil/Library/Application Support/VMware Fusion/Virtual Machines/Boot Camp/Boot Camp.vmwarevm/Boot Camp.vmdk’ or one of the snapshot disks it depends on.

Reason: The partition table on the physical disk has changed since the disk was created. Remove the physical disk from the virtual machine, then add it again.

I found the solution to that issue on the VMware Fusion blog comments:

“That means to go into the Virtual Machine library and delete the entry. Then, create a new Bootcamp based VM. Your VM wouldnt be damaged as it is running bootcamp and just using that info. If that still doesnt work, boot using bootcamp itself.”

2. MAMP and OS X Lion

The popular MAMP (Mac Apache MySQL PHP) software needs to be version 2.0 for Lion compatibility. An upgrade is all it takes. See the MAMP download page.

3. NAS (Network Attached Storage) issues with AFP/remote Time Machine

I am trying to connect with AFP to a fileserver on our network at work. I am getting this error message after installing Lion:

There was a problem with trying to connect to the server. The version of the server you’re trying to connect to is not supported.

This is also a problem for people using TimeMachine to do backups to Synology’s file servers. The problem is that Synology’s firmware ships with an older version of Netatalk, not compatible with Lion. Synology already has a DSM 3.2 beta which fixes the problems for many people it seems. Synology has also said that they are releasing version 3.2 at the end of July 2011, and that this version will fix the problems.

Smallnetbuilder.com has an article on the topic, with a link to a workaround that Alexander Wilde has dug up. I have tested his solution now, and I can confirm that it works.

4. Lion install failed — Boot Camp issue

Max OS X can’t be installed on the disk Macintosh HD, because a recovery system can’t be created. Visit www.apple.com/support/no-recovery to learn more.

I ran into this problem on my wife’s Macbook Pro. The help article on apple.com suggests I format the entire computer and reinstall Snow Leopard and then install Lion again. Seems like too much work, so I’m going to try another recipe:

1. Download and install Winclone
2. Make a backup of my Boot Camp partition on my OS X harddrive with Winclone
3. Backup OS X to Time Machine
4. Use Boot Camp assistant to remove the Windows partition
5. Backup to Time Machine again (paranoid!)
6. Install Lion, hopefully without problems
7. Recreate the Boot Camp partition and use Winclone to recreate it like it used to be

Thanks to Macworld tip on Backup and restore Boot Camp partitions.

I’ll report back when I’ve tried this, and hopefully succeeded.

5. More OS X Lion tips

Here is some further reading:

• Techcrunch: Nine things you should do after installing OS X Lion

Have you experienced any problems?

If you have found issues with other software after upgrading to OS X Lion, feel free to post it in the comments below.

Go to the Nooku Framework API documentation

Read more at the Nooku blog

I recently also saw a tweet concerning DeviantART’s mailing list having been compromised, and a lot of people’s e-mail addresses have probably now ended up in the hands of spammers. The person tweeting luckily had an alias set up that he could just kill off to avoid being spammed any further.

GMail has this nice little feature that allows you use your_name+whatever@gmail.com as your e-mail address. So for each new site you register on you can use a new address. For DeviantART you could use your_name+deviantart@gmail.com for instance. This makes it easier to find out who has lost or sold your e-mail address in the future, and it makes it really easy to block unwanted mail with a quick filter.

Table of contents

1. Dual purpose
2. How to add a behavior
   1. By identifier
   2. By instance
3. Where to add a behavior
   1. In the table class
   2. In the model class
4. Nooku’s built in behaviors
5. Creating your own behaviors
6. Comparing to Joomla 1.6
7. Revelation: Automated plugin events/hooks
8. Revelation 2: Row mixins
9. References and further reading

Dual purpose

The behaviors are something of a cross-breed between database triggers and database row mixins. Confused?

Database behaviors can first of all intercept table commands, meaning they can act on any select, update, delete and insert being run on your database, much like a database trigger, but with PHP-code, and thus a lot more flexible. For example: When selecting an article from a database table that has a column called “hits” and a behavior called “hittable”, the value of the hit column will increment automatically.

At the same time, the behaviors function as row and rowset mixins. Mixins are a way of doing multiple inheritance, something PHP does not support natively. So while your own table class may extend KDatabaseTable, it can also mix in KDatabaseBehaviorLockable, so you’ll get access to the public functions from the latter too.

The main idea is to make a flexible and reusable implementation based on composition, rather than one which relies on inheritance; Behaviors can be added to your code and triggered dynamically, so instead of having for example a “hit” method in a base model that all models inherit from, or worse, copying a “hit” method across your models, you can just mix in the behavior where it’s needed.

How to add a behavior

Behaviors are added to database table classes, either when initializing the database table class, or when constructing the related model class. When adding behaviors, you can either add by identifier or add by instance.

Adding by identifier

Adding by instance

// using the behavior's shortname
$sluggable = KDatabaseBehavior::factory('sluggable');
 
// using an identifier string
$notifiable = KDatabaseBehavior::factory('admin::com.shop.database.behavior.notifiable');

// use id and title for item slugs, instead of just title
$sluggable = KDatabaseBehavior::factory(
    'sluggable', array('columns' => array('id', 'title'))
);

Where to add a behavior

To use a behavior with your table class, you can either add it during database table initialization, or you can add it during model construction.

Adding during table initialization

class ComLibraryDatabaseTableBooks extends KDatabaseTableAbstract 
{
    protected function _initialize(KConfig $config)
    {
        // make the library's books lockable and hittable
        $config->behaviors = array('lockable', 'hittable');
        parent::_initialize($config);
    }
}

Adding during model construction

class ComLibraryModelBooks extends KModelDefault
{
    public function __construct(KConfig $config) 
    {
        // use id and title for item slugs
        $sluggable = KDatabaseBehavior::factory(
            'sluggable', array('columns' => array('id', 'title'))
        );
 
        $config->append(array(
            'table_behaviors' => array($sluggable)
        ));
 
        parent::__construct($config);
    }
}

$sluggable = KFactory::tmp('lib.koowa.database.behavior.sluggable');

Nooku’s built-in behaviors

Nooku’s core database table behaviors can be found in libraries/koowa/database/behavior of the Nooku Framework repository. At the time of this writing, the core behaviors are:

creatable

Use this to record who creates items and when. Triggered before an insert, and will auto-fill any created_by and created_on columns in your table. You won’t even need to have these fields in your form for this to be stored in the database.

hittable

Requires a hits column that will count the number of hits your items get. Just call the hit method whenever you want to increment the hit counter.

identifiable

Requires a column named uuid. This behavior will auto-create a Universally Unique IDentifier when a row is created.

lockable

For people who know Joomla, you will know this behavior by the name check in/check out. This behavior will make a row editable or uneditable, to prevent simultaneous editing by two people. This behavior requires two columns in your table: locked_by and locked_on.

modifiable

This behavior helps you manage the columns modified_on and modified_by, which will keep track of who edited an item last, and when they edited it.

orderable

Requires an ordering column in your table. Mixes in an order method which you can use to reorder elements. It also keeps your your items in order when updating items in, or deleting items from, your database table.

sluggable

Will automatically create a slug for a newly created item. It will create the slug from the column or columns you specify, default is the title column. It also uses the separator that you specify, and defaults to a dash. You can also configure this to be updatable or not, and set a length limit for the slugs created.

Creating your own behaviors

Behaviors should be placed in (/administrator)/components/com_yourcomponent/databases/behaviors/, for instance with the file name behaviorname.php. The class should then be named ComYourcomponentBehaviorBehaviorname and it should extend KDatabaseBehaviorAbstract.

Here is a very simple example example in the shape of a “notifiable” behavior, which sends a notification when a new row is inserted in a database table. I am writing this for an imaginary component called “com_shop”, where I need notifications when new orders come in.

< ?php
class ComShopDatabaseBehaviorNotifiable extends KDatabaseBehaviorAbstract
{
    protected function _afterTableInsert(KCommandContext $context)
    {
        $row = $context->data; // the new row object
        return mail(
            'myname@mydomain.com', 
            'New order placed by '.$row->customer_name, 
            'Here are the order details (more data here)'
        );
    }
}

I have here used _afterTableInsert, but remember that you can use any trigger after and before both insert, select, update and delete. For instance _afterTableDelete, if you need to do some cleanup after a delete for instance.

I then need to use the notifiable behavior in my orders table, where the new orders are registered:

< ?php
class ComShopDatabaseTableOrders extends KDatabaseTableAbstract
{
    protected function _initialize(KConfig $config)
    {
        $config->behaviors = array('notifiable');
        parent::_initialize($config);
    }
}

This is of course very simple and you’d of course never use the mail() function for something like this, but it’s just an example.

So why did I pick “notifiable” as an example? Well, notifications is something that could be useful in many cases. For instance: New client signups, new orders, new comment submissions, altered order statuses (use _afterTableUpdate for that) and so on. The trick is to make the code generic enough so it can be reused in multiple components.

If a behavior is deemed to be general and useful enough, it might be accepted into the core too, so perhaps you’re feeling up for the task and want to become the next Nooku Contributor rockstar?

Comparing to Joomla 1.6

Let’s look at how the Nooku core database behaviors are solved in Joomla 1.6. I am comparing this to 1.6 beta 15, as that is the most recent release at the time of this writing.

creatable

You will have to submit created and created_by variables with your form.

hittable

You’ll need to write this code yourself. For com_content there is a hardcoded function called hit in ContentModelArticle, but it will only work for com_content.

identifiable

Non-existant in Joomla 1.6 as far as I know.

lockable

A quick search in the codebase reveals at least eight different definitions of a function called “checkin”, where many seem to do the exact same thing; checkin/unlock a row item. So it appears as if there is a lot of code duplication here.

modifiable

You will have to submit modified and modified_by variables with your form.

orderable

If you extend JTableNested, you’ll have access to the functions orderUp, orderDown, move, moveByReference and saveorder, as far as I can tell.

sluggable

Slug is called alias in Joomla. The generation of an alias usually happens in a table class, but it’s all hardcoded in all core components, which means a lot of code duplication and copy pasting when writing components.

Revelation: Automated plugin events/hooks

This also reveals a small piece of another puzzle, the table command chain. We have now seen how we can perform actions on certain events like the afterTableInsert example above. In Joomla (both 1.5 and 1.6) you have to manually trigger events like “onContentBeforeSave”; in Nooku, these exist by default, in all components.

One might argue that there are more plugin triggers in Joomla, like in the example class plgContentExample you can find onContentChangeState for instance. In Nooku, all actions also translates to one of the core BREAD actions; Browse, Read, Edit, Add, Delete. The difference between Browse and Read is that Browse equals “read multiple”, while Read equals “read one”. Changing the state of an item usually means changing the state column of a database row, which equals an edit operation. So if you want to create something equivalent to onContentChangeState, you’d just use for instance afterTableUpdate and do $row->getModified() to see if “state” has changed.

You can find the same command chain design pattern in the controllers, where events both before and after the different BREAD actions are triggered, like controllerBeforeRead. Nicholas Dionysopoulos used this concept in a great tutorial where he demonstrated server side validation by command chain usage in Nooku Framework.

Revelation 2: Row mixins

Let’s not forget the mixin part of the equation here, the lockable behavior is a good example of that: It exposes the lock, unlock, locked and lockMessage functions to the row object.

These are in turn used in the core controllers, like KControllerView, to control access to the row object. Easy reuse of code in other words.

References and further reading

• Johan Janssens wrote the original introduction to database table behaviors on Dec. 27th 2009.
• On Nov. 7th 2010, Johan wrote another and more detailed explanation of how behaviors work.
• Another favorite: Herman Peeren’s design patterns illustrated presentation, which includes info on both the command chain and mixin patterns.
• The revisable behavior is a more complex behavior belonging to the revisions component. For now, this is located in the Nooku Components repository. This behavior is part of a component still in development, but it already can provide full version control for your content, and the code is totally reusable.

Joomla 1.6 caching explained

Joomla 1.6 caching for developers

Table of contents

1. Choosing a host for your Joomla site
2. Installation
3. Setting up and configuring the website
4. Running the website
5. Developer’s checklist
6. What to do if your site gets hacked
7. Further reading, other resources
8. Acknowledgements

Choosing a host for your Joomla site

First of all, you should find a proper hosting provider. You could ask others in the Joomla community for their recommendations, and you could check out the shortlist of hosting providers on the Joomla Resource Directory. These have at least gone through a manual screening process where their server setup has been checked for the most common pitfalls.

If you’re considering a host, here’s a brief list of requirements that you can run by your hosting provider to see if they fit the bill:

1. Secure communication

   Make sure your host supports secure connections. It will cost you around $30/year to get a 256-bit SSL certificate to secure your backend. If you need to transfer files, make sure that SFTP or SCP is an available option to you, instead of having to use plain FTP.

2. PHP configuration

• As with any software: Don’t use outdated versions, like PHP4
• Disable potentially harmful PHP functions
• Use open_basedir (with care, see comments after this article by Nicholas)
• Turn magic quotes off
• Don’t register globals
• Allow users to set local php.ini files

3. Apache configuration

• Enable .htaccess
• Enable mod_rewrite
• Enable mod_security
• Enable suPHP

Installation

4. Connect securely

   Use SFTP or SSH when you connect to your server, and do not store your password in for instance your FTP client. This of course also goes for any subsequent connections to the server after you have finished your install.

5. Follow your own best practices

   If you have already set up one site where you follow all the basic security measures you want to follow, and you have already implemented the security extensions of your choice, there is no need to reinvent the wheel: Use a backup tool like Akeeba Backup or something similar, take a backup of the site and use that backup as a starting point for your new site.

   Kudos to @hermanpeeren for the tip!

6. Do not use the standard DB prefix jos_.

   Many SQL injection attacks are based on the assumption that your database tables are named “jos_”. In case you did use jos_, you can still change it with a simple PHP script.

7. One database user per installation

   Do not give the same database user access to multiple installations, and do not use the server’s root user for your database connection.

8. Consider db user password quality

   Use a long and complicated password for your database, and when installation is done, for your login. It’s too easy to decrypt an MD5 or SHA1 hash these day. There are even webapps that help you do it. If someone gets hold of your database of hashed passwords, it’s only a matter of time before they are broken. There are lots of good tips for password quality in this previous article I wrote, “How to create—and remember—a different password for every single login“, and there are also a lot of good tips in the article’s comments.

   In general, when it comes to passwords: Don’t write them down anywhere, and if you have to, at least store them securely.

9. Don’t install sample content

   Sample content identifies you and your installation, and makes you easy to find and target. Don’t install sample content on what is to be a live website, because forgetting to remove absolutely all sample content is just too easy.

Setting up and configuring the website

10. Use correct file- and directory permissions

    Avoid 777 of course. It seems this can’t be repeated enough times though. Extensions like suPHP will take care of setting proper permissions, so talk to your host and make sure they support it.

    This will also make the need for the Joomla FTP-layer redundant, so you won’t neet to use your FTP username and password anywhere.

11. Uninstall stuff you don’t need

    Brian Teeman has a saying: “Nothing appears on my website that I didn’t put there“. Uninstall core components, modules, plugins, templates and other extensions that you’re not using, including templates and even images. Extensions on your website are all potential security liabilities, either because they add security holes or because they help attackers identify potential security holes.

    Observe for instance that installing the JCE WYSIWYG editor will also install TinyMCE, as it is bundled with JCE. Joomla comes with TinyMCE installed as it’s default editor, so then you’ll have two TinyMCE installations.

    Some core stuff can’t be uninstalled through the normal uninstaller. This is because they are marked as “core” elements in the database. In the components, modules and plugins database tables, there are fields called “core” which is set to 1 for these extensions. Change this value to 0 to make them possible to uninstall.

12. Global configuration setup

    1. Disable registration/login

       If you don’t want people to register and/or login on the frontend, make sure you disable the functionality.

    2. Disable XML-RPC

       Disable the XML-RPC-server if you don’t need it.

    3. Replace default Joomla meta information with your own data

       Make sure you replace, or at least replace, the default metadata. These will show up in your sourcecode and in Google.

    4. Use SEF urls

       Regular URLs gives away the fact that Joomla is running your system. But then again, so can a lot of other things. Like for instance a template graphic, a static file, a code structure. Changing from regular to SEF URLs won’t render the regular URLs useless either, so this is not a very strong security measure. Make sure you also enable the .htaccess-file, see below.

    5. Move logs and cache outside the site root

       Change the log and cache paths in the administrator to a folder outside the site root so that they can’t be accessed through a web browser, or protect the folders in some other way.

13. Remove generator information

    Remove the generator tag from the head-section of your website.

14. Delete the default user account

    The userid 62 and the username “admin” represents a weakness, but there’s no easy way to replace these during installation. In the administration, the easiest thing you can do is to add a new super administrator, log in as the new super administrator, then demote the admin user to a lower usergroup and then delete the user all together. As our greek friend @nikosdion demonstrates, you can also fix this and add users below id 62 with some easy SQL.

    Here’s some quick SQL to help you change the user id and username of the default account right after installation:

    -- Change 3 in both queries with the userid you want
    -- Change jos_ with your own db prefix
    -- Change yourusername with your new username
    UPDATE jos_users SET id=3, username='yourusername' WHERE id=62;
    UPDATE jos_core_acl_aro SET VALUE=3 WHERE VALUE=62;

15. Enable the .htaccess-file

    The default .htaccess-file has some basic security built in. In Joomla versions earlier than 1.5.15, you should also make sure it restricts access to critical files. In versions newer than 1.5.15 (1.5.20 is the latest version at the time this writing), you still have to uncomment parts of the .htaccess-file to activate this security measure. 

16. Enhance the .htaccess-file

    Nicholas K. Dionysopoulos (that’s @nikosdion in twitterish) also has a nice Master .htaccess-file with lots of other goodies included, that’s really worth a peek. For instance: Restrict directory listings, force https on certain pages, blocking of some common exploits, file injection protection, fingerprint attack blocking, and more.

17. Encrypt communication, or at least the login

    A nice article by Herman Peeren highlights the dangers of not logging in to your site with SSL, and suggests that if you can’t set up SSL you at least look into an extension called Encrypt configuration.

18. Make fingerprinting your site harder

    One of the easiest ways for an attacker to decide if your site is a potential Joomla! target is to perform a rudimentary visual fingerprinting. Both Joomla! and PHP comes with many static resources, special features and even easter eggs that can make it easy to identify what software you’re using, and what versions they are.

    There is a great post in the October 2010 Joomla Community Magazine about this: “Only a ninja can kill another ninja“, by @nikosdion.

19. Choose your extensions wisely

    1. Avoid extensions with encrypted sourcecode

       You can’t fix bugs in encrypted sourcecode yourself, and you’ll be left at the mercy of the extension producer should something bad surface. This is mostly a personal preference of mine, as I like probing around in people’s code both to learn and to get a general feeling for the actual quality of the software I’m running.

    2. Avoid dead extensions

       If a extension’s homepage is returning a 404 error, or hasn’t been updated in ages, it’s a good indicator that you should check out if this extension is still being maintained or not, before you decide to install it.

    3. Avoid legacy extensions

       Stick to extensions with fresh 1.5 compatible code. Joomla 1.0′s EOL has passed now, over a year ago, time to move on.

20. Add extra layers of security

    1. Protect /administrator with extra measures

       You could require an extra password to access /administrator, or even restrict access to certain IP addresses. Some security plugins, like jSecure can help you accomplish stuff like this too. (thanks to @nikosdion again)

    2. Consider installing security extensions

       Lots of opportunities on the JED in the categories site protection, site monitoring and login protection. Many of these will help you with the items in this list.

    3. Monitor your site for unwanted changes

       Lots of tools can be used here, for example there is a Windows tool out there called Akeeba SiteDiff, which you can use with Akeeba Backup, and which will compare the state of your site with the last known good state. Read more about Akeeba SiteDiff.

    4. Add a custom ACL solution

       Joomla 1.5′s default ACL is not very restrictive, and you may be giving out more access privileges than you’d like. Brian Teeman has a nice table showing who gets to do what exactly. Consider adding a custom ACL solution for better access control.

21. Avoid exposing information

    Disable the display of errors on live sites, so that system paths and server information is not shown. Set display_errors to 0 in a local php.ini for instance, or use php_value in a .htaccess-file.

22. Don’t send out username/password in plain text e-mails

    Sending a plain e-mail is like sending a postcard; it’s not wise to include anything sensitive in it. Joomla does this by default (!) each time you add a new user to your users list, or when a user signs up.

    One way to avoid this is to override the language files; the text that goes out in the account creating confirmation e-mails is located in the language file, so this can be tweaked to not include the password.

    In Joomla 1.6 you can also override a single language string without having to create a whole language pack, which makes this easier. There is also a plugin for 1.5 called Translation Override, which may prove to be useful for this purpose. (thanks to @jlleblanc, @nikosdion and @ot2sen for the tips)

Running the website

23. Stay updated

    There’s one newsfeed for Joomla Security News and one feed for news about vulnerable extensions.

    You should use the information to avoid insecure extension, because you can bet that those looking to hack your website are also keeping up to date with news on new vulnerabilities. – Read the result of Brian Teeman’s “Investigation of Exploits” from August 2010. – Read the vulnerable extensions list in the docs wiki, and subscribe to it’s feed.

    Note that you can also subscribe to changes on a wiki page like the one above, to be notified whenever it changes. If you go to the vulnerable extensions list and register an account and log in, you will get a button in the top menu that allows you to subscribe to changes on that page.

24. Install security patches immediately

    Pay attention to mailing lists announcing insecure extensions and updates to extensions you’re using, including Joomla itself of course.

25. Backup your site regularly

    If your server host does not do backups for you, you could backup your site to the cloud, or make good use of a backup extension.

    Make sure to test that the backup works and always store the backup off-site.

Developer’s checklist

26. Use an IDE

    IDEs can help considerably with code quality, development and testing.

27. Use a versioning system

    Stuff like SVN and Git will be a lifesaver the day something is hacked or modified without your knowledge, or goes to hell in another way. It also makes it easier to maintain and roll out different versions of your software. Use versioning even if you’re the only one doing development, it’s well worth it.

28. Test locally, deploy globally

    Run different configurations for your test sites and live sites: Stuff that gives away information should never be done where it’s visible to the public, in particular debugging. Errors should not be shown on a live site, especially not those who disclose paths or system information. As an extensions developer though, all you can do here is probably just advise your customers. This type of setting has to be done on the server.

29. Use CSRF-protection

    http://docs.joomla.org/How_to_add_CSRF_anti-spoofing_to_forms

30. Don’t chmod files or folders to 777!

    Not only is this a bad idea security wise, it also tells people reading your code that you’re lazy at best, and furthermore that you don’t know what you’re doing.

31. Filter data

    Filter data the user inputs and escape outputting of user-provided content, which is especially useful for preventing SQL injection and XSS attacks. Read more about this and see examples.

32. Keep your codebase small

    Reuse previously road-tested code where you can, and stay DRY (Don’t Repeat Yourself). Less code equals less potential security risks and less code maintenance costs for you.

33. Use Nooku Framework

    If you’re creating a Joomla extension, you should consider using Nooku Framework, which reduces your codebase with around 80% and does a lot of things automatically, where you in Joomla would have to write code manually. Directly related to security, Nooku gives you automatic CSRF protection (automatic form tokens and token control), automatic data filtering and soon also automatic output escaping by default.

34. No executable code in class files

    In your class files, stick to one class pr file and leave no executable code.

35. Use _JEXEC

    use a _JEXEC test in files, especially templates or files with executable code, to make sure the file is loaded from within the application. Files with just a PHP class in them do not need this.

36. Keep names and versions hidden

    Don’t display extension names and versions in the code or on your site. “Powered by Superapp version 1.5″ on page footers that use your application, combined with a listing of Superapp version 1.5 being vulnerable on the list of vulnerable extensions, makes your clients easy targets. At least don’t display this info until Joomla gets a better upgrading system so that people can update outdated extensions in a painless manner.

    Worth reading in this context: New Software Notifications in Google Webmaster Tools.

What to do if your site gets hacked

37. Take your site offline

    If malicious code has been injected into your site, you’d not want others to get their computers infected or compromised. For tougher cases: Add an IP filter so that only your IP-address can access your site while your fixing it.

    Remember: Offline does not mean unavailable

    Setting a website in maintenance mode is merely a visual thing that indeed will execute all plugins and component requests, but merely render the offline template. So if someone has found a loophole to get into your site, and you want to shut them out while you fix the problem, setting the site in maintenance mode will not help you.

    Nicholas Dionysopoulos published a blog post with information on this subject which is useful. He outlines one possible way around this issue, where he uses .htaccess to redirect all request to offline.html directly, bypassing Joomla completely. This means you have to have an offline-page of pure HTML to serve too of course. He also adds an exception so that you yourself can access the Joomla page from a specific IP-address.

    Read the original blog post for a more in-depth explenation and code sample.

38. Find other people with similar errors

    First thing to do would be to search the Joomla forums or search the web to try to find scenarios similar or identical to yours. This can save you a lot of time in the recovery phase, since you may benefit from other people’s findings.

39. Make sure your computers haven’t been compromised

    Malicious software on any computer with is used for accessing the site or it’s FTP accounts for instance, can be used by an intruder to gain access to your online user accounts. Use a scanner software to scan for malware, trojans, viruses, spyware, etc. A list of available software packages can be found in the Joomla documentation under “Local security”.

40. Verify that you have the latest versions

    Check that you have the latest Joomla version and the latest versions of your extensions, and that you’re not using any extension versions with known vulnerabilities. See lists of vulnerable extensions on the Joomla documentation wiki and in the Joomla security newsfeed.

41. Locate modified files

    Log in to your server and use the find command to find out which files have been changed recently.

    This command will list all files in the current folder where the file modification time (mtime) is less than three days old:

    find . -mtime -3

    This command will list all files in the current folder where the last change of file status (ctime) happened less than three days ago:

    find . -ctime -3

    This command will list all files changed at least one day ago but less than three days ago:

    find . -ctime +1 -a -ctime -3

42. Find out what’s changed on your server

    If files have been modified on your server, or files have been uploaded for instance, you can check the timestamps on those files to find out when the attacker was on your site. This is typical in the case of sites being defaced or malicious code being injected somewhere. Most of the time, the attacker will have gained access to your site shortly before modifying or uploading files to it. By checking your access logs for the period around that time, you may find some clues as to how the attacker gained access and which IP-address the attack came from, thus enabling you to track down things more easily in the logs.

    You can also try searching for suspicious POST requests made to for instance non-form addresses on your site.

    Use any information gained from this to block out further attacks and patch weak spots in your system.

43. Check your crontab/task scheduler

    Check your crontab and make sure there are no things in there that you didn’t put there yourself. If you can’t access your crontab or don’t know how to, ask your hosting provider for help.

44. Report the attack to your host

    Get your host to help you flush out the problems and make sure the attacker has not left any hidden backdoors to make it easy for him to regain access to your site.

45. Change your passwords

    Change passwords and, if you can, usernames to all access points to your site: MySQL databases, FTP users, administrators, SSH accounts, control panel logins, etc. Use strong passwords!

46. Restore a working backup, or reinstall completely

    Wipe your server clean and roll back to a known, safe backup. Make sure all security holes have been patched before you reopen the site. You should also consider deleting the entire installation and just reinstall Joomla and your extensions from scratch, so that you are certain not to include any backdoors a hacker may have left behind prior to the attack.

47. Report security issues you may find

    If you find soft spots in Joomla or any Joomla Extensions, report them on the security forum, but without outlining to the public how to hack one million Joomla sites in 10 seconds. Also contact extension developers directly to give them a chance to produce a patch for their users.

    When you report problems on the security forum, use the post assistant tool to make sure you include all the required information so that people are able to help you properly.

48. Official tips lists

    • Has your site been compromised? Read this.
    • Go through this Security Checklist
    • Read this before asking security support questions

Further reading, other resources

49. Read Nicholas’ blog

    Nicholas K. Dionysopoulos’ blog is currently, by far, the best source of new information on this subject.

50. Follow Jeff Channel (@jeffchannel)

    Jeff has found several security holes both in the Joomla core and in well-known Joomla extensions. He tweets regularly about security, and you could probably also hire him to do a security audit of your extension.

51. Joomla security forum

    Discuss at the Joomla 1.5 security forum.

52. Security checklist

    Joomla official security checklist

Acknowledgements

Thanks to Brian Teeman for valuable input and to Nicholas K. Dionysopoulos for his numerous articles on this subject!

Google says

I started with looking up Google’s Webmaster Guidelines, which was updated as late as 9/8/2010 according to the page footer, and I found the following relevant statements:

If you decide to use dynamic pages (i.e., the URL contains a “?” character), be aware that not every search engine spider crawls dynamic pages as well as static pages. It helps to keep the parameters short and the number of them few.

My conclusion: Static pages (without the ?) are more likely to be crawled by most search engine spiders. The more parameters you have in the query string, the more problems you can get. Google has not written off the value of static URLs just yet.

Allow search bots to crawl your sites without session IDs or arguments that track their path through the site. These techniques are useful for tracking individual user behavior, but the access pattern of bots is entirely different. Using these techniques may result in incomplete indexing of your site, as bots may not be able to eliminate URLs that look different but actually point to the same page.

My conclusion: Dynamic URLs, like static ones, should describe what’s on the page, nothing more. ?category=15&id=98 is perfectly fine.

Reading from the official blog post from Google with the spot-on title “Dynamic URLs vs. static URLs“, I conclude that Google’s opinion is this:

Don’t rewrite, you can do more harm than good, since rewritten URLs can be harder to maintain.

Experts say

Experts? Who are these so-called experts? Well, I googled some topics and clicked the top topics basically. I figure that those who manage to stay in the top 10 on Google for searches on SEF URLs are probably pretty good at this search engine stuff.

So here are some opinions I’ve come across (on sites that all seem to be using static URLs):

Opinions lifted from seobook.com:

1. People are more likely to click on SEF URLs. Looks like an assumption, but Google actually backs this up.
2. The URLs will provide better anchor text if people use the URLs as the link anchor text.
3. A transition to a new CMS can be easier with static URLs
4. Dynamic URLs don’t work well for offline marketing.
5. Dynamic URLs can be used for web application fingerprinting.
6. Google’s recommendation on avoiding rewriting URLs is directed mostly at less savvy webmasters, hoping that they think before they risk messing up their website at an attempt at installing and configuring a SEF URL rewriting module of some sort.

Rand Fishkin also backs up that last opinion, basically saying you must remember that Google is approaching this from a crawling standpoint, not a marketing standpoint. He also goes on to point out some pros and cons of static and dynamic URLs, and while this is written way back in 2008 he brings up some good points:

Pros of Dynamic URLs

• Umm… they’re usually longer?
• Google (1 of the 4 major search engines) says they can effectively crawl and index them

Cons of Dynamic URLs

• Lower click-through rate in the search results, in emails, and on forums/blogs where they’re cut and pasted
• A greater chance of cutting off the end of the URL, resulting in a 404 or other error when copying/pasting
• Lower keyword relevance and keyword prominence
• Nearly impossible to write down manually and share on a business card or read over the phone to a person
• Challenging (if not impossible) to manually remember
• Does not typically create an accurate expectation of what the user will see prior to reaching the page
• Not usable in branding or print campaigns
• Won’t typically carry optimized anchor text when used as the link text (which happens frequently due to copying & pasting)

Pros of Static URLs (mostly the opposites of the above)

• Higher click-through rates in the SERPs, emails, web pages, etc.
• Higher keyword prominence and relevancy
• Easier to copy, paste and share on or offline
• Easy to remember and thus, usable in branding and offline media
• Creates an accurate expectation from users of what they’re about to see on the page
• Can be made to contain good anchor text to help the page rank higher when linked-to directly in URL format
• All 4 of the major search engines (and plenty of minor engines) generally handle static URLs more easily than dynamic ones, particularly if there are multiple parameters

Cons of Statics URLs

You might mess up the rewriting process, in which case your users and search engines will struggle to find content properly on your site.

This is however a field in which things change rapidly, like in everything else web-related.

I’ll conclude for now with still thinking that SEF URLs will help SEO efforts, if you care about that. If you don’t, people will probably still find your content.

I don’t think it’s the most important part of SEO though. Everything starts at producing quality content. If you don’t have the quality content, working with SEF URLs will probably be a waste of time. If you’re using Joomla or WordPress, or basically any modern web framework or CMS, you’ll probably get SEF URLs for free, included in the package. In this context I see nothing wrong with just activating the feature, as it will give you some extra benefits.