J! 3.8.0 was released about a week ago and, as with any dot-zero release, the com­mu­nity’s initial reaction seemed to con­demn it rather than embrace or applaud it.  This article will look be­hind the storm of protest to examine the reasons why people have ex­perienced problems that, for the most part, were not caused by the release but were mainly the result of their ignorance about the update and why it is required.

The issues that people have complained about fall into two distinct groups:

1. There are legitimate issues relating to the J! 3.8.0 release:  the Joomla developers have responded to them and the fixes for those problems will be included in J! 3.8.1.
2. There are problems caused by the failure of a few third-party extension developers and, from what I’ve seen, those developers have already released fixes for their products.  Some extensions, however, may be incompatible with J! 3.8.0.  I don’t think it’s fair to lay the blame on anyone but I think that, in the first instance, we shouldn’t be too quick to accuse someone else for taking a wrecking ball to our websites.  We choose to use the software that we use and we’re ultimately responsible for taking appropriate steps to insure our sites against the possibility that one day they’ll go pear-shaped.

Despite these issues, J! 3.8.0 has been well received with nearly 6%[1] of [post J! 3.5.0] sites using this new release.  Installation, integration and implementation problems inevitably occur with new dot-zero releases.  We will examine a few of them in this article.

The facts

The reasons for releasing J! 3.8.0

J! 3.8 is part of the pathway to transition from J! 3 to J! 4.  In addition to a few minor bugfixes for problems with earlier releases in the J! 3.x series, J! 3.8 provides additional functionality, modifications to the codebase and database schema in order to ease into J! 4.x (some time in the first half of 2018).

Perhaps the most significant of these changes is the implementation of a new Joomla routing system (albeit in an “experimental” phase of development).  Without a doubt, this is a feature that has been a long time in coming (going all the way back to J! 3.0.0) and, equally, many people will want to jump on the bandwagon and immediately start to use it.   Before people get too carried away with the idea, a few words of warning about the feature[2].  If you choose to implement this feature then you will probably find some/all existing links to content that relied upon the previous “ID-based” URLs will result in 404 issues to contend with.  This will be even more apparent if you have existing references within your current content that explicitly refer to “ID-based” URLs as well for those external references that may exist “out there” in the wild (e.g. pages already indexed by the search engines or links to your site that you’ve used on other sites).  I guess we'll probably be hearing a few complaints from long-time members of the community who’ll write that they “can’t use the new routing system” because it ruins their SERPs or that they’ll need to doctor their existing content to remove hard-coded URLs in their websites.

With regards to matter of what to do with the SERPs, that's out of our control; one will just have to be patient and wait for the search engines to re-crawl the websites to detect and replace the indexing information.  In respect of using hard-coded “ID-based” SEF URL references within your site’s content, that’s something that people will have to remedy themselves.  Strategically-speaking, if you’re writing an article and you want to insert links to other articles on your site, you shouldn’t be hard-coding those links with SEF URLs.  We’ve all done it—we’re all guilty of it—and these are old habits that are difficult to break.  I guess we’ll have to wait and see how the community reacts to the new approach.

For new websites, however, the new SEF URL routing mechanism will probably be a welcome improvement.  For those of us who’ve had our sites running for years using the older "ID-based" SEF URLs, well … we may have a bit of “maintenance” work to do.

The problems

Yes, there are quite a few discussions where people have complained that the recent update caused white screens.  Yes, that’s a fact.  It’s a fact that people generally don’t say good things about new updates and we usually get one side of the story:  “the squeaky wheel” syndrome.  It’s also a fact that many of these people who are complaining today have suddenly come out of the woodwork; people who have never felt the need to become part of the Joomla community, to go on the forum to say “Hi, wonderful product this Joomla thing” and, instead, they’re gate-crashing the party with “I’ve been using Joomla for years and this new J! 3.8.0 is insufferably bad!”.

So, yes, there are many undisputed facts.  It’s an undisputed fact that J! 3.8 was in the pipeline for the past twelve months.  It’s an undisputed fact that some of the changes were intended to have been included with J! 3.7 but they were deemed too risky to implement when J! 3.7.0 was released five months ago.  It’s also true that plans for Joomla 3.x suggested end of development would cease in October 2015!  And look where we are today?

All of these changes are intended to pave the way for a leaner, faster, more durable and more easily maintainable CMS platform to begin with J! 4.0 (some time next year).  None of these changes will be easy to manage but they need to be progressed nonetheless.  J! 3.x has a limited lifespan.  Even so, people still cling to J! 1.0, J! 1.5 and J! 2.5 like ship­wrecked survivors adrift upon roiling waters in leaky life-boats.

The Joomla project is operated by volunteers and they’re not paid for their efforts; third-party extension developers, on the other hand, are making money.  As someone who’s been in this game for decades, when a major software developer signals that they’re building a new platform, they release beta versions for other software developers to trial and prove their own “extensions"; it was no different as far as Joomla is concerned.  Joomla 3.8.0 was not rushed into production as some people might have you believe:  four beta releases and one release candidate were made available for developers to use to provide feedback to the Joomla team.  If third-party developers didn’t use that opportunity, if they were “caught out” and if their customers were penalised because of it, then that’s sad.

J! 4.0 will be a monster but, with careful planning, the pain in traversing from the final J! 3.x release should be bearable.  This is why I believe it’s important to take a little pain along the way now.  How much further do we want to defer J! 4.0 because of [the inevitable] teething problems we’re having with incremental changes within J! 3.x?

Can we take parts of J! 3.7.5 and transplant them into J! 3.8.0?

Some people have questioned—argued, is a better description—that it might be better to merely transplant parts of J! 3.8.0 into J! 3.7.5 (especially those parts that may quell security fears that people may have[3]).  It’s a reasonable question seeking information about continuing to use J! 3.7.5 but wanting to take a piecemeal approach and add just the security bits implemented with J! 3.8.0.  There’s no harm in asking the question but it is also impossible to provide a comprehensive response within a forum context.  Unless someone was actively involved in the making of J! 3.8.0 (and knowing how the parts are assembled), it’s like asking whether one could take the pieces from one jigsaw puzzle, somehow put them into another jigsaw puzzle and finish up with a finished “picture” that looks basically the same.

The response to this question in an internet discussion forum is fairly predictable.  The advice that usually follows questions like these is, “No, we don’t think that’s a good idea."

These discussions do not stop there, however, and people retaliate with reasons like “I do not need or want any ‘new features’”, they “just want” those bits that might protect against unexpected—unaccounted for and unlikely-to-occur—potential security exploits within the old version of software that they are currently using.  Again, this isn’t an unreasonable question to ask but, again, it’s virtually impossible to answer in a forum context because it involves revisiting the hundreds of changes that have been made between J! 3.7.5 and J! 3.8.0.

Even so, the responses about whether it’s feasible or desirable to (somehow) kludge parts of J! 3.8.0 with J! 3.7.5 were also fairly predictable … and so the discussion keeps spinning around on itself in ever-widening circles of attack and counter-attack.

I manage a few websites.  I use software that works well with J! 3.8.0 (and I haven’t had the kinds of problems that others may have had) but I also view the need to keep up-to-date with Joomla as a strategic one to my business needs.  I know that when J! 4.0.0 is released my life will be turned upside-down.  I’ll either have to spend a few weeks revisiting all my websites and decide whether certain third-party extensions are worth the trouble of holding onto or ditch them.  I may even have to bid adieu to some of my favourite “friends” that have helped me to get where I am today.  C’est la vie.

All of these decisions will be tough, painful decisions.  It was the same when the bank stopped treating me like a person and I had to do my banking online; when I stopped sending Christmas cards because of the cost of postage; when I had to put fuel in my car and wash the windows and check the oil and water myself.  The way we do business today is not like the way we did business years ago.  Imagine how the dinosaurs must have felt when that comet hit the planet?  We need to move on.

Using a localhost (PC-based solution) to wrestle with those “update problems”

I don’t use XAMPP (or WAMP, MAMP, LAMP or “Universal Server”) these days unless it’s something really “tricky” and I’m dragged kicking, and screaming in protest, into doing it.  Other people have a different opinion to me.

If people want to pursue the XAMPP path (and I apologise that I can’t really help people with this because the last time I did this was about 10 years ago) they would need to install XAMPP, configure PHP, Apache and MySQL as appropriate—try to match the versions of those things with whatever you’re using on your professionally-hosted environment—and deal with any of those issues themselves.  There is a wealth of information about Apache-MySQL-PHP stacks on the internet; people should use Google to research that information.

And if, after getting XAMPP up and running—and good luck with that—then people can install Joomla using the standard installation process (if that information is helpful; I don’t know). If people want to use XAMPP to diagnose their current [broken] website then, of course, they will need to restore their website onto their local computer and set things up so that it works there (or does not work there, either, as may be the case).  This shouldn’t take more than a few hours to iron all those problems out, I guess ...

Some people live, breathe and die by XAMPP.  Some people swear by it ... and others, like me, usually swear at it[4]. 

“Me too …”

After updating Joomla from 3.7.5 to 3.8.0, there seems to be a problem with the backend.  I could see the login page but after signing [in an] empty white screen came up.  Any idea?forum user, Joomla Forum, 20-Sep-2017

A useful piece of advice—for when you have the “empty white screen” problem—is to enable Joomla’s debug mode.  There are many ways to enable Joomla’s debug mode even if you cannot login to your website!

There are too many different “problems” for this article to address individually.  As a general observation, I am sorry to hear that people are having problems with Joomla; it does not in­spire confidence within the broader community to read comments like “this was the worst update ever”.  I have seen similar complaints written when J! 3.7.0 was released, when J! 3.6.0 was released, when J! 3.5.0 was released and we can probably trace the source of these complaints all the way back to when Adam complained to God that Eve was the “worst update ever” as far as humankind is concerned.  So I’m not really surprised.

Unfortunately, when complaints that we read are exaggerated out of all proportion, when discussion forums becomes echo chambers for people who want to offload their frustration on to “Joomla”, there’s not a lot anyone can do to salvage any rationality when tempers flare.

As always, if you have any comments on this article, please use the form at the bottom of this page; if this article was useful to you, please use the “star rating” system at the top of the page.  All comments are very much appreciated.  I think I’ll leave it at that.

Notes:

[1]  Source:  https://developer.joomla.org/about/stats.html.

[2]  See under Content » Options » Integration » URL Routing = Experimental and the corresponding setting Remove IDs from URLs = Yes.

[3]  If you’re not using LDAP on your site and you don’t have any archived articles then you don't have any reason to patch J! 3.7.5 (for now).

[4]  See To “localhost” or not to “localhost”, that is the question.

About the author:

Michael Russell has worked in the information technology industry since 1971 and, since retiring from the workforce in 2007, is a website hobbyist specialising in Joomla, a former member of the Kunena project for more than 8 years, and contributor on The Joomla Forum™. The opinions expressed in this article are entirely those of the author. View his profile here.