Open dreistromlandMf opened 2 months ago
Thanks for opening this issue. We will investigate this as soon as possible .
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.
We have solved that internally via a CollectReasonsWhyTheRecordIsNotPublishable event listener. In there, we compare the source_host of the SysRedirectDatabaseRecord against the domains from Sites.
I don’t think the solution we currently deploy can be used 1:1. We ensure that the domain is different than the Sites on local. If it is the same as any local site, we abort publishing. I am not sure this would work on instances where local is on the same domain, but a different path. I would thus recommend ensuring that the domain is the same as a foreign site, instead.
The solution has been deployed on production for some time now. We did not have any issues since.
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.