Joomla wishlist! (Real-World Considerations)

[mikerotec]

Personally, I'd like to see this 3.8 experiment ABORTED.
Produce any necessary SECURITY PATCHES for 3.75 as stand-alone 3.75 patches.


Save all the router re-writes for Joomla 4, and BEFORE releasing J4, how about this:

PREAMBLE: advise all extension developers that they need to create a new 4.0 extension AND a well-tested 3.75-to-4.0 DATA IMPORTER. GIVE THEM CONCISE DETAILS ON WHAT THEY NEED TO BE AWARE OF.


ALSO: ( very important ) Give clear instructions to ALL Joomla users about the REQUIREMENT for new 4.0 compatible extensions. PUBLISH A LIST OF ALL KNOWN 4.0 compatible extensions! Put it on the FRONT PAGE OF JOOMLA.ORG!


Then...

1) let all users install a CLEAN Joomla 4.

2) produce a proper DATA IMPORTER for all 3.75 users ( core joomla functions)

That way all of us can TEST 4.0 on our development servers, knowing we're coming in with a CLEAN SLATE.
And decide if J4 is gonna work for us going forward (based on cooperation of extension developers!)


What think ye all???

[sozzled]

I don't have a problem with anyone expressing their opinions—favourably or otherwise—about the success or lack of success surrounding the release of J! 3.8. For whatever reasons that @mikerotec has created this topic, they deserve a respectful reply.

There are several abstract claims—"leaps of faith" one could describe them—that require testing before we could reasonably agree or disagree with the propositions that (a) J! 3.8.x has been a resounding failure in tems of design, implementation or marketing (perhaps), (b) that J! 3.7.x should represent the last stable release of J! 3.x and that further releases should be confined to security patches or straighforward bugfixes and (c) that it should be full steam ahead for J! 4.0 and that the any new features for J! 3.x should be confined only to J! 4.

I've got serious reservations about points (a), (b) and (c) above. In the first place, there's no empirical evidence that J! 3.8 was unsuccessful or so out-of-touch with the whole Joomla community that resulted in a number of people being caught out when Joomla extensions that they relied upon were not compatible/compliant with J! 3.8 at the time of its release. Of course (as with any dot-zero version) there are bound to be initial problems and it's regrettable that, for some people, circumstances prevent a number of websites around the world taking advantage of the security, bugfix and enhanced functionality included within J! 3.8.

By the same token, for whatever reasons may exist, some people are unwilling or genuinely unable to update from J! 1.0.4, or J! 1.5.6, or J! 2.5.20 or J! 3.4.8 or pick-a-number ...

In military-speak, this is called "collateral damage". No-one wants to suffer, of course, but sometimes there has to be a little bit of pain in order to make a substantial amount of gain.

Based on current usage information, the reported deployment of J! 3.8.1 is 9.5% compared to J! 3.7.5 with 4.4%. So, J! 3.8.1 sites are reported as being deployed 2:1 times more than J! 3.7.5 sites. I don't know if this information is necessarily useful or not but I just put it out there so that we can gauge the extent of the issue. (Just a BTW, total J! 3.7.x sites are 16.3% and total J! 3.8.x sites are 12.7%; it takes time for new versions of Joomla to gain traction but the trend demonstrates that J! 3.8 will overtake J! 3.7 within the next couple of months.)

One or two of the enhancements included with J! 3.8.x (that people may or may not choose to use) have been begged-for, screamed-at and the developers have been given a whipping-over ever since the release of J! 3.0. So, even though these features could be called four years overdue, they've been on the to-do list for the past four years as something that was intended to be delivered as part of J! 3.x.

As far as J! 4 is concerned, this "version" exists as little more than a blueprint of ideas. Both as a website owner and extension developer I am, naturally, interested in J! 4. I have no specific plans at this time to construct a test bed for J! 4. I will, however, need to carefully consider and plan for the migration of a number of websites that I own (that rely on PHP 5.6) so that they'll be in a position to be migrated to J! 4 at a time of my own choosing. In the meantime I will take all necessary steps to ensure that these sites will be as "J! 4-ready" as I can make them by keeping them up-to-date with the latest versions of Joomla. For that reason (and perhaps for that reason alone), updating to J! 3.8 and J! 3.9 will be a key part of that overall strategy.

I don't want to be left behind for any longer than is necessary. My principal needs are to maintain a series of Joomla platforms for testing, for blogging about the various interests that I have, and for selling my software products. That's what drives me.

[deleted user]

To be frank, your ideas suggest that the next Joomla version would be similar to the Drupal major releases of the past or a Joomla 1.0 to 1.5 or 1.5 to 2.5 style migration where you abandon a site and build a brand new version. The Joomla project would not survive another migration of that style.

[mikerotec]

My concept is far from having to 'abandon a site', the key factor i had in mind was

"produce a proper DATA IMPORTER for all 3.75 users" .

In other words, make a 'new and improved' joomla that can cleanly rebuild itself as a CMS containing all the data present in a 3.7.5 installation ( this is the last "known good" Joomla, as far as I can tell... )

When a Joomla version CONTAINING SECURITY PATCHES has only an adoption of 12.8% - I would call that an unmitigated FAILURE.

Thus I suggested that they patch the 'last known good' version, instead of only putting patches into the "new and improved' version that radically breaks a lot of the well-established third-party stuff that has been working perfectly well FOR YEARS.

Again, I reiterate, I do think the approach below is essential for getting this project back on track:

PREAMBLE: advise all extension developers that they need to create a new 4.0 extension AND a well-tested 3.75-to-4.0 DATA IMPORTER. GIVE THEM CONCISE DETAILS ON WHAT THEY NEED TO BE AWARE OF.


ALSO: ( very important ) Give clear instructions to ALL Joomla users about the REQUIREMENT for new 4.0 compatible extensions. PUBLISH A LIST OF ALL KNOWN 4.0 compatible extensions! Put it on the FRONT PAGE OF JOOMLA.ORG!

[deleted user]

In other words, make a 'new and improved' joomla that can cleanly rebuild itself as a CMS containing all the data present in a 3.7.5 installation ( this is the last "known good" Joomla, as far as I can tell... )

This was the Drupal development strategy until the release of Drupal 8. It is inefficient because for the longest time their methodology was "as long as the data can be imported then code compatibility be damned". And they are still working on data importers for proper migrations from Drupal 6 and 7. Look at the decline of Joomla's usage and popularity and how it very closely tied in to when users performed their migrations from Joomla! 1.0 to 1.5 and 1.5 to 2.5. Clearly, the strategy you suggest would work well given the project's history.

"Last known good" is entirely perception. Joomla 3.8 functions just fine. The extensions which broke were bypassing the core API to do things (which would be considered unsupported use of the API) or were overloading core classes to modify functionality and is also not a supported use of the API. The only way to avoid having that issue in a non backward compatibility breaking release would basically be to adopt the previous Drupal development strategy where you do not have minor feature releases and only issue major releases (which allow compatibility breaks, and yes some legitimately argue that adding a new method to an existing class is a compatibility break) and patch releases.

[sozzled]

... far from having to 'abandon a site', the key factor I had in mind was "produce a proper data importer for all 3.7.5 users"

Well, as we all know, all generalisations are false (including the one I've just written), because the evidence doesn't support the fact that "all J! 3.7.5 users" are faced with an either/or, exclusive choice of (a) abandoning their websites or (b) requiring any kind of "data importer" other than the Joomla! Update component to update their sites to J! 3.8.x.

Not all of us had the problems that @mikerotec has experienced and that's why I wrote (in another forum topic):

I am sympathetic towards for people who've had problems during and after installing J! 3.8.0. That's why I'm here to try to help those people (if they're serious about wanting help). I also know that people mostly use support forums to voice their criticism or to report their problems and they rarely (if ever) compliment the development team for the work done to update the software product. We need to keep these things in that perspective; let's not judge the success of J! 3.8.0 based on the echo chamber of a support forum where everyone wants their problems solved yesterday.

People should look around the internet and read the opinion pieces and blogs written by independent commentators. Yes, there are problems and, yes, there are solutions for those problems and, no, not everyone has these problems.

Some people are serious about wanting help and, even though it's an inconvenience, they're prepared to work with us to seek our help. Some people don't want our help and they only want to complain. I sense that this "Joomla wishlist (real-world considerations)" discussion topic is an undisguised Joomla bashing.

[J! 3.7.5] ... the last "known good" Joomla, as far as I can tell ...

It depends entirely whose opinion one agrees with. I disagree there's a body of opinion that supports a different judgement.

When a Joomla version containing security patches has only an adoption of 12.8%, I would call that an unmitigated failure.

I'm not sure what we're discussing but if we mean J! 3.8.x as the "Joomla version containing security patches" this is only a half-truth. J! 3.8 contains feature enhancements, maintenance fixes as well as security improvements over what J! 3.7 had. The second problem with the passage I've quoted is the "unmitigated failure" conclusion. Judging success or otherwise of J! 3.8, based on a thirteen per-cent (out of all versions of Joomla released since J! 3.5.0—based only on the voluntary reporting of this information to the Joomla developers) and knowing that J! 3.8 has only been publicly available since 19 September (about five weeks ago), is a creative use of statistics; nothing more than that. Even so, the selective use of statistics shows that, since J! 3.5.0 was released on 21 March 2016 (74 weeks ago), one in eight Joomla website report using J! 3.8.x in one-fifteenth amount of that time.

I'm not going to play games with numbers. I disagree with notion that J! 3.8 is out-of-touch with the real world. I accept that some people will have problems with J! 3.8. I also note that the people who have these problems are not prepared, themselves, to work with others to resolve those problems. As just about every page on this forum advises:

Forum Post Assistant - If you are serious about wanting help, you will use this tool to help you post.

[Webdongle]

3rd party extension/template devs can easily test if their extensions work before a new Joomla is released https://developer.joomla.org/nightly-builds.html

[mikerotec]

If it's so easy, then why the hundreds of dead sites? Clearly this whole 3rd party extension ecosystem is NOT very robust. I just think the whole thing needs to be RE-evaluated, in light of the actual reality in the field. Which is (IMO): right now there are way too many unqualified extensions floating around that got broadsided by this 3.8 update.

It's one thing to have to deal with the reality of such a fragile ecosystem, but quite another to pretend it's NOT fragile.

My suggestions are based on pragmatism. I see this as just the tip of the iceberg, and it's only going to go downhill from here if the reality isn't faced up to.

What's the harm in IMPROVING the situation? Start making some enforceable REQUIREMENTS for Joomla developers! There is such a thing as transaction testing... If the LINUX project was developed along the lines of the JOOMLA project, then the whole internet would be running on Windows Server by now...

[Webdongle]

@mikerotec

How would you 'improve' the system ?

Have the update check what 3rd party extensions are installed and disable them if they are not up to date? (that would be illegal) ... refuse to continue with the update until the extensions were updated? (that would prevent security updates from deploying).

Or perhaps make the warning about updating extensions in big, bold, red lettering ? Maybe you want the Joomla bugsquad to test all the 3rd party extensions(that are in JED) on the new version ... or better still test the update on a copy of your website.

Joomla updates work well on sites that were created with a Joomla full package zip. It is the websites admin to make sure that the 3rd party extensions (that they install) are up to date. It is the responsibility of the 3rd party extensions developers to test their extensions on the dev and RC Joomla versions.

Bottom line is ... you can't fix stupid.

[mikerotec]

@mikerotec

How would you 'improve' the system ?

Have the update check what 3rd party extensions are installed and disable them if they are not up to date? (that would be illegal) ... refuse to continue with the update until the extensions were updated? (that would prevent security updates from deploying).

DON'T BUNDLE SECURITY UPDATES WITH "FEATURE" UPDATES. KEEP THEM SEPARATE! (duh!)

Or perhaps make the warning about updating extensions in big, bold, red lettering ? Maybe you want the Joomla bugsquad to test all the 3rd party extensions(that are in JED) on the new version ... or better still test the update on a copy of your website.

How about kicking everyone NON-COMPLIANT out of the JED, for starters? Or if you don't want garbage in your system, don't bundle JED into Joomla! If all these third-party extensions are the SELLING POINT for Joomla adoption, ( and clearly they ARE) - then Joomla should take some responsibility for their QUALITY...

Joomla updates work well on sites that were created with a Joomla full package zip. It is the websites admin to make sure that the 3rd party extensions (that they install) are up to date. It is the responsibility of the 3rd party extensions developers to test their extensions on the dev and RC Joomla versions.

And who is responsible for the putting the JED "Install from Web" tab into Joomla??? How about kicking everyone NON-COMPLIANT out of the JED, for starters? Or if you don't want garbage in your system, don't bundle JED into Joomla! If all these third-party extensions are the SELLING POINT for Joomla adoption, ( and clearly they ARE) - then Joomla should take some responsibility for their QUALITY...

Bottom line is ... you can't fix stupid.

[sozzled]

How about kicking everyone non-compliant out of the JED, for starters?

People can assist other people in two ways (a) by writing reviews about products listed in the JED and (b) by reporting listed products for investigation. The people who manage the JED are not self-appointed law-enforcement, prosecutors, judges, juries and executioners. So, how about using your own time to help others?

And who is responsible for the putting the JED "Install from Web" tab into Joomla?

The Install from Web tab is generated by the Installer - Install from Web plugin. If people feel that the Install from Web feature is unnecessary, useless or causes more trouble than it's worth then they can disable this plugin. Therefore, to answer the question about "who is responsible" for putting the Install from Web tab on a Joomla website, I think the answer may be found by the questioner looking in the mirror.

[Webdongle]

...
DON'T BUNDLE SECURITY UPDATES WITH "FEATURE" UPDATES. KEEP THEM SEPARATE! (duh!)The staging version of Joomla often contains the feature/bug updates so any security patch applied to that will include those other updates.

...
How about kicking everyone NON-COMPLIANT out of the JED, for starters? Or if you don't want garbage in your system, don't bundle JED into Joomla! ...

It is the responsibility of the 3rd party extension devs to test their own code. JED is not bundled into Joomla ... the extensions in JED are not part of the Joomla core.