🇬🇧United Kingdom @rossb89

Just another update in regards to performance here (without patch!)

Testing out the 10.3.9 update which includes the 3.14.2 update locally on ddev with a m4 mac mini, loading up the permissions page on a project with a relatively large amount of contrib modules + permissions took about 6 seconds.

The site is hosted on Pantheon and on pantheon, a dev environment before the update was applied was also taking about 6 seconds to load the permissions page.

On a multidev environment with the 10.3.9 update including the twig update, the permissions page now takes 30+ seconds to load.

This wasn't immediately obvious that there was an actual performance issue here (locally) as ddev &/ m4 chip was masking it... but it's very much an issue with the site hosted in Pantheon :)

@lamp5 Do you think we could please get a new release cut as with the change in 📌 Ensure compatibility with the media_thumbnails 2.0 version requirement Active for media_thumbnails 2.0 compatibility means at the moment you can't install the 2.0.0 version (if you have updated media_thumbnails to 2.0.0) of the module due to the composer dependency on media_thumbnails:^1.0.

We have to rely on a dev hash of the 2.0.x branch in order to get this module installable at the moment (a composer patch is no good either as the dependency is checked before a patch is applied, blocking install).

Thank you in advance :)

rossb89 → created an issue.

Made a new MR for this as the previous branch for this ticket hadn't been setup properly.

rossb89 → changed the visibility of the branch 3343987-missing-config-schema to hidden.

rossb89 → changed the visibility of the branch 3343987-missing-config-schema to active.

rossb89 → changed the visibility of the branch 3343987-missing-config-schema to hidden.

I can confirm the changes do what @scott_euser states in comment 36, marking as RTBC.

Updated the merge request to merge in the latest 2.x changes.

Can't use a patch file generated from that with composer as it includes modifications to the tests directory contents which is actually specified in the .gitattributes file to export-ignore:

/tests export-ignore

So to use this currently (on beta10) (before this MR is hopefully merged in at some point), you'll need to use the patch here made by @ershov.andrey.

rossb89 → made their first commit to this issue’s fork.

Just had the same issue as above, the update hook deletes the latest exchange config but the other config file doesn't get it's dependency updated as part of config export so you need to manually edit to remove the dependencies section.

I've update the MR with the following:

• * merged in the latest changes from 8.x-1.x so there are no merge conflicts at time of writing
• * fixed the config type values in the imagick.config.yml
• * added the missing properties to the imagick.schema.yml
• * made the suggested change of moving (and modifying) the check to skip processing if garage collector is disabled, into hook_cron instead of being within the service itself.

rossb89 → made their first commit to this issue’s fork.

rossb89 → created an issue.

8.1.x isn't a supported version any more, The MR should be changed to be based against 2.0.x.

At the moment there are far too many changes reported because of being based on the 8.1.x branch.

For a view of the fork against 2.0.x where you can see the actual changes, https://git.drupalcode.org/issue/disqus-3296968/-/compare/2.0.x...329696...

@firewaller Yes, you'd have to remember to uninstall the module manually as part of the 10.3 upgrade.

Ah yes, I totally should have done this against 2.x! Thanks for approving, merging in and doing a new release!

I guess this issue can be marked as fixed now? I see 1.x isn't visible on the project homepage anymore.

I had completely forgotten about this!

I've re-done this against the latest 8.x-1.x with the suggested change to check the language module exists before trying to load the config.

I have opened a MR, but will attach a patch just in case that is useful for anyone.

Agreed. The work here that was committed in 10.2.x, 10.3.x, 11.x is absolutely needed, but i'm still having issues with the actual value.

Inside here:

if (!empty($info[$this->operator]['values'])) {
  switch ($info[$this->operator]['values']) {
    case 1:
      if ($value['value'] === '') {
        return FALSE;
      }
      break;

    case 2:
      if ($value['min'] === '' && $value['max'] === '') {
        return FALSE;
      }
      break;
  }
}

for grouped (checkbox?) input, $value is this:

array (
  1 => '1',
)

which causes the error still as there is no 'value' key to check against for this grouped exposed input value.

Patch 175 which is a re-roll of 48 actually checks to inspect $value to make sure that the expected keys are there which seems to be what's needed in some circumstances?

There is another issue here in relation to this though... where ViewsExposedForm::submitForm() https://git.drupalcode.org/project/drupal/-/blob/10.3.x/core/modules/vie...

seems to declare an $exclude variable at the top of the function, which is added to if acceptExposedInput() returns false but then immediately beneath this outside of the loop, it's declared again (with the same initial keys) which overrides any entries that were added by this loop!

So you can get into a weird situation where the handler for the exposed input returns false, but then beneath it can still be processed as it's no longer inside of $exclude... which in my circumstances is actually useful as I want the exposed filter value to be valid... but technically it shouldn't be doing this!?

Maybe someone with some more knowledge around this could provide some insights about the data structure of grouped $value's and how this is expected to work without the additions in patch 175...

Hi @AaronBauman , is there a planned release date for the 5.1.1 release? I ask as this issue here is the last blocker for a client's site to go to 10.3

rossb89 → changed the visibility of the branch 3458322-file-datafetcher-plugin to hidden.

rossb89 → created an issue.

There shouldn't be a reason why @entity_type.manager isn't injected.

Rebuilding the cache with `drush cr` should solve this.

Saying that, I just had a wild goose chase on a local multisite environment which was having this issue... It turns out I had a misconfiguration in sites.php referencing old port numbers in the aliases that weren't in use... so the site that I was rebuilding the caches for in drush wasn't actually the site that I I was hitting accessing the site via the URL....

Once I resolved that, this was a non issue after rebuilding the caches.

The patch in #5 although improving documentation around the __constructand changing member visibility from private to protected, doesn't actually do anything to solve this issue.

The patch in #11 is a bit of a hack but if someone is encountering this issue even after rebuilding caches and can't get it working should potentially solve it...

Re-roll of patch 6 for 4.0.1 with d10 compat.

rossb89 → created an issue.

This is working better with 10.2.x, thanks!

Thanks @wolffereast for the quick fix patch. Will do for now to stop the crazy button sizing till another solution comes along :)

From a quick test it appears that patch #7 works fine and the warning message on the text format configuration screen is no longer displayed. 👍

Did a few more tweaks to the work here in MR-92 to get tests passing, which they are now!

rossb89 → changed the visibility of the branch 2901579-selective-html-stripping-2.1.x to hidden.

rossb89 → changed the visibility of the branch 2901579-selective-html-stripping to hidden.

I've redone the last MR (68) as the rebase wasn't done correctly and it appeared to contain duplicated code that was already in 2.1.x...

I've done a new clean MR (92) with the patch re-rolled which is working nicely 👍

rossb89 → changed the visibility of the branch 2901579-selective-html-stripping-2.1.x to active.

rossb89 → changed the visibility of the branch 2901579-selective-html-stripping-2.1.x to hidden.

Looks like this was included in 4.3.3, can this issue be marked as Fixed now?

It looks like it was committed without the `$saved_config->isNew()` line, so is this all feature complete now?

I've added a merge request containing the same code in the patch provided in comment 2 by mediabounds.

rossb89 → made their first commit to this issue’s fork.

Yup, patch in https://www.drupal.org/project/crop/issues/3293782 🐛 Crop API is not appending a hash when the image styles are converted to WEBP Needs review is the one for webp.

Patch is working great, thanks!

Actually, further inspection reveals that I don't think the solution in MR-23 is quite right.

There is no reason that I know of that the block ID has to be unique *across* contexts.

At the moment the patch is loading up every context and making sure the block ID is unique across all of them... which is causing problems for me, as I need to re-use the same block instance across multiple contexts.

With the 'unique' option on the context block anyway, I don't think that we need to be so heavy handed in checking the ID is unique across *all* contexts...

MR-23 still applies against 5.x and solves the issue :)

rossb89 → created an issue.

Another vote for RTBC.

This patch works great and does indeed solve search not working and the once issue from the other issue.

@liza if you go to the merge request link in this node (https://git.drupalcode.org/project/context/-/merge_requests/36)

In the top Right hand side you'll see a blue select list dropdown titled 'Code'.

Click that, and under the 'download' click 'Plain diff' and that will give you a patch file. You should name it something appropriate rather than just 'mr-36.patch'.

You should then add e.g. a patches folder in your project (at the top level, outside the webroot), and in composer.json reference the patch from within there. E.g.

"Search is broken when placing block MR-36 ( https://www.drupal.org/project/context/issues/3374119 🐛 Search is broken when placing block RTBC )": "patches/the-name-of-the-patch-file.patch"

You technically could hotlink directly to the patch URL BUT if the code changes at all within the merge request then next time you ran composer install you'd get any changes that may have been made, which could cause issues with broken code, etc so it's highly recommended to NOT directly link to the patch from the merge request.

Re done the patch with the additional logic check requested above :)

This is great! I realised that javascript was being used to render this facet style ... which was no good for us on this project which is making heavy use of tailwind and associated templates.

The patch applies cleanly and appears to do what it say on the tin, so far so good.

Looks like this has been fixed at some point, it's at least in 8.1.6.

I've given this a test out locally and seems to do the trick and the module is working on D10.

I haven't tested the tests as it were, but this gets the module installing.

Again, +1 on patch #8 in lieu of this being fixed in core by [#15200716-74].

I've tested this out locally with the latest patch -17 and it appears to be doing exactly what it says on the tin... great work!

I've just created a new MR and re-rolled the patch against the latest dev as it's been a year since the last one was done and didn't apply any more.

rossb89 → made their first commit to this issue’s fork.

Can you elaborate on why the patch didn't work to resolve the error? I just tested it locally on 10.1.x and the error was resolved. Is it not working in 11.x then?

Patch works fine and MR-2 applies fine against 3.x.

I updated MR-11 with the latest changes in 3.x as it was a bit out of date and not mergeable.

I'm not quite sure why we have both MR-1 *and* MR-11 though?

rossb89 → made their first commit to this issue’s fork.

Looks like this ticket and 🐛 Fix deprecation notices RTBC are the same issue, we should close one of them and aim to get one merged in.

This issue appears to be trying to solve the same as this issue https://www.drupal.org/project/field_group/issues/2969051 🐛 HTML5 Validation Prevents Submission in Tabs Postponed: needs info .. I don't think we need two issues open trying to solve the same thing, unless i've missed some difference?

This patch from https://www.drupal.org/project/field_group/issues/2969051#comment-15022271 🐛 HTML5 Validation Prevents Submission in Tabs Postponed: needs info in that issue appears to solve the issue as far as I can see from my testing with 9.5.x.

We were previously using patch 60 from this issue on a project which at some point in the last year and a half seemed to stop working in all circumstances. Patch 99 (from comment #100) in the other issue (2969501) is working nicely though.

Yup this patch works great, lets get it merged.

Thanks for the work here. I also had the same issue as @kubokura in that I need this patch and the MR patch from #3269746 as well really and they are both modifying the same line.

I've created a combo patch if anyone finds they need both patches really (I can't see why you wouldn't need both!) which will suffice until such time one is merged and then the other can be patched cleanly and merged :)

Thanks @james.williams This looks promising but unfortunately I encountered an issue when using Migrate Tools:

Fatal error: Declaration of Drupal\migrate_tools\IdMapFilter::lookupDestinationIds(array $source_id_values): array must be compatible with Drupal\migrate\Plugin\MigrateIdMapInterface::lookupDestinationIds(array $source_id_values, bool $skip_unmigrated = false)

In @migrate_tools/src/IdMapFilter.php:195@ there is a declaration of

  public function lookupDestinationIds(array $source_id_values): array {
    $map = $this->getInnerIterator();
    \assert($map instanceof MigrateIdMapInterface);
    return $map->lookupDestinationIds($source_id_values);
  }

which would also need to be modified to handle the extra parameter, to work in conjunction with this patch.

I have just encountered this very issue this morning and couldn't figure out what the problem was intially.

My issue turned out to be the same as you have detailed in the original post:

If I have the following preprocess function: THEME_preprocess_field__paragraph__field_name()
and no template for field--paragraph--field-name
but do have a template for field--paragraph--field-name--bundle
the 'non bundle' (less specific) preprocess function will be available in the theme registry and apply to the more specific template.

If you do have a template as well for field--paragraph--field-name in addition to field--paragraph--field-name--bundle the theme registry then doesn't then have the 'non bundle' (more generic) preprocessor THEME_preprocess_field__paragraph__field_name() available.

The ksort in the patch does indeed fix the issues found and cause the order to be sorted and consistent.

Although @mdupont has a valid point here in that maybe we should be adding an additional key the options param of FileSystem::scanDirectory()...

rossb89 → created an issue.

I've changed the check to use a preg_replace ensuring the base_path() is at the start of the string (a bit safer than just the str_replace).

For version 2.0.6.

Re-rolled for latest 9.5.x