I’d like to add a personal story. My mother was born in a displaced person’s camp in Aachen, Germany just after the WWII ended. Her parents, my grandparents met while living in a slave labor camp. So, I feel quite strongly we should have nothing to do with a site owned by literally a nazi. For anyone who wants to try to defend him as oh, he’s autistic; so am I, and I have never accidentally or intentionally saluted to fascists. https://thedailytism.com/the-autistic-guide-to-waving-exuberantly-withou...
Yes, get off of both. Seeing as how Twitter and Facebook now allow activity that is in violation of D.O's own code of conduct, this shouldn't even really be a discussion.
https://www.drupal.org/dcoc: →
Specifically:
- "Sexist, racist, homophobic, transphobic, ableist, or exclusionary statements, regardless of intent",
- "Intentionally misidentifying, misgendering and/or “deadnaming” an individual"
to name a few
failed at git-fu. Here's the correct patch.
I've updated existing tests for 10.x and all unit tests now pass for me locally. Unfortunately, I'm not able to apply this to 11.x and create a MR at this point.
present
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.
I'm running drupal core 8.6.13 where the patch from #2947291 has been committed. The same change is needed, but to devel.module, not bootstrap.inc in drupal core. Here's a patch.