🇺🇸United States @ultimike

During DrupalEasy Office Hours, we moved one of the callbacks into the Hook class - I would love for one of our alumni to follow our lead and move the other callback - have at it!

-mike

I spoke with James about the phpstan.neon bit during DrupalEasy office hours and we decided that it would be best to remove the changes to phpstan.neon, and possibly open a new issue about updating the config.

I think this is ready to merge - anyone want to +1 it?

-mike

Where does drupal-canvas/ddev-drupal-canvas-dev even come from? When I try to ddev add-on get ddev add-on get drupal-canvas/ddev-drupal-canvas-dev, I get an error:

unable to get releases for ddev-drupal-canvas-dev: GET https://api.github.com/repos/drupal-canvas/ddev-drupal-canvas-dev/releases?per_page=100: 404 Not Found []

drupal-xb/ddev-drupal-xb-dev is still available here: https://github.com/drupal-xb/ddev-drupal-xb-dev - maybe this is a case of the documentation getting ahead of the code?

-mike

We still need to change the minimum version to 10.1.

I'm going to take first crack at this issue (with @nicxvan's help.)

-mike

Setting back to Fixed, as I think this was just a bad config issue on my part.

As part of my earlier debugging attempts with this, I had manually added an ignored_types: {} to my active config. At some point after adding this is when I ran the update hooks and I think this is where things went just a teeny bit sideways for me.

I just did the following and all appears to be working fine on my local now:

1. Removed my manually added ignored_types: {}
2. Temporarily renamed the schemadotorg_additional_type_update_10003() and schemadotorg_additional_type_update_10004() hooks to schemadotorg_additional_type_update_10013() and schemadotorg_additional_type_update_10023(), and then re-ran database updates.

Sorry for the false alarm!

thanks,
-mike

I did some debugging and I think the issue is with ignored_types from schemadotorg_additional_type.settings - I ran out of time before I found a reasonable fix.

I can circumvent the issue by adding |NULL to the $value argument of:

  public static function yamlEncodeFromConfig(array<strong>|NULL</strong> $value): string {
    $yaml = $value ? Yaml::encode($value) : '';
    // Remove return after array delimiter.
    $yaml = preg_replace('#((?:\n|^)[ ]*-)\n[ ]+(\w|[\'"])#', '\1 \2', $yaml);
    return $yaml;
  }

-mike

I am making a minor unrelated text change to the README.md file while demonstrating DrupalForge.

-mike

When trying out the latest -dev release (after this MR), I went to the /admin/config/schemadotorg/settings/types page and received this fatal error:

The website encountered an unexpected error. Try again later.

TypeError: Drupal\schemadotorg\Element\SchemaDotOrgSettings::yamlEncodeFromConfig(): Argument #1 ($value) must be of type array, null given, called in /var/www/html/web/core/lib/Drupal/Core/Form/ConfigTarget.php on line 188 in Drupal\schemadotorg\Element\SchemaDotOrgSettings::yamlEncodeFromConfig() (line 248 of modules/contrib/schemadotorg/src/Element/SchemaDotOrgSettings.php).
Drupal\Core\Form\ConfigTarget->getValue() (Line: 113)
Drupal\Core\Form\ConfigFormBase->loadDefaultValuesFromConfig() (Line: 117)
Drupal\Core\Form\ConfigFormBase->loadDefaultValuesFromConfig() (Line: 117)
Drupal\Core\Form\ConfigFormBase->loadDefaultValuesFromConfig()
call_user_func_array() (Line: 1010)
Drupal\Core\Form\FormBuilder->doBuildForm() (Line: 571)
Drupal\Core\Form\FormBuilder->processForm() (Line: 321)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->{closure:Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::wrapControllerExecutionInRenderContext():121}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->{closure:Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::onController():96}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 53)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 715)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Maybe the jsonld_values value isn't initialized properly?

I tried adding jsonld_values: { } to my local schemadotorg_additional_type.settings config, to no avail.

-mike

@jofitz, @lostcarpark,

Thanks so much for all your efforts on this task - it's looking great!

I just pushed a few minor wording, formatting, and dead code changes.

Before I merge, there's a couple of unresolved questions (see above) about whether this issue should trigger a minor or maintenance release and the bleedingEdge.neon addition.

thanks,
-mike

ultimike → created an issue.

This is done.

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.