Create new "power user" flag to disable warnings and validation

Thanks for opening this. My personal preference would be to introduce multiple config variables rather than a single catch-all flag like power_user_mode. For example, something like:

• skip_filter_enforcement
• skip_html_input_stripping

Personally, I would want to disable both, but I could see others wanting to disable just one or the other.

As more options get added over time, I could see power users wanting different combinations of behavior. Having discrete flags keeps it flexible and future-proof.

You could always do both. Support individual variables, but wrap them like this:

if ($config['power_user_mode'] ?? FALSE) {
  $skip_filter_enforcement = TRUE;
  $skip_html_input_stripping = TRUE;
}

This could give us the best of both worlds: fine-grained control and a simple, global override.

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

I looked at the MR, and the code looks good. I've not tested it yet.

I noticed 4 things:

1. In config/optional/filter.format.markdown.yml, line 23, <dl> <dt> <dd> appears twice in allowed_html list. Not a bug, but could be tidied up.

2. With the new global settings, do we still need hook_markdown_easy_config_modify()? I guess the hook is still useful for advanced customization that is not possible through settings alone? I don't have experience with the hook, so figured I'd call it out.

3. I believe the below is a breaking change that will cause fatal errors for existing sites with custom modules implementing the old hook. I doubt many implemented this hook, but still. I'll let you decide if it is worth fixing or not. It might be sufficient to document in the release notes.

// OLD:
function hook_markdown_easy_config_modify(MarkdownConverter &$converter) {

// NEW:
function hook_markdown_easy_config_modify(array &$config) {

4.

public function settingsForm(array $form, FormStateInterface $form_state): array {
    $this->settings = array_replace_recursive($this->defaultSettings(), $this->settings);

The fact that defaultSettings() are only merged in settingsForm(), and not in the constructor or process(), feels off. That said, it might be 100% valid. I'm thinking that if the filter ever processes text without the form being loaded first, it could result in unexpected behavior? I wonder if it makes more sense to initialize $this->settings in the constructor.

I'm not an expert in this codebase, so these may not be actual bugs. Thank you for working on this. These are exactly the changes I’d love to see and use.

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

The simplified MR looks great to me. I still haven't tested it, but don't block on me as I'm traveling extensively the next week. I'm glad to see solid test coverage.

Does this need something in README.md covering the new settings (and how to set them without a UI).

Also, there's a new install file for markdown_easy.settings.yml to set up the new settings when first installing the module, but these will not be created for existing installs. I don't think this will be an issue, as the settings will default, but should there be an update hook to add them to keep things tidier?

I set the skip filter enforcement with:

ddev drush config:set markdown_easy.settings skip_filter_enforcement 1

I then tested that I could disable the other filters without issues.

Next, I set skip input stripping with:

ddev drush config:set markdown_easy.settings skip_html_input_stripping 1

I tested that tags added in the node with the filter applied were allowed to pass through.

These both behaved as expected.

Setting back to 0 prevented tags in source from passing through, and forced the required filters to be enabled again.

One other thing I noticed. When markdown_easy.settings is set, the status page still warned about the missing filters.

Is this the correct behaviour?

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