🇺🇸United States @ultimike

ultimike → created an issue.

Possible new flavor names suggested by DrupalEasy alumni:

• Markdown Goulash
• Markie Markdown and the Funky Bunch
• Markdown Loaded
• Markdown Madness

We also discussed the possibility of adding additional extensions like Table of Contents, but the concern is that they're always on, and not enable-able (or disable-able) on a per entity basis.

-mike

Ahhh - never mind. I just figured it out! It works as expected.

It was my misunderstanding. The "Require paragraphs to be added inside a layout" option means that non-layout paragraph types have to be placed inside a layout paragraph type...

-mike

ultimike → created an issue.

As I mentioned in my previous comment, I didn't want to go down the road of adding additional configuration to the Markdown Easy so I decided to remove the Footnotes extension option and add a new "Markdownpalooza" flavor that includes both the Footnotes extension as well as the Description lists extension. (Full list of all possible extensions provided by the CommonMark library this module is already using.)

I believe that adding this functionality this way keeps my mission of this module intact: to be easy-to-use and easy-to-maintain.

Summarizing the three available flavors:

1. Existing flavor "Standard Markdown" is comprised of only the CommonMarkCoreExtension.
2. Existing flavor "GitHub-flavored Markdown" is comprised of the GithubFlavoredMarkdownExtension which is the same as CommonMarkCoreExtension plus the following extensions: Autolinks, Disallowed Raw HTML, Strikethrough, Tables, and Task Lists.
3. New flavor "Markdownpalooza" is comprised of GithubFlavoredMarkdownExtension plus the Description list extension and the Footnotes extension.

Some additional thoughts:

1. I am not against adding addition extensions to Markdownpalooza, but after going through the list of available extensions, I didn't see much value in any of the other available extensions.
2. I'm not 100% in love with the name Markdownpalooza, and am open to suggestions. My only criteria is that I'd like a name that is a bit fun.

Additional changes in this MR:

1. I added the relevant Footnotes and Description list HTML tags to the default configuration of the Markdown text format that is installed with this module.
2. I added test support for the new Markdownpalooza extensions.
3. I renamed the "Important" information when configuring the Markdown Easy text filter to "Tips" and added some additional information.
4. I added a new hook_markdown_easy_environment_modify that will allow folks to add additional extensions via a small custom module. Once this MR is merged, I'll update https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → with an example of how to use it. I'm happy to provide issue credit for anyone who wants to help me with this.
5. As this is a fairly significant addition to the module, once merged, I'll be releasing a 1.1.0 version.
6. Similarly, once 1.1.0 is released, I'll be reviewing and updating all of the documentation (including the README.md). I'm happy to provide issue credit for anyone who wants to help me with this.

Thoughts? Feedback?

thanks,
-mike

I talked this over with some folks during DrupalEasy Office Hours and I'm leaning towards doing the following:

1. Remove the option to enable Footnotes.
2. Add (at least) a new "flavor", calling it something like "GitHub flavored+" and including Footnotes and maybe a few other commonly-used extensions (I'm open to suggestions.) If we go this route, then I may want to consider automatically updating the "Limit allowed HTML" config based on the flavor selected.

The goal is to both keep the codebase of this module as simple as possible (for easy updates) as well as keeping its implementation as easy as possible for end users.

Thoughts?

-mike

volkswagenchick → credited ultimike → .

It would be really helpful if we could decide on the following for Atlanta, so that I can work with the DA in getting everything we need/want finalized:

1. A proposed schedule of mentoring events during DrupalCon. This includes first-time contributor workshops, mentoring workshops, issue queue triage workshop, mentor’s BoF. To this end, I am able to secure us a dedicated space for these workshops, including during contribution day (so that we can separate the first-time contributor’s workshop from the mentoring area.) BUT, to make any of this happen, I need a proposed/tentative schedule by January 1.
2. The name of the main contact on the mentoring team for marketing/communications. This person will also be asked to help work with DrupalCon marketing folks in writing and designing marketing materials (including a half-page handout for the booth.) The DA is willing to help us get the word out, but ideally, there will be a single point-of-contact.
3. I think we should identify a “mentor recruitment” lead. I have some ideas about how this could be really useful.

Also see my comment in Slack in the #mentoring-leads channel: https://drupal.slack.com/archives/G63JLJK7G/p1732311521966999?thread_ts=...

I hit this error while installing RC2 using Safari 18.1.

I tried doing a ddev drush cr as in comment 27 above, and I had the same output and the same result (the page refreshed fine.) Odd.

-mike

Workaround worked for me as well.

-mike

I've update the MR to address the things I noted above as well as I improved one of the functional tests to actually test the footnote extension.

I'm still on the fence about whether or not the Footnotes extension should be enabled by default or not seeing how there are additional tags that have been added to the "Limit allowed HTML tags and correct faulty HTML" configuration to support footnotes.

Regardless, once this is merged, I'll need to remember to add something to the release notes letting folks know that if they're upgrading and enable the Footnotes extension, they'll need to add the following to the "Limit allowed HTML tags and correct faulty HTML" config: id to the existing <li> as well as <sup id>.

I am amenable to adding additional extensions, but I really want to keep this module dead-simple to use - perhaps that means enabling and configuring extensions by default without giving users the option to enable/disable them in the filter's settings form.

Thoughts?

-mike

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

I have to agree with @bramdriesen on all of his comments. I would like to see this MR cleaned up a bit and a test added before considering this change (especially because this is a bit of an edge case and a workaround exists.)

-mike

mradcliffe → credited ultimike → .

mradcliffe → credited ultimike → .

mradcliffe → credited ultimike → .

lostcarpark → credited ultimike → .

teknorah → credited ultimike → .

ultimike → created an issue. See original summary → .

So is the plan that both drupal_cms_ai and drupal_cms_analytics will be apply-able in Drupal CMS 1.0 only via the command line? Or is that TBD?

-mike

drupal_cms_search is a weird one because it appears in the drupal_cms_starter recipe's composer.json file but not in the recipe.yml file - maybe this is an oversight?

I agree that drupal_cms_ai, drupal_cms_analytics, and drupal_cms_multilingual should all be available in Project Browser.

-mike

Does #8 work with the latest version of this module?

The current version of DDEV includes npm 8.19.4 - it would be great if this module supported this version of npm out-of-the-box, and it would make contributing to this module **much** easier.

Or - better yet - close this issue in lieu of 🐛 Switch from deprecated Node Sass to Dart Sass compiler and change minimum node version to 16.0 and later in the Bootstrap Styles module Active

-mike

This MR worked for me as well with Drupal core 10.3.9, Group module 3.3.0, and version 2.1.1 of this module.

-mike

johnpicozzi → credited ultimike → .

One other thought on this - as things currently stand, Project Browser will only work with recipes that are installed with Composer. If you download/create a recipe into a project, Project Browser won't find it (unless you've previously used Composer to require an additional recipe to the same directory.)

Regarding

When I do a composer require somevendor/somerecipe (where the project's composer.json has "type": "drupal-recipe", where is the Composer configuration that installs this dependency in the project root's "recipes" directory? (using a Drupal 11.0.7 site based on the drupal/recommended-project Composer template.) This is a bit of a mystery.

Credit to @ctrladel for figuring out that recent versions of composer/installers has this gem:

https://github.com/composer/installers/blob/main/src/Composer/Installers/DrupalInstaller.php

Mystery solved!

-mike

Doh! Never mind - I think the plugin already does this!

In Drupal 10 and and 11, it searches the project-root's "recipes/" directory.

From a code comment:

    // The recipe system requires that all non-core recipes be located next to each
    // other, in the same directory.

So, no "custom" or "contrib" directories allowed.

When I do a composer require somevendor/somerecipe (where the project's composer.json has "type": "drupal-recipe", where is the Composer configuration that installs this dependency in the project root's "recipes" directory? (using a Drupal 11.0.7 site based on the drupal/recommended-project Composer template.) This is a bit of a mystery.

Sidenote: I have noticed that the 11.x drupal/recommended-project Composer template includes "recipes/{$name}": ["type:drupal-recipe"].

Finally, in the Project Browser recipes plugin, there is this bit of code that uses information from Composer to figure out which directories Project Browser searches for recipes:

    // If any recipes have been installed by Composer, also search there. The
    // recipe system requires that all non-core recipes be located next to each
    // other, in the same directory.
    $contrib_recipe_names = InstalledVersions::getInstalledPackagesByType(Recipe::COMPOSER_PROJECT_TYPE);
    if ($contrib_recipe_names) {
      $path = InstalledVersions::getInstallPath($contrib_recipe_names[0]);
      $path = $this->fileSystem->realpath($path);

      $search_in[] = dirname($path);
    }

Bottom line - nothing to see here, closing this issue, leaving this information for those that are curious.

-mike

After discussions with one of the Recipe leads, it was determined that we should be including both /project-root/recipes and /project-root/web/recipes.

I've updated the issue summary.

-mike

ultimike → created an issue.

johnpicozzi → credited ultimike → .

I completely agree with @damienmckenna, @herved, @loopy1492, and others - removing update hooks is a bad idea.

-mike

lostcarpark → credited ultimike → .

I think I'm in a similar situation as the OP (@fessouma) where I can't figure out what I'm missing. Here's some details:

• I just pulled the latest -dev.
• I have "Stream" unchecked in the "AI Chatbot" block configuration.
• I can put my chatbox prompt in the "AI Vector DB Explorer" and get 3 results that are above my context threshold (0.1).
• I am only getting the generic answers from the chatbot ("I'm sorry, I can not find a database to look this up in.")
• Looking at the logs, after I use the chatbot, I only see a call to OpenAI to the "gpt-4o" modul - I do not see a call to the "text-embedding-3-small" model which makes me think that chatbox prompt is not getting embeddings-ized in order for the RAG search of my local Milvus database to happen. I should always see an initial call to the "text-embedding-3-small" model for the initial prompt, right?

In my head (which may be incorrect), I'm thinking that the following things should happen:

1. The chatbox prompt gets embedding-ized.
2. The local Milvus database is searched using the embedding-ized chatbox prompt.
3. The results of the previous step are added to the prompt instructions for the gpt-4o call.

So, when I look in the AI Logs, I am expecting to see the "Extra data" section contain the prompt instructions text along with results from the local RAG search. Am I not thinking about this the right way?

thanks,
-mike

Allowing subfolders could lead to naming collisions as you could have a content_type_page in multiple sub-folders and which one would a recipe that depends on it apply?

@thejimbirch - ah, makes sense. Thanks for the explanation.

-mike

Big +1 to the the 3 type options proposed (Foundational, Kit, and Site).

When I look at the project root for Drupal CMS, or within any module that contains multiple recipes, I think it would be helpful if there was a directory structure that mirrors these types. Off the top of my head:

/recipes/foundational/...
/recipes/kit/...
/recipes/site/..

This way, a developer would be able to quickly identify which was which without inspecting their recipe.yml file.

As for a second classification type, I don't have a strong opinion other than a standard naming convention could go a long way in providing this type of classification for foundational recipes.

-mike

@alfthecat - Thanks for the kind words!

Also - I loved your TV show when I was growing up!

When the setFile() method is used to specify the location of the batch functions, it must be called before setFinishCallback() or the finish callback will not be found:

$batch_builder = (new BatchBuilder())
  ->setTitle($this->t('Processing Batch'))
  ->setFile('/my_module.batch.inc')
  ->setFinishCallback('my_finish_callback_function')
  ->setInitMessage($this->t('Batch is starting'))
  ->setProgressMessage($this->t('Processed @current out of @total.'))
  ->setErrorMessage($this->t('Batch has encountered an error.'));

I think this is fine - if others feel a need for a DESC option, then a new issue can be opened. In my case, simpler is better!

thanks,
-mike

ultimike → created an issue.

I can confirm that in my case, a CSV file with 210,000+ rows and 17 columns loaded and performed well on my local with Drupal 10 and a standard DDEV configuration.

-mike

liberatr → credited ultimike → .

liberatr → credited ultimike → .

Merged!

ultimike → created an issue.

ultimike → created an issue.

ultimike → created an issue.

Tests are passing. Needs review.

-mike

@drubolbol and @nico059 did a great job during the DrupalCon Barcelona mentored core contribution day - making good progress on this issue (and learning a lot about the contribution process along the way.)

Currently, it appears that the changes have caused some tests to fail:

• Drupal\Tests\file\Functional\SaveUploadTest
• Drupal\Tests\file\Functional\SaveUploadFormTest
• Drupal\Tests\file\Functional\RemoteFileSaveUploadTest

See https://git.drupalcode.org/issue/drupal-3368857/-/pipelines/294400 for more details.

-mike

I will be working on this issue during the DrupalCon Barcelona mentored contribution with @pierregermain

After September 28, 2024, feel free to pick this issue up and continue.

-mike

Is the following correct for core lib tests?

Unit tests: core/lib/tests/Drupal/Tests/Core (\Drupal\Tests\Core\)
Kernel tests: core/lib/tests/Drupal/KernelTests/ (\Drupal\KernelTests\Core\)
Functional tests: core/lib/tests/Drupal/FunctionalTests/ (\Drupal\FunctionalTests\Core\)
Functional Javascript tests: core/lib/tests/Drupal/FunctionalJavascriptTests/ (\Drupal\FunctionalJavascriptTests\Core\)

-mike

I plan on working on this issue with my team.

-mike

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

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

Perfect!

thanks,
-mike

I think you may want to considering updating the help text, as it doesn't feel complete to me. The fact that Advanced mode is dependent on not only the Token module being available but also the Automator type probably warrants additional help text. Know what I mean?

-mike

@marcus_johansson - I didn't have anything specific in mind, I just thought it was odd that I couldn't access advanced mode even though I had token module installed.

I didn't realize that access to advanced mode was dependent on the automator type.

-mike

@lostcarpark - thanks for looking into this. As we discussed during DrupalEasy office hours, my ideal solution would be (in order of my preference):

league/commonmark magically introduced a new GitLabFlavoredMarkdownConverter class that I could just drop-in and have it work.
Some other wonderful open-source minded person or organization created a PHP dependency for GitLab-flavored Markdown that I could include just about as easily as the first option above.

I don't want to get in the business of partially supporting GitLab-flavored Markdown by enabling Commonmark extensions - if we do that, I feel the chances are currently low that we'll ever be able to claim 100% compatibility with GitLab Markdown.

-mike

ultimike → created an issue.

ultimike → created an issue.

ultimike → created an issue.

@jacobupal,

No, tokens that include a max-length value are not supported.

When using the new Smart Trim token, the max value (and the rest of the settings) will come from the Token view mode of the entity (if specified) or fallback to the default view mode settings.

-mike

@marc.bau - exactly which commit are you talking about when you say,

but a commit has pushed to dev 2 years ago

thanks,
-mike

ultimike → created an issue.

Hopefully, this is now all set.

During DrupalEasy office hours today, we updated the text fixture - it was a great learning experience for all of us, and definitely a team effort. I have asked those to participated to leave a comment below so that they can receive credit as well.

🤞🏼that all tests pass.

Some notes along the way:

To import the old database fixture, we first deleted all the tables from the database, then used the following command to import (from the "web" directory): php ./core/scripts/db-tools.php import ./modules/contrib/smart_trim/tests/fixtures/update/drupal-10.0.8-smart_trim-2.0.php

Prior to running the database updates for Drupal core, we checked out the 2.0.0 branch of Smart Trim (otherwise we would have run the database updates that are meant to be tested). After we ran the updates, we checked out the -dev for Smart Trim.

To re-create the fixture, we used (again from the web directory): php ./core/scripts/db-tools.php dump-database-d8-mysql > modules/contrib/smart_trim/tests/fixtures/update/drupal-10.3.2-smart_trim-2.0.php, then we used "gzip" to compress the file.

-mike

@ankitv18 - I _think_ I understand what you mean, but not entirely 100% sure.

In walking through all this during DrupalEasy office hours, we understand that it is not possible to upgrade from Drupal core 10.0.* to Drupal 11 (next major), which is why you're suggesting we update the "drupal-10.0.8-smart_trim-2.0.php.gz" test fixture to be based on Drupal core 10.3.x.

But, Drupal 11 has been the "next major" for quite some time now, so I'm not sure I understand why this is suddenly an issue.

For example, on April 22, 2024, it was failing - see [here](https://git.drupalcode.org/project/smart_trim/-/pipelines/153603). But, on February 25, 2024, it was passing - see [here](https://git.drupalcode.org/issue/smart_trim-3423678/-/pipelines/103540). In both cases, "next major" was Drupal 11, no?

...a few minutes pass...

Heh, we just figured it out. It turns out all all core updates prior to 10.3 were removed from Drupal 11 on April 19, 2024 - see [here]( https://www.drupal.org/project/drupal/issues/3439769 📌 Remove all the pre-10.3.0 updates hooks Fixed ).

Therefore, no need for @ankitv18 to answer my question, as we have answered it for ourselves 😀

Bottom line - yes, we need a new fixture based on Drupal 10.3.whatever and Smart Trim 2.0.0. The easiest way to create this fixture (database dump) is probably to:

• Start with a fresh Drupal 10.3.whatever code base
• Import the existing fixture (smart_trim/tests/fixtures/update/drupal-10.0.8-smart_trim-2.0.php.gz)
• Run database updates
• Export database (as .gz, not as .zip!)
• Update line 26 of smart_trim/tests/src/Functional/Update/SmartTrimUpdateMoreTest.php
• Run test locally to ensure all is working.
• Commit changes

Did we miss anything?

-mike

volkswagenchick → credited ultimike → .

volkswagenchick → credited ultimike → .

volkswagenchick → credited ultimike → .

volkswagenchick → credited ultimike → .

volkswagenchick → credited ultimike → .

volkswagenchick → credited ultimike → .

volkswagenchick → credited ultimike → .

volkswagenchick → credited ultimike → .

volkswagenchick → credited ultimike → .

volkswagenchick → credited ultimike → .

volkswagenchick → credited ultimike → .

volkswagenchick → credited ultimike → .

volkswagenchick → credited ultimike → .

volkswagenchick → credited ultimike → .

volkswagenchick → credited ultimike → .

volkswagenchick → credited ultimike → .

For me, the issue only occurs with some authenticated users. I've tried to narrow it down a bit based on permissions, but no luck.

Disabling BigPipe solves the issue for all users, so I'll be waiting for 🐛 10.3 upgrade now missing status-message theme sugestions Active to be resolved as well.

-mike

With the release of Drupal 11 a few days ago, before we tag the 2.2.0 release, I'd like for us to get a fully clean GitlabCI test report. Currently, "phpunit (next major)" is failing. I don't think that there's a Drupal core 12.x branch yet (via https://git.drupalcode.org/project/drupal), so I'm not sure if we should just disable that test for now, or another option.

I'm guessing that maybe "phpunit (next major)" is running against the 11.x branch and am working to confirm this (https://drupal.slack.com/archives/CGKLP028K/p1722796036303819).

...a few minutes pass... Whoops, I just noticed 📌 Update fixtures for run updates Active - glad we're on the same page 😀

Before tagging a release, I'd like to get ✨ Smart Trim Tokens for text with summary fields Needs review merged as well.

-mike

Thanks @lostcarpark and @ankitv18 - I'm closing this issue as the fix is part of ✨ Smart Trim Tokens for text with summary fields Needs review .

-mike

A couple of thoughts:

• Current tests are failing.
• If we want to proceed with this change, we'll need a new test for this new functionality.
• Do we want to proceed with this change, our goal has been to simplify the configuration, not add additional options. Is there any way to achieve the same results by utilizing a template override?

-mike

Looks good do me - merging.

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

I can confirm that using Gin with Field Group results in gin's tabs.css file being loaded in the front end (due to the Gin admin menu, I assume) and messing up many (all?) of Field Group's horizontal tab styles. 🙁

-mike

I changing this to "needs work", but for any serious reason - only because I have a question about the test logic that I couldn't figure out on my own...

thanks,
-mike

@markie - I'm don't follow - did you actually merge this? I don't see where you did...

-mike

ultimike → created an issue.

Thanks everyone for pushing this issue forward, and also for your patience for one of this module's slacker maintainers finds the time to check it out (present company included).

First off - this needs a test. @markie and I have been really trying to require tests for all feature additions and bug fixes, so this would be no exception. I think a functional test would be pretty straight-forward...

I manually tested this using Gitpod with a few of our DrupalEasy alums and all appears to work as expected. The only thing I would make note of (possibly with an update to the README and/or docs) is the fact that the Token view mode must be enabled and configured with a Smart Trim formatter (for the field(s) in question) or the Smart Trim tokens aren't really involved.

Regardless, we tested Smart Trim tokens with Pathauto and Metatag with everything working as expected.

I went ahead and committed @heddn and @akalata's suggestions, as well as a PhpStan ignore for renderPlain() in smart_trim.tokens.inc (see 📌 Handle renderPlain() deprecation Active ).

-mike

ultimike → created an issue.

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

volkswagenchick → credited ultimike → .

I left a couple of minor suggestions above.

-mike

I tested this using DrupalPod (Drupal core version 10.0.11, PHP 8.2) and when I went to /admin/people/createautologinurl I immediately received an error (partial stack trace):

The website encountered an unexpected error. Please try again later.

AssertionError: Cannot load the "user" entity with NULL ID. in assert() (line 261 of core/lib/Drupal/Core/Entity/EntityStorageBase.php).
Drupal\Core\Entity\EntityStorageBase->load(NULL) (Line: 106)
Drupal\auto_login_url\Form\CreateAutoLoginConfigForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm('auto_login_url_create', Object) (Line: 283)

I'm pretty sure this is because the first time a user visits this form, the auto_login_url.create config doesn't exist yet. I'm a bit confused by why this config even needs to exist - is it just so that the form remembers the previously used values? If so, then maybe a better option is using the Drupal State API.

Finally, I also want to mention that I don't understand why the password field is included if this form is only available to those with the "administer auto login url" role. It seems that with the password field present, one can only create auto login urls for themselves. Granted, maybe I am missing something, but I don't understand why the password field is part of this form - please explain.

thanks,
-mike