Per @nod_ in Slack:
can we add a wrapping div with only the corresponding id for aria? we already have that info in the template that would avoid changing the structure of description... I would much rather do that. We already have an extra div for errors so that wouldn't be strange to have one for description
I'm working on it.
Part of the problem is that the repo owner makes new tags, but not new releases. You can't subscribe to new tags as far as I can see.
No roadblocks really. I just don't keep up to date on new releases of the JS. Or ever think about it. Do you have any indication if your bug fix will be accepted soon? I can hold off adding a new version until it's ready.
I restored the original changes from the MR properly. Sorry about that everyone.
It actually needed a rebase today. But now the tests are failing due to deprecations with the following warning:
Targeting system/base css/components/reset-appearance.module.css from starterkit_theme library_overrides is deprecated in 11.2.0 and will be removed in 12.0.0. Target core/drupal.reset-appearance misc/components/reset-appearance.module.css instead. See https://www.drupal.org/node/3432346 →
Rebased MR 7340
Rebased MR 11853
There are lots of test failures caused by https://www.drupal.org/node/3499943 → .
Rebased MR 11901
Rebased MR 4583
Rebased MR 12000
Rebased MR 10487
I'm not sure why it thought the MR no longer applies. It was fine. Restoring RTBC.
Sorry, this was in NR status.
Rebased
This issue was for the 8.x-1.x branch which will not be made compatible with Drupal 11.
Agreed.
dcam → changed the visibility of the branch 3174255-docreate-invalid-bundle to hidden.
Added user interface screenshots
Change record: https://www.drupal.org/node/3523777 →
The problem isn't with element #prefix keys. Those are displayed outside of the element's wrapper. The problem is with the #field_prefix key, which is supposed to be inline with the input element.
The test has been corrected to demonstrate the actual problem. The issue summary has been updated.
Also has anyone gone through the git history for when this was added to see if done on purpose?
The field prefix was part of the original port of the form-element template into Twig. It was rendered adjacent to the input element which should be considered as the appropriate position. That's why the field prefix is rendered inside a <span>. The ability to move the description before input elements wasn't added until later in
#314385: Make position of #description configurable via the API →
. A search of that issue for "prefix" doesn't show any consideration for the position of the field prefix in relation to the description. Due to this, I think it's clear that this is unintended behavior and a bug.
Rebased, restoring RTBC
Restoring RTBC status
Can we get that issue added and update the code in MenuActiveTrail service to add a @todo pointing to the new issue?
Follow-up issue: https://www.drupal.org/project/drupal/issues/3523497 ✨ Load menu links for multiple routes Active
This needs to link to a change record rather than the nid of the issue
Change record: https://www.drupal.org/node/3523495 →
Thanks again!
This needed yet another rebase due to performance test changes.
If you need a workaround for this issue, then you can put this in your custom theme:
/**
* Implements hook_element_info_alter().
*/
function MY_THEME_element_info_alter(array &$info) {
$info['managed_file']['#process'][] = '_MY_THEME_process_managed_file_element';
}
/**
* Processes managed file elements.
*
* A required attribute isn't set on the child upload element and it can't be
* done in a preprocess function. It must be set before the element is
* rendered.
*
* @param array element
* A managed file form element.
*
* @return array
* The processed managed file element.
*
* @see https://www.drupal.org/project/drupal/issues/2852874
*/
function _MY_THEME_process_managed_file_element(array $element) {
if (isset($element['#required']) && $element['#required']) {
$element['upload']['#required'] = TRUE;
}
return $element;
}
I'll see about fixing it properly in Drupal Core another time.
Screenshots added.
I'll try to explain the part about the UUID.
Hypothetical scenario:
Let's say you have an existing configuation object in your site. It could be a view or some module's basic settings. You decide that you need to completely overwrite it for some reason. It doesn't matter why. You just need to completely replace the existing contents of that configuration with something else - let's say it's a fresh copy of the configuration from the source module. So you take that configuration, paste it into the config importer, and hit Save. Drupal will cancel the import and display the following error:
An entity with this machine name already exists but the import did not specify a UUID.
I don't know the details, but I'm sure this is protection against improper configuration imports. Try it for yourself! It won't hurt anything because Drupal will stop it.
Now let's go back to your situation. You really do want to overwrite the existing view configuration, at least for the sake of testing. So you would copy the view config from https://git.drupalcode.org/project/aggregator/-/blob/2.x/config/optional.... But you can't just put it into the config import form like that. You'll get the same error I showed above. You also need the UUID from the existing view configuration. You have to add that UUID to the configuration that you're copying and pasting. Without it Drupal won't allow you to do the import.
I hope that cleared things up.
Closing as outdated. Anyone who wants to do this in D8+ should override the styleguide_css library in their theme's info file.
Profile was removed from Core years ago. The User picture is provided by a field which is displayed with the Thumbnail image format, which is covered by the image formatter plugin. Closing as outdated.
I'm closing this as "won't fix" since there hasn't been any discussion in 12 years. Also, the sandbox module hasn't been maintained in that time either.
If someone else is interested in this feature, then they should collaborate on upgrading the sandbox module to the current Core APIs.
Since it's been 10 years with no response from past maintainers I'm going to close this as "won't fix."
This is something more complex than I personally want to develop for the module, especially given the potential for multiple or competing standards and the lack of direction the issue had before now. If someone else wants to write MRs or collaborate on integration, then feel free to reopen the issue. But for now I'm closing this as "won't fix."
This concern is still relevant. My first thought is to have a toggle (or one per element) to turn required-ness on and off via #states. This might be easier after
✨
Sub-page for each styleguide section / group / item
Active
.
Postponed on ✨ Categorize plugins & add dependencies on modules Active and possibly ✨ Configurable styleguide Postponed .
📌 Render groups as sub-tasks? Closed: duplicate has been closed as a duplicate. There was a D7 patch in progress over there, but that work won't be relevant anymore. Credit is granted to those who contributed to that patch.
This issue and ✨ Sub-page for each styleguide section / group / item Active are duplicates. I decided to close this one because virtually none of the work that was done here for the D7 version will be relevant due to the changes in the routing system. Credit will be granted in the other issue to everyone who worked on this patch.
I'm closing this feature request because it hasn't received any attention in over a decade. The separate module that was created has gone unsupported for nearly the same length of time.
If someone else wants this feature, then they should go request maintainership of http://drupal.org/project/styleguide_view_mode and fix it up. If you do, then feel free to report back here and ask that we link to it.
This seems outdated to me. I can't reproduce the problem on Drupal 11. In fact, the module doesn't show up at all when the dev branch is required.
The Available Updates page has undergone changes over the last few years with more coming in D11.2. It's possible that they stopped it from displaying these messages at some point. I'd have expected a change record related to that, but I couldn't find one.
Anyway, I'm closing this issue. Feel free to re-open it if the problem persists.
Yep, I agree this is important. Thank you for your contribution!
I'm closing this as being outdated because Drupal 7 is EoL and I can't reproduce the issue on a Drupal 11 site.
This is a duplicate of #2928676: Theme hook link not found. → which was fixed.
I can't reproduce this either. I read through the stack trace and code, trying to replicate any configuration that I thought might be relevant. The code tries to use the article content type in mock search results. It looks like Layout Builder is in the mix. I tried setting all that up, but had no success.
The bug certainly looks plausible because the style guide is rendering unsaved nodes. My concern is that this is specific to certain configurations. So I'm going to re-close this since it can't be reproduced by maintainers. Anyone can feel free to re-open it, but if you do then please provide steps to reproduce it starting with a fresh install of Drupal Core and the Style Guide module.
I'm sorry this didn't get much of a response 10 years ago. But the demo site is still up and I can see that the breadcrumbs are working properly on it. I don't know if the problem was fixed or if there was a misunderstanding about them. They don't show up on the front page because that's Drupal's default behavior. But if I visit the styleguide for a different theme, then the Home breadcrumb shows up.
Anyway, I'm closing this as working as designed.
Rebased. Restoring RTBC status.
I reverted @prashant.c's changes because they were out-of-scope. Then I added more assertions that to verify that hyphenated machine names are allowed and valid, but underscores are not.
It's still relevant, but I think ✨ Categorize plugins & add dependencies on modules Active ought to go in first.
I've been thinking about doing this since yesterday without realizing there was an existing issue. So I'm updating the branch to make it happen.
That other module hasn't been updated in 14 years, so I'm closing this issue as being outdated.
This needs to be checked in the current default branch. It's kind of in a gray area of undesirable behavior where it could almost be considered a bug. Though we might want to be intentional retain at least one active link as an example.
Thank you for your contribution! I'm marking this as outdated since jQuery UI was removed from Core and your module was made for D7, which is EoL.
This sounds more like a support request than a feature request. And it was answered. So I'm closing it.
I'm sorry this issue didn't receive any responses, but since Drupal 7 is EoL I'm going to close it as being outdated.
I'm closing this issue since Drupal 7 is EoL and this submodule wasn't ported to a D8+ version. If the submodule relied on variables for configuration, then it's likely that any eventual port will rely on the config system. In that case that info will be exportable by default.
I'm pretty sure this is outdated now.
Closing this since the modules mentioned in #25 were removed from Core.
It sounds like this was fixed at some point. If anyone notices the same problem in the 2.x branch, then feel free to reopen the issue and update the version.
Thank you for your contribution, but I'm closing this issue since Drupal 7 is EoL.
I updated the IS and issue title.
For the record, there's no restriction on using hyphens in machine names, other than what's defined in the element's replace_pattern. This is easy enough to test. Just make a Shortcut Set at /admin/config/user-interface/shortcut/add-set that contains spaces or other disallowed characters. The disallowed characters get replaced with hyphens with no problem. Save it and then view it in the config export page. There's no problem when you export the config to files either. It's saved with hyphens no problem.
Just reading the proposed solution “check replacement key…” not sure that’s been implemented.
The IS needs to be updated. I forgot to do it. In #22 @alexpott outlined the solution: any element that overrides the replacement pattern should also override the description to describe the change. In #23 he clarified that statement to say that we don't want to get into the business of trying to build a regex parser to do that work automatically.
Thus, the solution to this issue is to have the Shortcut's machine name element override the description and also update the machine name Element's docs to add text saying "if you override the replacement pattern, then you also need to override the description."
Title made me think that hyphens are valid machine names and is that true?
All I know is that the IS says: "Shortcut machine names require hyphens." And I didn't look into why, but currently the element does replace disallowed characters with hyphens. I'm guessing there's no test coverage around it since the last change made by @prashant.c didn't break anything.
The issue summary explicitly says "Shortcut machine names require hyphens." If this is being undone, then justification for that needs to be given and the IS should be updated accordingly. Please ensure that proper research into this change has been performed.
dcam → changed the visibility of the branch 3477464-invalid-anchor-names to hidden.
dcam → changed the visibility of the branch 3166502-figure-and-figcaption to hidden.
dcam → changed the visibility of the branch 3477450-remove-outdated-anchors to hidden.
dcam → changed the visibility of the branch 3478665-image-button-alt to hidden.
dcam → changed the visibility of the branch 3478639-identical-adjacent-links to hidden.
dcam → changed the visibility of the branch 3478625-form-element-reuse to hidden.
dcam → changed the visibility of the branch 3190203-t-calls-in-class to hidden.
The tagged issues are probably still important, but this issue's purpose is out of date.
The same problems existed in the 2.x branch. I didn't find any other instances. Thank you for the patch!
The comment in the OP about text not being valid content of a <figure> is incorrect. Figures can contain any flow content. MDN's own doc page has included an example of a <figure> that contains a <blockquote> for a long time. I know because I use that page for reference too.
So I removed that part of the issue summary, but I'm leaving the change from text to an image anyway just because I like it and I think that probably is how it's used most of the time.
Anyway, thanks for working on this fix!
Thanks for the MR, @david.czinege!