Rebased Merge request !28 to capture recent slew of updates to 2.2.x.
Though this captures the work in progress so far, the issue has not been resolved. Still needs work. Patch #31 likely needs a re-roll to apply correctly, but will wait until we have created a working solution.
No merge required. It turns out that, although the 2.2.x to 2.x comparison shows the logo change as a difference, the logo change is indeed part of 2.2.x.
The 2.2.x is the most up-to-date branch.
We can safely rebase 2.x from 2.2.x, then remove 2.2.x.
Maintainer may find the following helpful.
git fetch --all
git checkout --track origin/2.x
# skipped previously applied commit 8fb5e79, reapply-cherry-picks to include skipped commits.
git rebase --reapply-cherry-picks 2.2.x
# see that the branches now match at HEAD.
git log
# delete remote branch.
git push origin :2.2.x
# delete local branch.
git branch -D 2.2.x
This is a follow-up to #3371633-40: Exceptions thrown when toggling Advanced section of linking form → .
We no longer need to wait to decide if the other ticket takes priority and fixes this issue. Given the recent slew of changes merged to 2.2.x, and possibly due specifically to ✨ Use built-in CollapsibleView instead of DetailsView Active , this issue seems to have been resolved.
Marking fixed. Feel free to reopen if you're able to reproduce the exceptions described above. Note: this ticket will automatically be closed (fixed) if no status change is made in 2 weeks.
I've opened 🐛 Fix keyboard accessibility of advanced attribute fields Active for the issue described in #38.
Given the recent slew of changes merged to 2.2.x, and possibly due specifically to [#16061370], this issue seems to have been resolved.
Marking fixed. Feel free to reopen if you're able to reproduce the exceptions described above. Note: this ticket will automatically be closed (fixed) if no status change is made in 2 weeks.
You may need to run Yarn's yarn dedupe command to potentially consolidate the package to a single version if the versions are compatible.
This introduced duplicate, higher version than core in yarn.lock file:
"@ckeditor/ckeditor5-core@41.3.1":
version "41.3.1"
resolved "https://registry.yarnpkg.com/@ckeditor/ckeditor5-core/-/ckeditor5-core-41.3.1.tgz#b4bf65cc1a291d78d9e47269ae159aec1451d99b"
integrity sha512-h+PgPtCpS2vjO3HbKMYtddRPW+B3AJx9qpixmHJnUZMiFCmRjUZjXATjpi3j+kSQISs4L2Yghq+lsAQxyGHb+A==
dependencies:
"@ckeditor/ckeditor5-engine" "41.3.1"
"@ckeditor/ckeditor5-utils" "41.3.1"
lodash-es "4.17.21"
"@ckeditor/ckeditor5-core@41.4.2":
version "41.4.2"
resolved "https://registry.yarnpkg.com/@ckeditor/ckeditor5-core/-/ckeditor5-core-41.4.2.tgz#0779a727b0238368fc09ee4ec855536ea1ab24db"
integrity sha512-kCIJjviiMNIMBMx7XFXFp1IeTELQKv7xyPJiVFDyUftIfthf9uWty72ipZ3BBNBGBkaoTiSzDZ507EsX6czuIQ==
dependencies:
"@ckeditor/ckeditor5-engine" "41.4.2"
"@ckeditor/ckeditor5-utils" "41.4.2"
lodash-es "4.17.21"
Perhaps, to ensure we match core, we should remove the open constraint (~) on ckeditor5.
✨
Use built-in CollapsibleView instead of DetailsView
Active
introduced a bug to 2.2.x: the tabindex problem experienced in !14, described in #28--keyboard navigation skips advanced fields.
Do we want a new issue for this, or will we tackle that here?
Can we add the following bash examples to help with Yarn linking all packages?
<code>
cd path/to/ckeditor5/packages
for dir in ./*; do (cd "$dir" && yarn link); done
cd path/to/core
for dir in /path/to/ckeditor5/packages/*/; do (dirname=$(basename "$dir") && yarn link "@ckeditor/$dirname"); done
</code>
I am attempting to debug this via a source build. Requires a bump to CKEditor5 v41.3.1 due to errors mentioned in ✨ Upgrade CKEditor to match Drupal core at 41.3.1 Active .
Running through
CKEditor 5 development →
docs, when I am on v35.1.0, the yarn install command fails with:
error @es-joy/jsdoccomment@0.36.1: The engine "node" is incompatible with this module. Expected version "^14 || ^16 || ^17 || ^18 || ^19". Got "22.14.0"
When I am on 41.3.1, this error does not occur.
If this really is a necessary component of the CKEditor Plugin plugin module development, is it possible to provide the Drupal GitLab CI with an NPM build so these artifacts are not required to be committed?
Moved to the source example project driving Drupal modules to use webpack builds.
As I learn more about CKEditor 5 Plugin plugin development, I understand now that projects like Editor Advanced Link are led to implement a build by this project.
I am curious what, if any, dependency issues exist that might prevent a Drupal module from not including a build process for CKEditor Plugin plugins.
Re-titled this issue to be more clear.
I read back through the thread, and found that @godotislate described the bug I describe #38 in #28--including a link to a merged CKEditor PR.
The code from the PR mentioned is indeed present in the current yarn.lock version, CKEditor v35.1.0:
https://github.com/ckeditor/ckeditor5/blob/v35.1.0/packages/ckeditor5-li...
So, if CKEditor fixed this, what about the Editor Advanced Link implementation is reintroducing it?
This suffers from similar tab index issues found at 🐛 Exceptions thrown when toggling Advanced section of linking form Active and not saving link attributes for images found at 🐛 Link attributes don't save Needs review .
This is possibly a lot simpler than I originally imagined. There are no front-end dependencies outside Drupal core's CKEditor.
Regardless of the Paragraph inconsistency noted in #38, this module should be able to apply the attributes to the link whether wrapped in a paragraph or not. That seems to be the crux of the issue.
Now, if only I could get the front-end debugging figured out. I may need to have a go at #19 🐛 Link attributes don't save Needs review 's debug steps.
It turns out, depending on the image position chosen, a paragraph tag (
) may or may not wrap the image.
When the paragraph tag is present, all attributes save as expected. When the paragraph tag is not present, the attributes go away. You can see this happen in real time, changing back and forth between different image positions and source.
Additionally (and this may be a core bug), switching between different positions may or may not set it to Paragraph depending on whether it already had paragraph set. The only consistent position to always receive Paragraph, no matter which position you switch from is In-line.
benjifisher → credited jcandan → .
FYI, I won't be at DrupalCon Atlanta 2025, but there is a BoF scheduled for the Modeler API on Monday.
What ECA has demonstrated successfully in combination with bpmn_io should be opened up for other modules like Migrate, AI Agents, or others to also leverage modeler UIs like bpmn_io or others to do similar things without having to have parallel and similar implementations. Can we do that once and for all?
Good news. It works as designed.
I incorrectly called the connection. I needed to pass "migrate" as the 2nd argument:
$connection = \Drupal\Core\Database\Database::getConnection('default','migrate');
See Adding additional databases to your configuration →
Also, just a note for sanity in life: Lando doesn't make the MS SQL database persistent with a volume mount. Simplify your life with something like:
dest-mssql:
type: mssql
overrides:
volumes:
- ./mssql-data:/var/opt/mssql
@daniela.costa, Was there something wrong with the patch? Did it not apply? Was the bug not addressed or a new bug present? What versions were you working with?
My findings align with #3371633-35: Exceptions thrown when toggling Advanced section of linking form → . Marking RTBC.
This seems to be fixed by 🐛 Exceptions thrown when toggling Advanced section of linking form Active MR !17.
According to its #35 🐛 Exceptions thrown when toggling Advanced section of linking form Active , as of 2.2.6, it fixes the issues described there, including the console error and the tab index.
In my testing, it also fixes the bug described here. Perhaps we can get further community review by folks @here to prioritize that ticket and move it forward in lieu of this one.
Marking this ticket postponed while the other ticket is considered.
Marking as a major → bug, as I believe this qualifies:
- Render one feature unusable with no workaround.
- Cause a significant admin- or developer-facing bug with no workaround.
- Cause user input to be lost, but do not delete or corrupt existing data.
Patch #7 applies successfully to 2.2.6. Fixes issue described. However, tests failed (see report). Marking needs work.
I think there’s talk of the BPMN.iO module moving to a more generalized approach that we can take advantage of. But I agree with others that work should continue on this module until then.
I’ll also take a look at how Mermaid JS was included. It’s an interesting problem faced by Drupal modules using front-end packages.
However, I hope the focus of this spike can be on the diagram. I have a hard time visualizing the flow.
I am thinking a config form first need to establish the source and destination configuration, and THEN we can build the processors in a flow diagram from there.
Tested in a vanilla Drupal 10.3.2 with 2.2.6. Link attributes retained toggling Source and on save while wrapping either an image or a media item.
Rolled Merge request !28 into a patch for stable use.
Marking RTBC.
I did try my damndest to use what's there in BPMN.iO → and/or ECA's modeller_bpmn. I'm sure we can revisit this. But, that's a good question: does it conflict with ECA?
Here's some composer magic to make it simple to try it out:
"repositories": [
{
"type": "vcs",
"url": "https://git.drupalcode.org/issue/migrate_visualize-3511791"
},
{
"type": "composer",
"url": "https://packages.drupal.org/8"
}
],
With the above, you can composer require drupal/migrate_visualize:2.x-dev --no-update && composer update drupal/migrate_visualize --prefer-source.
Here's my go-to to try things out.
ddev composer require drupal/migrate_plus
ddev drush en migrate_visualize migrate_example -y
Log in and hit /admin/structure/migrate/manage/beer/migrations/beer_node/visualization
I've provided an orphaned 2.x branch to the [migrate_visualize-3511791](https://git.drupalcode.org/issue/migrate_visualize-3511791) fork.
volkswagenchick → credited jcandan → .
A patch for 10.4.x sites. MR !11320 is ready.
You might want to follow 🌱 Roadmap to experimental Project Browser in Drupal Core Active .
@ccarnnia, I'd prefer not to lose the original intent of the conditional. Which is to ensure we're dealing with a form submission.
Can you resubmit with the following instead?
use Symfony\Component\HttpFoundation\Request
...
$has_form_submission = $this->view->getRequest() instanceof Request && $this->view->getRequest()->request->get('form_id');
if ($has_form_submission && isset($this->view->temporary_options[$type][$id])) {
$info = $this->view->temporary_options[$type][$id];
}
I know D10/D11 compatibility is being assessed over at ✨ Drupal 10 Support Active . Any folks here have feedback on the upgrade processes?
My bad. I should have left a more clear instruction about what the proposed resolution should be.
The module correctly lists the stripe/stripe-php dependency in composer.json.
Therefore, there is no need to have a developer additionally require that dependency.
In the original post, the thing I was pointing out was that to acquire this module, named stripe_pay, the instructions incorrectly listed drupal/stripe in 2 places.
Most folks working with Drupal 8+ know they can acquire modules via Composer. However, if this instruction is to remain, the documentation should be updated to the the following:
Since the module requires an external library, Composer must be used.
composer require "drupal/stripe_pay"...
Getting started
- Create a Stripe Account if you don't have one already.
- Download and install this module with composer require "drupal/stripe_pay"
- ...
...
Hope this clarification helps.
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?
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
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...
- Follow the community's attempt via the Html::getClass() method.
- 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$
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.
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.
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.