Oh sorry, I forgot to update this ticket!
I've wrapped up a fix for this here: Drupal 10 compatibility for User Points#15 📌 Drupal 10 compatibility for User Points Needs review
As the patch for this ticket would not apply cleanly with the other one.
Updated patch #8 to include new AddPointsEvent and TransferPointsEvent to avoid creation of dynamic properties warnings.
Hey, I'm interested in helping maintain this module and get a D11 version ready.
I feel Drupal Views is too big, bloated, buggy and hard to use.
I think QueryBuilder could replace just the data fetching part of views.
Then there should be then be a plugin system to allow:
- Exposed filters
- Custom displays
A built query should be a custom Drupal (config) entity so can just leverage the existing Drupal routing system and permissions system, and new queries can be pushed to new environments just using a cex / cim.
Used plugin and their configuration should be attached to the entity.
Crazy this is 5 years later, but I've just tested this patch and it still applies and also fixed the schema errors I was getting in my test.
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"
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.
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 :)
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
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.
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...