TYPO3-Solr
Fetch site base from configuration instead of getter
The TYPO3 site handling has a "base" property which is the domain of the website. But there are baseVariants that are applied if a condition is matched. That means the "base" is not really persitend and does not really identify the "site". Instead of "base" the "identifier" should be used to decide which site is currently active.
Resolves: #2578
@timohund Before i continue here i just want to ask if that is a way we can go. This would require a full reindex and also a force index cleanup as the extension does cleanups based on the site hash wich is different now.
IMHO, the base is still the right approach. I have an example:
We have hosted-solr customers, which use the same core for all their stages. Even for live and local machines.
By using the identifier all the machines will consume and mix-up the same index(sitehash/id/whatever), which will be sick and result to sudden side-effects.
@sascha-egerer You mentioned different domain name for TYPO3 Backend and indexing the records via Backend? What happens if indexing via CLI?
Can you explain a little bit more about the setup with different domain for Backend? Also which conditions are used, is it possible to access FE by BE domain? ...
@dkd-kaehm I think your arguments are arguments that support the change that @sascha-egerer proposed. For the siteHash we should use the final used domain, especially to be able to have different document versions for different stages within the same core. Otherwise, a document will always be overwritten by the last writing system. Or do I miss something?
@dkd-kaehm I think your arguments are arguments that support the change that @sascha-egerer proposed. For the siteHash we should use the final used domain, especially to be able to have different document versions for different stages within the same core. Otherwise, a document will always be overwritten by the last writing system. Or do I miss something?
The problem is if the website is indexed under 2 different domains like i've described above. In the previous version this was not a problem as the Page-Indexing was always done by the domain configured via frontendDataHelper.host which is not possible anymore. Maybe it would also be a solution to bring that option back.
And IMO indexing 2 stages into the same core is also not a really nice idea and should not be done.
And IMO indexing 2 stages into the same core is also not a really nice idea and should not be done.
@sascha-egerer I agree, just said, it is possible ;) Regarding the frontendDataHelper. It would be nice if you could check that. Just by reading the code this should still be possible. In terms of the siteHash i would say we should have one unique siteHash by site and domain.
Maybe it makes sense to add the application context to the site hash or add a optional environment variable to the site hash. So it would be possible to use the Site Identifier as "site" and use the same solr core for local / live environments.
