Wrong url for update.php when domain module working.

[izmeez]

With the domain module working, when there is a need to run /core/update.php such as from Backdrop 1.29.0 to 1.29.1 login to the primary domain, going to the Status Report and clicking the link to run update fails because it is trying to reach the wrong url /core/core/update.php.

Disabling the domain module by commenting the line in settings.php file to include domain/services.inc allows the update link to work and uses the correct url.

Subsequently, when the line in settings.php is again uncommented and the site refreshed (clear caches), user has to login again. Something to be expected?

[rudy880719]

@izmeez Yes, it is normal behavior, since an update was made, and it will ask to log in again

[yorkshire-pudding]

I'm not worried about the logging in again, but it does seem like a bug that it goes to the wrong URL and I think this is a problem as it effectively makes it impossible to do updates completely in the UI, which is a key feature of Backdrop.

[izmeez]

Agree: logging in again may be an artifact of changing the settings.php file; the key problem is the wrong url for update.

[sudipto68]

@izmeez I can also reproduce this issue. But in the module's upgrade.txt file and also in the install_quickstart file it is written that when we need to update the site we need to remove that line from the settings.php file.

When upgrading, follow the additional steps below to ensure that the required
changes for Domain Access do not interfere with Drupal's update process.

-- Remove the Domain Access include line from settings.php.

[yorkshire-pudding]

@sudipto68 @izmeez @stpaultim @rudy880719
I think it is important that we try to overcome this for Backdrop. Breaking the update process to me seems like a real problem for a contrib module.

Perhaps we need wider support from people in the community with more expertise on this one?

[izmeez]

@elisseck Thank you for the PR. I have tested it and it works for me. I have updated the labels for the issue.

[izmeez]

@elisseck The PR also appears to fix #41

[sudipto68]

@elisseck Thank you for the PR. I have tested it and it works for me too. After adding the changes, If I run the core/update.php path to manually run the update, then it works perfectly and now no need to remove the include bootstrap line from settings.php file.

[stpaultim]

Thanks to @izmeez and @sudipto68 for testing. I went ahead and merged this PR and created a beta release of the module to encourage additional testing.

[stpaultim]

And special thanks to @elisseck for submitting the PR.

[yorkshire-pudding]

Thanks @elisseck @stpaultim @izmeez @sudipto68

[izmeez]

This PR also appears to fix issue #36.