-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sys_redirect with same source_host may prevent synching across systems #118
Comments
Thanks for opening this issue. |
It looks like this can cause further issues: If a redirect has changed but the site is not resolvable, the source_host on foreign will change to the local url. This not only breaks the redirect, but also causes the original reported issues to happen sooner or later. I have been able to produce such behaviour by changing the path segment of a page containing disabled pages. The newly created redirects for the disabled subpage don't have a site and apparently cannot be resolved. |
Assume you have a sys_redirect where every field, including the source_host, is identical on booth systems. This may be because you transfered one database backup to booth systems.
This will be cought by
SysRedirectDatabaseRecord::calculateChangedProps
- it doesn’t make sense that booth system have the same source_host, so in2publish assumes that booth have been reset onto the local system and foreign needs to be updated. The props are identical at this point.In this case
RedirectSourceHostReplacement::replaceLocalWithForeignSourceHost
will attempt to figure out the URL based ontx_in2publishcore_foreign_site_id
,tx_in2publishcore_page_uid
, ortarget
. Assume that the first two don’t yield results, and that the target also does not exist on the foreign system. This would mean the function returns at line 118. The properties would not be changed in this function either, there are still no changes to be published.Nontheless, the publishing resumes. There is no further check if the props are identical in all systems.
DatabaseRecordPublisher::publish
produces an empty array of changes and proceeds to issue an update. Doctrine will do as told and produce anUPDATE `sys_redirect` SET WHERE `uid` = ?
with no values after SET, which the database does not like. This results in a failed database query, which results in an abnormal end of the program flow at this point with an error message indicating an SQL error.Even tho this is produced by an inconsistent database due to bad deployment practices, it’d probably be a good idea to at least produce a more meaningful error message. Or check if the props are empty at some point after the source_host should have been updated and not attempt the change.
The text was updated successfully, but these errors were encountered: