🇺🇸United States @jcandan

Sorry, my previous comment wasn’t formatted correctly. Fixed. It includes composer command for the required modules.

Reviewed.

This did fix the Olivero Teaser. Obviously, nothing is shown, but there's no error.

I did try with UI Suite USWDS, and although the components provided by that theme also were blank, no errors were shown.

However, once that theme was enabled, I did get the following error in the Olivero Teaser component view:

The website encountered an unexpected error. Try again later.

Twig\Error\RuntimeError: An exception has been thrown during the rendering of a template ("Data provided to prop "attributes" for component "olivero:teaser" is not a valid instance of "Drupal\Core\Template\Attribute""). in Twig\Template->yield() (line 1 of core/themes/olivero/components/teaser/teaser.twig).
Drupal\Core\Theme\Component\ComponentValidator->validateProps() (Line: 127)
Drupal\Core\Template\ComponentsTwigExtension->doValidateProps() (Line: 109)
Drupal\Core\Template\ComponentsTwigExtension->validateProps() (Line: 52)
__TwigTemplate_6b0fecdcfa442453874f681702db33fb->doDisplay() (Line: 393)
Twig\Template->yield() (Line: 80)
__TwigTemplate_381600d8b2a74e1648ca6b760fdfea2d->doDisplay() (Line: 393)
Twig\Template->yield() (Line: 349)
Twig\Template->display() (Line: 364)
Twig\Template->render() (Line: 35)
Twig\TemplateWrapper->render() (Line: 234)
Drupal\Core\Template\TwigEnvironment->renderInline() (Line: 160)
Drupal\dab\Controller\DabComponentController->embed()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 741)
Drupal\Core\DrupalKernel->handle() (Line: 19)
<code>

Here's a one-liner to quickly get UI Suite USWDS running:

<code>
ddev composer require drupal/layout_options drupal/ui_styles drupal/ui_suite_uswds; ddev drush en layout_options ui_icons_patterns -y; ddev drush then ui_suite_uswds -y; ddev drush config:set system.theme default ui_suite_uswds -y;

What is the purpose of $version here?

jcandan → created an issue.

This seems to have fixed it.

While a patch 🐛 Rename erroneous Alert Banner grouping Active is now available to fix this module incompatibility, this really should be addressed, since there is no sanitization on the group usage in URL generation.

Any other suggestions than the 2 noted above?

Agreed; that is the issue with that module. And, yes, it would fix the incompatibility. But surely you can see this is a fair proposal considering the quotes in #8 🐛 Rename erroneous Alert Banner grouping Active .

I hope you'll reconsider.

Immutable patch provided for Composer.

Also, not to be rude, but how does grouping them make any sense?

An alert keeps users informed of important and sometimes time-sensitive changes.

Banners identify official websites of government organizations in the United States. They also help visitors understand whether a website is official and secure.

MR !100 opened.

@smustgrave, any thoughts then about 🐛 Fix InvalidParameterException on component_type URL generation Active ?

jcandan → changed the visibility of the branch 3499479-rename-erroneous-alert to hidden.

I've opened 🐛 Rename erroneous Alert Banner grouping Active to address the incompatibility.

The Annotated example component.yml docs → give no expectation of format on the group key. This seems like a shortcoming in the Drupal documentation. Perhaps a core issue should be opened.

This fix would have the added benefit of addressing a problem with 🐛 Fix InvalidParameterException on component_type URL generation Active

jcandan → created an issue.

Core doesn't have a canonical solution for this need to convert strings to URL friendly paths.

There's a couple options to deal with this. Either we...

1. Follow the community's attempt via the Html::getClass() method.
2. Add Pathauto as a dependency to gain access to its AliasCleaner::cleanAlias() method.

Curious for community thoughts on the following change:

  
  RewriteCond %{REQUEST_URI} !/core/(authorize|install|rebuild)\.php$

jcandan → created an issue.

The Annotated example component.yml → docs give no expectation of format on the group key. This module's use of the group as a URL parameter with no URL encoding may be part of the issue. Perhaps some manipulation of the group value to be URL friendly would be necessary.

jcandan → created an issue.

After having a look at the patch for 🐛 Issue: Call to a member function getRequestUri() on null in Drupal\ctools_views\Plugin\Display\Block->elementPreRender() Needs review , I saw that it may have been related to having AJAX enabled. I enabled AJAX for my view, but still had no issues. Also tested on Drupal 11.

Need steps to reproduce.

Dropped support for Drupal 8 and Drupal 9.

Re-added the newline at end of file noted in #6 ✨ Drupal 11 compatibility Active .

RTBC. MR !1 is ready to merge.

Actually, one thing...let's support Drupal 10+ only. Drupal 9 reached end-of-life. Drupal 10 is supported until Drupal 12.

I was going to address this in a follow-up issue, but that's probably not necessary.

While there may be some use of this module, this module is still in development and pending a beta pre-release. I think we're within rights to deprecate outdated Drupal core support without bumping major version for a breaking change.

Removing Drupal 8 and 9 support.

Use the merge request.

I was able to get this working on 10.4.0 and 11.10. Marking RTBC.

I have a working copy of this module installed with Drupal 10.4.0. I am able to add a block display to a view, add view mode as a block configuration option, select different view modes in the block instance, and see the result working.

What steps can we follow to reproduce this bug you are having?

Seems this is a known bug: 🐛 patches to info.yml files are created against the wrong version and don't apply Active .

The problem was with the whitespace at the end of the file, which is Drupal coding standard.

I'll test without that whitespace and see if 🐛 D10 upgrade ? Active is still an issue. If it all good, we'll re-add the whitespace to the merge request and consider this RTBC.

Not sure why, but MR !1 is giving me errors when I attempt to use the patch.

        "patches": {
            "drupal/views_override_viewmode": {
                "Drupal 11 compatibility": "https://git.drupalcode.org/project/views_override_viewmode/-/merge_requests/1/diffs.diff"
            }
        },

Gathering patches for dependencies. This might take a minute.
  - Installing drupal/views_override_viewmode (1.0.0-beta1): Extracting archive
  - Applying patches for drupal/views_override_viewmode
    https://git.drupalcode.org/project/views_override_viewmode/-/merge_requests/1/diffs.diff (Drupal 11 compatibility)
   Could not apply patch! Skipping. The error was: Cannot apply patch https://git.drupalcode.org/project/views_override_viewmode/-/merge_requests/1/diffs.diff

In Patches.php line 331:
                                                                                                                                          
  Cannot apply patch Drupal 11 compatibility (https://git.drupalcode.org/project/views_override_viewmode/-/merge_requests/1/diffs.diff)!  

Also tried with the .patch extension.

We can probably close 📌 Automated Drupal 10 compatibility fixes RTBC in lieu of this update when it is fixed.

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

I believe this is an Entityqueue → issue. They created an entity_subqueue content entity, but opted to do something special with the ID by making it a machine name instead.

Linked related 🐛 Machine name not set when using sub queue as an entity reference Active .

I suggest closing this ticket in light of the above.

This is an issue also reported in 💬 Entityqueue entity fails to import Active , which uses Default Content.

I am also getting this error when attempting to import and entity_subqueue via Default Content → :

In ExceptionHandler.php line 45:

SQLSTATE[HY000]: General error: 1364 Field 'name' doesn't have a default value: INSERT INTO "entity_subqueue" ("revision_id", "queue", "uuid", "langcode") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array 
(
      [:db_insert_placeholder_0] =>
      [:db_insert_placeholder_1] => my_entity_subqueue
      [:db_insert_placeholder_2] => c3655edc-a41b-42bd-bf82-5cbc92268c67
      [:db_insert_placeholder_3] => en
  )

In StatementWrapperIterator.php line 113:

SQLSTATE[HY000]: General error: 1364 Field 'name' doesn't have a default value

I got here from ✨ Add config actions to delete config Active . Even though I need this ability right now, I can completely agree with the idea of not including it.

The reason I need it is that we are firing up Recipes to run a bunch of automations for our turn-key websites. These automations fire off when one of our special themes is enabled.

However, Recipes introduces a new way of attacking our automations from scratch. We'll not need to provide the initial version of the site to then need to be overridden. We'll simply provide the right set of recipes from the get-go.

While I could see a use-case for this in a contrib module, perhaps this should not be included in core.

Seems something is brewing on that front.

✨ Add a config action to remove effects from image styles Needs work

I am experiencing this error when trying to supply config files for existing configs such as views or image styles.

Note: I am unable to just supply the full config file because I get an Error when installing a recipe that has configuration files already in the system, even if there is no difference 🐛 Error when installing a recipe that has configuration files already in the system, even if there is no difference Postponed: needs info .

Not re-opening, but curious if someone could chime in.

In the case of image styles, when a simple_config_update needs to swap an effect, there's no way to delete the existing effect.

A patch for 10.3.x sites. MR ready to be created if desired.

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

Good catch.

jcandan → created an issue.

jcandan → created an issue.

Adjust link colors. Apparently this is overridden in the d.o CSS causing links to be invisible until hover. This is not a good solution, but a temporary attempt at a fix for at least this page. Should probably submit an issue for a real fix.

Noted the functionality and linked to this issue from the Sub-Theme inheritance → docs.

Supplies link destination titles as link text.

Adds note about CKEditor Stylesheets behavior introduced in  Change record: New API for adding theme-specific styles in CKEditor 5 → . Links to existing issue to allow overrides from sub-theme.

Any reason this couldn't be submitted as a patch or merge request?

Go forward with an issue to get that Gitpod launcher working?

After reading https://git.drupalcode.org/project/drupal_cms/-/wikis/Contributing-to-Drupal-CMS and finding out that the trial experience is built on DDEV, I attempted to fire up Drupal CMS via DDEV Gitpod launcher.

It works. However, it does not support Project Browser out of the box, but not in the same way as 🐛 Fix Project Browser returns 0 results in Trial Experience Active . I get composer errors. I trudged through a couple, but hit a wall.

Not extensively tested other than that.

Steps followed:

1. Visit DDEV Gitpod launcher.
2. Enter `https://git.drupalcode.org/project/drupal_cms` as the git repository.
3. Delete the git repository with artifacts field.
4. Open Gitpod.
5. Replace config.allow-plugins: true with config.allow-plugins: { }.
6. Run ddev composer install and said yes to plugin install prompts except for tbachert/spi.

jcandan → created an issue.

mferanda → credited jcandan → .

The [node:field_mylimitedtermreferencefield:entity:url:path] worked perfectly. Thanks!

jcandan → created an issue.

I am playing with this same problem space. I am building an organization-specific USWDS (like design.va.gov), with a concept similar to how Emulsify demo’d Western U with multiple in-house brands. The plan is to have Storybooks at those multiple levels, and then at the individual project instance level (Drupal and non-Drupal projects).

So, the Drupal-specific twig muddies the waters.

Still playing. Curious how this pans out.

There is talk of forking Opigno. An effort is underway (see #14 → from another ticket), but it may not have gotten traction. However, with the release of 3.2.7, there may now develop a movement in the community to conduct a proper fork.

To avert this effort, to continue to foster community use, and to gain community contribution, please consider creating a development release for Opigno LMS and its ecosystem modules.

Drupal 10 compatible 3.2.7 has been released. With this release, setting to Needs Review to get community feedback to ensure Drupal 9 sites are now able to upgrade to Drupal 10 to close out this issue.

Thank you for this release! With the release of 3.2.7, setting to Needs Review to get community feedback to ensure Drupal 10 compatibility to close out this issue.

jcandan → created an issue.

jcandan → created an issue.

@andrewfarq,

Not sure what happened with [!5634], but it looks to have ended up only adding testSessionManagerInvalidateSessionOnDestroy(), and no other changes.

Also, your proposal in #40 🐛 Log out show error message "... your browser must accept cookies ..." Needs work may ignore other's experiences with this issue outside of the install process , such as after upgrade #21 🐛 Log out show error message "... your browser must accept cookies ..." Needs work or with anonymous users #22 🐛 Log out show error message "... your browser must accept cookies ..." Needs work . Or is that what #18 🐛 Log out show error message "... your browser must accept cookies ..." Needs work is proposing? I may have misunderstood that.

At non vanilla instance with firewall issues resolved, I am still getting "could not retrieve source count...".

Re-roll as suggested in #20 ✨ Import data from URL Closed: won't fix .

jcandan → changed the visibility of the branch 2927126-import-data-from to hidden.

::insert foot in mouth:: It turns out the CSV I was trying to reach was behind a firewall.

I've confirmed this functionality on a clean instance with a publicly available, remote URL https:// CSV.

Returning this to Closed (outdated). Cheers!

jcandan → changed the visibility of the branch 3469594-allow-a-remote to hidden.

Taking inspiration from patch #15 → of ✨ Import data from URL Closed: won't fix , with a fix to for the removal of file_save_data() → , it may be simpler to replace all the curl bits to go with something like:

    // Retrieve data from URL.
    $data = file_get_contents($remote_path);
    if ($data === FALSE) {
      throw new \RuntimeException("Unable to retrieve data from '{$remote_path}'.");
    }
    // Save data to temporary dir.
    $path = "temporary://" . basename($remote_path);
    $file = \Drupal::service('file.repository')->writeData($data, $path);
    if ($file === FALSE) {
      throw new \RuntimeException("Unable to save file to '{$path}'.");
    }
    return $file->getFileUri();

A patch rolled from #5 ✨ Allow a remote file to be specified for the Source path parameter Active .

This was closed 2 years ago. I did reopen, however I see ✨ Allow a remote file to be specified for the Source path parameter Active has a recent attempt at this. Setting back to closed, but as won't fix in lieu of that effort.

I disagree. Comment #16 ✨ Import data from URL Closed: won't fix simply points out that the s3:// stream wrapper works. External URLs are still broken.

Patch #15 needs a re-roll with the removal of file_save_data() → .

This is a core issue. Marking closed (duplicate). New core ticket: 🐛 Fix cropped handle icon Active .

jcandan → created an issue.

jcandan → created an issue.

So far as I can see on a cursory review, the set of Icons determined to be available are hard-coded here and here (Not sure why it is listed twice, and each list is different).

I imagine we could refactor this to a single place. Then ensure that place gets the list from configuration. There may also probably need to be a mapping from the above configuration to the iconSource options listed at the vanila-icon-picker NPM package docs.

jcandan → created an issue.

thejimbirch → credited jcandan → .

If it really is a breaking change, that warrants a major bump. But, I’m beginning to think it is not a breaking change. The controller and route were in place because the view had not controlled that without a page display. With this change, it does. It also shifts access control to the view with a new view access plugin. So, all the update is confined to the one view.

With a hook update, we could override any customizations they may have made to the view. Without the hook update, if they don’t run the view update config:set, they won’t get the changes and it’ll break.

I’m of the opinion that if they customize a module-provided view, any config changes upon update is there’s to deal with.

That said, I’m for a minor update to 1.1.0 and a hook update to close out this ticket.

Still awaiting community feedback on options 1 or 2 noted in #13. 🐛 Fix Bookmarks view is missing a display Needs review

This also solves a previously hidden views permissions issue which prevented non-admin users from seeing the links and title fields reported at 🐛 Fix bookmark link not shown for non-admin users Fixed #8 🐛 Fix bookmark link not shown for non-admin users Fixed .

Apologies, I should have noted this here before. The bug described in #8 and #18 should be resolved by 🐛 Fix Bookmarks view is missing a display Needs review .

One thing I noticed prior to the patch, this only affected one of our two migrations with the above uid field process configurations. Not sure why that is.

Either way, patch #2 applied successfully on 6.0.4 and warnings have stopped. Thanks!

jcandan → created an issue.

Leaving this one last note here for if we do decide to go with a hook update.

function bookmarks_update_VERSION() {
  $config_factory = \Drupal::configFactory();
  $view = $config_factory->getEditable('views.view.bookmarks');

  if ($view->get('display.default.display_options.access.type') != 'bookmarks_view_access') {
    $view->set('display.default.display_options.access.type', 'bookmarks_view_access');
    $view->set('display.default.display_options.title', 'Bookmarks');
    ...
    $view->save();
  }
}

As we consider this, these resources may help with development:

• function hook_update_N
• Don’t go making major version changes
• 📌 Document how contrib hook_update_N() should be numbered now that modules can be compatible with multiple major branches and versioned semantically Fixed

We've adopted patch #12 to a production project, I am happy to place this to RTBC; however, I am chewing on whether this needs a hook update for the veiws.view.bookmarks changes and whether this would need a major, minor, or patch version bump.

Obviously, the fix is adopted for any new install. But, for this fix to apply to existing installations would override their existing Bookmarks view--this could be considered a breaking change requiring a major version bump.

The way we applied the change was to simply import the single updated configuration from this module, and then used git to help us track which changes we wanted to keep:

cat web/modules/contrib/bookmarks/config/optional/views.view.bookmarks.yml | drush config:set --input-format=yaml views.view.bookmarks ? -

I imagine we could just bump the patch version and include this instruction in the release notes.

So, the above boils down to, either we:

1. Include a hook update and bump the major version.
2. Include the single config import instructions in the release notes and bump the patch version.

Opinions welcome.