🇺🇸United States @AaronBauman

Quick and simple MR adds API name to the select list.

MR 88 opened with these changes

Before:

After:

aaronbauman → created an issue.

So it does.

Thank you for your graciousness in telling me to RTFM, which I obviously did not do.

aaronbauman → created an issue.

removes `daterange` from field widget, per comment #5

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

Great idea.

Maybe even sort the options by the API name.

aaronbauman → changed the visibility of the branch 3391193-drupal-10-module to hidden.

Not clear what's going on with MR1 and MR2, or why we have 3 different approaches on this ticket.

We've been running with #11 for some time now, so I'm rolling that into a MR to make it easier to install and hiding the others.

Please feel free to unhide those if some wants to chime in with background or further explanation on MR1 and MR2.

aaronbauman → changed the visibility of the branch 3391193-drupal-10-compatibility-fix to hidden.

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

Do you want to link those issues here?
I'm gonna need this module for an upcoming project in the next couple months, i'd be happy to work on them.

aaronbauman → created an issue.

aaronbauman → created an issue.

bump

Same issue for me.

aaronbauman → created an issue.

facine → credited aaronbauman → .

catch → credited aaronbauman → .

i'm having the same issue.

did you have to make a change on the Stripe side, or the Drupal configuration side?

Seems like if "language" was working previously with a blank value, and now a value is required, then Rules should provide a default value.

aaronbauman → created an issue.

Opened MR77, which is a straight reroll of #32 against 4.0.x

Also #32 was not applying to latest 3.x

Doesn't look like this has changed substantially in 4.x

are you using facets 3 with views exposed filters?

The unique fields constraint checks to make sure that a mapped object doesn't already exist.

If one of the identifiers is empty, it's probably too early to be checking that constraint.

So I think we can skip the check altogether if that's the case.

aaronbauman → created an issue.

Indeed, Views UI has had a decent amount of a11y attention already. Less so for Views, from what I can find.

Here's a similar issue discussing using Announce more heavily, for example: 📌 Use Drupal.announce to give a screen reader user a succinct summary of how changes to a View's definition affected the preview Needs work
Here's an issue discussing feedback after updating a views preview 🐛 After enabling or disabling a view, convey changes to screen reader users. Active
And here's an older one about converting to core Dialog #1851414: Convert Views to use the abstracted dialog modal →
Several more Views UI issues related to a11y, but not ajax specifically that I found.

In terms of Views:
Adding ✨ Updates to AJAX view filters for assistive technology Active as an existing child issue for exposed filters.
Here's an a11y related issue related to sort column labels, but not ajax: ✨ Improve accessibility of Views table sortable columns Needs work
I did not find issues related to ajax sortable column headers, exposed sort, or pagination, so i think those 3 will need to be created.

Using Announce seems like the way to go here, since that already defines an aria-live component.

Ideally the page/content would only change when the submit button is clicked

Pretty sure this is how exposed filters work, unless you have a contrib like Better Exposed Filters configured to autosubmit.

Provide an option for editors to modify or adjust the text within the aria-live notification.

This sounds like it could be a can of worms. Possibly a good candidate to split into another issue so we don't hold up the basic functionality here. Implementers can use the language string override feature in the meantime.

aaronbauman → created an issue.

version bump, now with MR

Created MR 17 against branch 3.1.x
https://git.drupalcode.org/project/eva/-/merge_requests/17

it was a clean merge from MR 14 (now hidden)

ready for review

aaronbauman → changed the visibility of the branch 3430343-automated-drupal-11 to hidden.

MR22 ready for review

aaronbauman → changed the visibility of the branch 3430277-automated-drupal-11 to hidden.

MR45 works for me
RTBC+1

aaronbauman → changed the visibility of the branch 3430051-automated-drupal-11 to hidden.

MR19 (branch project-update-bot-only) ready for review.

worked for me.

RTBC+1

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

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

Neither js nor onclick are accessible, so this presents a significant access barrier.

Why can't an anchor tag ie. <a> be an option?

aaronbauman → created an issue.

Merged to 5.1.x dev

Thanks for the contrib

aaronbauman → created an issue.

Sounds like a duplicate of 🐛 Exception: Warning: Undefined array key "preprocess functions" Drupal\Core\Theme\Registry->mergePreprocessFunctions() Needs work

nod_ → credited aaronbauman → .

Maybe I'm missing something, but this patch works for me.

Very simply: we already have everything we need to generate the route from the view.

The patch in the referenced issue does not solve the problem for me.

aaronbauman → created an issue.

This change does not fix the problem for me.

Still having the same issue as described in 🐛 Exposed Form Reset button Inherits the page display URL when using as a block and AJAX Closed: duplicate and various others marked duplicate or referencing this issue.

The suggestion in #6 does not fix the issue for me.

Reset button still causes a redirect to the attached page display's URL, rather than reloading the current URL.

Not sure if straight duplicate, but seems like this is a core issue also.
🐛 Viewsform has incorrect form submit url if loaded through ajax Needs work

aaronbauman → created an issue.

found it: the "show the amount of results" toggle on the facet edit form.

aaronbauman → created an issue.

aaronbauman → created an issue.

you need to hook this controller up to a route, e.g. via your example_module.routing.yml file

for my use case, i used the path 'login' like so:

example_module.auto_login:
  path: 'login'
  defaults:
    _title: 'Login'
    _controller: '\Drupal\example_module\Controller\AutoLoginController'
  requirements:
    _access: 'TRUE'

Then, for a "deep link", just prefix any path with login?destination=

benjifisher → credited AaronBauman → .

fixed in 📌 Bump dependency on typed_data to 2.1.x Fixed

Thanks for the MR, i've merged latest changes from 5.1.x

This is looking good, but won't get merged into a release until at least 11.0 stable is released.

May need to go into a new major release or point release, depending on 10.3 compatibility.

I'll leave comments in gitlab when we're closer to that point.

Yes, i will update those.

And i'm going to push a 5.0.6 with bug fixes, and possibly more so long as D10.2 is supported.

fwiw:
5.0.x is the <= 10.2 branch
5.1.x is the >= 10.3 branch

Have you run with this patch?

Historically, we compare the SF updated date to Drupal updated date to prevent race conditions between the two systems.
ie. same record updated in both systems between cron runs: we use this date comparison to decide precedence.

seems like this change probably won't have ill effect for the default scenario.
but I am wary that there's some even further edge case where we're relying on this behavior e.g. to prevent some kind of recursion.

how about if, rather than always use LastModified for comparison in PullBase, we fall back on it only if getPullTriggerDate() returns a non-date?

something like this maybe?

       $pull_trigger_date =
-        $sf_object->field($mapping->getPullTriggerDate());
+        $sf_object->field($mapping->getPullTriggerDate()) ?? $sf_object->field('LastModifiedDate');
       $sf_record_updated = $pull_trigger_date ? strtotime($pull_trigger_date) : 0;
 
       $mapped_object

The "doesPush" check is not in the queue handler, but in the hook_cron implementation in salesforce_push.module

You could add "$queue->processQueues($mappings);" to your own cron implementation to achieve the same result, without any patch.

Yes, it was fixed. Thanks

Committed, thanks for the patch.

Will be included in 5.1.1 and 5.0.6

Thank you. Bumped and will be included in 5.1.1 release

Opened bug report against 10.2 with MR of same cherry-pick, please review: 🐛 Admin page access denied even when access is given to child items Needs review

AaronBauman → created an issue.

Not clear to me what the issue is either, but the suggested fix of removing the offending twig files fixed it for me as well.

Here's a related core issue, though not clear that it's actually a core problem or how to recreate with only core: 🐛 array_diff(): Argument #2 must be of type array, null given in array_diff() (line 702 [...] core/lib/Drupal/Core/Theme/Registry.php) Postponed: needs info

I will open a MR with the suggested fix as a temporary workaround.

Created MR from patch #3

Back to needs review to make sure it still works.

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

gah, sorry! i'll more the MR over there.

cross-linking new issue with MR

AaronBauman → created an issue.

This doesn't work for me in 8.x-1.x branch

Please reconsider?

Even if Gin is admin only theme, it seems weird to have magic hidden settings that can't be accessed or edited from blocks UI.

Since breadcrumbs are assigned via system block ui, why not implement this with block visibility settings, and allow users to override if they wish?

Makes sense, glad it's fixed upstream

TR → credited AaronBauman → .

+1 for this feature request

i just required it directly, rather than relying on simplesamlphp

composer require symfony/framework-bundle:6.4.3

AaronBauman → created an issue.

Looks like this is a bug with symfony/framework-bundle :
https://github.com/symfony/symfony/pull/57297

For me, I resolved it by rolling back to symfony/framework-bundle 6.4.3 but other version will probably work also.

AaronBauman → created an issue.

resolved in ✨ Move Action buttons to sticky header Fixed

OK, you're right, seems to have been resolved by #3356717

The primary conflict is the logic Gin uses in GinContentFormHelper::isContentForm and the paragraphs layout implementation.

When the paragraphs layout renders a subform inside a node form, Gin flags the subform as a content form, breaking the actions on the node form.

Since #3356717 does not change that logic, the problem persists regardless.

patch #21 does not solve the problem for me

Generally the process goes like:
1. issue reported (here on d.o) and patched
2. issue gets fixed in dev version
3. new release gets published

during (1), you will need to maintain the patch on your own install.
during (2), you can either keep using the patch, or upgrade to the latest dev version
during (3), you can update to the latest release

The OP doesn't describe the user-facing symptom, so probably would have been difficult to identify these as the same issue.