🇺🇸United States @ultimike

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

My thoughts on the four options (largely based on the discussion in #3493938):

1. Validate on save, and warn about any missing tags for the selected Markdown flavor. - if we were only considering options 1-3, I think this would be the easy choice.
2. Autoconfigure allowed tags based on selected flavor. - I'm not a fan of modifying config for users. 👎🏼
3. Make the HTML filter optional. This would be a potential security risk. - nope. 👎🏼
4. Move the HTML filter before the Markdown Easy filter. - this is an interesting idea. One of the tenants of my initial vision for the module was to make it "secure by default" in a way so that folks new to Markdown didn't even have to think (or know or care) about it in order to be secure. One of the things this decision drove was to use the Markdown config 'html_input' => 'strip', - so, if "Limit HTML" is moved before "Markdown Easy", it doesn't really matter what HTML is allowed, as it will be neutralized by Markdown Easy (unless the user overrides 'html_input' => 'strip', via hook_markdown_easy_config_modify()).

So, unless I'm thinking about this wrong (which is entirely possible), I think option 1 is the best way to go. If we do this, I think it should only be a warning, not a validation error, and should depend on the selected Markdown Easy flavor. For example, if GitHub or Smörgåsbord is selected, then the warning should look something like:

Consider adding the following HTML tags to the "Limit allowed HTML" filter configuration to fully support the Markdown Easy Flavor you selected:

• For Task Lists: <input type checked disabled>
• For Tables: <table> <thead> <tbody> <tr> <th class> <td class>
• For blah: <some> <other> <tag>
• etc...

Thoughts?

-mike

Going backwards...

Issue 2 should be resolved in #3493938 🎉

Issue 1 is something I'm not unaware of. Perhaps it is something that can be corrected with some updated language. When I originally wrote the module, I wanted it to be secure by default, and not easy to make insecure (by not using the "Limit HTML" filter.) With the "strongly recommended" language, I meant that it can't be made insecure via configuration - only by implementing a hook (which I documented here → .)

Note to self, once I tag a 2.0.0 release, I need to update the documentation page.

So, we could change the language to be more clear on this point, or add a configuration option to remove this dependency? If we do the latter, should it be a global configuration (which I kind of like because it would not be on the text format add/edit page and thus a slightly higher hurdle) or a per-text-format option? Or, is there another option to be considered?

thoughts?

-mike

Changing to work against the 2.0.x branch. Hopefully, no refactoring necessary. 🤞🏼

Great - thank you, @lostcarpark!

MR looks great (so far 😀)

I don't recall why I felt the need to encourage the use of the "Convert line breaks into HTML" text filter in the first place. I partially blame @lostcarpark because I'm pretty sure we were sitting together at Dev Days Vienna when I was working on this 😜

-mike

I goofed on the workflow a little bit, but I have merged this into a new 2.0.x branch (my goof was not creating a pushing the 2.0.x branch before merging locally.)

Anyway, I'm marking this as Fixed and hopefully giving everybody the proper credit.

Thanks, everyone!

-mike

ultimike → created an issue.

Rats - I didn't see this issue until after I added these in #3493938 - sorry!

-mike

@dries - thanks. "small things" added.

Also - after chatting with @lostcarpark about comment 18, he convinced me that we should move it into a new issue. So, once this issue is RTBCd, I'll create a 2.0.x branch, merge this issue into that, and then we can work on the future issue from comment 18.

-mike

I want to consider another change to this MR before merging...

Currently, the Markdown Easy module strongly suggests (requires, mostly) that the “Convert line breaks into HTML” filter be used in conjunction with the Markdown Easy text filter.

There are many potential use cases where it would be advantageous for the Markdown parser to completely own the HTML, and not rely on the “Convert line breaks into HTML” filter at all. So, I would like to look into changing the default config for the two new flavors introduced in this issue so that they do not require the “Convert line breaks into HTML” filter. This way, if someone is copy/pasting Markdown from another source, the output is consistent.

If we make this change, the module documentation will need to be updated as well (I just updated it with the hook changes introduced in this issue.)

Finally, once merged, as @lostcarpark suggested, I'll tag and release a 2.0.0 version of the module.

Thoughts?
-mike

I just found and fixed some issues in the markdown_easy.api.php file as well as some code comments related to the markdown_easy hooks.

-mike

Added info about new hook added in 2.x branch.

Updated with 2.x branch changes.

@b_man - thanks, looks great!

-mike

lostcarpark → credited ultimike → .

lostcarpark → credited ultimike → .

ultimike → created an issue.

nicxvan → credited ultimike → .

teknorah → credited ultimike → .

teknorah → credited ultimike → .

ultimike → created an issue.

rachel_norfolk → credited ultimike → .

ultimike → created an issue.

@avpaderno all valid questions to which I have no answers.

But, we need to collect input and samples before deciding the best path forward.

-mike

Here's the text of an AI disclosure that will appear on a future DrupalEasy blog post that will go to Drupal Planet:

AI was used to create the initial outline for this blog post using DrupalEasy's Professional Module Development curriculum as the source material. We support AI disclosure statements on all content that is posted to Drupal Planet ✨ Should content appearing on Planet Drupal have content notices if they are generated using AI such as ChatGPT? Active .

-mike

Updated status to Needs Review.

ultimike → created an issue.

Woot! Ready for a review.

Before and after screenshots added.

-mike

nicxvan → credited ultimike → .

An initial task would be to go through all the current feeds and send some emails to figure out who the listed owner of each should be...

Seems like maybe a good no-code task for a contribution day at a future Drupal event...

-mike

That is all very disappointing, but I understand. ☹️

This is now a much bigger task than I imagined....

-mike

@avpaderno - I'm not sure if it should be automatic, or more like a quarterly newsletter with different content each time reminding feed owners of the quality standards for posting on Drupal Planet.

As a first step, sure, an automatic reminder each quarter is fine, but I think we should aim higher.

Also - I wouldn't be against temporarily removing publishers whose current emails bounce. Being on Drupal Planet is a privilege, and should be treated as such.

-mike

I think it should be a requirement of posting on Drupal Planet - publishers should have to disclose any use of AI in the authoring of the post and/or images used in the post.

We (the Drupal community) could even provide suggested text or badging that publishers could use.

-mike

@ressa - I agree wholeheartedly, but I think that your idea should be spun off into a different issue.

I chose the two items in the issue description because I think they are easily achievable in the short term.

Thinking about the "AI disclosure" a bit more - we (the Drupal community) could even provide suggested text or badging to make it easier for authors to comply.

-mike

ultimike → created an issue.

Wow - this is all super-helpful. Huge kudos to @pdureau for taking this on.

As someone new to SDC, this discussion has been especially helpful in filling in some knowledge gaps for me.

-mike

ultimike → created an issue.

Initial best practices document published: https://www.drupal.org/node/3516295 →

Is there any reason not to close this issue?

-mike

I have been working on this in a separate Google Doc and will publish very soon - if anyone would like access to the doc, just ask.

-mike

If we focus on the title of this issue, I think that https://www.drupal.org/ixp → is actually complete enough for launch. Anyone feel differently?

-mike

@swirt Understood. I definitely think we need to somehow include content from your comment 3 above, and the Contrib First link, in our best practices document.

I might just copy/paste parts of your comment directly into the draft version of the best practices doc for now...

-mike

This issue feels overly broad to me.

Regarding @swirt's comments, I've responded to them in 📌 Develop IXP Best Practices Documentation Active

@chrisck - what do you are feel the short-term, achievable tasks for this issue? Maybe we can break those into individual issues?

You wrote:

Could the IXP initiative find a way to engage public organizations?

This is absolutely a goal for us (along with engaging other types of organizations), but I think it all comes down to messaging, correct? Do you feel that there are any structural additions we can make to the program to make it easier for government agencies to participate?

One of my goals is definitely for the IXP to have some visibility at every "summit" event at DrupalCons and other Drupal events - at the very least, maybe just a few minutes to introduce the program to summit attendees.

Thoughts?

thanks,
-mike

@flux423 - focusing only on the "IXP Survey" tab of the GoogleDoc, I think it is a no-brainer to move this along.

My main question to everyone is this: how do we use the resultant data? I think we need specific answers to this, including who will be doing the work to utilize the data. I don't think we should start this effort until we have a "realistic in a reasonable time frame" plan in place.

Some initial ideas:

• Additions to "best practices for IXPs" and "best practices for employers" pages (neither exists as of this moment, but I'm currently working on the latter.)
• A blog post suitable for general (Drupal) audiences.

-mike

mradcliffe → credited ultimike → .

@swirt - I'm putting together a "case studies" page for IXP. Is there any chance that you can turn your comment 3 above into a blog post somewhere? Ideally, it would be on https://medium.com/civicactions...

I would love to see the link to https://guidebook.civicactions.com/en/latest/common-practices-tools/cont... highlighted as well.

Thoughts?

thanks,
-mike

ultimike → created an issue.

Thanks!

-mike

swirt → credited ultimike → .

Following up on @kappaluppa's comment...

This was a bit of a tricky issue to reproduce as the form validation doesn't allow us to add an invalid link from an add/edit page that triggers the exception that needs to be logged. To get around this, we created a node with a link field with a valid URL, and then modified the uri value directly using SQL (see values in previous comment.)

Invalid values like this can be created via data migrations with malformed urls (as migrated link uri values are not always validated.)

Tests are still needed for this issue.

-mike

volkswagenchick → credited ultimike → .

This doesn't feel like a novice issue to me - I'm removing the tag.

-mike

Tim - this is all very exciting!

A couple of requested text changes/additions:

Developer hub

On https://jobs.drupal.org/ixp-developer-hub, please change:

The IXP Fellowship Program exists to promote opportunities for inexperienced developers to level up their Drupal skills by working for participating Drupal agencies.

To:

The IXP Fellowship Program → exists to promote opportunities for inexperienced developers to level up their Drupal skills by working for participating Drupal organizations . In exchange, once the mentoring engagement is complete, the participating organization is awarded contribution credits → .

IXP developers are inexperienced, but trained Drupal developers. If you have less than three months of paid Drupal experience, then you qualify for this program.

Contribution credits

Do we want to add the IXP hiring organization credit reward here and link back to the /ixp page?

thank you!

-mike

Wow - really great work so far - thanks so much!

I think the main page → , the What is an IXP? → , and IXP for new developers → are all ready to go - I made relatively minor changes to each of them.

That leaves IXP for organizations → and IXP for volunteers/reviewers → .

@anilu@ @camoa, do either of you have the content for either of these pages ready-to-go somewhere or will it need to be created (mainly from our "process" Google doc?)

I think the "IXP for organizations" page has a much higher priority, as that's what we want to be focusing on at DrupalCon next week - finding participating organizations.

-mike

ultimike → created an issue.

mradcliffe → credited ultimike → .

mradcliffe → credited ultimike → .

mradcliffe → credited ultimike → .

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

ultimike → created an issue.

@camoa and I have information from @horncologne and @flux423 that needs to be synthesized and added here.

-mike

ultimike → created an issue.

ultimike → created an issue.

I'm changing the title of this issue so that we have separate issues for best practices documentation for employers and employees (IXPs.)

-mike

ultimike → created an issue.

Maybe we want to build out the IXP home and sub-pages from https://www.drupal.org/ixp → ?

Regardless, IMHO, the near-term goal is to determine a hierarchy of pages that we'll need for launch. How about:

https://www.drupal.org/ixp → - main page that includes overview, summary of requirements, and links to sub-pages
https://www.drupal.org/ixp/employer-requirements → - employer requirements for contribution credit
https://www.drupal.org/ixp/employee-requirements → - who can apply for IXP positions
https://www.drupal.org/ixp/case-studies → - see 📌 Collect case studies from existing programs Active
https://www.drupal.org/ixp/best-practices-employers → - see 📌 Develop IXP Best Practices Documentation Active
https://www.drupal.org/ixp/best-practices-employees →

Much of the information for the main page and two requirements pages can come from 🌱 IXP Phase 2 proposed process Active

-mike

I think this is a duplicate of 📌 Develop IXP Best Practices Documentation Active - marking as such.

-mike