🇺🇸United States @jcandan

I know it is strange, but recipes are not expected to be in separate directories (contrib/custom). If the desire here is to be able to easily adopt GenericRecipeTestBase , then the path really should be ../recipes/{$name} . Otherwise, we'd need to manipulate installer-paths.

@jonathan1055, yes, feel free to submit an MR. You'll probably need to do something like:

.composer-base:
  variables:
    DRUPAL_GITLAB_TEMPLATES_PATCH_URL: "https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/408.patch"
    GITLAB_TEMPLATES_PACKAGE: "drupal/gitlab_templates"
    GITLAB_TEMPLATES_PATCH_DESC: "Apply MR408 to gitlab_templates"
  before_script:
    - |
      composer config --no-plugins --no-interaction allow-plugins.cweagans/composer-patches true || true
      composer require --no-interaction cweagans/composer-patches || true
      composer config --no-interaction \
        "extra.patches.${GITLAB_TEMPLATES_PACKAGE}.\"${GITLAB_TEMPLATES_PATCH_DESC}\"" \
        "${DRUPAL_GITLAB_TEMPLATES_PATCH_URL}"

@fjgarlin, I meant to clean that up. Not really, it just adds hidden-variables, additional security scans, and changes workflow rules.

@jonathan1055, the default value, no. Docs indicate it will default to modules/custom. But, if you meant that it would get it from the PROJECT_TYPE, it seems this value comes from the *.info.yml, which Recipes don't have.

Since supplying the type would place it in recipes/custom, one might be inclined to think the easy solution would be:

variables:
  PROJECT_TYPE: 'recipe'

    ...
    return "{$absolute_path}/web/recipes/custom/{$dirname}";

But, if you only specify the PROJECT_TYPE: 'recipe' CI variable, a dev would also need to update the Composer installer-paths (perhaps via .composer-base, maybe). Because, otherwise, dependencies will be in ../recipes, and he would get a recipe does not exist.

Here's an demo of this:
https://gitlab.com/jcandan/demo_drupal_gitlab_templates_recipe/-/merge_r...

So, would you like to change scope for this ticket to update documentation with an explanation about using DRUPAL_PROJECTS_PATH: '../recipes'?

Until a solution is released, the following workaround seems to suffice:

# .gitlab-ci.yml
include:
  - project: 'blue-hangar/project/gitlab_templates'
    file:
      - '/includes/include.bluehangarci.main.yml'

variables:
  DRUPAL_PROJECTS_PATH: '../recipes'

/**
 * @file recipes/myrecipe/tests/src/Functional/GenericTest.php
 */

declare(strict_types=1);

namespace Drupal\Tests\myrecipe\Functional;

use Drupal\Tests\system\Functional\Recipe\GenericRecipeTestBase;

/**
 * @group myrecipe_recipe
 */
class GenericTest extends GenericRecipeTestBase {

  protected function getRecipePath(): string {
    // Assume this test in located in PROJECT_DIR/tests/src/Functional.
    $absolute_path = dirname((new \ReflectionObject($this))->getFileName(), 4);
    $dirname = basename($absolute_path);
    return "{$absolute_path}/recipes/{$dirname}";
  }

}

jcandan → created an issue.

I can also confirm this fixes the error as seemingly introduced by 🐛 Controlled-by fields inside a Paragraph don't work Needs work .

jcandan → created an issue.

jcandan → created an issue.

My bad: tests/src/FunctionalJavascript/ConditionalFieldParagraphsTest.php. Since there was no .gitlab-ci.yml entry to get Paragraphs, I wrongly assumed that there were no tests. I didn't realize Paragraphs was a dev-dependency for this module.

jcandan → created an issue.

With ✨ Add require on publish as a conditional field option Active merged, we need to determine if this is still a concern.

jcandan → created an issue.

jcandan → created an issue.

jcandan → created an issue.

jcandan → created an issue.

Closing in lieu of prioritizing ✨ Support plugin integration Active .

jcandan → changed the visibility of the branch 3454164-support-compound-fields to hidden.

jcandan → created an issue.

jcandan → created an issue.

jcandan → created an issue.

Needs to be re-worked with the recent merge from 🐛 content_moderation support Needs work . I'm giving it a go.

🐛 PHPUnit job hangs as of update to PHPUnit 11.5.29 Active

jcandan → created an issue.

Added tests. Tests pass, but since the PHPUnit update bug they fail.

Needs review.

This may prove more complex than originally thought. See #3126210-3: Address with default country code always validates as required → .

I can remove the HTML5 required attribute via any number of hooks, but backend validation still applies and the fields are required on submit (published or not).

I'm glad we separated this from ✨ Add support for multi-value fields like Name and Address fields Active . In the meantime, as a not-so-great workaround, those wishing to apply Require on Publish to an Address field may consider leaving off a default value, and assuming the user's intent to fill out the full address when they provide a country.

Needs test coverage.

Moving forward with the release. 🐛 content_moderation support Needs work will come in a patch shortly thereafter.

Released 2.0.0-rc2!

Very happy with the tests added in 🐛 content_moderation support Needs work . Very strong candidate for 2.0.0. That ticket needs review.

Added significant test coverage including Paragraphs and Content Moderation support. Needs review. Any takers?

Does 🐛 content_moderation support Needs work fix this?

Added test coverage.

Needs test coverage.

Bumps previous phpunit job to this phpunit job from 8 to 9 tests and 73 to 77 assertions. Happy with the result.

Blocked by 📌 Add test to ensure require on publish after saving Active .

jcandan → created an issue.

Given the jump in assertions, I consider this a success.

Never mind. #3539138-2: Ensure require_on_publish setting is applied when FieldConfig is created programmatically → explains why.

But, there is another issue. 📌 Fix EditPageTest not actually ever hitting assertions Active needs to be resolved so we can effectively test the Name Field support.

jcandan → created an issue.

Never mind. This only becomes a problem when we introduce #states Form API handling. Providing the third-party setting programmatically is the correct path forward for tests in ✨ Add support for multi-value fields like Name and Address fields Active . Postponed until we work on ✨ Add require on publish as a conditional field option Active .

@anirudhsingh19, thank you for contributing! We're close. We need test coverage. I got us part of the way there by adding Name as a part of the CI pipeline.

However, I recognized a problem while writing tests for this. We're currently blocked by 📌 Ensure require_on_publish setting is applied when FieldConfig is created programmatically Active .

jcandan → created an issue.

My bad--I didn't explain why I'd switched the version. It seems 2.x-dev should be deleted while a minor dev releases exists. See 🐛 Fix Composer stable, caret constraint installs dev release Active .

@jeroen dost, I agree this affects both, but it seems--as with many other issues-- 📌 Refactor custom JS for CKEditor5 v45+ Active will address this issue. I wonder if we need to ensure the scope of that ticket includes this, or just mark this as a 2.x-dev issue.

I can see an argument for either way. Just having this note here may be sufficient. :)

Also, in addition to the problems described, it seems 2.x has been abandoned anyway (source).

Pipelines fail. Needs fixes. Would like to shoot for a 2.1.0 release.

Am considering 🐛 content_moderation support Needs work for 2.0.0.

Am considering this for 2.0.0, or 2.0.1, depending on the speed with which we get a review.

We have released the bug fixes to 8.x-1.11 and 2.0.0-rc1.

We encourage everyone to at least try 2.0.0-rc1. Feel free to provide feedback here or open new bug tickets.

We will support bug fixes8.x-1.x for at least a couple of weeks after 2.0.0 is released, which we hope to complete in the coming days.

Also...

so a composer install on a fresh environment no longer works to patch

@alimc29, I wouldn't rely on MR URLs for patches. It is best to use patch files uploaded to the issue or to commit them to your project.

However, don't fret--a release candidate supporting Drupal 11 is forthcoming. :)

Yeah, sorry, this is in progress. Assigned to me. I am working out some testing kinks in 🐛 Ensure ConfigPageTest actually verifies require_on_publish setting Active first. I plan to get this out today.

jcandan → created an issue.

Could we add the following to one of the lists?
🐛 Empty action sets field value to "undefined" Active

jcandan → created an issue. See original summary → .

Tested 2.3.1 on Drupal 11.2. This issue does not exist in 2.3.1.

This bug is isolated to 2.2.x releases, and should be addressed in that branch for continued support up to Drupal 10.4 and 11.1 and below core versions.

Drupal 10.4 and 11.1 will receive security coverage until December 2025 ( source → ).

Given 🐛 Link attributes don't save Needs review bug affects both 2.2.x and 2.3.x,

And given the effort here to fix 2.3.x specifically for CKEditor 45+

Can we officially adopt the image/media link attributes bug within the scope of this issue?

This would allow us to laser focus on the issues as they exist differently in each minor version.

The question is, are we willing to change the scope of each, given the amount of work already attempted?

Give it a day or so, if no comments to the contrary, I may go in and update and clarify scopes for each.

Given this bug affects both 2.2.x and 2.3.x,

And given the effort at 📌 Refactor custom JS for CKEditor5 v45+ Active

Should we make this ticket officially focussed only on 2.2.x?
And should we make the 45+ refactor include this bug in its scope?

This would allow us to laser focus on the issues as they exist differently in each minor version.

The question is, are we willing to change the scope of each, given the amount of work already attempted?

Give it a day or so, if no comments to the contrary, I may go in and update and clarify scopes for each.

@s_leu, MR !16 is still in draft. Any particular reason? If not, consider removing the Draft prefix from the MR title, and marking Needs Review.

Agreed. It seems this would be fixed by #3534699.

I am not sure why, but I am unable to recreate the success I had in #47!

Confirmed text link attributes all persist as expected with MR !37 on 2.3.x with Drupal 11.2.2.

However, MR !37 breaks image link attributes which, according to #3349389-47: Fix image/media link attributes being lost → , all but target="_blank" have been shown working in 2.3.1.

jcandan → created an issue.

@ndviet, just a side-note: you may enter issue links as [#123456] and [#123456-7] to take advantage of drupal.org issue and comment linking, and status highlighting.

2.3.0+ has been released alongside 2.2.0+, and there is now a 2.3.x dev branch to support CKEditor 45 ( #3519380-4: Editor Advanced link 2.3.0 release plan → ). This issue is obsolete, and the 2.x branch should be deleted (instead of deleting 2.2.x) to support the multiple minor versions currently supported. Additional reasoning can be found at 🐛 Fix Composer stable, caret constraint installs dev release Active .

jcandan → created an issue.

Testing editor_advanced_link 2.3.1 on Drupal 11.2.2 reveals this is almost fixed. Attributes remain except target="_blank".

Right. It seems Twitter/X is no longer supporting the widgets.js embed as an alternative to the paid basic tier API. I have not seen any official announcement to this specifically, but at this point I think it is safe to assume they've turned off support for this method.

@estebanvalerio.h, I don't the the README has been updated.

Looking at the commit list for README.md, I see where @adam-vessey got the line from cc493bf7. But the conditional he suggested hasn't been added.

It’s a beautiful thing.