-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
4.4.4, 4.5
-
2
-
Team Dragons 2025 Sprint 1.2, Team Dragons 2025 Sprint 1.3
It is common practice to:
- Clone/copy a production site to a staging or non-production site, for testing etc.
- Promote by copy/clone a staging site to production
In both cases these sites will have the same data (DB and filedir) but will have a different URL. Also the production site could be registered.
Currently, it appears that the registration process does not recognise the cloned site as being different from the original site. In cases where the original site is registered.
This leads to a workflow where the options are to update the registration of the cloned site, or unregister the source site.
Instead, the options should be to register the cloned site or skip registration. Which is the same workflow for a newly installed or unregistered upgraded site.
In the less common case where a production site has changed URL's, it isn't necessary to explicitly accommodate this workflow. If the site is registered (as a new site) the admin still gets the benefit of registration. The registration database will mark the original URL as an unreachable site after a period of time and the new registration data from the site will be added to the database. So there is not net difference.
In cases where a non production site is constantly/regularly updated from production. To save the non production site from displaying a registration prompt, admins have the existing option to set: `$CFG->site_is_public = false;` in the config.php file.
- will help resolve
-
MDLSITE-7710 Enable admins to register their site without having to ask for an existing registration to be deleted
-
- Resolved
-