Projects installed by selecting an older version via the project installer cannot be updated via the UI

[klonos]

Description of the bug
Projects installed via the project installer cannot be updated via the UI.

Steps To Reproduce
To reproduce the behavior:

1. Start the installation of a module via the Project Browser.
2. During the "Select versions" step, click on the "change release" link, and select to install an earlier version of the module, rather than the latest one.
3. Install another module; also earlier version than the latest, but this time install it manually, by downloading and extracting the .zip file in the modules directory.
4. Go to /admin/modules/update and try to update the modules as per usual...

Actual behavior
The update process finishes successfully, w/o any errors 👍 ...but when you check the "Available updates" page, only the module that was installed manually is updated; the module that was installed via the Project Installer is still in the older version 👎

Expected behavior
Modules installed via the Project Browser/Installer are updated to the latest version when updating via the admin UI.

Additional information
I have tested this with enabled/disabled projects; with modules/themes/layouts; with the site online vs in maintenance mode; selecting to update a single outdated module at a time, or multiple ones simultaneously. The outcome is that modules installed via the Project Installer are not updated.

[klonos]

I have tested this with:

• webform 1.x-4.19.3 -> 1.x-4.20.0 (installed via the UI - update finishes w/o errors, but fails) 👎
• backup_migrate 1.x-1.0.13 -> 1.x-1.0.14 (installed via the UI - update finishes w/o errors, but fails) 👎
• rules 1.x-2.1.0 -> 1.x-2.1.1 (installed manually - updated successfully) 👍

[laryn]

I've tested updating via the Project Browser with some modules that were already installed on a dev site. I assume they were installed manually but can't recall for certain.

• field_multiple_limit 1.x-1.0.3 -> 1.x-1.0.4 (successful)
• job_scheduler 1.x-1.1.2 -> 1.x-1.1.3 (successful)

[klonos]

Trying to figure out what could possibly be different in installing manually vs via the admin UI. Could it be that the Project Installer does not set proper permissions when extracting the module files? ...and if so, then why aren't we picking that the update did not actually happen?

[indigoxela]

I can confirm, there is a problem with updates, but it has nothing to do with permissions. File permissions are fine.

Backdrop does download the project and extracts it to tmp, but it downloads the outdated version again. Hence the old version gets replaced with the same old version.

Check your temporary folder for the update-extraction-XXXX dirs and check the .info files in there.

Either the way the most recent version url is constructed fails, or we maybe get fooled by the update cache. Flushing it didn't help, though. Neither does running cron.

I've been testing here with googleanalytics and webform.

[indigoxela]

I guess, it's related to the update_cache.

The full project download url gets saved to the database. Table "cache_update", column "data". These database entries have "expire" timestamps.

If I manually set such an expire timestamp to now in the database, then flush the cache (not sure about that), the update to the most recent version works.

[klonos]

Thanks for digging into this @indigoxela ...I intent to have a look too when I get a chance, but your investigation helps 👍

[jenlampton]

Since this issue has a bug-fix milestone, but does not have a PR, that means it must be a high-prioroty bug, so I have added it to the Bugs Project, on the High Priority list. @klonos if you don't think it belongs there, please also remove the milestone :)

[ghost]

Since this issue has a bug-fix milestone, but does not have a PR, that means it must be a high-prioroty bug

I don't see that criteria on https://backdropcms.org/user-guide/adding-milestones-to-issues... Does that page need updating to reflect this?

Based on the currently-documented criteria for bug-fix milestones, I don't see this issue as being eligible without a PR, so removing milestone.

[yorkshire-pudding]

I have confirmed this odd behaviour while testing the PR for #3245:

• Installing an older release via manual installation via the UI prevents it, with a silent fail, from updating
• Installing by downloading the older release zip and unpacking into the modules folder fixes it

While it is rare for people to manually install the older release, it is possible through the UI and the fact that this silently fails is a problem. As this only happens if the older release is done (I've installed loads of modules through the UI, but always the recommended release), I'm going to change the title to reflect this.