User tests: Successful: Unsuccessful:
Pull Request for Issue #36741 .
This Pull Request includes changes in the JavaScript. The Patch Tester component DOES NOT support Joomla 4 PRs with changes in the JavaScript or the vendor folder as these items are NOT included in the repository; they are rebuilt when the Joomla build script runs before a release. You MUST use the pre-built packages, or build your own packages. Always start with a NEW site to avoid browser caching issues — especially pertinent if you've already tested another Joomla 4.3.0 development PR in your testing site!
To build your own packages, start by checking out this PR in a branch, let's say feature/jupdate-chunked-j4
.
Then open a console and run, go into the build
directory and run php ./build.php --remote=feature/jupdate-chunked-j4 --exclude-gzip --exclude-bzip2
This will check out the branch you created into a temporary folder in build/tmp
, build Joomla (you need Composer and npm available in your path), and come up with packages in build/tmp/packages
. Use the Joomla_4.3.0-dev-Development-Full_Package.zip to install a site for testing purposes.
You can now tell Joomla Update to download the upgrade packages one chunk at a time (default: 10MiB; can be as low as 256KiB and as high as 20MiB). This allows the update to download on very slow servers, as per the linked issue.
The default is to enable chunked download with a chunk size of 10MiB and a 2 seconds wait time between chunk downloads. On the vast majority of sites the update will run at the same speed or about 2 seconds slower. On local sites and slow servers which previously struggled with upgrades this will allow updates to work properly. For the remaining servers and local sites, users will have to edit the Joomla Update options to lower the amount of data downloaded per page load (most of them will find 1MiB to be just about right).
This is a port of #38774 to Joomla 4.3. The former will not be merged into J3. This PR was requested by @obuisard on behalf of the production leadership.
Common instructions
name
= files_joomla
to have a fake version, e.g. 4.2.0. This requires editing its manifest_cache
to read, for example, {"name":"files_joomla","type":"file","creationDate":"2022-07","author":"Joomla! Project","copyright":"(C) 2019 Open Source Matters, Inc.","authorEmail":"admin@joomla.org","authorUrl":"www.joomla.org","version":"4.2.0","description":"FILES_JOOMLA_XML_DESCRIPTION","group":""}
Test 1
Makes sure that updates without any further configuration still work (with chunked downloads).
Test 2
Makes sure that non-chunked downloads work.
Test 3
Makes sure the fine-tuning settings work.
Please select:
In docs.joomla.org the following section needs to be added
Joomla needs to download a rather big update ZIP package from Joomla's update servers. The size of the package depends on the version you're currently on and which is the latest version. Update packages can be as small as 1 MiB for small updates between consecutive patch versions (e.g. 1.2.3 to 1.2.4) or as big as around 30 MiB when upgrading to a new major version.
The Joomla Project is using a variety of file hosting platforms to make sure that these downloads are generally speedy. However, the download may not be going very fast because of a network issue, or simply because the server is behind a slow connection (as is the case with sites installed on your local computer if your Internet connection has a low speed or is on a congested network). To work around this problem, Joomla Update starting with Joomla 4.3.0 downloads the updates in smaller chunks and waits a little bit between each successive download. When all chunks are downloaded the update proceeds as per usual.
By default, Joomla downloads 10 MiB at a time and waits 2 seconds between each download. You can change that by going to System, Update, Joomla, clicking on the Options button, and going to the Fine-tuning tab. You will find the following options:
Remember, you cannot go wrong with these settings! If the download fails you can tweak these settings are described above until the download completes. Before the download completes there is absolutely no change made to your site. Therefore it's safe to change these settings, even if it takes several tries to get a successful download. Nothing on your site breaks by tweaking these settings.
This PR introduces 19 new language strings.
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_joomlaupdate Language & Strings Repository NPM Change JavaScript |
Labels |
Added:
Language Change
NPM Resource Changed
PR-4.3-dev
|
Please read your screen. Your problem is that the update.php file was not created. This code has not been touched by this PR.
Please read your screen. Your problem is that the update.php file was not created. This code has not been touched by this PR.
Anyway, but my problem is caused by this PR. I wrote that you can install a new package with this PR or a nightly build and then a package with an update from this PR. Therefore, in the 2nd case, I have the opportunity to install the service pack with this PR, but only 1 time, because in all the following cases I will receive an error.
Moreover, it is easy to check this by installing any other service pack from another PR - you can do this countless times. And only when you install the service pack with this PR again will the error appear.
I don't know what exactly is causing the problem, but it is related to this PR in some way.
Thanks for the info, I can now understand better what is going on. The root cause is definitely somewhere else.
The form in tmpl/joomlaupdate/update.php was using view=joomlaupdate even though it will ever call task=update.download — which needs to render view templates from the update view. It worked up until now because this was a silent task (no HTML output, it just issued an HTTP redirection).
Knowing that I had build that component with one controller, one view (as it should be) I changed the UpdateController's display() method with a hardcoded view.
However, this broke the extraction because the extraction in Joomla 4 never used the Joomla\Component\Joomlaupdate\Administrator\View\Update\HtmlView view controller, it always used \Joomla\Component\Joomlaupdate\Administrator\View\Joomlaupdate\HtmlView because the extraction was using the wrong view all along
So, I had to revert my change and modify administrator/components/com_joomlaupdate/tmpl/joomlaupdate/update.php with the correct form name.
I will push these changes shortly.
After this PR is merged I will have to make a new PR to shape up the internals of JoomlaUpdate. Each of the actions it takes needs to be a separate view with a separate controller, view controller, and tmpl subdirectory. The way this is currently all thrown together both on the PHP and the JS side makes it super hard to work with as nothing is what it is labelled to be. It's less like developing software and more like Indiana Jones and The Temple of Doom.
In addition, I will report that so far I have never been able to update - the process hangs and does not depend on enabling or disabling new options.
Perhaps I am doing something wrong. I edit the version to the old one in libraries/src/Version.php
and in the database (manifest_cache
, only ID 224 in table #__extensions
, 700 is for Joomla 3), then I try to upgrade to 4.3, but the process hangs every time. I tried 3 times.
Please check someone else.
@Kostelano The report about the icon is valid; there was a typo in the icon name.
I cannot reproduce your issue about the update not running. The only thing I can think of is that you have a browser cache problem, something very likely if you have tested any Joomla 4.3.0 development PR in the same site in the past.
In my test I created a brand new site using the installation package of this PR. I changed the #__extensions
table and the libraries/Version/Version.php
file per the testing instructions (which I just edited to clarify EXACTLY what I am doing), set the update source to testing and minimum stability to development and searched for updates. It found 4.2.5-dev. It downloaded and installed it just fine.
Note: the development builds of Joomla are served from GitHub which does not support chunked downloads. Even if you enable chunked downloads you will not see the progress bar moving. This is intentional and prevents Joomla Update from failing when installing dev builds ;) If you want to see chunked downloads in action please use the normal update source to find a stable Joomla release. Stable releases are served from a CDN which does support chunked downloads.
Category | Administration com_joomlaupdate Language & Strings Repository NPM Change JavaScript | ⇒ | Administration com_fields com_installer com_joomlaupdate Language & Strings Repository NPM Change JavaScript Front End com_content Libraries |
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-12-07 12:24:39 |
Closed_By | ⇒ | nikosdion |
Status | Closed | ⇒ | New |
Closed_Date | 2022-12-07 12:24:39 | ⇒ | |
Closed_By | nikosdion | ⇒ |
Status | New | ⇒ | Pending |
I am not going to be contributing to this project anymore. I won't be replying to any questions or making any changes until then. I will close any outstanding PRs and delete their code on December 31st, 2022. Merge whatever you want until then.
Category | Administration com_joomlaupdate Language & Strings Repository NPM Change JavaScript com_fields com_installer Front End com_content Libraries | ⇒ | Administration com_joomlaupdate Language & Strings Repository NPM Change JavaScript |
I guess fixing the real problems people on slow connections face updating Joomla is not a priority for the project. Closing this PR.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2023-03-05 17:25:25 |
Closed_By | ⇒ | nikosdion |
Install nightly build 4.3, then package with this PR or install immediately a new build with this PR (does not matter) - then after trying to manually install the service pack we always get an error.
Does not depend on enabling/disabling new options from this PR.
Localhost, PHP 7.4.29, 10.5.15-MariaDB