🇺🇸United States @ultimike

Merged and credit given to @lostcarpark via new contribution record thingy.

-mike

@damienmckenna - thanks for the MR and the change.

I went ahead and changed the order of the checkboxes so that "Strip HTML" is at the bottom.

During DrupalEasy Office Hours, we noticed that there were a couple of PhpStan issues for next minor and previous major - we attempted to fix them all, but ran out of time so I suspect there's still a little more work to do.

One is a bit of a chicken-and-egg issue, where support for annotations is deprecated and will be removed in Drupal 12, but using annotations results in PhpStan issues with previous major. Any ideas?

We didn't have time to try this, but maybe something like this is the solution?

/**
* Test the smart trim tokens.
*
* @group smart_trim
*
* @phpstan-ignore-next-line
*/
#[Group('smart_trim')]

-mike

@ultimike wuz there 2025 🤘🏼

I haven't done a full code review yet, but some initial thoughts:

1. I would love an MR instead of a patch, but I know how old-school @dsnopek is so I'll let this one slide (for now.)
2. I would much prefer if the "Allowed HTML tags" text field appeared directly under the "Strip HTML" checkbox. Perhaps we can change the order of the checkboxes to move "Strip HTML" to the bottom and then move "Allowed HTML tags" underneath it.

thanks,
-mike

@jofitz - thank you so much for your effort on this - I can't wait to merge it in!

I left some comments via GitLab above.

A couple of additional things. You wrote:

I have addressed @lostcarpark's comments on the MR (not sure how to resolve the one that has been replaced)

Neither @lostcarpark nor I understand what you're referring to here. Please elaborate.

I was also wondering what you think about possibly adding an "extension" array to the Attribute. This could be used to list the extensions in the attribute rather then in addExtensions(). Then each plugin wouldn't need addExtensions() - that could be moved to the base plugin and extensions added by iterating over the attribute array. I'm not suggesting that we have to do it this way, just looking for feedback/pros/cons.

thank you!
-mike

@gustavorf90 - thanks for the MR! I have a few small suggestions - see above.

thanks,
-mike

Dries mentioned a similar idea that he had implemented via a custom module - see https://dri.es/switching-to-markdown-after-20-years-of-html

These tokens get processed by my custom Drupal module and transformed into full HTML. That basic image token? It becomes a responsive picture element complete with lazy loading, alt-text from my database, Schema.org support, and optional caption.

@anruether -

Thanks for the kind words.

Yes, I believe that autolinks work as advertised in Markdown Easy.

To confirm: create a text format that uses only the Markdown Easy filter with either the GitHub or Smorgasbord flavor, then create a node that uses your new text format an add content that includes a URL like "This is a URL: https://drupal.org". Save and view the node and the drupal.org text should be a link - this is autolinking in action.

Your question did spur me to confirm that I had the documentation correct - which I did not, so thanks for that! It is fixed now.

Please let me know if this all makes sense so we can mark this issue as closed.

thanks,
-mike

Corrected feature list of the various flavors.

ultimike → created an issue.

Thank you!

-mike

Added details about various flavors.

ultimike → created an issue.

2.0.0 has been released - looking forward to the re-roll!

thanks,
-mike

ultimike → created an issue.

Hey now.

ultimike → created an issue.

2.0.0 release tagged!

I've left some minor comments about a few of the code comments above.

Testing this on my local, I had version 1.2.1 installed. I checked out this MR, rebuilt caches, and ran `drush updb` and the 10001 update hook fired as expected without any issues.

I did notice that if I made changes on /admin/config/development/devel/toolbar, I needed to rebuild caches before the changes were reflected in the menu - maybe do a form alter to rebuild caches when that form is submitted?

Regardless, everything else looks super-solid! I'll RTBC this because nothing I found is a deal-breaker.

-mike

ultimike → created an issue.

Added reference to markdown_easy.api.php file.

Added info about the breaking change from the hook implementation update!

Added "Markdown Smörgåsbord"

Actually, I'm going to leave this issue open as once the 2.0.0 release is made, I'll need to update the project page with the changes listed above.

-mike

Thanks - merged.

-mike

Minor change for clarity.

I just added some info about changes to the project page as well.

@lostcarpark - good idea in your comment 8, I'll add that as well. Okay to RTBC then?

thanks,
-mike

@lostcarpark - thanks so much, the changes look good and all tests are passing. Merging!

thanks,
-mike

Thanks, @joachim!

In case anyone stumbles upon this issue in the future, the fix was in the drupal-code-builder/drupal-code-builder dependency. Here's the fix: https://github.com/drupal-code-builder/drupal-code-builder/commit/fe307b...

-mike

$ ddev composer show nikic/php-parser
name     : nikic/php-parser
descrip. : A PHP parser written in PHP
keywords : parser, php
versions : * v5.6.0
released : 2025-07-27, this week
type     : library
license  : BSD 3-Clause "New" or "Revised" License (BSD-3-Clause) (OSI approved) https://spdx.org/licenses/BSD-3-Clause.html#licenseText
homepage : 
source   : [git] https://github.com/nikic/PHP-Parser.git 221b0d0fdf1369c71047ad1d18bb5880017bbc56
dist     : [zip] https://api.github.com/repos/nikic/PHP-Parser/zipball/221b0d0fdf1369c71047ad1d18bb5880017bbc56 221b0d0fdf1369c71047ad1d18bb5880017bbc56
path     : /var/www/html/vendor/nikic/php-parser
names    : nikic/php-parser

I get this error when running Drupal 11.2 locally with PHP 8.3 (via DDEV) and the most recent version release version of this module. I can't speak to the original poster or the issue summary.

-mike

ultimike → created an issue.

Added 2.x info.

I dug into this one a bit and I don't think that line is actually necessary.

It was added early on in 📌 Support additional extensions Active , but was never removed as the MR evolved.

I also removed a default setting for the "tips" form element, which is just static text.

Additionally, I searched in core and a bunch of contrib modules for a something similar and found nothing. There is a setConfiguration() method in web/core/modules/filter/src/Plugin/FilterBase.php, but I don't think it is relevant here.

Tests are passing without this code, and I can't think of any reason why it might be necessary.

Thoughts?

-mike

ultimike → created an issue.

Woot! Merged.

thank you!

ultimike → created an issue.

Why is this "Closed (won't fix)"? This is a real issue with PHP 8.3 and there appears to be a patch to fix it. What am I missing?

Without support for PHP 8.3, this module isn't really compatible with Drupal 11.

-mike

I just found and removed a duplicate warning message about missing HTML tags.

Setting back to "Fixed". Confirmed with @lostcarpark that he changed the status by accident 😃

-mike

@bart lambert - yes, that is my experience.

-mike

It was a bit of a battle, but I believe I've updated this to the current 2.0.x branch.

I'll definitely have to add something to the release notes about this issue as well as update the project home page → and the docs → .

Merging - thank you, @lostcarpark!

Marking at RTBC based on @lostcarpark's last comment.

I created a MR that:

1. Refactors the "tips" render array at @lostcarpark suggested.
2. Adds a tip for "Standard markdown"
3. Hides the tips when skip_filter_enforcement is enabled (with test)

Based on an idea from @warped during DrupalEasy office hours, I refactored a few lines of code having to do with finding the missing tags and attributes. All tests continue to pass, so I have merged this. Thanks, everyone!

I added info about this feature to the docs → .

Added power user modes info.

Thanks for the review, @lostcarpark. Merged.

-mike

Note to self: do we also need a tip for "Standard Markdown" allowed tags?

Discussed during DrupalEasy office hours. Mike will merge 📌 Improve interaction with HTML filter Active and ✨ Create new "power user" flag to disable warnings and validation Active and then we can whip out a MR for this task - no test is necessary as the tips list is static.

-mike

@camhoward brought this up during DrupalEasy office hours and we looked into it a bit and based on our conversation, I have a couple of questions that might help inform the best path forward:

1. Personally, I'm not sure what the goal/point of 📌 Menu Local Tasks should be sorted by alphabet if there is no weight set Needs review was. What problem was it solving? I'm not saying that I don't think it makes sense, but it would be good to know what prompted it in the first place.
2. I would really like to know how many *.links.task.yml files in core would need to be updated to include weights. I think this would be a valid data point. A quick search shows 27 or so. As each are updated, would a test be needed for each (or would that be overkill?)

We also discussed what effect of this issue's MR !12697 would have on contrib and custom modules, and we came to the consensus that it doesn't really affect contrib and custom modules. If anything, a blurb about 📌 Menu Local Tasks should be sorted by alphabet if there is no weight set Needs review would have probably been helpful in the 11.2.0 release notes.

-mike

ultimike → created an issue. See original summary → .

ultimike → created an issue.

If sponsors are going to be a big part of what makes DrupalForge possible, then prime real estate should be provided on the home page for sponsor logos and links, IMHO.

-mike

Part of this issue is that at entry is not added to the subtheme's libraries.yml file of the form:

subtheme-name.layout.page:
  css:
    theme:
      styles/css/generated/subtheme-name.layout.page.css: { }

-mike

ultimike → created an issue.

lostcarpark → credited ultimike → .

@lostcarpark - your changes are fine with me and much appreciated.

thanks,
-mike

Alrighty, I think this one is ready for review. It ended up being a bit more work that I originally planned, but I think it will be useful. When a user submits a new or edited text format, if Markdown Easy is enabled and the "Limit allowed HTML" filter is missing any tags or attributes that prevent full compatibility with the selected Markdown Easy "flavor", then a non-blocking warning message appears of the form:

For full compatibility with the selected Markdown flavor, add the following tags and attributes to the "Limit allowed HTML tags and correct faulty HTML" filter: <a class href role title> <img alt src title> <li class id role> <del> <input checked disabled type> <sup id>

I'm thinking about changing the first few words to "For (optional) full compatibility...", but I'd like some feedback on it first.

This check is made as part of the text format validation, so if skip_filter_enforcement is enabled (from ✨ Create new "power user" flag to disable warnings and validation Active ) then this warning will not appear.

-mike

@lostcarpark - based on our Slack conversation, I've added the additional <a class role> and <li class role id> attributes to fully support Markdown footnotes.

thanks!

-mike

Looks good, @lostcarpark!

I especially like the bit about only loading the library when the proper alignment syntax is present! 🤘🏼

Also, thanks for consolidating some of the test strings into constants.

Merged.

thank you!
-mike

Great! Thanks @nexusnovas and @lostcarpark 😃

-mike

I did some things:

1. Created new issue for duplicate tags mentioned in comment 5 📌 Duplicate tags in schema Active
2. Created new issue for potential settings merging issue mentioned in comment 5 📌 Doublecheck settings being merged Active
3. I've updated the README.md with information about the new configuration options.
4. I've added a post-update hook to add the new config (good idea - thanks! New test with it!)
5. Excellent catch about the Status Report stuff - should be fixed now (also with a new test.)

Next step - I need to update the Advanced Configuration documentatio → n with the new hidden config options.

-mike

ultimike → created an issue.

ultimike → created an issue.

Heh - I accidentally did the MR against 1.x, not 2.x so many of the changes you were seeing are not relevant to this issue.

Should be better now.

That being said, regarding your comments:

#1 is indeed a small bug/typo, I'll fix that.
#2 - I'm going to leave it in for now.
#3 - yes, it is a breaking change, and I do plan on adding a note about it to the release notes for 2.0.0.
#4 - ah, good point. I need to take a closer look at that.

I'll open issues for #1 and #4. Thanks!

-mike

Woot! Merged.

-mike

A note about setting 'html_input' = 'allow' - while testing, I learned that Markdown inside of an HTML element will not be processed into HTML. This is by design by the CommonMark library.

For example, if the text is:

But we’ve met before. That was a long time ago, I was a kid at [St. Swithin’s](https://chrisnolan.fandom.com/wiki/St._Swithin%27s_Home_For_Boys), It used to be funded by the Wayne Foundation. It’s an orphanage. My mum died when I was small, it was a car accident.

then a link to St. Swinthin's will not be created, as the Markdown syntax is inside of an HTML tag.

Once this is committed, I'll move on to 📌 Improve interaction with HTML filter Active .

-mike

nicxvan → credited ultimike → .

I couldn't find an issue for adding documentation for this new feature - is it planned somewhere?

-mike

Ready for review. These changes are really only useful for the 1.0.x branch because 📌 Improve interaction with HTML filter Active , ✨ Create new "power user" flag to disable warnings and validation Active , and 📌 Remove/lesson dependency on "Convert line breaks into HTML" Active will modify this behavior.

As suggested above, core issue created: ✨ Provide warning on Site Status page when "Limit allowed HTML tags" filter is not used? Active

-mike

ultimike → created an issue.

ultimike → changed the visibility of the branch 1.0.x to hidden.

ultimike → changed the visibility of the branch 3530329-filter-enforcement-and to active.

ultimike → changed the visibility of the branch 3530329-filter-enforcement-and to hidden.

ultimike → changed the visibility of the branch 3530329-filter-enforcement-and to active.

ultimike → changed the visibility of the branch 3530329-filter-enforcement-and to hidden.

Changing my mind - going back to 1.0.x 😃

Changing to 2.0.x

I created a new issue for the creation of a new setting for disabling guardrails: ✨ Create new "power user" flag to disable warnings and validation Active

For the rest of the issue, assuming we go with option 1 from above ("Validate on save, and warn about any missing tags for the selected Markdown flavor.") I'd like to focus on the MVP and then potentially open new issues for @lostcarpark's "nice to haves". With that in mind, as we already have a "Tips" section on the Markdown Easy config form, how about we add the list of tags that need to be added to the corresponding bullet. For example:

• GitHub-flavored Markdown includes the following extensions: Autolinks, Disallowed Raw HTML, Strikethrough, Tables, and Task Lists. Add the following tags to the "Limit allowed HTML tags" filter for full support: <del> <table> <thead> <tbody> <tr> <th class> <td class> <input type checked disabled>
• Markdown Smörgåsbord includes everything from GitHub-flavored Markdown plus the following extensions: Footnotes, Description lists. Add the following tags to the "Limit allowed HTML tags" filter for full support: <sup id> <dl> <dt> <dd>

Then, upon the saving of the text format, display a non-blocking warning if any tags are missing for the selected Markdown Easy flavor.

I don't think these warnings need to appear on the Site Status page. A missing "Limit allowed HTML tags" filter warning is fine, but I don't think we need to worry about missing tags on that page.

Finally, I'd really like to keep 'html_input' => 'strip' as-is. I've worked on too many sites where folks have copy/pasted crazy HTML from another source into a body field not understanding what the consequences are. Besides, it is (and has been for some time) documented here → how to change it. Perhaps this is a discussion in a new issue for another hidden config variable in the future.

-mike

ultimike → created an issue.

Looks super-duper to me. Merged into 1.0.x and cherry-picked into 2.0.x

@lostcarpark - thanks for the test!

-mike

I really like this discussion.

That can be useful for enforcing layout or editorial rules.

This was my original reason. I was thinking that site admins might want to make Markdown available to authors, but also limit what they are allowed to do with it. I've been assuming this is the 80% use case. Perhaps I'm wrong?

Is the 80% use case users who will want/need/understand the full power of the Markdown flavor they choose?

Images are at the front of my mind here - allowing images added via Markdown seems problematic as they would bypass Drupal's image styles and potentially break layout.

I think what we're discussing here is what is the best default config for this module. "Best" being defined as "secure" and "serving the highest percentage of users".

As for:

I am warming up to the idea of having a setting to disable the guardrails. It would be nice not to maintain a custom module just to turn this off.

As am I. How about a hidden (no UI) config variable. Something like "disable-all-warnings" (or "power-user-mode") that can be set by flipping a boolean in config. I would include documentation for doing this in the "advanced" section of the docs. If this is agreeable, I'll open a new issue for this.

-mike

I just remembered another bit about my thinking that the "Limit allowed HTML tags" filter should remain after Markdown Easy...

Since Markdown is configured with 'html_input' => 'strip' by default, the "Limit HTML tags" filter is really to prevent authors from adding wild-west HTML that the design doesn't support.

For example, by stripping out <img> tags, it forces the author to use Markdown style images - which leads to more predictable HTML. But, if the site design doesn't allow inline HTML images, they can be removed by "Limit HTML tags" regardless of what Markdown syntax the author added. Same for things like table and other elements that Markdown will happily process, but may not be wanted/allowed by the site design.

Then again, if the user chooses to change the 'html_input' => 'strip' setting, all bets are off and they're on their own.

-mike

I opened 📌 Support Markdown table alignment Active for the table cell alignment stuff.

-mike

ultimike → created an issue.

This is a very cool idea. I think I would want to do it with an AJAX call though, so that we are 100% guaranteed to be using the same Markdown config for both preview and display.

Maybe horizontal tabs for "Raw" and "Preview", with the AJAX triggered when switching to the "Preview" tab?

Let's give this one some more thoughts once #3530290 and a few others are behind us.

-mike

Before finalizing this issue, let's decide on #3530906

(Very) temporarily postponing this issue.

-mike