[RELASE BLOCKER] Brokenen sites on update

[wojsmol]

Steps to reproduce the issue

Update from Joomla 3.7.5 do 3.8.0 on a lost with low php max_execuntion_time or resource limits

Expected result

Proper update of the Joomla corere.

Actual result

Broken site or admin with man-less error or blank page

System information (as much as possible)

from one of FPM reports PHP Configuration :: Version: 5.6.31 | PHP API: apache2handler | Session Path Writable: Yes | Display Errors: | Error Reporting: 32759 | Log Errors To: error_log | Last Known Error: | Register Globals: | Magic Quotes: | Safe Mode: | Open Base: | Uploads: 1 | Max. Upload Size: 100M | Max. POST Size: 8M | Max. Input Time: 60 | Max. Execution Time: 30 | Memory Limit: 32M

If this care there is only core plus one plugin on php 5.6

Additional comments

@mbabker @nibra @Webdongle @zero-24 @brianteeman relase blocker and priority please

[Webdongle]

@wojsmol Perhaps you should look at your version numbers. A;so Joomla is not responsible for poor server settings.

[brianteeman]

I dont see how this is a release blocker

[mbabker]

Annoying as it is, without reverting all the work in 3.8 or rewriting the already fragile post update steps in the update component to do the tasks in even smaller chunks, there is no fix here other than tuning the server specs.

[brianteeman]

For a start you should provide server logs to show that there was an issue with the system

I suspect the issue on that server is the ridiculously low memory limit setting of 30mb where the php default for that version of php is 128mb http://php.net/manual/en/ini.core.php#ini.memory-limit

[wojsmol]

@mbabker do like akeeba backup or phoca gallerry.

[brianteeman]

Hint. Look at the code for com_joomlaupdate and see who wrote it.

The problem is the server not Joomla.

[wojsmol]

https://checksums.kubik-rubik.de/ Don't close valid issue because a example.

[wojsmol]

@mbabker Please reopen

[mbabker]

The issue is server configuration. Low memory is not something we can account for without the major work I mentioned above and that is not happening in 3.x if at all.

[wojsmol]

ok, then help user by adding relese faq entry or sampthig.

[wojsmol]

see migrating to 3 3 section on forums and the issues on github.

[brianteeman]

None of the issues on github are anything to do with poor servers

[wojsmol]

then try on localhost do the update and see waht you get when error_reportinf=defolt or none.

[wojsmol]

Please follow https://github.com/joomla/joomla-cms/issues/18157

[wojsmol]

@mbabker Can we block com_joomlaupdate on sites where we kwnow that doing the update will break the tike?

[mbabker]

We don't know where the update is causing issues and until we have concrete facts about what update paths are causing issues we are not changing anything. Because in theory every site can be broken by an update because of a combination of variables outside our control, like extensions which bypass our API then break because the files were moved.

As I have said before, WHEN someone gives concrete and reproducible paths, we can evaluate what steps need to be taken as a project.

[wojsmol]

@mbabker We knows yjat for this issue: memoryry limit below at lest 64m 128M for safety max_execution_time beloe 120s

[ggppdk]

@wojsmol

ok, update process can exceed max_execution_time (30s) on slow hosts,

but what do you mean with "120s" ?

make it a requirement on which hosts , with what criteria ? you mean run a measurement to decide if a host is too slow ?

[wojsmol]

@ggppdk it't braks for shore on 45s - -SG settings

[wojsmol]

Siple read php ini valus for 3.8.1

[wojsmol]

@mbabker Check PM on forum.

[mbabker]

The update system does not support blocking updates based on PHP runtime configuration.

[wojsmol]

@mbabker Mayby same message above? and a enmry in relase FAQ

[mbabker]

Not every update has the same system resource requirements. Because 3.8 did more filesystem operations it'll need a bit more memory.

Again, without concrete data, there is nothing we can address. Max execution time just says "this is how long the PHP process can run before timing out". The update should NEVER hit 45 seconds, and if it is then there is something else wrong at the server level. You are more prone to hitting memory exceeded errors than timeout errors.

[wojsmol]

If we fix this there in only one issue left, but not so criticatk,

[wojsmol]

Then contct SG ang debug with them.

[mbabker]

I run my site on SiteGround, it had zero issues. It also doesn't have low resource usage.

The key word in your PM to me was "test drive", this seems to purposefully be a lower resource account level. Moreso designed for sampling the platform, not for long term use.

====

Fix what? The fact that some users host sites on platforms with questionably low resource limits? That is out of scope for a bug fix release. The only way to do anything with that is a major rewrite of the update component. It's not happening anytime soon.

[wojsmol]

i test on td but in forms there few onnue with not TD , one after using SG autouptater. And SG support hava to clue wat issue is and this is this issue.

[mbabker]

SiteGround's autoupdater isn't our's to debug or troubleshoot. The most we can tell them is to make sure the updater follows the same steps the core one does. Same goes for everyone else who provides alternative update scripts.

[wojsmol]

I'm knoow that SG autopdatej in not offitial but if out parner support dpn'y know what the issue doy's tatherf noy good for as.

[wojsmol]

Regarting crapy server setup somply work user abot potentiall issues and mayby record the issiu in update loh, for now nee have always success message in the log.