With the holidays approaching, we have some busy elves working overtime in Joomla! land! If you haven't noticed, Joomla! 3.2 is packed with new features. Unfortunately, one of the features has a problem that was not discovered during pre-release testing. During late-stage development in September and October, there were alpha, beta and release candidate testing cycles where many community members kicked the tires to uncover as many possible issues. But one was missed, and unfortunately it was a big one causing some users deploying new sites to get locked out of their site with no easy solutions to restore access.

What has had contributors stymied is choosing what direction to take to solve it. This issue isn’t just a bug that can be patched. There are no perfectly "right answers". The solutions involve either:

  1. breaking backwards compatibility, which means jumping to Joomla! version 4.0, when there are other new features that would also break backwards compatibility that developers would prefer to be included if we are making the effort of going to a new major version (plus dealing with user confusion about the LTS version expected to be numbered J!3.5 or J!4.5);
  2. imposing an increase in the version of PHP your server must be running, which makes one-click upgrades not work anymore for some sites, and inhibits the ability to put out future unrelated security patches, or
  3. reinstating a lesser level of security for password encryption which leaves us with the same or slightly better security than we have in J!1.5 and J!2.5 and we really should be doing better than that.

None of these options are ideal, and the Production Leadership Team (PLT) have been wrestling with which direction to go. What was initially thought to need a set of patches has turned into a far bigger issue, set of decisions, and community education than anyone expected.

The good news is that a plan has been formed and is diligently being tested now. The 3.2.1 upgrade will partially roll back the related changes in 3.2 and intelligently test and adjust the password encryption being used. This release will solve most of the access issues; however, we can't automatically restore access to your site if you have already been locked out due to changing PHP versions.

Following is some interim advice on how to avoid these issues until the release of 3.2.1.

I'm currently running a production site on Joomla! 3.2

If you have already installed or one-clicked your way to being on Joomla! 3.2 and everything is working, then no worries. You do not have any new vulnerability because of 3.2. But, do not turn on the Strong Password option if you have not already done so without being in a test environment and without checking the version of PHP you are running on your production server. Sites running on PHP 5.3.7 or higher in both their design/test/staging environment and their production environment will be enjoying enhanced security that will only improve with the 3.2.1 release.

I'm currently designing a site with Joomla! 3.2

And you are getting ready to deploy to production. This is where people have experienced issues with getting locked out of their accounts when pushing the site to a server running four year old software. They have turned on the Strong Password option in their development environment so their admin password and other user passwords are highly encrypted, but when they migrate the site to a hosting environment with a very old version of PHP (5.3.6 and older) the higher password encryption software is not available to grant them access. (A password reset does not work to solve the situation because of a bug, now patched in 3.2.1, which also did not properly access the password encryption scheme.)

If this is you, and you can wait for 3.2.1 before you deploy, great, problem solved. As an alternative, you can ask your hosting company to upgrade your server to PHP 5.3.7 or later, and if they do, no worries. Otherwise, turn off the Strong Passwords option while still on your development server and create a new superuser admin account using the previous level of password encryption. You can then migrate to a lower-level hosting server. User passwords created or updated while the Strong Password option is enabled will not work after the deployment to the lower-level server. They need to be reset before making the move or re-entered using the Administrator’s User Manager panel.

For sites which have the Strong Password option enabled, instructions on disabling it are available at https://docs.joomla.org/How_to_disable_the_Strong_Passwords_feature.

I am currently running a Joomla! 3.0/3.1 site

You can one-click to Joomla! 3.2 and have a play with all the great new features, just don’t turn on the Strong Password option until 3.2.1 is out or check your server PHP versions and follow the guidelines above.

I am currently running a Joomla! 2.5 site

Great - You are not affected. As 2.5 is under long term support, new features, such as this code, have not been added to it since the release of Joomla! 3.0.

I am currently running a Joomla! 1.5 site

Make sure all your users are also using Internet Explorer 6! (kidding) Get with the program! Joomla! 1.5 support ended in December 2012 and as such we encourage users to update their sites to 2.5 or 3.2. Although the software is no longer supported, this does not mean your sites will stop working.

When will Joomla! 3.2.1 be released?

Your crystal ball is as good as mine. Because the path is unclear, this isn't a matter of forecasting the volunteer man hours needed for implementation. But it isn't as bad as needing the U.S. congress to agree on any topic. We have a wonderful group of volunteers that are working diligently to consider all ramifications of these decisions, and are coming up with excellent solutions that fit all user scenarios. It should be "soon", which could be next week or just after the first of the year.

How can we avoid this happening again?

We simply need more people helping out with testing and reporting bugs. When the call goes out for Beta and Release Candidate testing, we really need new people to jump in and kick the tires in many different hosting environments. Those that have been developing these features have already tested and debugged the software in the environments they use every day, so we need fresh eyes and servers included in the process.

Volunteer to test! If you are able to help, please join the Google Group mailing list which we use to announce pre-release testing. (This is a low-traffic group, so your inbox will not be inundated.) https://groups.google.com/group/jtesters