Cleaning up for Joomla 4.0

[rgtr]

Hi
I have 8 joomla sites.
Five have updated "ok".

I am now investigating what needs to be cleaned up in long term installed extensions.
First is Akeeba backup - in a site I started in J1.5, now in J4 beta6, tried to uninstall Akeeba - lots of stuff from tables and other stuff. Got a "Whoops". Front end carried on working fine, but backend knackered.

Does anybody know how to clean up Akeeba Backup, and Admin Tools ?

JCE seems ok
Sigplus seems to be ok

Community Builder and Regular Labs are not ready for J4 but seem to uninstall Ok

Does anyone have a checklist ?

Redundant stuff seems to include:
KC Old Browser Warning
P3P Policy
plg_content_geshi
PLG_CONSOLE_AKEEBABACKUP
AkeebaStrapper rev699A630-1420553182

Richard

[JAVesey]

Does anybody know how to clean up Akeeba Backup, and Admin Tools ?

Why do you think that you need to do this? Admin Tools already works on J4 anyway.

I shouldn't worry about it; leave it to the extension developers.

Besides, the migration path will be J3.9.x --> J3.10.x --> J4.0.x

[rgtr]

John
The problem is the junk which has been lying around for years....
I have been using the migration path, and then one has a site which ought to but doesn't upgrade.
One needs a methodology to work out what is going awry.
The developers cannot cater for every mishap that has happened to every user over the last decade ... I was software developer for 20 years, and I understand the problem.
The news group I used - and I had better not name for fear of a blast of emails saying I am advertising and getting off the subject always assisted, and politely corrected.
There is a problem [a big one for many] that one common way of cleaning up is to remove an extension, and then reinstall it. This causes J4 to crash if done at that level, and if done earlier, causes a whoops on the 3.10 to 4 step. Problem is the "whoops please tell us message" does NOT give even the module let alone the line no where the crash occurred.
Error trappers are an art, and the one we developed was quite good - allowing us to fix often within hours.

Question is where do I publish the results of my research ... have now sort of sorted Akeeba.

Richard

[toivo]

Question is where do I publish the results of my research

If it is an issue in Joomla 4, use the Joomla! Issue Tracker - CMS or if you want a sounding board for ideas, then in the Joomla CMS Discussions in Github.

[rgtr]

Thanks for the heads up.

Very helpful.

When one removes something in Joomla 4 and it crashes - then its a J4 problem.
I tried removing Akeeba - is that a J4 problem, or an Akeeba one ?

Is there going to be an error trapper for J4 soon ? Or is there a setting I need to change.

I am used to being able to demonstrate things by reference to a web site. Is this really banned ? For example having a sticky header and breadcrumbs is something which I specified in 2006. See the web site associated with my email address. Its java script and static of course.

Richard

[toivo]

I tried removing Akeeba - is that a J4 problem, or an Akeeba one ?

At the moment Joomla 4 is in its Beta stage. Extension developers like Akeeba are no doubt interested in feedback, especially in the Release Candidate stage, but during Beta testing Joomla 4 is still updated daily and extensions like Akeeba Backup and Admin Tools do not release update so frequently.

As a test, happened to install from the web both Akeeba Backup and Admin Tools and then uninstalled them in Beta7-dev using PHP 8.0.1 and the error reporting level 'Maximum'. A few messages were displayed in each case and one table from Akeeba Backup was left behind but the components were uninstalled and the site was still working.

[toivo]

I am used to being able to demonstrate things by reference to a web site. Is this really banned ?

If your Joomla site has an issue, including the URL is recommended and often also necessary so that our volunteers review the configuration and give proper assistance.

Rather than showing a link to a non-Joomla website, it would be better to include just a screenshot. If you want to find out if there is a Joomla extension that implements a particular function, which requires viewing or hands-on experience, you can show a broken link, for example by including spaces in the domain name.

The rules of this forum are strict about self promotion. Any posts seen advertising one's own extensions or services and referring to blog posts or forum topics to a similar effect will be removed.

[rgtr]

Toivo
I guess you do not like me or my questions.
I do NOT provide any services relating to web development, and I do NOT therefore promote them. I do however try and address common problems - but ONLY about Joomla. ALL my sites are Joomla based except for a couple from 20 years ago which are driven by java.
Richard

[sozzled]

The same question was asked by the OP on GitHub and the recommended answer (from one of the lead J! developers) was ... wait for it (drum-roll please):

This is a feature in Joomla 3.10 that will be provided (you can try the nightly for that already).

That answer was given on 27 January this year. And when was the last version of J! 3.10 released? The announcement about the availability for J! 3.10 alpha 5 was on 2 February. The announcement, however, does not contain any links for people to download J! 3.10 alpha 5, however. This kind of makes things hard, doesn't it?

So, on one hand, the pre-update checker feature for people wanting to migrate from J! 3.x to J! 4 will be available in J! 3.10 but, on the other hand, it's a nightmare trying to find where to download J! 3.10.

Before everyone rushes to tell me that you can download the latest nightly build of J! 3.10 from https://developer.joomla.org/nightly-bu ... joomla-310, yeah, I know all about "nightly builds"!

Nightly builds are:

• snapshots of the development activity for upcoming Joomla! releases and include new features and bug fixes scheduled for these releases. These releases are made available to make it easier for users to test their websites and extensions for potential issues with an upcoming release or to test new features and provide feedback on ways to improve them before being released to the Joomla! community.
• more likely you may encounter an issue compared to the stable releases. If you have encountered an issue, please check our issue tracker to see if it has already been reported; if a report hasn't been made, please report it so our community members can review the issue and make any needed fixes.

Use nightly builds if you have confidence in things not breaking or don't use them, that's your choice. The last official/formal announcement about J! 3.10 was 3½ months ago. Doesn't look very promising to me.

I have absolutely no intention of trying to migrate more than one J! 3.x site to J! 4.0 this year; that's a big enough job for anyone. I don't even know how popular J! 4.0 will be or, by then end of the year, how many people will be using it. Trying to migrate eight websites at this time ... well ... the best of luck with that!

[rgtr]

Sozzled.

I have followed the recommended route - going via J3.10.

I have written the two things I needed for which I could NOT find a free replacement - to show a Facebook page in a sidebar, and to display a kml file in Googlemaps.

The Facebook one was exceedingly simple - code mostly provided by Facebook, and the J4 models.

Googlemaps was a bit more complex. Main problem was sorting the TWO scripts which are needed - one a constructor, and the other for authorisation. Googlemaps support [free] sorted me out.

One plugin which I rely on which has not been converted is undergoing a major rewrite at the moment, and it will be available in J4 in due course. I also use some of Regular Labs stuff - mainly sliders and articelesanywhere but I am sure these will be made available for J4 in due course.

Of my 8 sites, ALL are now ready for J4 - viz a copy has been converted for each.
The problems encountered were mainly "garbage" left over from J1.5, 2, and 2.5. Interestingly all different.
I am slowly removing all this one site at a time - so when the time comes it will be all done in a few days.

The J3.10 checker is very necessary !

For some thirty years I developed in Clipper and then CAVO. The Google Group for that was amazing. One thing we did was quote code and show examples on the web. The latter is exceedingly useful, and the moderators really should review the rules about doing this. Anyone abusing it and advertising etc should be banned.

On Mike Reumer's code. There is NOTHING in the CODE which is even vaguely malicious. AFTER he passed it on, someone added a Twitter link... nothing bad. BUT When that person junked it, the update site "got infected", and that remains a problem today. My code is only about 7% of the size - but it does a lot less.

My last comment is on the updating mechanism. Only one script is required, and it works in J3 and J4.

The J4 team are doing ok. Patience is required. The dumping of Moo tools in favour of Bootstrap 5 is a brave move and to be applauded.

Richard

[sozzled]

I have followed the recommended route - going via J3.10.

Agreed; that's the correct approach. You cannot go from J! 3.x to J! 4.0 unless you go via J! 3.10. My point is that J! 3.10 doesn't actually exist for production purposes.

I agree with you that the J! 3.10 update checker is necessary. What's even more necessary is a stable release of J! 3.10 that includes this update checker. For reasons best known only to the development team, it appears that J! 3.10 stable will be released after J! 4.0 stable. Therefore, if you're using the J! 3.10 update checker now, it may change between now and the release of J! 3.10 stable. That's all I'm trying to say.

The J4 team are doing OK. Patience is required.

Really? I don't need to continually wear down my worry beads?

The dumping of Moo tools in favour of Bootstrap 5 is a brave move ...

MooTools was dumped a dozen years ago when J! 3.x was first developed (just in case you didn't know). And the J! developers are removing all traces of Bootstrap from the J! 4 frontend template ...

If you want to talk about "cleaning up" for J! 4 then let's talk about that. I don't know if it helps to talk about a third-party developer's product and how you've improved it. OK?

[rgtr]

Sozzled

The 3.10 stable cannot be released before the J4 stable release because there would be no clear spec of what has to be checked.

I have NOT improved Mike's stuff. Started with a clean sheet and of course a totally new GoogleMaps API.

I would quote a web site to demonstrate this, but sadly it would be redacted. It also explains a number of other tings which are only of interest to "mappers"

Richard

[sozzled]

The 3.10 stable cannot be released before the J4 stable release because there would be no clear spec of what has to be checked.

EXCELLENT! Can we just repeat the last nine words of what you wrote in letters about 3 metres high?

As far as J! 4.0 stable is concerned, there is no clear spec of what it contains (and therefore what would have to be checked within J! 3.10). This is, perhaps, the biggest catch-22 of the entire J! 4 project! You can't have a migration path from J! 3.x to J! 4 unless you have J! 3.10 but you can't have J! 3.10 unless you have the end point—J! 4.0. That's a conundrum, isn't it?

Over the course of the past six years, when everyone supposed knew what the "end point" would be, the goalposts shifted and today we still don't know what will be in J! 4.0. And to compound matters, you're trying to check the ability to migrate eight J! websites (from J! 3.x) for J! 4.0 without what will be in J! 4.0 when/if it eventuates.

That's why I wrote:

I have absolutely no intention of trying to migrate more than one J! 3.x site to J! 4.0 this year; that's a big enough job for anyone. I don't even know how popular J! 4.0 will be or, by then end of the year, how many people will be using it.

I don't have any reason to change my opinion at this time. I'm going to wait and see how the next six months pan out. I don't expect a gold rush any time soon.

[rgtr]

Sozzled.

As an experienced software developer, I comment that most development takes place in an ever changing environment where needs and requirements are the first part, and technology the second part.

This sets the precedence. It makes migration even more problematical. One has to support many release versions at the same time. On a major project [e.g. a £400 million hospital with up to 100 users over 5 years] it is best to start with a stable release and continue to the end.

Richard

[sozzled]

Agreed (up to a point). In order to keep software projects running on track, it's important to scope the requirements and agree on that scope of requirements before launching into the [technological] development. That's why J! 1.0→1.5, J! 1.6→2.5 and J! 3.0→3.9 were a success. The scope was defined and the development followed after it: the cart was designed to suit the horse.

The scope for J! 4.0 was defined in 2017 or thereabouts. The development community failed to achieve complete agreement on the scope and, because of that, the J! 4.0 has been a project where the design of the cart has changed so much that I'm not sure whether there'll be a horse still be alive to pull it.

The J! project, overall, is not big enough to "support many releases" at the same time. And, besides, what does "support" mean? There is no official support for J!; the technology has always been "use at your own risk".

All of which is off-topic. The essential point is that the J! 3.10 update checker is still a work-in-progress.

[sozzled]

The dumping of Moo tools in favour of Bootstrap 5 is a brave move ...

MooTools was dumped a dozen years ago when J! 3.x was first developed (just in case you didn't know). And the J! developers are removing all traces of Bootstrap from the J! 4 frontend template ...

I need to correct my earlier comment. The developers are working to have Bootstrap 5 with Cassiopeia; I confused the question with jQuery: there's a cloud hovering over that.

[brian]

> On Mike Reumer's code. There is NOTHING in the CODE which is even vaguely malicious

there absolutely was - can't speak for today.