🇬🇧United Kingdom @dahousecat

Thanks for the fix here halth - I've updated the test and applied your changes in version 1.0.5.

I fixed this by removing the force attribute from env name="SIMPLETEST_BASE_URL"

dahousecat → created an issue.

Whilst category is not being used for anything, it's not breaking anything either. So see no harm in just leaving as it is.

block_field is not using a translated string for @FieldType category, but instead @Block, which is still translatable.
So this ticket should be closed.

dropdown_language is not using a translated string for @FieldType category, but instead @Block, which is still translatable.
So this ticket should be closed.

entity_usage is not using a translated string for @FieldType category, but instead @Block, which is still translatable.
So this ticket should be closed.

google_tag is not using a translated string for @FieldType category, but instead @WebformHandler, which is still translatable.
So this ticket should be closed.

lb_tabs is not using a translated string for @FieldType category, but instead @Layout, which is still translatable.
So this ticket should be closed.

masquerade is not using a translated string for @FieldType category, but instead @Block, which is still translatable.
So this ticket should be closed.

Actually I take it back, pathauto is using category for @AliasType, which doesn't appear to even have category defined.

dahousecat → created an issue.

dahousecat → created an issue.

dahousecat → created an issue.

dahousecat → created an issue.

dahousecat → created an issue.

dahousecat → created an issue.

dahousecat → created an issue.

Patch #42 for accessible-slick is not right as it uses

typeof _.options.responsive !== 'array'

which should be

!Array.isArray(_.options.responsive)

See https://github.com/Accessible360/accessible-slick/issues/103 for a patch that includes the above.

If you are using accessible-slick with Drupal 11, and therefore jQuery 4, you will need to patch the library to remove calls to $.type.
See the patch here: https://github.com/Accessible360/accessible-slick/issues/103

I was getting this error on /admin/config/development/performance with $key config_override_status_messages which comes from Drupal\Core\Form\ConfigFormBase.

Patch #14 applied and resolved the issue for me.

Some Drupal coding standards fixes slipped into this patch too as my linter got a bit carried away when I wasn't looking :)

dahousecat → created an issue.

Rerolling patch #80 for Drupal 11

I don't think the latest patch is working.
When I update a fields "Skip this field for translation check" the value does not persist.

Patch #5 did not apply on D11 so have re-rolled

dahousecat → created an issue.

Ticket version updated.
I should have a chance to get some steps to replicate together today (or at least this week) so will update again then.

Re-rolled to work with D11

I just encountered this issue and found that the SimpleMathField class is a bit flakey.

getFieldValue says it returns mixed, but then the return value is used by functions like preg_match and strpos without first checking the type.

I suspect really getFieldValue should define it's return type as string and probably log an error if it tries to return something that is not.

However I've just gone for a very light refactor in this patch introducing these changes:

- In removeSeparator if $data is not string just return $data.
- Re-write the whole part where if it's a commerce price field.
- Add an additional is_string check before calling preg_match.

It looks like the patch from ivanpg94 would also fix this bug but I only came across this ticket once I'd already written my own patch, which does include some additional safety checks.

Ha, I realise I've named the patches "view_data_export" but I promise really they are for this module.

dahousecat → created an issue.

Last patch was missing most the content.
I've also just reformatted the whole file to conform to Drupal coding standards in this patch and fixed the remaining call to drupal_set_message.

dahousecat → created an issue.

dahousecat → created an issue.

dahousecat → created an issue.

dahousecat → created an issue.

dahousecat → created an issue.

dahousecat → created an issue.

dahousecat → created an issue.

Actually the fix from #19 was needed too.

I've attached the final patch I ended up using.

Patch #23 applied on 10.2.12 and fixed the issue of the page not saving.

Great suggestion for improvement and good implementation.
Approved and merged.

I needed to ensure that this was 100% accessible, and I was getting confused about the nested a in the li, so decided the only way to be sure it was correct was to just match the HTML from the example page here: https://www.w3.org/WAI/ARIA/apg/patterns/tabs/examples/tabs-automatic/

So the tablist should be a div, with each tab being a button.

This involved updating QuickTabs.php to adjust the html output, and also updating the JS to work with the updated html.

I've also added a setOptions method to the QuickTabsInstance as this allows for programmatically setting the label before render.

Patch would not apply due to the "Information added by Drupal.org" bit.
Re-rolled to include that.

dahousecat → created an issue. See original summary → .

Here is the update as a patch

Patch #8 works well for me

Applies cleanly and makes module D11 compatible.

Patch #3 applied cleanly and after this updb was able to complete and views_post_update_pager_heading() did not error.

In my instance $this->value was set to 'menu_link_content' so not an array.

dahousecat → created an issue.

None of the patches above apply.

There should be a captcha.settings for just a globally enabled flag. This could then be overridden via local settings file.

I've updated the schema, default settings, SettingsForm and captcha_form_alter to add this setting - see provided patch.

Once the patch is applied you can add $config['captcha.settings']['captcha_enabled'] = FALSE; to your local settings file to override the config.

Patch #2 didn't apply due to the Information added by Drupal.org packaging script on 2024-01-10 bit so I created this one.

It's a good question - but I am not sure in this instance.

But it's clearly something that can happen.

Any call to entity storage load can either return an EntityInterface or null, and any calls to this method should be able to handle either scenario without causing the whole site to run into a fatal error.

This is just good defensive programming.

Created a stable release and opted in to security coverage

Thanks Scott - runs fine locally.

Really appreciate you adding this test.

100% agree - will wait till the end of next week.

I did not know about the margin-inline-end css property so thanks - I will find that useful in a number of other projects I have going on.

However from my testing it was not creating the gap as required, as least with the rest of my theme present, so I have use grid-gap instead, as it will consistently place the margin between the 2 elements, regardless of text direction.

Thanks Scott, that is super helpful.

I just merged my first MR on drupal.org and credited you.

Thanks again Scott, I totally missed that.

If your happy to complete that then i would be very grateful.

I'm a bit new to MRs on drupal.org - if you could give me any pointers on how to merge then that would be super helpful!

This is next on the to-do list but I'll need to complete this task in my own time so will have to wait for now.

Changes look good - I've updated the widget.

Thanks for raising this ticket.

I've now added a schema.

See https://git.drupalcode.org/project/entity_reference_field_autocomplete_f...

Good spot, thanks.

The widget already had

if ($selectedBundle) {
    $element['target_id']['#selection_settings']['target_bundles'] = [$selectedBundle];
}

so I just needed to add:

else {
  // Limit to the bundles defined in the field settings.
  $element['target_id']['#selection_settings']['target_bundles'] = $enabledBundles;
}

See https://git.drupalcode.org/project/entity_reference_field_autocomplete_f...

Hi Scott, thanks for taking the time to review this - much appreciated.

Added composer.json

https://git.drupalcode.org/project/entity_reference_field_autocomplete_f...

dahousecat → created an issue.

Patch #37 didn't apply for me.

I'm hitting this bug by trying to edit a computed field with no schema.

I've created a very simple patch that just checks if there are any columns before creating any applying the orConditionGroup.

I added that fix but then got error:

Warning: Undefined array key 0 in Drupal\commerce_product_quantity\Form\ProducttypeForm->validateForm() (line 207 of modules/contrib/commerce_product_quantity/src/Form/ProducttypeForm.php).

So added a fix for that too and can now add product types without any warnings.

dahousecat → created an issue.

dahousecat → created an issue.

$context['resource_type'] is set in entity_share/modules/entity_share_client/src/Service/JsonapiHelper.php from the return value of ResourceTypeRepository->getByTypeName()

This will return null if a resource type is not found with that name.

Just showing the user which name returned null, and possibly a list of valid names, would go a long way to helping debug what the underlying issue is.

E.g.

if (!$resourceType instanceof ResourceType) {
  $allTypes = $this->resourceTypeRepository->all();
  $args = [$data['type'], implode(', ', array_keys($allTypes))];
  throw new \InvalidArgumentException(vsprintf('ResourceType with name %s not found. Valid names are: %s', $args));
}

After I added this code when when syncing entities that fail I now get an error like:

ResourceType with name node--region not found. Valid names are: batch_plugin_entity--batch_plugin_entity, block--block...

This patch is against the 2.1.x branch as I had issues running the dev branch.