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.
dahousecat → created an issue.
Patch #6 applies and lets me set the from address 👍
Patch applied cleanly and fixed the error, but the then I got this error upon enabling the module:
PHP Fatal error: Trait "Symfony\Component\DependencyInjection\ContainerAwareTrait" not found in /var/www/html/web/modules/contrib/queue_stats/src/Plugin/QueueStatistic/EstimatedTimeToFinish.php on line 22
I replaced
use Symfony\Component\DependencyInjection\ContainerAwareTrait;
with
use League\Container\ContainerAwareTrait;
in EstimatedTimeToFinish.php and now it works.
dahousecat → created an issue.
dahousecat → created an issue.
That default value for options is still not correct.
Updated last patch to fix bug with missing default value on options in schema, and updated js to not reuse mapbox_renderer namespace and make map object available to custom modules.
dahousecat → created an issue.
I see, the ID was already there as the key, but it's just mapbox_field was not setting the key.
Updated the patch to use the ID from the settings key.
To ensure that renderMap() is only called once per mapbox_renderer settings instance I have introduced a requirement where an id property must be set on the settings object.
E.g. mapbox_renderer[0].id
This id matches the id of the field wrapper.
This allows targeting that element using once, to ensure settings are only bound once.
As a result of this MapboxFormatter from the mapbox_field module will also need to be updated.
I'm working on patching a number of issues in that module so will include that update there.
dahousecat → created an issue.
dahousecat → created an issue.
dahousecat → created an issue.
I agree with dawehner, if a view is missing a warning should be logged.
I was also getting undefined index due to these lines in getTokenArgument:
return [
'type' => $match['type'],
'id' => $match['id'],
];
So this patch addresses that issue too.
Huh, actually the exception was thrown via trackUpdateOnEdition, not trackUpdateOnDeletion.
Updated patch to try catch that method too.
dahousecat → created an issue.
dahousecat → created an issue.
Patch 3 would not apply for me due to the "Information added by Drupal.org" bit so I've created a version with that it in.
I think that approach sounds very wise.
The patch I have will solve my use case for now, but once this feature gets added I can delete my patch :)
Example data-disabled-dates attribute:
data-disabled-dates="2024-12-17,2024-12-18,2024-12-19,2024-12-25,2024-12-26"
Sorry, wrong thread. Please ignore me.
dahousecat → created an issue.
My bad, I was still using vs 10.0.0 not 11 simplewebauthn/browser.
Now a load of other things are broken instead but I assume once I fix bugs those I'll have some base64 encoded ids!
dahousecat → created an issue.
Hi, thanks for the swift reply :)
The MR looks good to me, better than my patch as simpler.
Yes, it's a shame this update has so many breaking changes but thanks for the pointer - I'll review the updated documentation.
I did try and create an MR but I'm having some issues with permissions when pushing and it's late so will just attach a patch for now.