🇪🇨Ecuador @jwilson3

jwilson3 → made their first commit to this issue’s fork.

Improve the summary text for display on the parent page "Local server setup". (related to discussion on #3499635 📌 Review/archive the local server setup section Active ).

Thanks @ressa for the explanation.

1. Taking into account the OG Page limitations, I've done what I could to make things a little more clear per some of the ideas in #18.
   https://www.drupal.org/node/2804427/revisions/view/13934826/13942883 →
2. I then, updated summary of the "Docker-based development environments" sub-page for more coherent display on "Local server setup".
   https://www.drupal.org/node/2941639/revisions/view/13925027/13942888 →

Update summary for more coherent display on "Local server setup" parent page, per discussion on #3499635-18 📌 Review/archive the local server setup section Active

try to fix the <small> secondary cta links.

Improve UX of the page to best of our ability, given OG Page limitations, per discussion in  #3499635-48 📌 Review/archive the local server setup section Active .

Hi @finex,

1. Can you please try the workaround in #6, which has an approach that should resolve the issue for you. TL,DR; create a View Mode called "Thumbnail" for Media, and render the actual SVG Field instead of the bundled Thumbnail field. Then edit the Media Library view to not use "Media Thumbnail" field, but to display the Rendered Entity, and render the "Thumbnail" view mode.

2. If this doesnt fix the problem, can you please provide some additional context, including:

Which theme is being used?
Screenshot of where the SVG is appearing too large.

Fixed thanks.

https://www.drupal.org/node/2863622/revisions/view/13281561/13942859 →

@ben.campbell, does rebuilding all caches after updating, as indicated in the 2.3.4 release notes → resolve the problem?

jwilson3 → created an issue.

IMO the way https://www.drupal.org/docs/develop/local-server-setup → is currently laid out is confusing due to the different visual components used and content organization.

A few things of note:

1. The div.note-tip for DDEV at the top of the page looks like something you'd skip when scanning the page to get to the juicy details further down the page.
2. The only section with sub-section links is Windows, and one of those is a DDEV-related link. Shouldn't the DDEV thing just be moved to the DDEV section instead, since we're driving people to DDEV lander first, and then you pick your platform?
3. It's not clear whether the other sections on the page are in fact Docker or DDEV related or not, you have to click to find out.
4. It's not clear what if any of the tools like XAMPP or USBWebserver are legacy or not.

I get that this is kind of a topic lander page for what could be considered a completely legacy section, since now we have DDEV, but I think it makes more sense to present information in a cohesive way on the page (even if it doesn't belong to this section).

So, I took the text extract of the page to GPT and asked what it suggests to make usability and understandability improvements, and it gave me the following cleanup recommendations:

• Deprecate or archive legacy tools like XAMPP and USBWebserver if unmaintained.
• Clearly tag older alternatives as legacy or unsupported.
• Use components like tabs, accordions, or sections in the UI to separate "Docker-based", "Non-Docker", and "Windows-specific" options.

It then wrote the following up as one example of page organization. To be clear, I'm not saying we should go with this, but certainly making it more clear that DDEV is an option on par with the other options on the page seems sensible to be able to compare apples-with-apples, instead of making the DDEV note-tip into an orange.

Local Server Setup for Drupal Development

A local server environment is recommended for Drupal development. It lets you work offline, safely experiment, and tailor your dev stack as needed.

🔧 Recommended: DDEV (Docker-based)

DDEV is the officially recommended local development tool for Drupal. It supports macOS, Linux, and Windows, and provides:

• Easy project setup
• Consistent environments
• Built-in HTTPS and mail support
• Drush and Xdebug integration

➡️ Get started with DDEV →

🐳 Other Docker-Based Options

Other Docker-based tools exist but are not officially recommended:

• Docker4Drupal
• Lando

🪟 Windows-Specific Options

For users on Windows who don’t use Docker:

• Installing Drupal on Windows for local usage
• Using DDEV in WSL2 on Windows (consider moving this to the DDev Section)
• XAMPP setup (legacy)
• USBWebserver (legacy)

🛠 Non-Docker Alternatives

If you prefer not to use Docker, see the general guide:

➡️ Installing Drupal without Docker

✉️ Email Handling Locally

Learn how to catch and read emails sent by your local Drupal site:

➡️ Managing mail on a local server

🐞 Debugging & Dev Tips

• Enable verbose error logging
• Disable and debug caching

🔗 Related Guides

• Installing Drupal
• Setting up Drush
• Configuring Xdebug with DDEV

When you install the theme, the main menu block configuration provided out-of-the-box displays fine without any whitespace errors.

I'm unable to reproduce this issue and am going to need more precise instructions on how to reproduce this, and ideally a config export of the menu block you're using.

This theme is intended for university websites that typically have 2 or 3 levels deep menu structures.

1. The out-of-the-box configuration for this theme is to hide breadcrumb trail when "Home" is the only option.

   Page: /admin/appearance/settings/rivet

2. But, if you switch to one of the other options, then the breadcrumb trail shows up, as expected.
   
   
3. Furthermore, if you setup proper breadcrumbs on a node, then you get breadcrumb trail with either of the two breadcrumb settings:
   

I'm going to close this because, afaict, this is "Works as Designed".

If I've overlooked something, then feel free to reopen and PROVIDE PRECISE STEPS on how to reproduce the issue.

Thank you.

1. Remove any mention of the upstream BSD license on the Drupal theme’s project page to avoid confusion.

✅ This has been done in Revision 13938284 → .

There are instructions here for how to reference CDN assets in libraries.yml

https://www.drupal.org/docs/develop/theming-drupal/adding-assets-css-js-... →

I will update rivet.libraries.yml accordingly.

jwilson3 → created an issue.

Also I don't understand how #4 B and #16 could work because laravelmix executes everything in parallel. If I delete my build folder, and try to mix.postCss a file that is generated via mix.sass, laravelmix complains that the source file doesn't exist (because it has not been compiled yet).

Can you test stacking the calls like this?


mix
.sass('src/sass/ckeditor5.style.scss', 'css')
.postCss('assets/css/ckeditor5.style.css', 'css', [
require("postcss-selector-replace")({
before: [".ck-content body", ".ck-content html", ".ck-content :root"],
after: [".ck-content", ".ck-content", ".ck-content"]
})
]);

Thanks @tasc for keeping me honest and tracking down the change. I misremembered what we named it, got confused with a totally unrelated change (dd086f0). Will update the notes accordingly.

Since the patch in Comment #40 is for Drupal core, I suggest creating a Drupal core issue if for no other reason than to see what core maintainers have to say about this issue.

The issue summary, as written, is still relevant today. The top-level link is still called "Configuration", and could be shortened to "Configure" since it conveys the same info, and provides more room in the horizontal toolbar, e.g. for additional contrib modules that provide top-level links (like "Groups" module for example). In the vertical sidebar toolbar, it could ultimately lead towards the ability to make the sidebar narrower.

Since Paragraphs ultimately have to be "attached" to some entity, perhaps there is a way that the canonical link implementation could dynamically recurse up the entity reference tree using Paragraphs::getParentEntity() until it finds the first parent entity that has a canonical link and return that?

Huge +1 to comment #30, but doesn't that problem already exist today with or without the implementation here? For that reason, this should be split off to a follow-up, for its own discussion and implementation, independent of the scope of this issue.

jwilson3 → created an issue.

Ah. Sorry. No it doesn't work. As stated in the issue summary in slightly different wording, pasting (ie CTRL/CMD + V) does not strip out all the crazy formatting and inline styles when pasting from another rich-text application, like Word.

I was using CTRL/CMD + V (mac), because this module's Project page description states the following:

CKEditor 5 plugin to force pasting content as plain text.

If this module requires using CTRL/CMD + SHIFT + V, then either the module description should be updated to clarify this, or the module needs to be fixed to actually "force" pasting as plain text.

I hit this snag using site_audit:4.0.0-rc5

Site Audit module now has a 4.1.1 version, which may have resolved this issue, but needs additional testing.

I have an internal ticket to pick this up during maintenance cycle, but it may be some time before we can come back around to this.

For this ticket, I will also update the summary text on the project page for clarity:

Current summary text, cropped

In normal rendering of Drupal form fields, the field's "description" (i.e., its help text) gets placed below the form's input element, which is not necessarily the most useful…

Proposed summary text

Allows adding help text between entity field labels and their corresponding inputs. Particularly useful on tall form inputs where standard field description text goes unnoticed at the bottom.

The bold theme looks better, by far, in the context of the Project Browser.

I've created the following two options:

Version 1.0 - a light theme

Version 2.0 - a bold theme

jwilson3 → created an issue.

Thanks @Micropat for the fix, and particularly for your proactive response and keeping the house in order, despite my grumblings in OP.

It sounded like – but can you please clarify that – there will not be any required changes at the Drupal module level, as this has been fixed upstream?

Looking forward to reviewing this.

I've released label_help:2.0.0-rc2 → .

Looking under the hood, the current codebase is a complex mess and has several limitations.

Work is currently under way to bring Paragraphs support ( ✨ Add Label Help support for Paragraphs module fields Active ) and generally overhaul the module architecture ( 📌 Refactor Label Help to use hook_field_widget_WIDGET_TYPE_form_alter Active ), which I think is important for achieving a truly "stable" release, but I also don't want to give a false impression that getting to stable will not imply some potential bugginess, and since we're already at "Release Candidate" stage.

I'm thinking there are effectively two routes:

1. create a 2.0.0-rc3 containing the overhaul work; let it stabilize and then version off 2.0.0 with something everyone is more happy with.
2. draw a line in the sand soon-ish with a 2.0.0 release (after the current rc2 has had time to be adopted and settled), and then start a 2.1.x branch and a 2.1.0-beta1 release for the overhaul.

Any feedback on how to version such an overarching change are welcome. Thanks.

jwilson3 → created an issue.

Current status:

• I've created several TEST submodules for testing Core Fields, Custom Fields, Paragraphs (cherrypicked from ✨ Add Label Help support for Paragraphs module fields Active ) and a few random contrib modules that implement their own field widgets (Theme Field, Address Field, Telephone Advanced).
• Happy to report that Paragraphs integration now works! 🎉
• Special case code was added to support the three Address field widgets.
• All core field types and widgets work with the exception of:
  • ❌ Radio buttons. Eg, A "List" field configured with 2 or more options, "Allowed number of values" is set to 1, and the "Check boxes / radio buttons" (options_buttons) is selected as the field formatter. In this setup, the radios do not display AND the Label Help does not display
• Presumably other contrib modules will need custom field widget logic specifically added. This may be a deal breaker and cause regressions on existing installs, but it is hard to know what people are using out in the wild. Ultimately (sadly) this will likely require smarter fallback logic, similar to the original codebase.

I'm going to mark this postponed on 📌 Refactor Label Help to use hook_field_widget_WIDGET_TYPE_form_alter Active , since part of the testing of the refactor on that ticket has to do with ensuring things work for Paragraphs too.

I've cherrypicked the commit c6b2b82a from the MR on this branch over to the other issue to facilitate testing.

jwilson3 → created an issue.

We don't have the full data, but are able to reproduce it consistently with a search for any word or number immediately preceded by a dash (minus sign) in the querystring eg:

Ex. 1 math equation
"Prove that k x B= -pEw. Write all assumptions made for derivation of this relation."
/search?search_api_fulltext=Prove%20that%20k%20x%20B%3D%20-pEw%1A.%20Write%20all%20assumptions%20made%20for%20derivation%20of%20this%20relation.&sort_by=search_api_relevance&sort_order=DESC

Ex. 2 GPS coords
/search?search_api_fulltext=-37.81663%20144.96186&sort_by=search_api_relevance&sort_order=DESC

Ex. 3. "not" some word
/search?search_api_fulltext=-emancipation&sort_by=search_api_relevance&sort_order=DESC

jwilson3 → created an issue.

Thanks for the bump. I'll add to my list for this week. Apologies this dropped off my radar.

Thank everyone for pushing this forward.

First glance I thought the class changes were out of scope but it's so the attributes exist even if a custom class isn't set.

Good point. Also worth pointing out that initializing the Attributes may also have the positive knock-on effect of resolving #2845400-24: Adding attributes to views-view-list.html.twig doesn't work if Views List class Style option is empty → 🙌! But it's worth confirming and double-checking because the patch there is similar to the work done here, but has one additional hunk not present in this issue. Even if it doesn't completely solve that issue, maintainers could consider bringing over issue credit from that issue.

PaperTrail reports these as "emergencies" because an exception is generated. Exceptions usually result in a 500 error or in some way indicate that the code is incorrect. Having trouble understanding why a simple 403 response is along an expected permissions-based codepath generates an Exception. Is there a good reason not to handle this exception and log the 403 cleanly?

jwilson3 → created an issue.

Ah. I just found that the fix for the same issue on the 2.0.x branch was done in a separate issue and there was no mention of that from this issue... So I'm linking these now. 😅

🐛 MissingValueContextException: Required contexts without a value: node Active

Sadly this is filling up our logs too, and the patch on #4 applies cleanly to 2.0.3 but not 2.0.4. It was committed on the 2.1.x branch, I presume that the 2.1.x branch has diverged quite a bit from the 2.0.x branch, meaning this needs a reroll until 2.1.x is stable.

I agree with this issue, and so does the community, for the same reason outlined in the OP.

See https://www.drupal.org/docs/develop/creating-modules/adding-assets-css-j... →

Emphasis mine:

Inline JavaScript is highly discouraged. It is recommended to put the JS you want to use inline in a file instead, because that allows JavaScript to be aggregated and cached on the client side for performance, and enables the use of a stronger Content Security Policy to protect against XSS and other vulnerabilities.

Furthermore, the inline script is added to html_head instead of the footer, which adds a bit of unnecessary performance overhead.

Both of these points are mentioned in the Siteimprove Analytics help page:

We recommend that the JavaScript is always added at the bottom of the website in a footer or similar, just before the closing HTML body tag. Also, JavaScript can be blocked by a content security policy (CSP) configured to prevent unwanted cross-site-scripting. If you use CSP, please configure it to allow the Siteimprove script.

It seems there is no easy way to add JS to the footer from page_attachments unless you:

• Use *.libraries.yml, whereby JS files are added to the footer of the page by default. This suffers from the problem that the JS script URL is different for every site due to the unique $config['siteimprove_analytics.settings']['code'] and therefore hard to add a dynamic URL with libraries.yml files. In theory the module could use hook_js_settings_alter() but it feels wrong to hack your own library definition.
• Use hook_preprocess_html() instead of hook_page_attachments() to add the script to the page_bottom variable manually. This is probably the only practical approach this module can use.

There might be other ways but I had to set the problem down for the moment.

Additionally, since the module's functionality is so small in scope, I decided to just write my own custom module leveraging approach 1 from above.

MYMODULE.libraries.yml:

siteimprove-analytics:
  js:
    https://siteimproveanalytics.com/js/siteanalyze_11378.js:
      type: external
      attributes:
        async: true

MYMODULE.module

<?php

/**
 * @file
 * Primary module hooks for MYMODULE module.
 */

/**
 * Implements hook_page_attachments().
 */
function MYMODULE_page_attachments(array &$attachments) {
  // Don't add on admin pages
  if (\Drupal::service('router.admin_context')->isAdminRoute()) {
    return;
  }

  // Check if we're on an allowed domain.
  $allowed_domains = [
    'MYSITE.com',
    'dev.MYSITE.com',
    'test.MYSITE.com',
    'MYSITE.ddev.site',
  ];

  $current_domain = \Drupal::request()->getHost();

  if (in_array($current_domain, $allowed_domains)) {
    $attachments['#attached']['library'][] = 'MYMODULE/siteimprove-analytics';
  }
}

MYMODULE.info.yml

name: MYMODULE
description: Adds Siteimprove Analytics script to specified environments.
type: module
core_version_requirement: ^9 || ^10 || ^11
package: custom

Cleaning up my old issues. I've merged this to 1.0.x branch.

Thank you @webmestre for confirming this.

It is a good practice to both rebuild caches (and run database updates) any time you update modules.

I will update the release notes of 2.3.4 to ensure people know they should clear caches.

Asked @drumm in Slack about this:

Would it make any sense to open an issue Drupal.org packaging to automatically exclude the .ddev folder from contrib package builds, so that maintainers do not need to add their own .gitattributes export-ignore rule?

his response:

The majority of requests about packaging are for it to do less. The .info.yml modifications can be annoying, but are necessary. So I don’t think I’d want to have it do more. I do think there is a place for an optional project template for new projects that includes the right LICENSE.txt , default .gitattributes and anything else mostly universal.

Since this is not a new project, it wouldn't really apply, and if such a project ever took off I guess we could add/update our .gitattributes to match a template.

Therefore I'm going to go ahead and merge this one. We need to continue to monitor the builds to confirm that the .ddev folder is actually getting removed, before marking this fixed.

The Drupal 11 compatibility fixes here have been included in the latest SVG Image Field module release 2.3.4

We have a follow-up issue to bring about additional Drupal 11.2.x compatibility due to deprecations:

📌 Drupal 11.2.x compatiblity Active

I believe this is an expected issue with the cache. We renamed a php class from SVG to VectorImage in order to pass phpstan requirements from GitLab CI on the Drupal infrastructure.

@webmestre After rebuilding the Drupal cache, does the error go away?

I created an MR, but the potential issue here is that Drupal’s packager provides a default .gitattributes file, so by adding this file to our module repository, the module maintainer assumes responsibility for keeping it in sync with the scaffold file from Drupal infra.

Perhaps the better solution would be to have Drupal infra to just exclude .ddev folders from all package builds.

jwilson3 → created an issue.

This was reported upstream https://github.com/ddev/ddev/pull/6941 and has been fixed in DDEV HEAD.

Expected Behavior

ddev config should work even if a module of a Drupal project has a .ddev in it (which often happens when using the ddev/ddev-drupal-contrib add-on)

Actual Behavior

In v1.24.2, if you do a ddev composer install that happens to pull in a component (like a Drupal module) which had a .ddev directory, you can't ddev config the project.

The workaround for now (until next ddev release is available) is: ddev delete -Oy svg-image-field

Thanks for filing. I'll have a look.

Thanks for the review and merge. This is included in release 2.3.4 →

👍

This critical Drupal 11 compatibility issue has been included in the latest SVG Image Field module release 2.3.4 →

Note we still have a follow-up issue pending to get the new constraint validator (the fix introduced here) working on the modal forms:

📌 Svg Image Constraint Validator is not used in Media Library modal upload form Active

Thanks everyone!

I’ve found a different module that purportedly does work and has a lot of installs, but it requires a bit more manual configuration to get it correct, which means more testing and review is required rather than this module which is basically "set it and forget it" (except that it doesn't work).

https://www.drupal.org/project/ckeditor5_paste_filter →

Yes, for now the D9 compatibility should be kept. Eventually it makes sense to remove support but since it is not a burden yet, were okay to keep it. will review and test soon. Thanks so much for collaborating.

Before:

After:

jwilson3 → created an issue.

Some screenshots

jwilson3 → created an issue.

Thanks folks for helping with the fix here.

With this issue fixed, I believe the module should now be fully compatible with Drupal 11.

While working on this issue, I noticed some deprecation warnings related to views integration for bleeding 11.2.x branch (release date scheduled for June 2025).

I've created a follow-up: 📌 Drupal 11.2.x compatiblity Active