🇵🇹Portugal @dubois

breidert → credited dubois → .

This issue and 3413414 🐛 t.nodeName is undefined Active possible have a common cause but different symptoms based on core version; see https://www.drupal.org/project/module_filter/issues/3413414#comment-1539... 🐛 t.nodeName is undefined Active .

dubois → created an issue.

@tim-diels, we've been using this for a while and works as expected.

@tim-diels, I'm having a look at what upgrade would entail, and will post findings here.

@tim-diels, another use case: Sites using this module with Gutenberg.

+1 Makes sense to ignore Elasticsearch system indexes from Views.

I've also run into this issue, and taking inspiration from @zviryatko's example in #10 and the type_boost processor in search_api, I've created an type-specific boost processor for Elasticsearch. I opted for this approach instead of just adding the logic to our general custom module and keeping the search_api type_boost to avoid confusing Site Builders: the processor should only show up in the 'PREPROCESS QUERY' query stage in the UI and the inoperative search_api version should be marked as discouraged. The attached patch does that.

Does this approach make sense?

It's pretty easy to miss the radio buttons on the admin/config/search/search-api/add-index form and then end up unable to open the edit page for the index to fix one's mistake. The simple change in this module proposed by drunken monkey prevents it.

I should not have created an issue fork for this simple change. Ignore it unless things get complicated.

Here's a simple reworking of the above mentioned plugin from Search API Solr. I've focused on my indexing use case and dropped option to preserve what gets replaced and altering of queries as it is not necessary for my use case.

dubois → created an issue.

@lostcarpark, this change helps for another case: Seven admin theme with meta_position → to allow for full-width panels. Without the patch 'Scheduled moderation state change' shows up in every panel. With the patch it shows up as its own panel as expected.

Simple change, patch works, not much more to say here. Would be great to get it merged soon to avoid hook_update_N issue mentioned by @szeidler.

Change to composer.json does the trick. As @hosterholz says using issue-fork is required given the nature of the change. `composer dump-autoload` did not work on our site bootstrap.

Using the forked version requires a number of changes to composer.json:

• Update repositories section to exclude getting releases of this module and add repo pointing to fork:
  

      "repositories": [
          {
              "type": "composer",
              "url": "https://packages.drupal.org/8",
              "exclude": [
                  "drupal/domain_menu_access"
              ]
          },
          {
              "type": "git",
              "url": "https://git.drupalcode.org/issue/domain_menu_access-3372512.git"
          }
      ],

• Required the change dev branch:
  "drupal/domain_menu_access": "dev-3372512-make-compatible-with",

Module works as expected with domain 2.0.0-beta1. This is a trivial change so suggest so hope we can get it merged soon.

dubois → created an issue.

I'm not sure if this is a bug as my I've managed to get quite confused digging into how these two modules interact. Would appreciate someone a big more familiar with Gutenberg's handling of blocks/forms from other modules taking a look.

dubois → created an issue.

Not sure the problem is in this module. The ViewsBlockOverride::blockSubmit function is not called when block form is submitted via Gutenberg. The way the settings form is rendered in Gutenberg's BlockSettingsForm doesn't pick up the blockSubmit function from the class.

Patch applies cleanly and gets rid of the ReferenceError which has been muddying the waters when debugging other issues since it popped up whenever Gutenberg was unable to render a block.

Can this be merged and go in the next release, please?

@chris-maissan, your instincts are correct. Turning off --single-transaction is not the way to go. See if you can pin your tools version as per https://github.com/mysql/mysql-server/commit/022e73ba6976b984658a1c26521.... Alternatively you can give users extra rights, specifically the RELOAD privilege, until this is hopefully fixed in MySQL. Aegir should probably not change anything until we have clarity on how MySQL will proceed.

Ran into issue mentioned by @betarobot in #29. Looks like cache ID /sitemap.xml does not take into consideration the domain. Quick workaround is to disable route cache for /sitemap.xml. Better would be to dig into how Domain handles this so we can get /sitemap.xml cached per domain.