Support #13134
closedNew site (a clone) point to old dashboard
0%
Description
Steve Brier cloned a site to create the new site 'F20 Historical Perspectives on Urban Education - https://f20urbedhistory.commons.gc.cuny.edu
But clicking Dashboard gets you back to the original site - https://f19urbedhistory.commons.gc.cuny.edu/wp-admin/
Updated by Boone Gorges over 4 years ago
- Category name set to Site cloning
- Status changed from New to Reporter Feedback
- Target version set to 1.17.1
I've manually updated the option values for Steve's site.
As to root cause: When the Cloning feature was being built, we decided at some point fairly late in the process to move from a list of allowed db tables for cloning to simply copying all of them with the prefix. See https://github.com/cuny-academic-commons/cac/commit/f0a0bce5cfe1394f0a1f751b888c2bfc875a28a4. But this change was too broad, because it resulted in the 'options' table being overwritten too, which defeats the purpose of our selective option-copying earlier in the process: https://github.com/cuny-academic-commons/cac/blob/d044d5f377569d2d451d53fe46e9168be3259b7d/wp-content/plugins/bp-custom.php#L3242 As such, the 'home' and 'siteurl' (as well as other values not involved in this ticket) were being overwritten with the corresponding values from the source site.
In https://github.com/cuny-academic-commons/cac/commit/cd3bf4f8c56c64152de53a914b77c80a4a82bf7b, I've made a change so that the 'options' table is explicitly ignored. This solves the 'home' and 'siteurl' problem. I can't think of any other tables that would need to be ignored explicitly, but I'm going to ask Jeremy and/or Ray to chime in here if they have any thoughts about the solution. In the meantime, I'm pushing the change to the production site as a hotfix.
Updated by Boone Gorges about 4 years ago
- Status changed from Reporter Feedback to Staged for Production Release
Updated by Boone Gorges about 4 years ago
- Status changed from Staged for Production Release to Resolved