Skip to content

fix: stop upgradesettings.php loop on styles upload widget (#47)#53

Merged
eXeLearningProject merged 1 commit into
mainfrom
47-fix-upgradesettings-loop
May 11, 2026
Merged

fix: stop upgradesettings.php loop on styles upload widget (#47)#53
eXeLearningProject merged 1 commit into
mainfrom
47-fix-upgradesettings-loop

Conversation

@erseco
Copy link
Copy Markdown
Collaborator

@erseco erseco commented May 9, 2026

Summary

Fixes #47 (and the duplicate #51).

After upgrading to v4.0.0, every admin login was being redirected to admin/upgradesettings.php with the Styles upload widget shown as a "new setting" — and clicking Save changes never cleared it, even when a style was selected.

Root cause

admin_setting_stylesupload extends admin_setting_configstoredfile, whose get_setting() reads the stored file id from plugin config. Our write_setting() extracts the uploaded ZIP and immediately deletes it, so nothing is ever persisted in config_plugins. As a result, get_setting() always returned null. Moodle's admin_output_new_settings_by_page() (in lib/adminlib.php, line 9231) flags any setting whose get_setting() is null as new, so the upload widget reappeared on every visit and the admin was trapped in the loop.

Fix

Override get_setting() in admin_setting_stylesupload to return an empty string. The widget itself does not need a stored value — it always starts from a fresh draft area — so this is functionally equivalent to "nothing pending" while telling Moodle the setting has been seen. write_setting() keeps behaving exactly as before.

This mirrors the pattern already used in admin_setting_embeddededitor (the embedded-editor management widget), which solved the same problem the same way.

Test plan

  • Fresh install of plugin: visit /admin/upgradesettings.php?return=admin — the Style packages (.zip) row no longer appears as a new setting.
  • Click Save changes in the regular plugin settings page (Modules > eXeLearning Web): the form saves cleanly and does not bounce back to upgradesettings.
  • Drop a style ZIP, save: the ZIP is extracted and the upload widget shows the new entry under Uploaded styles.
  • Drop a second time: install errors are still surfaced via \core\notification.

Sibling PR

Same fix on the SCORM side: exelearning/mod_exescorm#68 (issue exelearning/mod_exescorm#66).

Closes #47. Closes #51 as duplicate.

`admin_setting_stylesupload` extends `admin_setting_configstoredfile`,
whose `get_setting()` reads the stored file id from plugin config.
Our `write_setting()` consumes the dropped ZIP and removes it, never
persisting anything in `config_plugins`, so `get_setting()` kept
returning `null`. Moodle's `admin_output_new_settings_by_page()` flags
any setting whose `get_setting()` is null as "new", redirecting every
admin login to `admin/upgradesettings.php` and re-rendering the widget
no matter how many times "Save changes" was clicked.

Override `get_setting()` to return an empty string so the setting is
never reported as new. The widget always builds a fresh draft area, so
no stored value is needed for rendering, and `write_setting()` keeps
behaving exactly as before.
@eXeLearningProject eXeLearningProject merged commit fab506b into main May 11, 2026
1 check passed
@eXeLearningProject eXeLearningProject deleted the 47-fix-upgradesettings-loop branch May 11, 2026 08:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

upgradesettings.php issue Error finishing plugin update

3 participants