🇺🇸United States @jasonawant

slucero → credited jasonawant → .

Thank you @mstrelan! This worked for my use case.

I don't think its quite necessary to consider adding this to DTT, but perhaps if the request comes up again, maybe.

Closed, duplicate, see 🐛 'migrate status MIGRATION' loads every migration Needs review

Closed, see 🐛 'migrate status MIGRATION' loads every migration Needs review

Ah, I just realized that the Migration entity is provided by the migrate_plus module.

I guess this logic could either conditional check if that module is installed and or continue with the conditional in the patch

 if (array_key_exists('migration', $this->entityTypeManager->getDefinitions())) {

However, this would need an else statement to fallback to the previous approach...or something different all together.

These are possibly related issues #2909256: D7 to D8 Upgrade Looking for Non-Existing D6 Tables → , 🐛 D7 Migration failing on d6_filter_format Needs review , #3144216: [SOLVED] D7->D8 Migration failing on filter_formats v. filter_format → .

Here's an initial patch to consider

jasonawant → created an issue.

jasonawant → created an issue.

Here's a patch against 9.1.0-beta10

Here's an initial patch for review, and I think an MR https://git.drupalcode.org/project/patternkit/-/merge_requests/137

jasonawant → created an issue.

Thanks mstrelan!

I think I'm missing something. How does this get the user session cookie?

Prior to the example usage, would you use UserCreationTrait::setUpCurrentUser() to create use and set as current user?

jasonawant → created an issue.

I don't think you have to be a maintainer to update the issue summary.

I used this diff to revert the changes
https://www.drupal.org/node/3440013/revisions/view/13598088/13729680 →

Also, is this github project and this issue related https://github.com/drupal-graphql/graphql/issues/975?

jasonawant → created an issue.

I think this particular error is a result of config schema validation by Durpal core's ValidKeysConstraint, see change record https://www.drupal.org/node/3324853 →

I think the solution to this issue could be along the lines of the following:

1. Refine the Markdown filter plugin form and configuration to remove vertical_tabs from the saved form_state
I think when saving the filter without Markdown enabled, vertical_tabs is left in the form_state and it is being saved with the markdown filter settings; however, vertical_tabs is not a key defined with the filter_settings.markdown schema.

2. Further define the schema for the markdown filter settings

Here's how Drupal core's filter_html schema is defined here

filter_settings.filter_html:
  type: mapping
  label: 'Filter HTML'
  mapping:
    allowed_html:
      type: string
      label: 'Allowed HTML'
    filter_html_help:
      type: boolean
      label: 'HTML help'
    filter_html_nofollow:
      type: boolean
      label: 'HTML nofollow'

Compared to the markdown filter schema here

# Filter settings.
filter_settings.markdown:
  type: markdown.parser
  mapping:
    override:
      type: boolean
      label: 'Override'

Created https://git.drupalcode.org/project/patternkit/-/merge_requests/128

Let me know if there is any feedback and if there are any tests that need to be added/changed

reviewed bug with slucero and refined approach, I'll work on a merge request

jasonawant → created an issue.

jasonawant → created an issue.

I'm also experiencing an issue when saving a text format that does not utilize the markdown filter, see 🐛 Unable to save text format without enabling Markdown filter Active .

jasonawant → created an issue.

added line "Reinstalling the module may be required to recognize new parser libraries." b/c of  https://www.drupal.org/project/markdown/issues/3470352 🐛 New parser libraries are not available unless uninstall and re-install module Active

jasonawant → created an issue.

I attempted to add this change here using 11.1.0 and 12.0.0 as the versions and referencing this issue in the message.

@longwave, what would be the versions referenced within the message, 11.1.0 and 12.0.0?

    if ($theme_handler === NULL) {
      @trigger_error('Calling ' . __METHOD__ . ' without the $theme_handler argument is deprecated in drupal:11.1.0 and it will be required in drupal:12.0.0. See https://www.drupal.org/node/3078162', E_USER_DEPRECATED);
      $theme_handler = \Drupal::service('theme_handler');
    }

I'm guessing a change record is also required?

The duplicate issue 🐛 Fetching does not respect use_imagecache_root when using converted webp image styles Fixed

Here's a start.

Uploading a patch file for reference.

I've created a related issue 🐛 AssetResolver::getCssAssets $cid does not account for ckeditor5-stylesheets variations Active

jasonawant → created an issue.

The latest MR and this patch fix a logic error and now provides support for Send to all affiliates option.

Feedback welcomed!

Here's the patch file also.

I was unsure about which module would include this; but went with domain_content.

I was also unsure if the search_api should be listed as a module dependency. I omitted it for now. I imagine that the domain module maintainers
may not want this functionality included within the project, and this should be a separate module. Feedback welcome either way.

I have yet to fully verify this works as intended. If it doesn't work. I'll update the issue.

Adding another related issue from Metatag module, ✨ Add new Search API processor plugin for more generic data indexing Needs work , which represents a different use case.

Adding related issues links:

• #2186437: Domain Access + Views + Search API →
• #1508526: Content Viewing and Domain Access →
• #2302759: Filter Domain Access in Search API view →
• #1969938: Integration with search module →

jasonawant → created an issue.

Yes, agreed that does provide a work around, thx!

A team member is experiencing this issue related to 📌 Clear Config Filter plugin cache to update from 2.x to 3.x Fixed , and I wanted to create an issue for SEO and search engines.

We're encountering this when deploying updates using drush deploy. See 📌 Clear Config Filter plugin cache to update from 2.x to 3.x Fixed for work around and other related issues.

jasonawant → created an issue.

I think this may be related 📌 Create a way to declare a plugin as deprecated Needs work and its draft change record: https://www.drupal.org/node/3198662 →

FWIW - using all of the drush commands behind drush deploy works without issue. This is a work around for those using drush deploy

From https://www.drush.org/12.x/deploycommand/

drush updatedb --no-cache-clear -y
drush cache:rebuild
drush config:import -y
drush cache:rebuild
drush deploy:hook

I've encountered this issue when updating from 2.x to 3.x and using `drush deploy` as part of the deployment process.

docker@cli:/var/www/docroot$ drush deploy -v -y
 [info] Starting bootstrap to full
 [info] Drush bootstrap phase 5
 [info] Try to validate bootstrap phase 5
 [info] Try to validate bootstrap phase 5
 [info] Try to bootstrap at phase 5
 [info] Drush bootstrap phase: bootstrapDrupalRoot()
 [info] Change working directory to /var/www/docroot
 [info] Initialized Drupal 10.2.4 root directory at /var/www/docroot
 [info] Try to validate bootstrap phase 5
 [info] Try to bootstrap at phase 5
 [info] Drush bootstrap phase: bootstrapDrupalSite()
 [info] Initialized Drupal site dxp-content.docksal.site at sites/default
 [info] Try to validate bootstrap phase 5
 [info] Try to bootstrap at phase 5
 [info] Drush bootstrap phase: bootstrapDrupalConfiguration()
 [info] Try to validate bootstrap phase 5
 [info] Try to bootstrap at phase 5
 [info] Drush bootstrap phase: bootstrapDrupalDatabase()
 [info] Successfully connected to the Drupal database.
 [info] Try to validate bootstrap phase 5
 [info] Try to bootstrap at phase 5
 [info] Drush bootstrap phase: bootstrapDrupalFull()

In DefaultFactory.php line 97:
                                                                                                                 
  [Drupal\Component\Plugin\Exception\PluginException]                                                            
  Plugin (config_ignore) instance class "Drupal\config_ignore\Plugin\ConfigFilter\IgnoreFilter" does not exist.  
                                                                                                                 

Exception trace:
  at /var/www/docroot/core/lib/Drupal/Component/Plugin/Factory/DefaultFactory.php:97
 Drupal\Component\Plugin\Factory\DefaultFactory::getPluginClass() at /var/www/docroot/core/lib/Drupal/Core/Plugin/Factory/ContainerFactory.php:17
 Drupal\Core\Plugin\Factory\ContainerFactory->createInstance() at /var/www/docroot/core/lib/Drupal/Component/Plugin/PluginManagerBase.php:83
 Drupal\Component\Plugin\PluginManagerBase->createInstance() at /var/www/docroot/modules/contrib/config_filter/src/Plugin/ConfigFilterPluginManager.php:41
 Drupal\config_filter\Plugin\ConfigFilterPluginManager->getFiltersForStorages() at /var/www/docroot/modules/contrib/config_filter/src/ConfigFilterStorageFactory.php:88
 Drupal\config_filter\ConfigFilterStorageFactory->getFilteredStorage() at /var/www/docroot/modules/contrib/config_filter/src/ConfigFilterStorageFactory.php:54
 Drupal\config_filter\ConfigFilterStorageFactory->getSync() at n/a:n/a
 call_user_func_array() at /var/www/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php:255
 Drupal\Component\DependencyInjection\Container->createService() at /var/www/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php:177
 Drupal\Component\DependencyInjection\Container->get() at /var/www/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php:440
 Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() at /var/www/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php:237
 Drupal\Component\DependencyInjection\Container->createService() at /var/www/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php:177
 Drupal\Component\DependencyInjection\Container->get() at /var/www/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php:288
 Drush\Runtime\LegacyServiceInstantiator->resolveFromContainer() at /var/www/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php:253
 Drush\Runtime\LegacyServiceInstantiator->resolveArgument() at n/a:n/a
 array_map() at /var/www/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php:223
 Drush\Runtime\LegacyServiceInstantiator->resolveArguments() at /var/www/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php:193
 Drush\Runtime\LegacyServiceInstantiator->instantiateObject() at /var/www/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php:174
 Drush\Runtime\LegacyServiceInstantiator->create() at /var/www/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php:131
 Drush\Runtime\LegacyServiceInstantiator->instantiateServices() at /var/www/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php:60
 Drush\Runtime\LegacyServiceInstantiator->loadServiceFiles() at /var/www/vendor/drush/drush/src/Boot/DrupalBoot8.php:257
 Drush\Boot\DrupalBoot8->addDrupalModuleDrushCommands() at /var/www/vendor/drush/drush/src/Boot/DrupalBoot8.php:233
 Drush\Boot\DrupalBoot8->bootstrapDrupalFull() at /var/www/vendor/drush/drush/src/Boot/BootstrapManager.php:236
 Drush\Boot\BootstrapManager->doBootstrap() at /var/www/vendor/drush/drush/src/Boot/BootstrapManager.php:377
 Drush\Boot\BootstrapManager->bootstrapToPhaseIndex() at /var/www/vendor/drush/drush/src/Boot/BootstrapManager.php:329
 Drush\Boot\BootstrapManager->bootstrapToPhase() at /var/www/vendor/drush/drush/src/Boot/BootstrapHook.php:36
 Drush\Boot\BootstrapHook->initialize() at /var/www/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:44
 Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->doInitializeHook() at /var/www/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:36
 Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->callInitializeHook() at /var/www/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:29
 Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->initialize() at /var/www/vendor/consolidation/annotated-command/src/CommandProcessor.php:145
 Consolidation\AnnotatedCommand\CommandProcessor->initializeHook() at /var/www/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:376
 Consolidation\AnnotatedCommand\AnnotatedCommand->initialize() at /var/www/vendor/symfony/console/Command/Command.php:292
 Symfony\Component\Console\Command\Command->run() at /var/www/vendor/symfony/console/Application.php:1096
 Symfony\Component\Console\Application->doRunCommand() at /var/www/vendor/symfony/console/Application.php:324
 Symfony\Component\Console\Application->doRun() at /var/www/vendor/symfony/console/Application.php:175
 Symfony\Component\Console\Application->run() at /var/www/vendor/drush/drush/src/Runtime/Runtime.php:110
 Drush\Runtime\Runtime->doRun() at /var/www/vendor/drush/drush/src/Runtime/Runtime.php:40
 Drush\Runtime\Runtime->run() at /var/www/vendor/drush/drush/drush.php:139
 require() at /var/www/vendor/drush/drush/drush:4
 include() at /var/www/vendor/bin/drush:119

Here's a patch for 10.1.x branch.

This resolves an issue I was experiencing when attempting to apply runtime contexts to condition plugins. The condition plugins, specifically entity_bundle:node, was not able to evaluate b/c of missing context value.

        $contexts = $this->contextRepository->getRuntimeContexts($condition_plugin->getContextMapping());
        $this->contextHandler->applyContextMapping($condition_plugin, $contexts);

Sorry, I'm not able to help with CR or the issue summary; I'm not sure what exactly is needed.

Hi! I created a change record for the 10.1/10.2 changed behavior. Is this needed? If so, could someone review it and then I'll publish it?

https://www.drupal.org/node/3426397 →

I found myself in a similar situation as @john.oltman above.

I was relying on 10.1 behaviors to migrate entity revisions' moderation_state values and (I think) relying on ModerationHandler::onPresave() set publish state accordingly.

@john.oltman, thanks for the solution!

While implementing a custom content type entity, I looked into access checking related to entity query logic and found this issue. I also created this support request 💬 Does entity query access checking perform any access checking for custom content type entity? Active to confirm my understanding of entity query access checking.

In that support request, I've also proposed a few documentation changes and happy to have these documentation discussions over there. I think be helpful to communicate more clearly for custom content type entity developers.

jasonawant → created an issue.

benjifisher → credited jasonawant → .

oh, I see now. Thank you for linking to the field definition; I had not seen that before.

If the type isn't set the behavior would essentially be the same as a normal link field.

Are you looking to be able to set a link in the typed link field and not set a type?

I see your point. No, I don't have a specific requirement to allow some Typed Link values with types and some values without a type. If this does come up, I'll create a separate feature request issue.

Using #required and #states seems like the way to go to visually indicate that input is required, and with the addition of the empty option definitely communicates the need to select an option b/c of client and server side validation errors.

One other observation, the empty_value in the MR uses the string '- Select -'. If instead, it uses the string '- Select a value -' to align with core's OptionsSelectWidget here, the string would benefit from using translations from https://localize.drupal.org/ for Drupal core....nevermind! It looks '- Select -' is used in several places in Drupal core and also has translations from https://localize.drupal.org/.

Looks good, thanks again!

Thank you very much for considering this feature request and contributing the changes so quickly!

✓ I can see the - Select - option selected as the first option when the form is rendered
✓ The link type field is now required when the field is required

The #states usage is a nice touch! It's helpful and mirrors the behavior from Drupal core's LinkWidget behavior here when providing link text and the the URL input becomes required. However, this makes the type type required even when the field is not required (though this be expected and consistent with current link type behavior, more below).

I realize the following scenario represents an edge case, b/c I manually added the novalidate attribute to the form element to bypass clientside form validation, but I thought I'd share it. In this scenario, without clientside validation, I can submit the form and receive an error from server side validation error, "The value you selected is not a valid choice.".

I think this behavior is consistent with previous behaviors as the link type value can only be a value from the allowed list of configured options. However, if the field is not a required field, I'd expect to be able to submit the form without selecting a link type option. Have you encountered a need for this behavior, to save without a link type option?

Awesome! Well, I'll share what prompted the issues. When I was trialing the module out with a multivalue field, Drupal will render the link text, uri and type inputs. The type input defaulted to the first option and drew my eye on the form. As a result, I was second guessing if the value was going to save with the form or if I should unset it. It just threw me off from a content authoring perspective. Hope that helps and thanks, Jason

Thank you @geekygnr! Did you have any preferences on a way forward here or would you like to see me propose something?

great!

jasonawant → created an issue. See original summary → .

I'm closing as outdated. Please set the status back to active if you still need support.

This issue appears to be inactive for some time now. I'm closing as outdated. Feel free to re-open if this is still an issue.

jasonawant → created an issue.

jasonawant → created an issue.

Thank you for your interest in co-maintainership.

I'm no longer involved with the project or client that originally sponsored this module. I'm going to remove myself as maintainer.

I have pinged former Nerdery colleagues about your request in Drupal slack.

https://www.drupal.org/u/qymanab →

https://www.drupal.org/u/kamkejj →

slucero → credited jasonawant → .

Based on support from Drupal slack,

https://git.drupalcode.org/project/drupal/-/blob/10.2.x/core/modules/jso....

EntityResource::patchIndividual()

and

EntityResource::updateEntityField()

There isn't a way to target a specific delta of a multivalue field value.

In the scenario I found myself in, which I've concluded is a poor design, was preventing race conditions from an application updating the same resource from different browser tabs. Since posting, my research has lead me to use a different model to ensure operations don't step on each other.

Right, I used that version b/c simplytest.me site was using 9.5 by default.

My use case would be for the latest version.

I changed the version in case its used to filter out issues if that matters.

If using PATCH, the request would include all unchanged values, for example:

curl -X PATCH \
-H 'Content-Type: application/vnd.api+json' \
--user user:password \
https://master-6hplc6fufbi9r9qm4cpm32byiowejoz4.tugboatqa.com/jsonapi/node/recipe/1ccd8b1b-b09b-405c-ad44-e1aadb1bc880 \
-d '{"data":{"id":"1ccd8b1b-b09b-405c-ad44-e1aadb1bc880","type":"node--recipe","attributes":{"field_ingredients":[{"value":"For the pastry:"},{"value":"299g plain flour"},{"value":"140g butter"},{"value":"Cold water"},{"value":"For the filling:"},{"value":"1 onion"},{"value":"2 garlic cloves"},{"value":"Half a courgette"},{"value":"450ml soya milk"},{"value":"500g grated parmesan"},{"value":"2 eggs"},{"value":"200g sun dried tomatoes"},{"value":"100g feta"}]}}}'

Seems like there could be a way to use POST similar to #2996339: Adding a new value to a multi-value relationship field without losing existing data →

jasonawant → created an issue.

I replaced links with issues in summary and added related issues. I imagine this is a feature request instead of a bug

jasonawant → created an issue.

I think I naively removed them; this patch includes them.

And another patch to update the PatternFieldProcessorPluginManagerTest test case. There were no other failing tests.

• add $optional_field_token to represent an non-required entity field that may not have a replacement value
• Set field_url as an empty string to represent the field without a value.
• Set the example pattern's field_url property to use $optional_field_token
• Add asserts to confirm the tokens are removed from output as expected with the ['clear' => TRUE] change to the PatternFieldProcessor TokenProcessor plugin.

Here's a new patch:

• Removes unnecessary comment with the apply method. Someone can read the token replace and replacePlain docblocks
• Add the ['clear' => TRUE] to the token processor class
• Updates the TokenProcessorTest class by removing unused code updating/adding replace and replacePlain test cases for the apply method.

I know the PatternFieldProcessorPluginManagerTest class is impacted by the ['clear' => TRUE] change. Let's see what other test fail as a result.

Also related to Patternkit's token replacement logic, I think it would be beneficial to use the replacement option ['clear' => TRUE], as documented here within Drupal core Token class, to remove the token if no replacement was found.

Should this be a separate issue or combined it with these changes and include test coverage for it here?

The previous patch introduces use of the \Drupal\Core\Utility\Token::replacePlain() method whereas the existing test used the \Drupal\Core\Utility\Token::replace() method.

The attached patch updates the test to use the expected method.

I imagine patternkit may want to test plain and formatted text token replacements. Any recommendation on how you may want to see test coverage for both?

jasonawant → created an issue.

jasonawant → created an issue.

Updated change records links in issue summary; unable to use issue formatting such as [#3301716], with non issue content.

Uploaded patch for usage

jasonawant → created an issue.

Linked Akamai module to the project page to help communicate for which project this documentation represents.

I thought I'd add some notes as I dug into this a bit today.

When programmatically retrieving a user's email address via $user->getEmail() method, it does not respect the Drupal core user 'view user email addresses' permission here or any implementation by this module. Moreover, using entity api to retrieve field values bypasses access checking, including that of this module.

However, if you were to use field access checking via $user->mail->access('view'); , this module could impact its access grants.

EntityAccessControlHandler.php::fieldAccess() invokes UserAccessControlHandler::checkFieldAccess() → here and then later EntityAccessControlHandler.php::fieldAccess() here would invoke field_permissions_entity_field_access()

However, I don't think there is a way to configure field permissions for user account mail property. The proposed solution would be a deviation from field permission's module configuration UI for fields.

For Drupal 8+ usage, see Drupal change record https://www.drupal.org/node/2101719 →

The previous patch did not apply to latest beta release. Here's a skinny patch of just the permission, no tests.

That I did! Thanks for calling that out. Here's an updated patch and interdiffs.

Attached patch uses patch from 14 with changed protected property name to match that of the Drupal 6 node source plugin here

Two interdiffs for comparison.

Well, we've pivoted away from using this module. Instead, we've implemented a custom Drupal @Filter plugin (see d.o. forum for related discussion on filter plugins → ) to use CommonMark V2 directly.

Here's an example of that implementation. In ours, I created custom extension and image renderer to replace commonmarkcore below and its processors and renderers to not render image markdown.

namespace Drupal\my_module\Plugin\Filter;

use Drupal\filter\FilterProcessResult;
use Drupal\filter\Plugin\FilterBase;
use Drupal\Core\Logger\LoggerChannelTrait;
use League\CommonMark\Environment\Environment;
use League\CommonMark\Extension\CommonMark\
use League\CommonMark\Exception\CommonMarkException\CommonMarkCoreExtension;
use League\CommonMark\Extension\Strikethrough\StrikethroughExtension;
use League\CommonMark\MarkdownConverter;

/**
 * CommonMark V2 filter plugin for Markdown.
 *
 * @Filter(
 *   id = "commonmark_v2",
 *   title = @Translation("CommonMark V2"),
 *   description = @Translation("Utilizes CommonMark V2 to parse markdown and convert into HTML"),
 *   type = Drupal\filter\Plugin\FilterInterface::TYPE_MARKUP_LANGUAGE,
 * )
 */
class CommonMarkV2 extends FilterBase {

  use LoggerChannelTrait;

  /**
   * The configuration array.
   *
   * @see https://commonmark.thephpleague.com/configuration/.
   */
  private array $config = [
    'renderer' => [
      'block_separator' => "\n",
      'inner_separator' => "\n",
      'soft_break'      => "\n",
    ],
    'html_input' => 'strip',
    'allow_unsafe_links' => FALSE,
    'max_nesting_level' => 10,
  ];

  /**
   * {@inheritdoc}
   */
  public function process($text, $langcode): FilterProcessResult {
    try {
      $environment = $this->createEnvironment();
      $converter = new MarkdownConverter($environment);
      $converted_text = $converter->convert($text);
      return new FilterProcessResult($converted_text);
    }
    catch (CommonMarkException $e) {
      $this->getLogger('my_module')->critical('Unable to convert markdown into HTML.');

      return new FilterProcessResult($text);
    }
  }

  /**
   * Generate an environment with extensions.
   */
  private function createEnvironment(): Environment {
    $environment = new Environment($this->config);

    // Add CommonMarkCoreExtension for commonly used parsers and
    // renders.
    $environment->addExtension(new CommonMarkCoreExtension());

    // Add additional extensions.
    // @see https://commonmark.thephpleague.com/2.4/basic-usage/#using-extensions
    $environment->addExtension(new StrikethroughExtension());

    return $environment;
  }

}

Attached is a new patch that solves the following error by creating a CommonMarkCoreExtension MarkdownExtension plugin. This probably isn't the best way to solve the error; I imagine CommonMarkCoreExtension should be added to the environment by default without enabling it as a MarkdownExtension plugin.

Solve for Error: RuntimeException: Unable to find corresponding renderer for node type League\CommonMark\Node\Block\Document

The patch also changes the existing Commonmark MarkdownExtension plugins InstallableRequirement constraints to prevent them from being used with the new CommonMarkV2 parser.

And lastly, the patch includes a new configurable Disallowed Raw HTML MarkdownExtension plugin with CommonMarkV2 parser Installable Requirement constraint. This uses the v2 supported config options and satisfied my project requirement to remove tags.

While I can render content using the CommonMarkV2 parser...HOWEVER, its not rendering using the Enable Emphasis, Enable Strong, Use Asterisk, Use Underscore or Unordered List Markers options.

I need to check-in with my project team about the remaining effort and timing. I'm starting to think using a custom, or contributed, Drupal @Filter plugin that integrates directly with CommonMark V2 may be more reliable and maintainable path going forward. As much as I'd like to see this Markdown module work with CommonMark v2 for more broader usage, there's a lot of abstraction found within this Markdown module to account for.

While I work on this, I'll assign this issue to myself. I'll share some progress in the next few days.

There is a sandbox project that supports this functionality, see Migrate booster https://www.drupal.org/sandbox/onkeltem/2828817 →

Hi,

I've attached two files as work in progress: 1) commonmark-v1-v2.diff to show changes between the two versions and 2) a new patch to add CommonMarkV2.php MarkdownParser plugin. The second patch differs from the first patch by making an entirely new Commonmark v2 plugin.

I have to switch to some other work briefly, but will return to this later today.

Here's a list of next steps

• Solve for max_nesting_level value type casting as string instead of integer; this results in an error: League\Config\Exception\ValidationException: The item 'max_nesting_level' expects to be int, '10' given. in League\Config\Configuration->build() (line 195 of /var/www/vendor/league/config/src/Configuration.php)
• Solve for Error: RuntimeException: Unable to find corresponding renderer for node type League\CommonMark\Node\Block\Document in League\CommonMark\Renderer\HtmlRenderer->renderNode() (line 88 of /var/www/vendor/league/commonmark/src/Renderer/HtmlRenderer.php)
• Check the Configuration Option Changes, @see: https://commonmark.thephpleague.com/2.0/upgrading/developers/#configurat...
• Refactor max_nesting_level default value management instead of using PHP_INT_MAX
• General code cleanup and refactoring
• Updating CommonMark MarkdownParser to not include v2
• Creating required CommonMark v2 Extensions; updating existing existing extensions to not include v2

Thanks tikaszvince for the notes and C-Logemann for reporting. I'm looking into these changes this week.

@tikaszvince, I agree about a new plugin for Commonmark v2, but I do wonder about sharing the commonmark markdown extensions across both; will there also need to be v2 only extensions.

The project requirement I'm hoping to satisfy utilizes Commonmark v2 ability to configure disallowed raw HTML tags, which will require an update to the commonmark-disallowed-raw-html markdown extension; a change not compatible with Commonmark v1.

The v2's Commonmark::convertToHtml() will have to change per these update docs.

From

  protected function convertToHtml($markdown, LanguageInterface $language = NULL) {
    return $this->converter()->convertToHtml($markdown);
  }

to

  protected function convertToHtml($markdown, LanguageInterface $language = NULL) {
    return $this->converter()->convertToHtml($markdown)->getContent();
  }

jasonawant → created an issue.

Hi @tikaszvince, thanks for the patch!

Have you encountered any issues? I'm curious how you are using this module with Commonmark v2.

A quick glance Commonmark 1.6 to 2.0 upgrade docs suggests other changes are required.

Perhaps these are already in place when looking at https://git.drupalcode.org/project/markdown/-/blob/3.0.x/src/Plugin/Mark... from changes in #3142418: Support multiple libraries per plugin → .

Ah, I think I figured out a work around.

Instead of invoking \Drupal::service('markdown')->parse(), which uses the default parser; l instantiated a parser by name with the parser's configuration. For example:

 drush php-eval "echo(\Drupal::service('markdown')->getParser('commonmark', Drupal::config('markdown.parser.commonmark')->getRawData())->parse('This is **BOLD**.'));"

This results in the expected output of
<p>This is <strong>BOLD</strong>.</p>