quietone → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
mtift → credited webchick → .
xjm → credited webchick → .
I know I've been a bit quiet on this thread (in fairness, it feels exceedingly weird to comment on your own farewell post though?! LOL) but I wanted to come back to say a resounding
thank you
to everyone here for your wonderful, kind, AMAZING, and supportive words. <3 I read every single one, and I'm SO grateful for such a wonderful send-off. :') You all are LITERALLY the best, and I can't wait until our paths cross again! <3
OMG, EVERYONE!!! 😭😭😭 Thank you SO much for all of your amazingly kind words. This is exactly why this was a really, really tough decision to make. The Drupal community is SO incredibly special. 💖 Each and every person commenting here is conjuring up such warm and fantastic memories from the last, uh, almost 20 years (!). The Drupal community is truly special, and I'm so incredibly blessed to be part of it with you all. *HUGS*
webchick → created an issue.
Another library raised in the Twitter thread that's not here yet. https://github.com/github/auto-complete-element (via https://twitter.com/dgrammatiko/status/1159820163547566081)
Also cross-posted to the #accessibility channel in Slack.
@andrewmacpherson there noted (verbatim apart from fixing a few typos for clarity):
FWIW, my favourite keast-shitty one us still the jquery.ui autocomplete. Sad to see it go :-(
The earlier issues around Select2 and whatever-the-other-was-called fizzled out because it wasn't ckear what we wanted.
To me, these kind of libs suffer from nany features, one-stop swiss army knife. Same as sludeshow libs.
The a11y problems are difficult, because the libs expose lots of independent config options, which deserve different semantics.
Plus, even in the a11y community there is no reliable consensus on what the semantics/behaviours should be for those "buttons inside a textbox" widgets
I think it could help if we know what (accessible) widgets we need for Drupal, rather than looking at the huge list of configurations these libs advertise.
It's about satisfying users, not the W3C... because WCAG doesn't actually cover this at all.
ARIA has semantics which can describe a dynamically changing list of options. jquery.ui autocomplete didn't use them though. Probably because it was written when ARIA implementations were at ab earlier stage. instead it uses an aria live region like our drupal.announce. Every time you press a key it adds a new entry in an invisible live region, which can grow forever! Crude but it works.
The "buttons inside a text box" pattern is pretty problematic. They favour pointrr users at the expense of making it more laborious for other methods .
Say there are 4 tags there already. Pointer users can directly remove any tag. But on implementations I'e seen, if a keyboard user wants to remove the first tag, the have to use backspace to delete them all, then re-add the ones they want to keep.
That means a greater risk of unintended data loss too.
The GREAT thing about a nirmal text box, is that once you're inside it, everyone is on a very even footing.
[The pill/chip pattern is] something that is being explored in the ARIA Authoring Practices guide. It's still controversial in the a11y community though.
Basically the thing that looks like a text box with pill buttons inside us actually a fieldset with a nested ARIA grid widget for the pill buttons...
... followed by an autocomplete combobox + list, without visible borders.
Examplec2 here. https://www.w3.org/TR/wai-aria-practices-1.1/examples/grid/LayoutGrids.htm
I've not seen this implemented in an off-the-shelf library yet.
It's also a but controversial among the a11y community. Some concerns are that "grid" doesn't reflect what it looks like, and keyboard discoverability, and users just aren't familiar with it yet.
Or, it's a cowpath that is unpaved as yet :-)
I just checked the Van11y widget collection [https://van11y.net/]. It follows the ARIA Authoring Practices closely, for better or worse. It doesn't include the pills + autocomplete yet.
One that was brought up in that thread that doesn't seem to be here yet is http://leaverou.github.io/awesomplete/ (apparently one of the ones under consideration for Joomla! 4, according to https://twitter.com/brianteeman/status/1159733875377135622)
Thanks for the issue summary updates! Ok, posted this to Twitter to hopefully get it in front of a wider set of eyes. https://twitter.com/webchick/status/1159727661897273344
AMAZING work! :O :O
I think the next logical step here might be to overhaul the issue summary with a clear summary of results, and then try and get a wider audience (JS, a11y folks) to look at our findings and provide feedback. (Happy to tweet something out.)
To set the record straight on the FUD in #58, Acquia uses a variety of JS libraries for its products—Angular, Ember, React, etc. and https://dri.es/announcing-node-js-on-acquia-cloud explicitly is framework-neutral, because most of our customers are in the same boat. Dries previously came out explicitly against React last time this conversation came around because of the patent clause: https://dri.es/selecting-a-client-side-framework-for-drupal
So let's stick to facts in these threads, not to unfounded accusations, thanks.
Another tip: "what I have heard" type comments about community/developer velocity between the two projects would also be a lot more compelling if they came backed up with data/stats (google trends, job trends, github trends, that sort of thing) vs. personal anecdotes.
Just your friendly neighbourhood grammar police. ;)
Yes, because it's still a feature request. Console was committed only in support of closing the critical issue at #2447573: [meta] Make sure 8.x - 8.x hook_update_N() testing is possible → .
Core committers spoke today about this and related issues.
Given that "the simplest thing that can possibly work" to fix the admin/content page is to switch it so it's showing nodes instead of translations—then all the underlying assumptions work fine, and the form works the same regardless of multilingual sites or not—spun off #2485159: Switch admin/content from showing one translation per row to one node per row → as a new critical issue, essentially for a) in the list of proposed resolutions here.
Re-purposing this one to talking about "Views that provide lists of translations" since all of this is still an issue for those, but after the above issue core will not ship with one, so not something we have to resolve before release. Will downgrade all the children of this one as a result. (They're still great things to fix, mind you.)
Agreed; thanks a lot!
The core committers discussed this today on a triage call.
Revisiting the definition of critical, https://www.drupal.org/node/45111 → , an issue is critical if it:
1. Renders [the] system unusable and have no workaround.
2. Causes loss of data.
3. Exposes security vulnerabilities.
Obviously, 1) and 3) do not apply. 2) is interesting though, given this:
For instance, if you selected the French translation of node/1 and clicked Delete either in the row ops or with bulk ops, it would delete all translations, while the UI expectation would definitely be (since you could also see the Spanish and English versions there) that you're deleting just the French one.
We agreed that this is a bad enough usability problem that will result in unexpected loss of data, so a) from the issue summary is critical, so +1 to blocking D8's release on it. However, b-d sound like usability issues/improvements that are "normal" or at best "major" and we would never hold up the release of Drupal 8 on them.
So let's either repurpose this as a meta and split off sub-issues for a-d, or let's re-scope this to just a) and spin off sub-issues for b-d.
Screenshots would be helpful here to understand the issue. The issue summary sounds quite vast so it'd be nice if we could split out "must fix this to ship D8" (here) versus "other usability improvements" into separate issues.
Sorry about that! Sometimes my enthusiasm for a small RTBC queue gets the better of me. :) Reverted.
Oh, nice! Less code, same functionality.
Committed and pushed to 8.0.x. Thanks!
This feels like 8.1.x material at this point, I think.
untagging for backport to D7.
Wow!! Great to see this bug fixed! But I agree that a test is mandatory.
Also, is there by chance a nicer way to get this value than $elements['#parents'][0]? that's not really at all intuitive.
Kick ass! I'm so happy to finally see this fixed! :D
Committed to HEAD! Marking "needs work" until it's documented in the 6.x => 7.x upgrade page.
Ultimately this is up to Gábor, of course, but given what was required to fix this in 7.x, I'm pretty sure we can't backport this to 6.x. It's an API change that requires module developers to make changes to their menu items' access callbacks. In addition to this being a mean thing to ask people 1.5 years after D6's initial release, it will result in hackish "if function_exists" workarounds in order for this to work for people not using the latest versions of Drupal 6. Granted, it'd only affect the handful of modules that define their own top-level admin blocks like OG, Panels, and Project. But still. Stable means stable.
Confirmed this problem. Would be nice to back-port fix to 6.x as well.
Steps to reproduce:
- Create a role called "editor" and an "editor" user assigned to that role.
- Give the role both "administer nodes" and "access administration pages" permissions.
- Log in as "editor" and go to "Administration"
You'll see entries for Site building, etc. in the navigation menu even though those result in "Access denied" when you try to go there. See attached screenshot.
Let's get tests with this patch though to make sure this bug doesn't recur.
Here's a first stab. I had to change user_roles() to return $role rather than just the name, and haven't begun to track down all the places this broke things.
Also todo:
- The update hook adds descriptions to anonymous/authenticated, but this needs to be done in system.install too.
- We now need the ability to edit the autheticated/anonymous roles so that their descriptions can be changed.
- Probably some tests for user_roles().
@jakeg: Please update the docs. Anyone with a CVS account may do so. The file's in contributions/docs/developer/forms_api_reference.html, I believe.
This is still an issue in 5.x and, presumably, HEAD.
This prevents programmatically creating node content with drupal_execute on imagefields, for example, when the field's #required property is set to TRUE.