Sounds like this was fixed.
Sorry I missed seeing this issue back in March.
I wasn't sure I'd be able to debug this just from the stack trace, but it turned out to be pretty easy. recipe_build_yield() returns early if the yield quantity is NULL. So it had to be the fault of the yield units. Turns out that you can reproduce this problem just by making a recipe and deleting the units value.
I made an MR. Can you apply the change and see if it fixes the problem for you?
Also, this is happening during cron runs when Drupal Core's Search module is indexing your content. Do you actually use the Search module? If not, then I suggest uninstalling it. It won't fix the problem (it occurs when the yield-unit-less recipe is viewed), but it will stop the log spam during cron runs. And Search is basically the worst module in Core because of how inefficient it is.
dcam → made their first commit to this issue’s fork.
I added a test. The IS was updated in #11.
I added a test. To do it I reconfigured SymfonyMailerTest::testMail() so that it uses a provider. So expect a lot of changes related to that. That test was originally testing newline characters in the subject. That too was extracted to one of the test cases.
Also, there's a PHP 8.4 deprecation for str_getcsv(). To fix it we have to used named parameters so that we can specify the escape character. See https://www.php.net/manual/en/function.str-getcsv.php.
dcam → made their first commit to this issue’s fork.
I'll update the IS when a decision is made.
I disagree with the approach in MR 7117 and from reading through comments it was contentious to begin with.
I spent the last couple of evenings studying the checkboxes and radios form elements, trying to figure out what parts of the system were setting wrappers and IDs and descriptions. I wanted to make absolutely certain that I'd found the source of these attributes so that it could be solved there.
It's the Checkboxes and Radios form element classes that do it. They both copy the parent element's attributes to the children, including the aria-describedby. This choice is made unilaterally by those classes. The rest of the form system, e.g. FormBuilder, is just doing what it's supposed to do. Also, the element classes are also managing the child descriptions or rather the lack of them. So if the element classes are setting the attributes, then they should be in charge of unsetting any irrelevant attributes. I opened MR 12287 with this strategy in mind. If this idea is accepted, then MR 7117 should be closed.
I can sympathize with any desire to not duplicate code, but I will note that there is already a lot of duplicated code between the two elements. I probably wouldn't bother. If someone wants that to happen, then I assert that we should put off eliminating duplication for a follow-up.
You might see if https://www.drupal.org/project/entity_ref_filtering_link → works for you.
Uh, yeah. This is a problem. Don't expect a quick fix. It's going to require something completely new to be developed. TBH, there's probably an argument that it should be done as a separate module.
I'm going to update the project page to note that it's incompatible.
That's not good. Thank you for reporting it.
I don't have any projects using Facets 3 yet. I'll have to set something up from scratch.
I have a bad feeling that this will force a complete rewrite of ERFL.
There may be some cross-over with 🐛 Details elements have incorrect aria-describedby attributes Needs work , which is RTBC.
To be honest, from my perspective if people want to serve a different, specific version then they should host it locally. Or the library definition can be overridden in a custom theme. In other words, my initial inclination is to put the burden for customization on the person who wants to do the customizing. But I'll give it some thought.
#57 feedback was addressed.
This line of code changed 7 months ago. Instead of calling array_filter() directly, now it calls FilterArray::removeEmptyStrings() instead. I don't expect that this solved the problem. I suspect that this may result in a fatal error because FilterArray::removeEmptyStrings() typehints the $value parameter as an array. So if the inherent problem of calling this with NULL still exists, then I'd expect an error.
Someone who is experiencing this problem needs to report what happens with an up-to-date version of Drupal 11.
I added the test.
PHPCS is complaining about an EoL character in the new quicktabs.install file. Unfortunately, I'm working in the web IDE today and can't do much about it. The committer may want to run PHPCBF on the MR before committing.
Also, I selected 8001 for the hook_update_N() because my site's schema number was set to 8000. I'm aware that there's no consensus on what numbering scheme everyone should use. Just replace it with whatever you think is appropriate.
I added support for 3.9.7. If that doesn't work for you, then you can always download the library and serve it from your local files.
I'll put out a new release shortly.
I worked on this issue over the weekend not realizing that I'd experience it first-hand two days later. I've been adding inline styles to the .views-exposed-form class. Then I navigated to a different page where the exposed form is in a separate block. The class was bubbled up to the block wrapper, causing the block heading to be displayed in-line with the form as shown in the image below.
I didn't expect it to pass. I assumed that something else was probably relying on the attributes as they were. Oh well.
I made a change record: https://www.drupal.org/node/3525287 → .
Based on comment #10 I checked to see if this is still an issue in Drupal 11. It is. The same problem with the Search block form's data-drupal-selector attribute being applied to the block wrapper still exists.
There was no need to make a new test for this. The test created for the related original issue, #2171269: Handle block rendering's #attributes correctly (fixes in-place editing of custom blocks) → , can be adapted to check the change.
MR 1402 was broken. I don't know why some of the additional changes in it were made because they aren't well documented. The change from #atrributes to #wrapper_attributes was lost. I think that's the reason for the confusion in the more recent comments. I'm sure that it did stop doing anything to fix the issue. Since it's difficult or impossible to rebase MRs for old Core versions anyway, I hid the branch and created a new one for D11 restarting from the #5 patch. We'll see if this causes other tests to fail.
I updated the @return statement.
I've continued to work on this. I can't reproduce the problem with the migrate_upgrade module or write a failing test that checks for a logged warning. I'll post the output of the migrate_upgrade command. You can see that d7_block runs before d7_menu, but it does so without a warning. I wonder if this problem was fixed at some point in the last 5 years. If someone is still experiencing this issue, then please post more thorough steps to reproduce it.
dcam@davidslaptop:~/drupal_core$ drush migrate:upgrade --legacy-db-key=migrate
[notice] Upgrading action_settings
[notice] Upgrading d7_action
[notice] Upgrading d7_dblog_settings
[notice] Upgrading d7_file_private
[notice] Upgrading d7_filter_format
[notice] Upgrading d7_filter_settings
[notice] Upgrading d7_global_theme_settings
[notice] Upgrading d7_image_settings
[notice] Upgrading d7_image_styles
[notice] Upgrading d7_node_settings
[notice] Upgrading d7_search_page
[notice] Upgrading d7_search_settings
[notice] Upgrading d7_system_authorize
[notice] Upgrading d7_system_cron
[notice] Upgrading d7_system_date
[notice] Upgrading d7_system_file
[notice] Upgrading d7_system_mail
[notice] Upgrading d7_system_performance
[notice] Upgrading d7_theme_settings
[notice] Upgrading d7_user_flood
[notice] Upgrading d7_user_mail
[notice] Upgrading d7_user_settings
[notice] Upgrading file_settings
[notice] Upgrading menu_settings
[notice] Upgrading system_image
[notice] Upgrading system_image_gd
[notice] Upgrading system_logging
[notice] Upgrading system_maintenance
[notice] Upgrading system_rss
[notice] Upgrading system_site
[notice] Upgrading taxonomy_settings
[notice] Upgrading text_settings
[notice] Upgrading update_settings
[notice] Upgrading block_content_type
[notice] Upgrading block_content_body_field
[notice] Upgrading d7_custom_block
[notice] Upgrading d7_comment_type
[notice] Upgrading d7_node_type
[notice] Upgrading d7_shortcut_set
[notice] Upgrading d7_taxonomy_vocabulary
[notice] Upgrading d7_user_role
[notice] Upgrading d7_block
[warning] The "aggregator_feed_block" block plugin was not found
[warning] The "aggregator_feed_block" block plugin was not found
[notice] Upgrading block_content_entity_form_display
[notice] Upgrading block_content_entity_display
[notice] Upgrading d7_comment_field
[notice] Upgrading d7_comment_entity_form_display_subject
[notice] Upgrading d7_comment_field_instance
[notice] Upgrading d7_comment_entity_display
[notice] Upgrading d7_comment_entity_form_display
[notice] Upgrading d7_field
[notice] Upgrading d7_field_instance
[notice] Upgrading d7_file
[notice] Upgrading user_picture_field
[notice] Upgrading user_picture_field_instance
[notice] Upgrading user_picture_entity_display
[notice] Upgrading user_picture_entity_form_display
[notice] Upgrading d7_user
[notice] Upgrading d7_node_complete:article
[notice] Upgrading d7_node_complete:page
[notice] Upgrading d7_comment
[notice] Upgrading d7_view_modes
[notice] Upgrading d7_field_formatter_settings
[notice] Upgrading d7_field_instance_widget_settings
[notice] Upgrading d7_menu
[notice] Upgrading d7_menu_links
[notice] Upgrading d7_node_title_label
[notice] Upgrading d7_url_alias
[notice] Upgrading d7_shortcut_set_users
[notice] Upgrading d7_shortcut
[notice] Upgrading d7_taxonomy_term:tags
----------------------------------------
Executed migrations
----------------------------------------
action_settings
d7_action
d7_dblog_settings
d7_file_private
d7_filter_format
d7_filter_settings
d7_global_theme_settings
d7_image_settings
d7_image_styles
d7_node_settings
d7_search_page
d7_search_settings
d7_system_authorize
d7_system_cron
d7_system_date
d7_system_file
d7_system_mail
d7_system_performance
d7_theme_settings
d7_user_flood
d7_user_mail
d7_user_settings
file_settings
menu_settings
system_image
system_image_gd
system_logging
system_maintenance
system_rss
system_site
taxonomy_settings
text_settings
update_settings
block_content_type
block_content_body_field
d7_custom_block
d7_comment_type
d7_node_type
d7_shortcut_set
d7_taxonomy_vocabulary
d7_user_role
d7_block
block_content_entity_form_display
block_content_entity_display
d7_comment_field
d7_comment_entity_form_display_subject
d7_comment_field_instance
d7_comment_entity_display
d7_comment_entity_form_display
d7_field
d7_field_instance
d7_file
user_picture_field
user_picture_field_instance
user_picture_entity_display
user_picture_entity_form_display
d7_user
d7_node_complete:article
d7_node_complete:page
d7_comment
d7_view_modes
d7_field_formatter_settings
d7_field_instance_widget_settings
d7_menu
d7_menu_links
d7_node_title_label
d7_url_alias
d7_shortcut_set_users
d7_shortcut
d7_taxonomy_term:tags
----------------------------------------
If you're using Apache, then make certain mod_rewrite is enabled. That's what caused the problem for me when setting up a brand-new web server.
It didn't actually need a rebase, but I did one anyway just to be certain. Restoring RTBC.
It didn't actually need a rebase, but I did one anyway just to be certain. Restoring RTBC.
@benjifisher looks like we cross-posted. See my comment in #41.
I'm not sure why this is implemented as a media specific solution, if anything it should probably be done on content entity storage?
I had the same question! So I opened MR 11949 to see what would happen if this were done in ContentEntityStorageBase::doCreate(). I meant to document my findings here, but forgot.
What I found was that we take advantage of the fact that the bundle isn't validated in tests everywhere. In fact, we do it so much that it's practically a feature. I'd argue that the idea should move forward, but there's a lot to consider. Simply throwing the exception in ContentEntityStorageBase would be so disruptive that it would likely require a meta issue to manage all the changes across Core. Then we have to consider that if Core's doing it, then contrib probably is too. Again, the potential for disruption is so high that it could probably only be done in a major release because we'd be breaking backward compatibility and modules everywhere might suddenly see failures in their own tests.
That said, maybe we figure out a way to bypass the exception for tests. I'm thinking of something like the flag that skips config schema checking. That may not be a good analogy; it's just an idea. It could be turned on by default for all tests. Or maybe we specifically turn on the flag for tests that are affected by the exception, but then contrib would have the same burden due to BC breaks. It would have to wait for a major release.
After analyzing the impact of changing ContentEntityStorageBase::doCreate() I decided that I agreed with @codersukanta's assessment that the scope of this issue should be limited to MediaStorage since unlike other Core entities it will throw the fatal error from an invalid bundle. How often does that really happen? Probably not often, which I imagine is why this issue's priority is minor. So if a Core manager decided "This issue needs to be refocused for all entities," then that's probably OK. But I don't want to make that call.
Please analyze the other MR and the impact it had on Core tests, draw your own conclusions, and tell me if I'm mistaken or not.
I've updated the IS with this information.
I added a test for the Exception and created the change record → .
umm but then we get duplication, I'm asking for other opinions
It looks like you were right to me. I don't see any duplication. I knew there had to be a way. Thank you for showing me.
I updated the IS and CR again.
It needed a rebase due to ongoing changes in the performance tests. I expected the tests to fail, but apparently the new performance metrics from 11.x are still good here.
Ok, I guess there is also concern due to the "(not recommended)" message, which indicates perhaps not properly working.
Using the latest version from the CDN is not recommended because the maintainer can and will release backward-incompatible changes. They've done it before. See the release notes for version 4.0.0 of the module → . By all means go ahead and use it, but you do so at your own peril.
Although @nod_ said "can we add a wrapping div with only the corresponding id for aria? we already have that info in the template..." I couldn't figure out how to get individual attributes out of an existing Attribute object, at least not cleanly. Given that, I figured that this was probably best done in the preprocess function and assigned to a new variable. If I've missed something, then let me know.
I updated the IS and CR with information about this change.
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.