benjifisher → credited aaronmchale → .
benjifisher → credited aaronmchale → .
penyaskito → credited aaronmchale → .
esmoves → credited aaronmchale → .
benjifisher → credited aaronmchale → .
benjifisher → credited aaronmchale → .
benjifisher → credited aaronmchale → .
Those look nice!
The issue with split buttons, in the context of menu items, is that it introduces different interactions patterns depending on which part of the menu item the user interacts with. It can be challenging to communicate those different interactions to users and complicates the interface. These can also be challenging to use on touch devices, for users who struggle with precise mouse clicks/taps,
There's a really good article from Nielsen Norman Group that goes into much more detail as to why these should not be used for navigation:
Don’t Use Split Buttons for Navigation Menus - nngroup.com
That article also proposes some alternative option, some of which we've discussed here, like providing a link to the "landing page" inside the sub-menu, which is perfectly fine; But as we've discussed if we do this for all sub-menus, in the vast majority of cases those "Overview" links are entirely redundant.
Ultimately I don't think we're going to find a good technical solution here, and that's because this is not a technical problem, it's an information architecture problem.
In cases where the "Overview" page is relevant, because maybe that's the content type list or similar, we should simply provide that as a link in the sub-menu, and we should call that link something like "All content types". Or ultimately reorganize the entire admin menu (but that's probably out of scope here 😀). What we shouldn't do is add a lot of repeating links which use the label "Overview".
I think when we treat this as a problem of information architecture, and not a technical problem, we'll end up with a much better user experience.
Would love to see something like Gin Login → replace the Core login experience.
Yes, this is no longer relevant. Usability group meetings have been happening on Zoom for several years now.
This issue is now generally redundant because the new navigation module allows configuring which menus show in the navigation sidebar.
I'm assuming the toolbar module will eventually move to contrib, so this issue could stay open and move with the toolbar module.
I was also around for some of those early discussions and so was going to say something similar to what @lauriii said in comment #26, so I'll try not to repeat, but I still support the decisions that were made around thsi.
Paragraphs is an interesting example, because what it does is non-standard, there are no example in core of these kind of "add" links appearing in the menu in this way, neither are there examples of all the different "types" appearing in the menu. Similarly, admin_toolbar adding links for all the Views a site has is also very non-standard. In both of these examples, if you have a lot of Paragraph types or a lot of Views, they don't all appear in the menu, so you end up going to the full page anyway. I think it's really important that we have consistent patterns for how things should be done.
I also still agree that in the vast majority of cases the Overview links are not useful, therefor adding them results in a net-negative user experience because it adds more visual noise. For screen reader users, having a lot of links that all say "Overview" is really unhelpful and could be confusing. Not just because they have to hear the word "Overview" every time the user opens a sub-menu, but also because if a screen reader user asks for a list of all links on the page, having a bunch of links that read simply "Overview" or "Add" without any other context could be very confusing.
So my feeling is that we shouldn't encourage a pattern which results in all of these generally redundant "Overview" links.
I think we can probably find a pattern that addresses what Paragraphs, Views and Admin toolbar are attempting to do, but right now I don't know what that pattern should be.
aaronmchale → created an issue.
Thank you @pameeela and @lauriii for providing more insight and motivations behind this, much appreciated.
This allows us to explain why for example Location should be a content type, and not a type of Block Content; because it's something that you may want to be able to list for the end-user,
When I read this, I think it started to make a lot more sense to me. Initially I was approaching this from the perspective of reusable pieces of content that you might add into a page via layout builder, or embed in a sidebar. Which I think we can all agree is probably what you would use blocks for. But if we consider the example of a Location content type and Location content, which would be structured content and used in a specific way; As you say, you want to display that content not as pages, but instead embedded in a View or elsewhere, that's where I can now see the potential in this.
I was trying to think of other types of content which would be suited to this, and I think a really good example of where this might be used is with a Person/Staff Profile content type. Let's say initially your a small team, and you create a staff profile content type, you only want these to be displayed in a list and you use Views to do that, you don't want people going directly to each individual profile. Over time, the team size grows, so you have more profiles, the fields also start to grow, maybe initially you only had a few basic fields, but gradually more rich fields are needed, like a photo, a biography, links to social media. Eventually you realise you need these profiles to be their own pages, but you still want a list of all of them. That graduate evolution of the content as the needs of the business evolve will defintiely be a lot easier to deal with if you don't have to do any kind of migration or rebuilding of that content!
I think Profiles are actually a really good example of where this feature could be used, it's a good example of a content type that might grow organically over time, I think this is the kind of thing you were getting at @pameeela ?
This then brought me to another though, I was thinking about the example of Locations, and how at The University of Edinburgh, our new course/programme content types are supported by a number of taxonomies, we have a location taxonomy for our various campuses, a taxonomy of awards, a subjects taxonomy, taxonomies of our schools and colleges, and more. We actually don't want people directly navigating to any of these term pages, there's nothing of value on them! These vocabularies all exist to facilitate a common set of terms, being able to filter on those in the backend using Views exposed filters, and to facilitate facet filtering using Search API. This all got me thinking that this option would be even more useful on taxonomy vocabularies. So if this hasn't already been considered, I would strongly support adding this option to vocabularies/terms, in addition to nodes.
Where this leaves content blocks, I agree with what @lauriii said:
Unlike Nodes, Block Content is for content that you would never want to display as a page or list for the end-user. It could be used for example for a hero that you want to display on multiple pages or a cookie banner. It would be rare for someone to create a page for a hero block or a list of hero blocks for other than administrative purposes.
Looking more at what Experience Builder is doing, I do wonder if the role of content blocks will be significantly reduced. Right now, a lot individual content in a Layout Builder page is a content block, but Experience Builder won't be taking the same approach, and reusable content could be something different.
So in summary, I now have a much clearer view on how this feature could be used, I no longer think it conflicts with the role that content blocks have, and so I'm very much in support of adding this and even expanding it to taxonomy terms (where it may see even more usage than on than it would on nodes).
benjifisher → credited aaronmchale → .
Thanks for explaining that @catch, that does sound like a very cool idea then! I can definitely see the potential in this!
So I do understand where the motivation for this is coming from, but to elaborate further on what concerns me:
Let's imagine for a moment you're delivering a Drupal training session to people who have never used Drupal before but are maybe familiar with other CMS's, you start by trying to explain to them what nodes are. You explain that content types are like pages and posts in WordPress. You then explain that content blocks are reusable pieces of content that can be embedded in other parts of your site, whether that be on a page, in the header, footers, sidebar, etc. There's a pretty clear distinction there, but with this change I worry that we're making it harder for new users to understand what they should be using nodes and blocks for. Because now, with this change, you explain blocks, but then you also explain that nodes can do the same thing, and so someone asks what's the difference between nodes and blocks, and now you probably don't have as good of an answer.
We already have a difficult time describing to new users what nodes are, are they pages, posts, articles, all three... In the Drupalisms working group how we name and describe nodes is a problem that we're very much aware of. I worry that this change would only make it harder to define what nodes are.
A while back, at a usability group meeting we were presented with an issue which would have added a "View" tab to blocks, and after a long discussion our recommendation was not to do that, and at most to add a "Preview" option, so you can still see what the rendered content block looks like, but it's still clear that content blocks are not meant to be pages. Our worry then was the same, that we would be blurring the lines between nodes and blocks.
Drupal by design has a huge amount of flexibility in how you can structure entity types and fields, and as a result of that it may be confusing at first for new users as to what the purpose of all these different types are - blocks, nodes, media, taxonomies, etc - and what makes each different and when to use them. With that in mind, I do feel that Core needs to do its best to make it clear what the purpose of each of these different types are.
An alternative solution to this problem could be to look at the Storage module → , it's a module I've personally used, it provides an entity types where the entities can be used for storing arbitrary data, can be embedded in other entities, or can be viewed on their own.
Again, I do understand the motivation here, I'm just not sure that the solution is to blur the lines between nodes and blocks and by doing so make it harder to clearly communicate the differences.
This is a really clever idea, and could really solve some interesting problems! I could see this being used to allow, for example, paragraphs on a node to all move with the node through the workflow.
One thing we need to be mindful of is the large number of sites using content moderation with existing complex workflows. So we need to be clear that not all workflows are simply draft/review/publish. For instance, I'm on a project right now where we have content moderation workflows with many stages and transitions, and some branching logic. For instance, we essentially have different "tracks" within a workflow that content can be on depending on other factors. The fact that it's easy to set the moderation state of a node in-code, just by calling ->set('moderation_state', '...')
really helps enable these more complex workflows.
If we can continue to maintain the power and flexibility of content moderation, this could be very powerful stuff!
Maybe I'm missing something here, but isn't this what you would use content blocks for?
Nodes are already hard to define - are they a page, an article, a post, who knows? - are we just making them even more ambiguous?
benjifisher → credited aaronmchale → .
We have a use-case for creating an additional "from library" paragraph type, and while it does work, mainly because we kept the machine name of the field the same, we had to copy some of the hook functions from paragraph_library.module and tweak them to reference the machine name of the additional from library paragraph type that we've created.
I agree it would be great if these are not hard-coded. Trying to think of a more extensible way that would support the need for more than one "from library" though. The issue we have, is the additional one exists to point to a different Entity Browser View, and making a separate paragraph type was the easiest way to achieve that.
benjifisher → credited aaronmchale → .
Using the 3.0.x dev branch and the recent commits from this issue seem to have broken existing exposed filters that were added to Views.
Obviously I'm aware that following the dev branch things will change and break.
What I have noted though after re-adding a Facet exposed filter results in a PHP error when trying to access the Settings screen in Views:
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "views_exposed_filters" plugin does not exist. Valid plugin IDs for Drupal\facets\UrlProcessor\UrlProcessorPluginManager are: query_string in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of /var/www/html/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).
benjifisher → credited aaronmchale → .
benjifisher → credited AaronMcHale → .
benjifisher → credited AaronMcHale → .
benjifisher → credited AaronMcHale → .
Thinking about this more, I think what would work well is to add a checkbox to the workflow transition form which allows setting whether content should be required on transitioning to this stage, something like:
Label: Enable require on publish checks for this transition
Description: When enabled, content passing through this transition will have the require on publish validation performed for any fields which have the "Require on publish" option enabled.
That then gives us the flexibility to have the check performed at multiple transitions, which I think is more robust.
For example, enabling this for both "Ready to publish" and "Published" would mean that even if content is edited after it has transitioned to the ready to publish state, the validation should still be performed.
We have a requirement for this, where we have a "Ready to publish" state, just before publish, and so it would be great to be able to select the transition that the check should be done on.
benjifisher → credited AaronMcHale → .
benjifisher → credited AaronMcHale → .
benjifisher → credited AaronMcHale → .
Not sure what the best component for this is, but going with base system, since I'm guessing setting it to ajax was probably an unintended change of moving to from ideas to core ;)
@anruether just to double check, are you also using the admin_toolbar
module, because that does add a load of extra menu items for things like individual content types, that might not play well with the navigation module.
Yeah that config doesn't have anything under display_extenders
, did you try importing that? Importing that config might help with the issue.
@coaston what I'm trying to do is steer us away from simply making form elements disabled, because, as I noted, that's not great from an accessibility perspective. What I'm saying is that the way the approach taken by the Readonly Field Widget module is good because it doesn't result in "disabled" form elements, it actually just displays the output of the field. Obviously that module is solving a different usecase but the approach taken is a sensible one.
@devkinetic not a duplicate of those issue. Those issues are about making the taxonomy style exposed filter available for all entity types, whereas this issue is specifically about when using an Ajax-based field widget for an entity reference field, it not being possible to exclude the current entity.
On one hand you could argue that this works as designed, because strictly speaking when using an Ajax field widget the current URL is the Ajax request URL, rather than the URL of the page the user is on. However, I don't think that's a helpful way of looking at it, because the result is that the entity reference view behaves differently depending on the field widget that is being used.
Let's take the example of a contrib module that provides an entity reference view, the View has no knowledge of where its going to be used, the users of this module should be able to use the entity reference View and field with any of our Core supported widget and expect consistent behavior.
Therefor, I would argue that this is a problem that Core needs to address because the result is inconsistent behavior with a supported Core feature. I don't think the answer to that should be to say this is a problem to solve in contrib.
Thanks,
-Aaron
benjifisher → credited AaronMcHale → .
Another option for people who need this, could be to use the Readonly Field Widget module: https://www.drupal.org/project/readonly_field_widget →
The module provides a "readonly" widget, which can be used with a field and allows rendering the field on the form using one of the field formatters. It works even if the user does not have edit permission to the field.
The good thing about that approach is it's much better from an accessibility perspective, the problem with disabled form elements is that often the way they are rendered by browsers it's not always clear to the user that they cannot interact with the element, often disabled elements do not look visually distinct enough from editable elements.
benjifisher → credited AaronMcHale → .
For commands like site:instlall
, what if those were just Compsoer plugins? We already recommend the composer create-project
command as the first command you run, what if the next command was just composer drupal-install
.
Then you have a installed site, and move onto using drupal
(or whatever the name is).
For the record, I prefer just drupal
as the command name.
I don't know too much about the existing drupal
command, but it seems to not require a booted site, so if the non-booted parts of that were just moved to Composer commands, that would free up the drupal
command to become one which can be used for a booted site.
drupal
at core/scripts
could then be deprecated, and eventually replaced, while drupal
at core/bin
is what we are building here.
Usability review was done in #255, I think I just forgot to remove the tag, sorry for any confusion.
benjifisher → credited AaronMcHale → .
@Castor-designs If you have an export of your site's config, go into the views.settings.yml, look for the line metatag_display_extender, remove that line and try doing a config import, that might fix the issue for you.
This sounds like a good idea. More accurate usage data is a good thing.
Decide if it should be opt-in or opt-out.
My default position is opt-in, but we should definitely encourage sites to opt-in, highlighting the benefits of doing so, linking to a privacy statement, etc.
Having said that, I personally wouldn't object to an opt-out strategy, as long as it was very clear to users that they can opt-out and the implications of staying "in" are clearly communicated.
At the end of the day I think it comes down to how we communicate it and where we choose to place the option.
benjifisher → credited AaronMcHale → .
Given the changing landscape of Drupal recently, could Same Page Preview be added to Starshot, that seems like a good option, then decide whether it needs to be in "Core" beyond that.
I was trying to figure out why this wasn't working for me, and after some debugging, discovered that the $_ENV
array was empty.
This being because the php.ini that comes with the PHP Docker Images set variables_order
without E
[1], meaning $_ENV
is empty.
The getenv()
function is not impacted, so I'd recommend we use that instead.
[1] https://www.php.net/manual/en/ini.core.php#ini.variables-order
Here, you can see what the two default php.ini
files set variables_order
to:
/usr/local/etc/php $ cat php.ini-development | grep variables_order
; variables_order
variables_order = "GPCS"
; are specified in the same manner as the variables_order directive,
; in the variables_order directive. It does not mean it will leave the super
/usr/local/etc/php $ cat php.ini-production | grep variables_order
; variables_order
variables_order = "GPCS"
; are specified in the same manner as the variables_order directive,
; in the variables_order directive. It does not mean it will leave the super
To illustrate this, here you can see an interactive PHP terminal, showing $_ENV
is empty, but getenv("DRUPAL_CONFIG_SYNC_DIR")
returns a value.
/usr/local/etc/php $ php -a
Interactive shell
php > var_dump($_ENV);
array(0) {
}
php > var_dump(getenv("DRUPAL_CONFIG_SYNC_DIR"));
string(14) "../config/sync"
benjifisher → credited AaronMcHale → .
benjifisher → credited AaronMcHale → .
however, if it's just a menu block in the layout, those sites could swap it out with a different menu block easily enough. So using the same block by default might be plenty?
Agreed. We should think in terms of what's the most sensible default for the 89% use-case. As you say, they can always use a different menu on the front-end, or swap this one out for a different one in the navigation.
Don't get me wrong, I love the idea here. The challenge we have to consider, I think, is that we would then have the form submit button in very different locations depending on which form your using.
For instance, if you're on the node edit form you would Save by going to the top right of the screen, but then if you go to a configuration form, you would save by going to the bottom left of the screen, that feels a bit too inconsistent.
There's also the question of whether this is follows form design best practice, the user generally expects to start at the top of the form and work their way down until they get to the bottom where they expect to find the submit button. I suspect (although we would need to test this), that users might find this change challenging, especially users who use magnification software so cannot see the entire screen at once.
As part of this, could we also add a test which ensures that the local tasks on /admin/content and the content menu are always consistent?
For instance, if a future issue adds a new local task to /admin/content, the test should fail if the same tab is not a link in the content menu and is not in the same position.
In comment #2 it looks like this issue is postponed on itself, is that correct?
Nothing against this, I guess the question I would ask is, is a better solution ultimately to flatten the admin hierarchy a bit so it's less deep.
Now, yes I'm aware that's more of a longer term view and doesn't help existing sites which need this now, but since this is already a low priority issue, figured I'd bring this up.
Definitely a good idea for 📌 Decide strategy to customize or provide 1st level menu items' icons Active .
📌 Decide strategy to customize or provide 1st level menu items' icons Active appears twice under the must have list, not sure if that was an oversight or if one of those was meant to be a link to a different issue?
Absolutely fantastic to see this get committed 🎉
I'm proud to have played a small apart in this! A huge achievement by all involved, well done!
Having the "User account menu" and the user account links that appear in the toolbar being different does feel like a weird quirk, from a UX perspective I think using the "User account menu" and "modernizing" it makes a lot of sense. As noted, it also allows the user menu links in the toolbar to be customized, which is a win in my opinion. I think it would be weird if every other menu in the Navigation could be customized apart from the user links.
Agree with @Liam Morland and @alexpott that this is still an improvement on the current situation. I think we can continue to improve it in follow-up issues. For example, maybe there's a way for us to tell if the override is coming from settings.php (likely the 90% case), so that could be a good follow-up candidate.
At least now we are telling people that an override exists, the current state is arguably more confusing because there's no indication on the form. I think in most cases the site itself would have applied the overrides, so there's a good chance that the person looking at the form was the person who applied the override, or at least they are aware that some settings have been overridden. They might have completely forgotten that in the past they did override a value, maybe because they did it only for a specific environment in settings.php by wrapping the override in an if statement that checks the value of, say, the ENV_NAME variable, and it's not the environment they are working on.
Another good thing about this change is that it gives you confidence that your overrides are actually taking effect. The site name is an easy one to check, but maybe you have overridden configuration like the mail server settings for the SMTP module for only a specific environment, and the only way for you to know if the override worked is to send mail and hope it goes to the right place. At least now, no matter what configuration you override you have a way of knowing that the override value is in use.
Add comments
the field api IMO is the ultimate source of bloat. Storing a simple string value for instance as its own table has alot of extra unnecessary data on top of it.
That's something which has always bothered me, why is it that base fields can quite happily just be columns on the same table, but each field created through the field UI must have its own table. (I guess that's why they're called base field heh)
benjifisher → credited AaronMcHale → .
Just because an issue has been open for a long time doesn't mean it needs to be postponed, generally issues should only be postponed if there's an actual need to block the issue on another issue or an external factor preventing it from being progressed. Marking an issue as postponed only reduces any potential for engagement on it.
That said, I don't have a strong opinion either way on whether this should be done in core or not. This issue was opened following a Drupal Usability Group meeting, and during the meeting it was identified that there is a user need for this.
benjifisher → credited AaronMcHale → .
Hi @kopeboy
The change record has information for those developing entity types, please refer to the "Module developers" section at https://www.drupal.org/node/3242827 →
Thanks
Thanks @dww, that all makes perfect sense to me :)
So yeah I'm in favor of just get this in as-is, and then we can do behavior change and any further labeling/description changes in a follow-up.
Thanks for summarizing that @ultimike, based on what you're saying there I think that all makes sense, and it looks like the end result will be a .gitignore
file in the project root, so I am happy :)
Arguably how you assumed it works would make more sense -- if you have administer software updates you should automatically see the warnings. [...]
Hmmmmm....... yeah I can see the rational for wanting to have the ability to perform software updates, without getting notified about them. But then, if you are the administrator, then presumably you cannot "turn off" these messages because you have all permissions.
I wonder if it would have been better to just made this an option on the user profile for those who have the permission.
So in that case it would work like:
- If you are have the "administer software updates" permission you see the messages by default;
- And, if you have the "view update notifications" permission then you also see the messages by default;
- However, you can individually choose to turn off these messages using a new option by editing your user profile, and this option is only visible if you have either of those permissions.
The idea that you would not see the messages if you have the administer permission doesn't sit right with me because it goes against the established permission hierarchy pattern that users have come to expect in Drupal. That being, where those who have the "administer X" permission generally have access to all of the things, and the more specific permissions like "view X entity" and "edit X entity" provide more granular control for those who don't have the "administer X" permission.
This is interesting, because as a site builder you might want to provide an icon for a custom menu link that you happen to place on the navigation.
Similarly, providing icons for menu links could be seen as a common requirement for websites in general.
So one thing to also consider (maybe this is a separate issue though), could Core also provide a "icon" field on custom menu links, which would then be used by the navigation module, but could also be used by the frontend theme for menu links which appear in the main navigation.
@penyaskito are you testing with CKEditor5? Because yes CKEditor4 is disabled fine, this issue is specifically about CKEditor5 and here we used the CKEditor5 API to disable the editor, but from my testing that only seems to work if JS Lock is turned on.
Re #12. I'm not sure about that description, to me it's just saying the same thing the title says but using more words.
How about:
title: View software update notifications
description: Displays software update notifications for users who do not have the Administer software updates permission, users with that permission always see these notifications.
Here's my rational:
- Using the term "software updates" cogitatively links it to the "administer software updates" permission.
- In the description we state the key difference between the two permissions.
- We reassure the administrator that if you have the ability to administer updates you will always see the notifications, which is something we said in the previous issue would be good idea. Is this actually how it works though, if not it probably should work that way?
benjifisher → credited AaronMcHale → .
Great to see this get committed.
In testing, I note that this only works with CKE5 when the JS locking feature is enabled. I wonder if that's something which needs to be addressed, or if that's more of a "by design" and it just needs to be documented. My worry is that because CKE5 is the default editor in Drupal, if that option isn't on by default then it could result in people thinking that this module still doesn't work with CKE5.
Just reporting the comment I just made on the parent issue because it's equally relevant here:
Part of me feels like, if we go down the feature flag route, it still has the same problem that the current checkbox does, in that a on/off checkbox is not really the best way to communicating the two options. So I'm leaning more towards that, whether we have this as a feature flag or not, it may be better to still have a form with the two radio buttons.
Part of me feels like, if we go down the feature flag route, it still has the same problem that the current checkbox does, in that a on/off checkbox is not really the best way to communicating the two options. So I'm leaning more towards that, whether we have this as a feature flag or not, it may be better to still have a form with the two radio buttons.
benjifisher → credited AaronMcHale → .
I agree that the end result should be that a .gitignore
file (of that name) is placed at the root of the project after running the composer create-project
command; And that existing project should, ideally, not be impacted.
Whether we call it template.gitignore
or something different in our source control, I don't feel strongly, assuming we have a mechanism to place it at the project root with a different name.
In any case, my feeling is that since CKE5 provides an actual API for disabling the editor, maybe using that here is a more robust and future proof solution?
@smustgrave in your last comment you linked this issue, did you mean to link a different one?
While commenting on #3431164-7: [meta] Improve the "Expose all fields as blocks to Layout Builder" feature → , it made me realize that we need to be really clear about how feature flags should be used, to quote myself from over there:
When I think feature flags though, I'm thinking things which are experimental and might be merged in some day, because that's how web browsers like Chromium treat them, I think that'll mean a lot of people will already have that expectation. What we have here though doesn't quite fit that expectation, where we've added this option not as something which might one day be "on by default" but almost the opposite, to remove something which was causing problems.
So we need to be mindful of those existing expectations from people before going ahead and using them. We should have a clear governance process/documentation for when it's appropriate to use feature flags.
Using a feature flag module is definitely an interesting way of doing this.
When I think feature flags though, I'm thinking things which are experimental and might be merged in some day, because that's how web browsers like Chromium treat them, I think that'll mean a lot of people will already have that expectation. What we have here though doesn't quite fit that expectation, where we've added this option not as something which might one day be "on by default" but almost the opposite, to remove something which was causing problems.
Maybe before going ahead with this being a feature flag we should wait to see what we determine their purpose to be?
Very much in favor of this!
Back at DrupalCon Lille, @lauriii and I were talking about 📌 Combine field storage and field instance forms Fixed and I floated this exact idea as a way for us to reduce the risk associated with large-scale UI changes while still allowing us to move and iterate at pace.
A great example of how we could implement this is by following the patterns that web browsers like Chromium (and all of those built on it) use for feature flags. A screen that lists all of them and allows enabling/disabling them.
I fully support the idea of making this deployable, whether that's in configuration or in settings.
I would be in favor of this having a UI, because as noted, we could then use this for UI changes which can be turned on for sites without the need to update configuration or settings. We should though communicate clearly that these feature flags are for experimental features, and think carefully about where we place links to such a page.
Overall though, big +1 to this!
@SKAUGHT we only close the issue once all of the remaining tasks are done :)
Currently those are: adding a link to the recording, transcript, and adding issue credit for participants. Those are done by benji.
@penyaskito have you tested the latest MR to be sure that it does not work? Because in my testing this module works as is for CKE4, but not CKE5, and while I haven't tested the MR here (yet), my assumption is that it makes this work for CKE5.
Attendees at todays meeting for issue credit: @AaronMcHale, @Quynh, @rkoller, @simohell, @SKAUGHT, @worldlinemine
We probably don't need the link to documentation to open in a new tab, I don't believe other links to Drupal.org open in a new tab in the admin UI.
WCAG 2.1 says "Opening new windows and tabs from a link only when necessary", to me this doesn't seem like a "necessary" case. Additionally, "In general, it is better not to open new windows and tabs since they can be disorienting for people".
Source: https://www.w3.org/WAI/WCAG21/Techniques/general/G200
My previous comment may not apply actually., I had not set the entity reference field itself to require on publish, after doing that things seem to be working better, but I need to do some testing tomorrow.
This doesn't seem to work for paragraphs which have been added to storage entities → , where storage entities are embedded using inline_entity_form. For that matter, it also doesn't work for any field added in a storage entity.
Maybe there's a way to make this work for more than just paragraph entities, like any entity which is embedded within the parent entity using inline_entity_form?
Comment added to 🐛 Display status message on configuration forms when there are overridden values Fixed .
Usability review
We reviewed this issue at 📌 Drupal Usability Meeting 2024-03-08 Active . That issue will have a link to a recording of the meeting.
For the record, the attendees at the usability meeting were @AaronMcHale, @benjifisher, @rkoller, @shaal, @simohell and @worldlinemine.
If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.
During the meeting we discussed the wording of the message, we acknowledged that this is a particularly tricky one to get right because of the context in which overrides are used, so we spent a lot of time trying to find wording that appropriately conveys that the overrides don't directly apply to what the user sees on the form, while also trying to keep it short and to the point. We also noted that a previous usability review was done only 6 months ago, but we feel confident that we were able to improve on the wording.
The recommendation we settled on is: These values are overridden. Changes on this form will be saved, but overrides will take precedence. See [configuration overrides documentation](https://www.drupal.org/docs/drupal-apis/configuration-api/configuration-override-system) for more information.
That is the wording of the first paragraph of the message, followed the unordered list of form elements.
This recommendation is based on a few key points:
- Documentation link: it should be clear to the user where they are going and what they can expect when clicking the link, additionally for users of assistive technology, when tabbing through the list of links on the page, the link text should describe the link without requiring any other context.
- Similarly, we tried putting the link on its own line, but we worried that the link could be confused for being part of the list of form elements, so showing the link further away from the start of the line and wrapping it within text should help distinguish it from the list of links following.
- We felt we were able to reduce the number of words in the message to a degree where it is concise but still clear. We were mindful that the unordered list could be quite long, if the user is viewing a form where many values are overridden.
- We noted that the text "The following form elements have overridden values" is not strictly true, the form may actually be the only place where the user sees the non-overridden values.
- Similarly, we felt that the proposed message contains enough information to communicate the situation, without using words like "current context" which may not be clear to the user. We felt that providing the documentation link was sufficient enough for users who needed additional information.
I just want to clarify something that I missed the first thoughs. I think this is more about EXTERNAL marketing. To people that do not already have a contract and do not already have a Drupal site and may not have heard about Drupal.
I think I'm on board with that, but it would help to have specific examples of where we would see the impact of this change?
I'm not sure, but this issue might be slightly related here 🐛 PathBasedBreadcrumbBuilder needs to be able to exclude pointless paths Needs work .
One thing I see here is that if the page title is consistent across all local tasks, then the barodcrumb probably doesn't need to contain the primary local task. For example, when on the "Manage fields" tab of the Article content type, "Article" appears in the breadcrumb, but it probably doesn't need to be there because it simply goes back to the "Edit" tab.
Perhaps the usability meeting can provide some suggestions/recommendations on the wording :)
One thought, based on the GIF in comment #9, I wonder if the toggle should also hide the default alt text, because with that visible but the override option hidden, it kind of implies that the default alt text will be used. I think it would be better to hide the default alt text as well, because once the image is set as decorative, the default alt text is no longer relevant.
benjifisher → credited AaronMcHale → .
larowlan → credited AaronMcHale → .