Discuss Joomla! 3.8.4

[VasyaV001]

Wow! After many problems with the router, ID, session time, errors 500 and more, I rolled back to version 3.8.3. In general, I do not advise multilingual sites are updated to version 3.8.4. I'm sorry! I hope new version 3.8.5 will be better.

[ribo]

In general, I do not advise multilingual sites are updated to version 3.8.4. I'm sorry! I hope new version 3.8.5 will be better.

Wrong advice. I updated many multilingual sites to joomla 3.8.4 and i don t have the problems that you have.

[wbtcpip]

Wow! After many problems with the router, ID, session time, errors 500 and more, I rolled back to version 3.8.3. In general, I do not advise multilingual sites are updated to version 3.8.4. I'm sorry! I hope new version 3.8.5 will be better.

I agree. Me too i had the same probblems in my multilanguage site. Waiting for 3.8.5

[GillianBPP]

Jenn and @Scrabble: I reported the colour hilighting issue on GitHub.

https://github.com/joomla/joomla-cms/issues/19520

Thank you.

[jojo12]

I had the same problem with login on multilingual sites. And in my eyes it's very bad, that there's no information about that in the FAQ for joomla! 3.8.4. Only searching in some forums showed me, that the login problem comes directly from Joomla!

[Fan33GR]

Hello to all.

Do we have any news when the next update of Joomla will be released? (3.8.5)

I read about the bugs, but I have a huge problem with the number of visitors and the logged in users because they stay logged in forever and the numbers of visitors also remains and still rising and counting them as they are live in the site all the time.....

Also happens and something funny... Some people think that we do this on purpose to show that we have thousands of visitors to our site :P

So do we know anything about the date of the update?

Thank you.

[gws]

In the interim you can empty the session table via phpmyadmin.Sorry don't know when 3.8.5 will be available.

[jgress-]

https://www.joomla.org/announcements/re ... lease.html

[ribo]

Please check viewtopic.php?f=8&t=958978

[rjo]

Thanks a lot, the update has resolved the issues with login and editor on two of my sites.
Question: Would it make sense for the future to clearly distinguish between security patches and general patches?
If security patches only contained the relevant fixes, the risk to break other stuff (things happen) could be reduced.
That might help increasing the readiness to install security updates quickly. Some sites might have remained unpatched for a couple of days after the first issues with the update had been reported.

[mikerotec]

Thanks a lot, the update has resolved the issues with login and editor on two of my sites.
Question: Would it make sense for the future to clearly distinguish between security patches and general patches?
If security patches only contained the relevant fixes, the risk to break other stuff (things happen) could be reduced.
That might help increasing the readiness to install security updates quickly. Some sites might have remained unpatched for a couple of days after the first issues with the update had been reported.

I've been asking Joomla for this for years now... it is 'standard best practice' in most other software eco-systems!

BIG THANKS to the devs who got 3.8.5 out... I was on the verge of sending a bulk mailer out to 20,000 users, advising them all to clear their browser cookies!

[ribo]

If you want to be safe, every time update joomla, third party extensions, template and not be vulnerable. But also there are other things too, like safe passwords, safe ftp, right permissions, etc.

[rjo]

that's what I do ;-)

[deleted user]

We can't efficiently distinguish between security patches and "general" patches.

Assume that we had a 3.8.4 release which was JUST the security patches, then the 3.8.5 release was the rest of the maintenance work. Joomla would prompt you to update to 3.8.5 and wouldn't stop nagging until you did so, because it just sees that you are on an out-of-date release.

How do security patches get rolled? Do we patch every previous security release, effectively creating a security only upgrade path for users who just want to lock on a version and never upgrade (i.e. 3.8.2 was a security release, so should there have been a 3.8.2.1 with the 3.8.4 security fixes too), or are users still forced to update to a release which has other miscellaneous fixes in place? Depending on the approach, release day turns into a major affair where a release manager is easily spending 6-8 hours merging patches, committing release tags, running scripts to build packages, and publishing all release artifacts (whereas now if need be I personally could get something out unplanned in 60-90 minutes, 30-45 minutes on a planned release day because of taking the time to prepare things in advance).

While there are a lot of ideas about how security patches can be handled, the resource requirements to implement many of them are too great for an all volunteer workforce (and my employer is not paying for my time spent in release prep, so for me personally I have to sacrifice either other time outside my normal work window or time on my job which affects my paychecks because our release windows fall in line with my office day) so I personally don't see a lot changing anytime soon.

[sozzled]

Question: Would it make sense for the future to clearly distinguish between security patches and general patches?

I agree with comments made by @ribo and @mbabker.

Before addressing this question (also asked by @mikerotec) I think we should ask these people to consider "What would happen if there was a differentiation between 'security' and 'general' patches?" How might this affect people's decisions to implement the update or not?

Each dot-point release of software (regardless of so-called "eco-system") includes a mix of change: improvements in functionality, resolving outstanding issues that were present in previous releases, improvements in security and (occasionally) improvements or changes in functionality.

So the real question here—whether or not the production team were capable of isolating security from general changes—is really "How would this affect people in deciding whether or not to adopt the update(s)?" When people can adequately address that question then we may have a worthwhile basis for continuing that discussion.

Some people have problems with new releases and some people don't. Some people always have problems (but for different reasons). Some people have problems when they don't update (and some people have problems because they don't update); we tend to receive more topics on this forum for those reasons. I don't believe the case has adequately been made for why differentiating between security and general patches is "better" (or even worthwhile). In the meantime, I agree with@ribo that it's better for overall maintainability of Joomla websites, to apply the changes as and when they are released.

[rjo]

Thanks for your detailed response.
Of course I can only speak for myself. I install security updates immediately because I consider them to be essential. On the other side I would take some time to test updates that contain more profound changes or even new functionality.
Of course non-critical updates must be installed too to not get out of sync with the project. I fully agree to that, but I could avoid spending the weekend on updating when it is not urgent and I could take some time to test in a separate environment before breaking a production website. So I guess it would be nice to have separate security updates, if that was possible. I simply don't know if github provides any tools to assign specific tags to a change and to create a release based on such this information.

[sozzled]

@rjo: Everyone has their own/different priorities. Some people have no sense of priorities (and that's why they're still struggling with J! 1.5, J! 2.5 or pre-J! 3.5 websites). Some people never get it into their heads that support for older versions of Joomla is wishful thinking on their part.

The Joomla project is a living, dynamic, evolving project. Of course, everyone has different needs: developers are continually at the cutting-edge of new developments in webcraft and they're continually pressing for those developments to be added to Joomla! Your typical hobbyist/enthusiast/"one-page website" owner may have none of those interests and just wants to build a website, put it "out there" and basically forget about it ... until something comes up and that's when they ask questions on this forum.

There's no pleasing everyone.

[mikerotec]

Actually, I think it's getting much better. The release notes for 3.8.4 did explicitly mention that it included 4 "low priority" security patches.

But I kind of got suckered in with the announcement "Joomla 3.8.4 is now available. This is a security release for the 3.x series of Joomla addressing four security vulnerabilities and including over 100 bug fixes and improvements."

"Joomla 3.8.4 addresses four security vulnerabilities and several bugs"

Unfortunately for our users, I had become complacent after that relatively smooth 3.8.3 update, and made the fatal personal mistake of not TESTING more rigorously. Problem was that our dev test server is NOT https! (Yes, it will be soon...) And on the live server (yes, I do run through the live site after updating...) the issue was not revealed through any surfing of the site - WHILE LOGGED IN - the redirect problem only happened when logged out and then logged in again. ("GOTCHA!")

But really, in retrospect I see that I should not have updated without testing this much more rigourously on an HTTPS dev server. And If there is any improvement I could suggest in the release notes, in the case of 3.8.4 it might have been nice to have a warning like "Note: this release contains Major changes to core routing code, test accordingly!"