🇬🇧United Kingdom @rossb89

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 RTBC 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 Needs work .. 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 Needs work 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