@itmaybejj have you been able to make some progress on this roadmap?
In looking around, it seems like a custom test could do link checking - https://editoria11y.princeton.edu/configuration/#customtests - but that would be a different way of checking links vs leveraging the linkchecker module.
Thanks!
If people want to get to D11 with zurb_foundation before this gets into the project, check out https://gorannikolovski.com/blog/how-to-upgrade-drupal-9-to-10#how-to-in.... It has nice steps on how to use https://github.com/mglaman/composer-drupal-lenient.
PS - https://git.drupalcode.org/project/zurb-foundation/-/merge_requests/30.p... is the patch that you can download and use OR I've attached a current copy.
@rahulrao.cs have you tried updating versions of select2? It looks like you are on version 4.0.13 and https://github.com/select2/select2/releases (and in issues on github) mentioned the 4.1 version has accessibility improvements.
I ask because I have the same SiteImprove issue that I'm trying to address! I'm going to try updating to 4.1 and I'll make a note here on what happens, but maybe you'll beat me to it and could report too.
I created a MR that handles only the first letter of each word. I'm backing away from trying to do what Google does with every letter. I'm assuming there is a use case for this, but I don't have one at this time and it seems very hard to do.
I've also uploaded a patch file if people want to test it out. Thanks.
nmillin β created an issue.
Updated patch for 2.0.9 release.
**Note** Hopefully this helps a future dev.
I like that the message isn't being displayed anymore. Now an error message of "An error occurred while searching, try again later." will show for me. This is coming from SearchApiSolrBackend.php (for me at least).
This message can be overridden by something like:
/**
* Implements hook_preprocess_HOOK().
*/
function mymodule_preprocess_status_messages(&$variables) {
// Normal error message from SearchApiSolrBackend.php. Could be better.
if (isset($variables['message_list']['error'])) {
$status_messages = $variables['message_list']['error'];
foreach ($status_messages as $delta => $message) {
if (strpos((string) $message, 'An error occurred while searching, try again later.') !== FALSE) {
$variables['message_list']['error'][$delta] = "Search had a bad time. Call the help desk for assistance.";
}
}
}
}
I've created the MR, but here is a patch if people want to add try it out in the meantime.
Maintainers, please let me know if there should be any changes. Thanks!
I can confirm the same issue.
The stage_file_proxy.fetch_manager service was removed in https://git.drupalcode.org/project/stage_file_proxy/-/commit/aca5a868ef3... from https://www.drupal.org/project/stage_file_proxy/issues/3438649 π Automated Drupal 11 compatibility fixes for stage_file_proxy Fixed . It looks like the stage_file_proxy.download_manager service should be used instead.
I'll try to create a patch to address this.
@mglaman, it looks like sarwan_verma did that back in comment 15 - https://www.drupal.org/files/issues/2023-09-28/commerce_cart_flyout-3359... β
I was able to use the patch with https://github.com/mglaman/composer-drupal-lenient (wish I found this project earlier...). I'm kicking the tires of commerce (no live site yet), but things work.
@mglaman can you review if this is the correct direction, and then maybe someone with more commerce experience than I can polish the patch (if needed). Thanks!
sigh... the config change took forever to figure out why it wasn't working in the tests. I found https://www.drupal.org/node/2951441 β (paragraphs module) that is similar. drupal_flush_all_caches() is what is required for the config to work in the second test.
I've added screenshots from the local test results I did. Removed the Needs Tests tag to reflect that tests were added and marking as needs review.
Let me know if there should be any changes!
Sure!
Screenshots
The default (per config/install/layout_paragraphs.settings.yml) is to not show the paragraph labels and not show the layout labels. I've included screenshots of how this looks with both labels showing and with a mouse hover.
Div & a class
I've pushed a commit to the MR doing this. Naming things is hard, so let me know if there should be any changes.
Tests
I'll poke at this. I'm guessing a new test in BuilderTest.php would be best. Let me know if this is the wrong direction.
Thanks!
Marking as Needs review since sakthi_dev addressed feedback in #15.
I noticed the code was only for show_paragraph_labels and not show_layout_labels. I've enhanced the code sakthi_dev did (will try to push to MR) that shows the layout when the setting is checked. Part of this is adding an additional check to existing code to make sure the paragraph is not a layout.
Let me know if anyone has any questions and great to find this issue!
-Nate
I ran across this and it looks like the Webform module handles how this works. src/Plugin/Field/FieldFormatter/WebformEntityReferenceEntityFormatter.php is the webform file that controls this behavior and doesn't know how the layout_paragraphs module does things.
My solution for this is to use a custom display mode (preview) for my webform paragraphs. Then I display the webform URL instead of the default of the webform.
There probably could be an update to $is_entity_edit_form and $is_paragraph_entity_edit_form to fix this functionality, but that would be something for the webform issue queue (and I'm not sure its worth it).
@Dom. I was able to have a view working with masonry_views as the display format.
The biggest issue I had was including "px" in the Gutter Width setting (px isn't needed). Ideally there would be a warning to prevent people doing what I did, but that is a separate issue.
+1 from me on this. Thanks!
Thanks Dom. I plan to test it this week and report back here. If anyone else wants to test this, here is the git info that I added to my composer.json in the repositories section:
"drupal/masonry_views": {
"type": "package",
"package": {
"name": "drupal/masonry_views",
"version": "2.x-dev",
"type": "drupal-module",
"source": {
"type": "git",
"url": "https://git.drupalcode.org/project/masonry_views.git",
"reference": "9cf47eae179ddca42dcb4883461cbd555cca4809"
}
}
}
Then you can reference the 2.x version of the module. Aka "drupal/masonry_views": "^2.0",
@Dom. any chance you can promote the 2.0 version on the project homepage? https://git.drupalcode.org/project/masonry_views shows the 2.x branch as default, but https://www.drupal.org/project/masonry_views β doesn't show it.
Thanks!
@mingsong, thanks for the documentation page!
One thing I got caught up on is the "if (Drupal.fullcalendar_block) {" not working. This ended up being due to the order of the JS being loaded. I resolved it by adding a dependency in my library to:
- fullcalendar_block/fullcalendar
I'm not sure if/how to add this note to the documentation page, so adding it here in case it is helpful for others. Thanks.