[PP-1][markdown] Drupal 9 Support

Now that Drupal 9 has been released, I can confirm that what is described in the issue summary and is in the patch actually does work. After modifying Drupal core's composer.json as shown in the issue summary to enforce the updated composer metadata:

$ composer require drupal/markdown ^2.0@dev
    1/1:	http://repo.packagist.org/p/provider-latest$9ae020164ffb0616f81d6753f72a395d892edb3c85cad609ac7b2875ef757911.json
    Finished: success: 1, skipped: 0, failure: 0, total: 1
./composer.json has been updated
> Drupal\Composer\Composer::ensureComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
    1/1:	https://codeload.github.com/thephpleague/commonmark/legacy.zip/5a67afc2572ec6d430526cdc9c637ef124812389
    Finished: success: 1, skipped: 0, failure: 0, total: 1
Package operations: 2 installs, 0 updates, 0 removals
  - Installing league/commonmark (1.3.3): Loading from cache
  - Installing drupal/markdown (2.x-dev 8.x-2.x): Cloning 8.x-2.x from cache
drupal/markdown suggests installing webuni/commonmark-attributes-extension (Adds Attribute support for the CommonMark parser.)
drupal/markdown suggests installing webuni/commonmark-table-extension (Adds Table support for the CommonMark parser.)
drupal/markdown suggests installing uafrica/commonmark-ext (Adds Strikethrough support for the CommonMark parser.)
Writing lock file
Generating autoload files
> Drupal\Core\Composer\Composer::preAutoloadDump
Hardening vendor directory with .htaccess and web.config files.
Cleaning vendor directory.
> Drupal\Composer\Composer::generateMetapackages
Updated metapackage file composer/Metapackage/CoreRecommended/composer.json.
If you make a patch, ensure that the files above are included.

That works! :)

Not sure why, although I did notice the module actually also still has the old core: key, which I've seen other version of Drupal complain about (

Yes! This should be changed too.

The problem is not so much the presence of core: 8.x (although that will be a problem too, the real problem here is that core_version_requirement was misspelled to core_version_requirment 🤫

Actually, now that I've thought about this a bit more, I'm going to remove D9 support from 8.x-2.x entirely and leave it fully 8.x compatible so that it's a proper replacement for 8.x-1.x.

I'm going to also reduce the minimum PHP version to 7.1 which is a hard requirement of league/commonmark ^1.0.0.

Drupal 9 support will be in a new 3.0.x branch with a new 3.0.0 release.

I'm going to work on getting a stable 8.x-2.0 release out this weekend so we can switch gears to 3.0.x and add support for D9.

Hi @markcarver Any chance you could open the 8.x-3.x branch so we can continue with Drupal 9 compatibility there? Thanks.

Work can't really start on this until #2952435: Merge in the CommonMark project is finished and a 8.x-2.0 release is made. I made some significant progress over this weekend, but not quite there yet.

So I've created the 3.0.x branch, but only so we can start setting issues to it. We'll need to merge commits back into this branch once it's finished.

For that reason, I'm setting this issue as postponed until such time arrives.

Drupal 9 support will be in a new 3.0.x branch with a new 3.0.0 release.

I'm going to work on getting a stable 8.x-2.0 release out this weekend so we can switch gears to 3.0.x and add support for D9.

🥳

This patch applies to the tip of the 8.x-2.x branch, including to the 8.x-2.0-rc1 release.

Anything that I can do to help with this? This is the last module that I need to updated before I can update to D9.

Since #2952435: Merge in the CommonMark project is now fixed, I re-rolled patch in #17 against 3.0.x (it was failing to apply).

In testing, I am experiencing an error while loading the /admin/config page, but I wanted to get this posted first:

TypeError: Return value of Drupal\markdown\Plugin\Markdown\PhpMarkdown::version() must be of the type string, none returned in Drupal\markdown\Plugin\Markdown\PhpMarkdown::version() (line 48 of /app/web/modules/contrib/markdown/src/Plugin/Markdown/PhpMarkdown.php)

The 8.x-2.0 release hasn't been made yet.

Issue is postponed, but I already made a patch to use this in my own D9 installation, so I'm sharing for anybody else who needs/wants to use Markdown in D9 now.

Note that my patch also requires the patch in #18.

An 8.x-3.x branch would be really nice. I could not get the patches working with composer on 8.x-2.x (using cweagans/composer-patches) probably due to version constraints which composer applies before running the patch, for now i made a custom local copy (And applied the patches there), which works fine.

@workplaysleep++ — indeed, composer resolves version constraints before applying patches, hence this is a pretty big blocker.

So it seems that at this point in time, now that #3162471: Error during install, "Serialization of 'Closure' is not allowed" (Drupal 8.9.2) is done, all that is left for a 2.0.0 release is #3152957: You must configure the selected text editor. - do I have this correct?

After that, safe to assume that the 3.x branch will be open and we have a clear path to a Drupal 9 release?

thanks,
-mike

Looking at the repository, it seems like 2.x is more up to date and 3.0.x still needs work to get done; in light of that, 2.x looks relatively close to stable, so wouldn't it make sense to add the Drupal 9 compatibility, fix any remaining deprecated code use, and get 2.0 released? It feels like a shame to have the shiny new CommonMark stuff (great work by @markcarver!) gathering dust in dev without a stable release, waiting for a 3.0 that may take a while.

Edit: if there's any remaining work to be done to make a 2.0 release happen, I'd be interested in helping out.

+1

+2 I would love to help anyway necessary.

FWIW, I did some testing with 8.x-2.x, and it didn't seem to be working at all. Markdown wasn't getting converted to HTML no matter which Markdown library I selected. I'm pretty sure that settings changes weren't getting saved either, but it's been a month or so, and I don't recall the details. This might be on me. I may have missed something in the setup process, but my testing time was limited, and I had to move on.

Meanwhile, I understand the reasons to not change 8.x-1.x because it would potentially break existing Drupal 8 sites using the old install method.

I wish I had time to help get the next release out the door, but at least I can suggest a workaround for those who need to get their existing 8.x-1.x implementations working in Drupal 9. I am neither recommending nor offering to support this, just sharing what I did.

I made a fork of markdown-8.x-1.x and applied this patch. (Note the change in vendor name!) Then I added my forked package to the repositories section of my composer.json file, just like I've done for my custom modules. This has allowed me to start moving sites to Drupal 9.

I wish I could jump in and help more with the new versions. My front-end devs are looking forward to the new CommonMark features! In the meantime, maybe this workaround can help some others find ways to get Markdown into their D9 projects, too.

Edit to add info similar to @protitude comment #35 below.

To get this working, first add to repositories section in composer.json:

        {
            "type": "git",
            "url": "https://bitbucket.org/hfccwebdev/module_markdown.git",
            "reference": "8.x-1.x"
        }

Then composer require hfccwebdev/markdown to include the module.

I recently added another patch to add Drupal 10 compatibility, and this version passes scans for D10.

Hi there,

Do we have news about this issue ?

Thanks,
Simon

Added a patch to fix the remaining D9 deprecations against 2.x-dev @ commit 94b3de98. Includes #18.

My apologies, I forgot to include the new FileSystemTrait trait in the patch. This new patch has it.

Thanks for the patches and workarounds. Is there an ETA for a version of this module that is compatible with D9? This module is holding us back.

I too am waiting for this module to catch up. But in the meantime I created a fork that will work with drupal 9.1: https://github.com/protitude/module_markdown

Then in my repositories section in my composer file I add:

"markdown": {
    "type": "vcs",
    "url": "git@github.com:protitude/module_markdown.git",
    "reference": "8.x-1.x"
},

Then I just need to include: protitude/markdown and I'm good to go. Feel free to fork from me or take what is needed from this ticket and create your own fork. Hope that helps.

@protitude, nice! I guess I could have included my platform composer snippet above.

Thanks for making my workaround even easier for people to use!

FYI: This is what I added to my repositories section:

  {
    "type": "vcs",
    "url": "https://github.com/protitude/module_markdown"
  }

Thanks @protitude for making this available!

If you prefer to apply a patch to the 8.x-1.x branch, instead of a complete fork, I have attached one. If the patch fails to apply, it may be because of drupal.org's packaging script adding additional lines to the markdown.info.yml file. To bypass this, you can instruct Composer to install the module from source:

"config": {
    ...
    "preferred-install": {
        "drupal/markdown": "source",
        "*": "auto"
    }
},

While working with my patch from #38, I became blocked when upgrading Drupal core. This seemed to be related to not having an explicit drupal/core requirement in markdown's composer.json. The docs claim this is not required, but I needed it in my testing.

The other complication is that it seems that when Composer checks the compatibility of dependencies, it happens before patches are applied, so applying a patch will not work. Now I understand all the usages of forks in this thread! I have created D.O. issue fork and am now using that in my repo.

An even better way would be to fork this issue and provide configuration as described in this blog post by Damien McKenna, which was published in today's newsletter. Relying on Github sometimes causes issues when you need to rebuild a website multiple times in a row (happened to me while I was testing the continuous integration mechanism for a website). I will have a look at it, but cannot do it right now, so feel free to do it if you have a little spare time ^^

I have attached a patch for Drupal 9 compatibility for Markdown 2.x. From my perspective, at least it doesn't make things worse. I couldn't get Markdown 2.x to work, but I gave the module just a couple of minutes. The Drupal module says in its config page that there are a couple of 3rd party libraries and the PECL-based extension installed, but it still shows markdown without any conversion directly in the HTML.

If I were the maintainer I would looks at the patch and decide it isn't risky, just commit it to 2.x.

Any update on the 8.x-3.x branch?

Hi all, FYI patch from #44 seems to be working well with 9.1.7 Thank you @Gogowitsch
It will be great to have module release supporting D9 out of the box.

I had no such luck with the patch from #44 as I got the following ServiceNotFoundException error after trying to install the patched module on a 9.1.9 site:

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "logger.channel.markdown". Did you mean one of these: "logger.channel.form", "logger.channel.image", "logger.channel.cron", "logger.channel.rest"? in Drupal\Component\DependencyInjection\Container->get() (line 151 of /app/my_site_name_dir/web/core/lib/Drupal/Component/DependencyInjection/Container.php).

For those needing to upgrade to D9 with the Markdown module blocking the upgrade, see Installing Drupal 8 only contributed module with Drupal 9 patch.

@z3cka I had the same error when trying to enable thru the GUI on D9.2. Only way I got it to enable was to edit the core.extension.yml file (markdown: 0) then import config.

#36 works for me!

Hi,

I just tried a couple of the various issue branches here, and thought I would report the results. I followed the steps that @Chris Burge linked to in #51 to try both the branches for 2.x and 1.x on a Drupal 8 site.

For 2.x, the database upgrade reported a bunch of issues, and did not complete successfully. I then tried using `composer require league/commonmark` and ended up getting a bunch of package conflicts, based on drush/drush requiring grasmash/yaml-expander, which requires dflydev/dot-access-data:^1.0 -- whereas league/commonmark:^2.0 requires league/config:^1.0 which requires dflydev/dot-access-data:^3.0.

I was able to install league/commonmark:^1.0 successfully, and then tried a bunch of the extensions, none of which detected the libraries successfully. Due to errors/uncertainty of getting a working markdown library, I decided to roll back to 1.x.

Using the issue branch with 1.x, I successfully installed Markdown with D9 support, and successfully upgraded the site to D9.

Successful upgrade steps

1. Update your composer repository setting with this block:
   

       "repositories": [
           {
               "type": "package",
               "package": {
                   "name": "drupal/markdown",
                   "type": "drupal-module",
                   "version": "dev-1.x",
                   "source": {
                       "type": "git",
                       "url": "https://git.drupalcode.org/issue/markdown-3103679",
                       "reference": "6e951bd4f71d69e65273b0ab514518cd23a120d4"
                   }
               }
           },
           {
               "type": "composer",
               "url": "https://packages.drupal.org/8"
           }
       ]
   

2. composer require drupal/markdown:dev-1.x league/commonmark:^1.0

... from there the upgrade to D9 worked fine! And basic markdown is working.

It seems like D9 compatibility should not be a blocker here -- a single commit on the https://git.drupalcode.org/issue/markdown-3103679 1.x branch fixes D9 compatibility for the stable release, and the issues I hit trying to do 2.x and 3.x are unrelated to Drupal 9, but instead, package conflicts with other non-core packages, or incomplete functionality.

I'm wondering if the D9 patches can just get applied, and then sort out the other issues in other issues? I don't see why this should be blocked on a 2.0 release...

Specifically https://git.drupalcode.org/issue/markdown-3103679/-/commits/3103679-d9-8... shows the single commit to the 8.x-1.x branch that makes the 8.x-1.x module compatible with D9.

I filed an issue at https://github.com/grasmash/yaml-expander/issues/22 for the package conflict issue noted above.

The https://git.drupalcode.org/issue/markdown-3103679/-/tree/3103679-8.x-2.x branch that I tried looks like might be a bunch of commits behind the main 2.x branch -- would it make sense to update the patches for d9 and get them committed so we don't have to spend a bunch of extra work reconciling patches for d8 and d9? Especially when d8 EOL is just a couple months away...

@freelock

D9 support

Although I would prefer too that the 1.x and 2.x versions would get official D9 support, the maintainer's preference is to have the 1.x and 2.x versions reserved exclusively to D8. @markhalliwell doesn't like to break compatibility for older minor versions of D8, even if these are no longer supported. (He explained this in #3187011-7: [markdown] Release 8.x-2.0.)
My assumption is that this is because he had some bad experiences upgrading minor Drupal versions on some sites that he maintained:

The core team also is (mostly) just concerned about the path moving forward; bleeding-edge if you will. This is fine and certainly a lot easier to maintain such a large project. However, the reality is that many large sites (at least the ones I have worked on) are often built starting at a specific core version. As things progress and the site starts to take a life on its own, the reality is that sometimes it can't always "upgrade to the latest version" especially due to the shear complexity of it. Instead, individual security holes are patched as needed while the underlying structure remains the same.

I respect Mark's preference, since he's the maintainer of the project, though it is a bit unfortunate that he doesn't seem to have that much time to maintain the project causing an official release to support D9 getting delayed.
I considered applying for co-maintainership - though only for getting an official D9 release out because I've already enough other projects on drupal.org that I maintain and try to find enough time for - but I'm afraid of going against the path he had in mind to reach a release that has D9 support.

If I were to become co-maintainer of this project, I would:

• Commit my own fixes that I made for the 2.x version so far.
• Fix coding standard issues if there are any.




• Maybe add some automated tests.
• Ignore "the must have" noted on #3187011: [markdown] Release 8.x-2.0. The only must have for a stable 2.x release is #3135360: [markdown] Add/fix documentation and I feel I don't know enough of the ins and outs of the module to complete the documentation. And I don't find writing documentation a priority for me (it isn't necessary for getting my client sites to move to D9).
• Push all changes from 8.x-2.x to 3.0.x, so that these two branches effectively become equal.
• Apply changes for D9 compatibility to the 3.x version.
• Create a release candidate for the 3.x version (because the 2.x version has a release candidate as well).

After that, I think I would not actively participate in issues of this project, as my priorities in maintaining projects on drupal.org are with other modules.

Markdown 2.x

I managed to get the 2.x version to work on a site, though I didn't give it much testing yet, so there might exist issues that I'm not aware of.

For the 2.x version:

• I used version 1.x of league/commonmark
• Created and applied a fix for #3222716: Error: Call to a member function getId() on bool in markdown_preprocess_installable_library() (line 179 of markdown.module)
• Created and applied a fix for #3226069: Allow "incompatible" filters to be enabled (but validate that they appear after Markdown)
• Reconfigured Markdown on text formats.

The reason the upgrade to 2.x initially fails is that league/commonmark gets removed when doing a composer update from 1.x to 2.x. The 2.x is no longer explicitly requiring that library, so you have to require it manually. Perhaps if you do that first, then the Markdown configuration won't get broken when performing database updates, but I haven't tested that yet.

I'm still puzzled by this... if you aren't going to upgrade from an older, unsupported minor version of Drupal 8, why would you need a new version of Markdown at all? You could just keep using the version you already have...

In my experience, the people who don't upgrade old versions also don't upgrade their contrib modules, or install new ones...

@freelock

if you aren't going to upgrade from an older, unsupported minor version of Drupal 8, why would you need a new version of Markdown at all?

My thoughts exactly. But I think that Mark wants to make it a clear that people may expect that a certain major version of Markdown is guaranteed to work on all Drupal 8 versions. To minimize surprises for people stuck on older core versions. This philosophy of maintaining a project on drupal.org is perhaps a bit different from how other persons maintain D8/D9 projects on drupal.org, but I think we'll need to respect our differences (not saying that you didn't, by the way).

It does make it harder for people to make the jump to D9, so that's a bit unfortunate. Hm, maybe I do should apply for co-maintainership? Even if I don't plan to put time in the project after the D9 release is there?

I'm using version 8.x-2.0-rc1 and I was was able to eliminate the errors reported by the upgrade_status module using the patches in #18, #23, and the attached patch.

I'm using version 8.x-2.x with the d9 issue fork repo:

//composer.json

"require": {
  "drupal/markdown": "dev-3103679-8.x-2.x",
}

    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8",
            "exclude": ["drupal/views_url_alias", "drupal/markdown"]
        },
        {
            "type": "git",
            "url": "https://git.drupalcode.org/issue/markdown-3103679.git"
        }
    ],

This patch clears the remaining errors reported by the upgrade_status module.

MegaChriz made a proposal in #57 with an approach around the blocking issue, and is willing to be a maintainer to make it happen. That proposal looks good to me and we have people testing that the module itself works with Drupal 9 so all we need is the new branch for people using or upgrading to Drupal 9 to use this fine module.

@mlncn
I've added my proposal to #3236946: markdown project open to new maintainer applications on 5 Oct, 2021. My client does however prioritize getting sites upgraded to D9 that do not use Markdown. So I'm not sure yet if I'm able to act quickly should I become co-maintainer. And it's not certain that I'll get to the sites that do use Markdown before November 2.

I rebased the merge request to the latest 8.x-2.x in case anyone is wondering about the above. 😎

Question: I noticed that some of the non-static methods had services referenced via the \Drupal static object when they could instead use real dependency injection; would it be out of scope of this issue for me to add a commit with those changes or is that okay to do here?

Not sure why, but the patch in #61 includes a diff for markdown/src/Plugin/Markdown/CommonMark/Extension/AutolinkExtension.php that seems to be for version different than that of the 3103679-8.x-2.x branch in the fork. Attaching a version without that bit.

Thanks everyone for getting a path forward for Drupal 9, even if it is less-than-ideal!'

#61 works for me.

-mike

This was the one module I wanted to wait on a new release before pulling the trigger on a D9 upgrade. Is there any movement for a new release, or will I need to live with a patch in perpetuity?

@geerlingguy
In #3236946: markdown project open to new maintainer applications on 5 Oct, 2021 @markhalliwell said he expected he would get soon to releasing stable releases for Markdown. But he also said that life takes priority, so I think that we'll need to wait a bit longer for it. In the mean time we can get by by using a forked d9 repo.
He's willing to accept co-maintainers if they contribute to multiple issues first.

The Taking over unsupported (abandoned) projects policy only addresses situations the maintainer of an abandoned project either agrees to the addition of the co-maintainer request or doesn't respond. It doesn't address a situation like Markdown where the maintainer of the abandoned module refuses the co-maintainer request.

According to #3236946: markdown project open to new maintainer applications on 5 Oct, 2021, Markdown will be designated as unsupported tomorrow (2 Nov 2021). It strikes me there are two ways out of this situation: 1) someone in D.O. infrastructure swaps out maintainers or 2) someone creates a competing Markdown project as an alternative. The status quo is untenable.

@Chris Burge
I agree that the situation is less ideal, but I think that we need to be more patient and use the d9 fork for the time being. Or someone of us should go through the issue queue to provide fixes for a few issues - and review/test issues for those that have already proposed fixes.

Dear markhalliwell please note that adding a maintainer with the ability to make commits but not make releases is an option for you and would give us a Drupal 9 compatible dev branch to use, and for other issues to be patched / tested against.

We maintain an in-house installation profile that is being upgraded to Drupal 9. When trying to upgrade a sample instance that has a clean installation of our install profile and sample content, the update hook from #3142418: Support multiple libraries per plugin fails to update the instance properly. The previous version in the profile was Markdown 07491136 (between 8.x-2.0-rc1 and 8.x-2.0-rc2) and we're on 9a55ddf of the dev-3103679-8.x-2.x issue fork.

During the post-update, the following errors appear:

>  [notice] Update started: markdown_post_update_8950
>  [warning] No default markdown parser set, using first available installed parser "commonmark".
>  [warning] No default markdown parser set, using first available installed parser "commonmark".
>  [warning] No default markdown parser set, using first available installed parser "commonmark".
>  [warning] No default markdown parser set, using first available installed parser "commonmark".
>  [warning] No default markdown parser set, using first available installed parser "commonmark".
>  [warning] No default markdown parser set, using first available installed parser "commonmark".
>  [warning] No default markdown parser set, using first available installed parser "commonmark".
>  [warning] No default markdown parser set, using first available installed parser "commonmark".
>  [warning] No default markdown parser set, using first available installed parser "commonmark".
>  [notice] Unable to update config for "filter.format.basic_html", it must be updated manually or recreated from the UI.
>  [notice] Unable to update config for "filter.format.full_html", it must be updated manually or recreated from the UI.
>  [warning] Illegal offset type in isset or empty markdown.post_update.php:78
>  [warning] Illegal offset type in isset or empty DiscoveryTrait.php:45
>  [notice] Unable to update config for "filter.format.plain_text", it must be updated manually or recreated from the UI.
>  [notice] Unable to update config for "filter.format.restricted_html", it must be updated manually or recreated from the UI.
>  [notice] Update completed: markdown_post_update_8950

I've attached the pre-update configs for Markdown and the text formats.

We're using this in conjunction with league/commonmark:1.6.6, drupal/simplemde:1.0.0-alpha4, and ionaru/easy-markdown-editor:2.15.0.

After the post-update warnings (above), we're seeing the following behavior:

• No content that was using our markdown text format is rendering with Markdown.
• The Markdown settings page (/admin/config/content/markdown) indicates that both league/commonmark:1.6.6 and commonmark-gfm:1.6.6 have been detected. But, if I edit the Markdown text format itself, it indicates that no parser was detected and several text filters that are not compatible with Markdown are enabled in a way that I cannot disable them (the checkbox is checked but disabled). (Screenshot attached.)
• If I save the Markdown text format settings, I get a lot of errors. (Screenshot attached.)
• If I edit the Markdown text format settings, all the Markdown settings were lost. (Screenshot attached.)

Thanks... the main blocker here is maintainer cooperation. There's some discussion in Drupal Slack, recently:

https://drupal.slack.com/archives/C1BMUQ9U6/p1636490699405100

We might be approaching the point where we need to fork. Not desirable, but a lot of people are similarly blocked.

Thanks for the update, @bradjones1. Unfortunate if that needs to be the path forward but ultimately the community needs to pursue the path that is most sustainable.

Separately, the post-update errors I was seeing may have been introduced in 8.x-2.0-rc2 rather than in this issue, while the PHP notices that appear when saving the settings appears to be a SimpleMDE issue which I've written a patch for: #3249036: "Warning: array_filter() expects parameter 1 to be array, null given" Warning Appears when Saving Text Format. For now, I'm trying an approach of manually deleting all the configs, setting up Markdown and SimpleMDE all over again, exporting the configs, and then deploying them in the install profile through update hooks. That may be the cleanest way for us to update our sites while avoiding the bad migration path from 8.x-2.0-rc1.

@GuyPaddock We had a similar experience going from RC1 to RC2 on Omnipedia. I can't recall the exact steps I took to fix it, but I had to comment out or remove the things causing the updates to fail, re-importing the dev database each time to ensure I was starting from the same point. I think I got it to a point where most of it was updated, and exported the config, which I could then import on the live site.

I see a lot of people struggling to get 8.x-2.x working. If 8.x-1.x will work for you, there are a couple of forks described in #30 and #35 above. I've been running this in production with Drupal 9 for over a year with no problems.

Question: if the current 1.x release is on the 8.x-1.x branch and tagged 8.x-1.3, what would happen if a 1.3.x branch were created along with a 1.3.1 tag? (or some similar scheme) Would that avoid the problem of breaking non-composer installs? This might resolve the maintainer's desire to not break non-composer installations with a new release, and could still open the way to have a stable release for D9 and D10 until other problems in 2.x and 3.x get worked out.

I don't know enough about how the new version schemes would affect those older D8 installations, or this would show up correctly in drupal packages, but I would assume most of those old sites are being manually maintained (if maintained at all) so this would clearly be a different branch those non-composer site owners should avoid.

the main blocker here is maintainer cooperation

You're kidding me right? No, that is not what the main blocker is... like at all.

This topic has been open for nearly 3 years with very specific comments as to why this issue has not yet been resolved: namely for the simple fact that the project was completely refactored and has yet to see an officially 8.x release of that work (the majority of which I did BTW).

I have also explained multiple times, across many different issues/slack, why the versioning for this project is setup the way it is. Attempting to circumvent this architectural decision just because "you need it" is not what great software makes.

I would say I'm shocked by the shear amount of people in this "community" that complain and then attack the ones who are actually doing the work they benefit from rather than helping them out in the first place; unfortunately, I am not.

Just the same song and dance I have witnessed in this "community" over the past 13 years. I personally don't understand why people are so adversarial and take offense when I don't treat their lack of planning/involvement as an emergency on my part.

This is open source.

You have not spent the countless hours rebuilding this project from the ground up and working with several people to help standardize the CommonMark spec in the Drupal ecosystem. You do not live my personal life. You do not pay my bills. You do not get to dictate a course of action simply because you have a story/deadline to meet.

The recent comments are not very open source behavior and is just one of the reasons I had to force myself to take a sabbatical this year from the Drupal "community"; for my own mental health. Quite frankly though, what I really realized over this past year is that I don't have time for nor do I wish to give credence to this kind of crap.

We're all [mostly] adults and I refuse to continue to be demoralized by other "community" members just because they only RECENTLY just got involved with this project and cannot respect the YEARS of (primarily personal) work that has gone into this.

I'm tired of the political correctness.
I'm tired of trying to coddle people's feelings.
I'm tired of having the CWG involved just because I tend to tell it how it is (I'm not a politician).
I'm tired of getting burnt out because I have to spend more time dealing with this level of ignorance rather than actually working on the issues at hand.

No, I'm going to only speak facts from now on.

The fact is this: I don't deserve this comment. It is extremely disrespectful and I demand an apology.

Instead of attacking me (or others), might I suggest the following:

• Context is king: read the issue, related issues, as well as all their comments; you might actually make a more informed decision before speaking then
• Bigger picture: understand that when comments are made by individuals that maintain projects that they aren't just some random thoughts, but usually well thought out architectural decisions that take into account the history of existing sites and implementations.
• Participate: I don't know why I even have to say this, but actually help out; don't just complain or yell "fork"... you haven't even tried helping out with what you wanted to fork from in the first place. So what is it really about then? Control?

---

Now that is out of the way. To actually get to the issue at hand again.

I'm setting the issue status back to what it was because #3187011: [markdown] Release 8.x-2.0 has yet to be resolved.

I've gone ahead and made joelpittet a co-maintainer #3247801: Offer to co-maintain. Hopefully this will help alleviate some of the bottlenecks in the near future.

(edit: The only reason I did this was because I have worked with him in the past and know his work. Sorry to anyone else that has previously requested this, but I couldn't justify making that kind of decision without knowing the quality of their work).

Regarding the comment I made here: https://www.drupal.org/project/markdown/issues/3236946#comment-14231131

I did have every intention of doing this... then I got a new job. Now that I have started to settle into my new routine, I can set aside a few hours a week to start working on this again.

@markhalliwell: I get where you're coming from; there are plenty of (much smaller) projects I have here on Drupal.org that I want to be able to focus on that I can't because life gets in the way. In truth, I doubt you can find a talented maintainer like yourself here who hasn't struggled with how to balance what's best for their community project against what they, themselves, need personally -- whether it's personal time or the larger project they're trying to get done for their day job.

I also get that you're trying to preserve compatibility across multiple versions for those who choose to stick with Drupal 8 (despite no further security updates and no paid support) or those who choose not to use Composer (even though it's pretty much required by most D8+ projects nowadays). It's a noble goal, but to a lot of us it feels like you're sacrificing what the majority need-- that being the ability to upgrade to Drupal 9 and keep Markdown functionality -- for what a minority of users prefer.

Presumably, you're trying to avoid causing pain and frustration for holdouts who are anti-Composer or anti-Drupal-9. But, by trying not to create pain for those users, the result is actually a greater pain for users who are using more modern techniques. This leads many of us to ask "why?" What is to be gained by holding so tightly to semver in a case like this? What are the real use cases we're trying to protect here? Are those use cases really more valuable than trying to get everyone on a secure, maintainable system? What is the actual risk if we were not to roll things out the way you've planned? Walk us through the logic.

When you couple the confusion in trying to understand what your goals are with the fact that you, yourself, are going through a lot personally and haven't really been able to participate in this conversation, I think you can at least understand where some of us are coming from. I don't think there are that many people in this thread who are here for politics or a coup -- we're just site admins and developers who really love the work you've done here and are desperate to get our sites sustainably updated to a secure version of Drupal before we have to face bad actors who would exploit sites that we still have on Drupal 8.

I also get that you're trying to preserve compatibility across multiple versions for those who choose to stick with Drupal 8 (despite no further security updates and no paid support) or those who choose not to use Composer (even though it's pretty much required by most D8+ projects nowadays).

This isn't entirely true. 8.x-2.x requires composer; the entire "InstallablePlugin" API depends on this to detect installed parsers. If you're referring to the 8.x-1.x branch, that was a basic "port" (and I say that loosely) of the 7.x code that defaults to using antiquated parsers with very little functionality; this branch has long been unsupported as it has many issues that 8.x-2.x has since resolved. Some generalized history: #2952435: Merge in the CommonMark project.

It's a noble goal, but to a lot of us it feels like you're sacrificing what the majority need-- that being the ability to upgrade to Drupal 9 and keep Markdown functionality -- for what a minority of users prefer.

Given that this refactoring started taking place well before D9 was even a thing, this is really kind of a moo point. The majority of users will likely be upgrading from 8.x-1.x anyway. While there's an upgrade path, it has still yet to be fully tested and is likely easier for users to manually recreate and reconfigure the filter in question. The fact of the matter is that the 8.x-2.x code is still sitting at a 8.x-2.0-rc2 release. It's 99% of the way there, it just needs a little bit more reliable testing and documentation; the latter could technically be done after the fact.

Presumably, you're trying to avoid causing pain and frustration for holdouts who are anti-Composer or anti-Drupal-9.

No; it's not about composer or D9.

But, by trying not to create pain for those users, the result is actually a greater pain for users who are using more modern techniques. This leads many of us to ask "why?" What are the real use cases we're trying to protect here? Are those use cases really more valuable than trying to get everyone on a secure, maintainable system?

This "pain" was caused purely by core because they decided to roll out semver support in a minor release; haphazardly I might add.

What is to be gained by holding so tightly to semver in a case like this?

Because semver is a spec. You don't get to pick and choose what it means; despite everything thinking they can.

What is the actual risk if we were not to roll things out the way you've planned? Walk us through the logic.

I already have: https://www.drupal.org/project/markdown/issues/3187011#comment-14014872

When you couple the confusion in trying to understand what your goals are with the fact that you, yourself, are going through a lot personally and haven't really been able to participate in this conversation, I think you can at least understand where some of us are coming from.

First, it isn't that I "haven't really been able to participate in this conversation". It's that I don't like wasting time on having to repeating myself. I get email notifications for every single issue in this project; nothing of consequence has really been reported other than "we want D9".

I can understand the desire to get a compatible release for D9 out, yes; we all want that. What I don't understand is the MRs and shouts for forks to add a few lines just so it can simply be recognized by D9. That doesn't actually account for whether or not it will actually work in D9 or have other unforeseen issues. Especially since all the current work has been against D8; without a [yet] stable release.

I don't think there are that many people in this thread who are here for politics or a coup -- we're just site admins and developers who really love the work you've done here and are desperate to get our sites sustainably updated to a secure version of Drupal before we have to face bad actors who would exploit sites that we still have on Drupal 8.

So security and stable upgrades only pertain to core? I also don't understand why there's this push for getting this project to "just install" on D9 as an acceptable "solution". How is that "stable" or acceptable criteria for site admins/developers?

At the end of the day, I have stated that this project (while 99% of the way there) is not yet ready. No amount of badgering or pestering changes that. What would is actual participation by creating issues of bugs and helping document the new code so others can use it (assuming you have a clear understanding yourself).

Again, participation. That's the key here. If you want this to get moving then help out instead of relying on just one person to do all the work. Because when that happens, this is where we end up.

Sorry my attempts to provide a helpful (and temporary) workaround set off a firestorm. I meant no disrespect. Clearly site maintainers like me are no longer welcome in the Drupal community. I'll keep my head down and my mouth shut from now on.

No @micahw156. My comments were not because of what you said. The firestorm is because of this disrespectful comment
https://www.drupal.org/project/markdown/issues/3103679#comment-14289216.

In fact, you confirming that you've been running on D9 with 8.x-1.x just proves that there are temporary solutions that can be done if this issue is a blocker for some; which shouldn't be used as a battering ram for this issue.

That being said, I completely overlooked your question:

if the current 1.x release is on the 8.x-1.x branch and tagged 8.x-1.3, what would happen if a 1.3.x branch were created along with a 1.3.1 tag? (or some similar scheme)

Unfortunately, that is not possible since d.o will not allow a semver tag to be used if there's already a drupal branch in place with the same major number, from https://www.drupal.org/node/1015226#semver-transition:

When your project switches to using semantic versioning, you must increment your major version. For example, if the latest release is 8.x-3.5, your next stable release will be 4.0.0

edit: this is why a separate 3.0.x branch was created

Thanks, @markhalliwell for the clarification. I figured it was a long shot.

I was having an issue that made my site completely break on all nodes using Markdown:

Error: Call to undefined method Drupal\Core\Theme\ActiveTheme::getBaseThemes() in Drupal\markdown\PluginManager\AllowedHtmlManager->getThemeDefinitions() (Zeile 348 in /var/www/html/web/modules/contrib/markdown/src/PluginManager/AllowedHtmlManager.php)

When I changed

getBaseThemes() => getBaseThemeExtensions()
resulting in 
$themeAncestry = array_merge(array_keys($activeTheme->getBaseThemeExtensions()), [$activeTheme->getName()]);

it seems that my site is working again.

Drupal 9.2.10
"drupal/markdown": "dev-3103679-8.x-2.x",

Can anyone please integrate this change in a patch? I have no PHP programming knowledge.

Thank you all for your help on this issue.
I've committed !11 to the 3.0.x-dev branch with a minor change to the remove core: 8.x too.

My apologies on if I didn't credit someone who may have deserved it. With limited time to contribute, figured people would be happy it's out over my lack of attention to detail, correct me if I'm wrong and I can retroactively credit you.

I'll do some testing and make a tag for the 3.0.x.

I was going to cherry-pick stuff back to 8.x-2.x but gave up after a few need 8.8 and we aren't going to make 2.x branch require that.