I should be able to test this last this week.
credit me
It's definitely not a drop in replacement. I'm not sure how different the two libraries are but I can say their folder structure and class names are not the same.
first
first
MatthewS → credited johne → .
I was getting likely the same error when solr was indexing content.
Fatal error: Type of Drupal\domain_access\Plugin\views\filter\DomainAccessCurrentAllFilter::$value_value must be string (as in class Drupal\views\Plugin\views\filter\BooleanOperator) in /var/www/html/docroot/modules/contrib/domain/domain_access/src/Plugin/views/filter/DomainAccessCurrentAllFilter.php on line 0
Adding this as a patch has resolved the issue.
Ah, the correct way around this is to use an issue fork that already has the needed changes.
I re-rolled this patch and it now applies to the latest in dev. However it looks like composer.lock is generated before patches are applied. So, composer.lock will not correctly list changes to the require section of this module. I had to manually edit composer.lock to be able to install 2.x of domain.
MatthewS → credited johne → .
MatthewS → credited johne → .
MatthewS → credited johne → .
I finally found out what was causing this. We had default_page_base_path: set to "form". The correct value would be "/form". On the module's configuration page, this is labelled "Default base path for webform URLs".
To fix this I needed to delete the broken aliases, update this value for the webform module and finally resave any related webforms.
It looks like webform_update_8606() tried to address this, but only in one isolation case.
Hopefully this helps someone else struggling with a similar situation.
minutes reviewed and attended meeting.