b_sharpe → created an issue.
Are you just dealing with 🐛 Cannot have div tags inside columns in CKEditor 5 Active ? This was fixed in 2.1.x
b_sharpe → created an issue. See original summary → .
Same
MR for review, adding a todo for D11 change. Also added 📌 Fix Tests, Add Preserve Changed Test Active to test this in the future
b_sharpe → created an issue.
It appears the API here has changed in core. Also as of drupal 11, we can use #2329253.
b_sharpe → made their first commit to this issue’s fork.
Updated project page, thanks both!
Added https://github.com/pfrenssen/coder/issues/238, please review.
Code looks good and works, added comment as I'm not sure if this needs a doc update specific for config actions and/or recipes?
Looks good, test failure was unrelated and passing after rerun 👍
Nice! Tested and working as designed. RTBC
Looks good
Up for discussion, but if I'm wanting to clone an existing config and it doesn't exist, I'd expect an error here rather than just not cloning as this could affect further actions.
Removed my comment as I think base plugins make sense to be named this way as in `entity_create` and have derivatives be camel case. Everything looks great! RTBC
Everything looks good, I'm sure the messaging will always be of debate, but this could always turn to a config option at a later date.
Extremely small fix, otherwise looks good to go
b_sharpe → created an issue.
I agree this should have a label, but the implementation here I think would break some existing installations.
b_sharpe → made their first commit to this issue’s fork.
Added closures and core dependencies to libraries. thanks
b_sharpe → made their first commit to this issue’s fork.
Fixed, thanks
Not currently, each user can decide on dispatch based on the notification group, but not per notification.
Makes sense, MR for review
b_sharpe → made their first commit to this issue’s fork.
Added in
Small typo and suggestion. Code is fine.
Fixed merge conflicts, moving back to review
Related? ✨ Modernize Drupal.ajaxCommands.scrollTop() Active
Fixes the variable not being passed when use cookies is turned off.
b_sharpe → created an issue.
Leaving closed as this is obviously a 4.x thing as mentioned, but the following patch fixes the issues mentioned in #21 as I was having that exact problem of two streams initialized in a single request resulting in incorrect config.
Thanks for the reminder, I had already created a tag but forgot to add the release. Done :)
I was referring to the "New installation methods" section, it seemed somewhat relevant as core builds using webpack. My understanding of an upgrade of CKE in drupal is:
- Update core/package.json
- cd core
- yarn install
- yarn build
- yarn build:ckeditor5-types
What OS / Browser were you testing with? Here is the same thing (Simplytest default install) showing the issue on 15 with Chrome:
b_sharpe → created an issue.
Though in my tests the performance impact is negligible, this makes sense and has no impact on functionality. RTBC
The MR appears to add the domains (if connect/img-src enabled) and nonce value as expected, but I still am getting blocks on scripts added by GTM.
(Report-Only policy) The page’s settings would block a script (script-src-elem) xxx from being executed because it violates the following directive: “script-src-elem 'self' 'report-sample' http://cdn.jsdelivr.net https://cdnjs.cloudflare.com 'nonce-EjwscYt6M7NBaMfSm3IMrw'”
Passing NULL to the entityFieldManager->getFieldDefinitions
is the root here. It really shouldn't happen unless a payment type has been removed improperly, but regardless this will preven't the fatal and fallback to unavailable.
b_sharpe → made their first commit to this issue’s fork.
@pearls you're using the patch, for composer you need to use the diff: https://git.drupalcode.org/project/rate/-/merge_requests/7.diff
That is not part of this error. All I did was fix the issue of CKE update in which the modal was changed to viewModal: https://git.drupalcode.org/project/inline_responsive_images/-/merge_requ...
b_sharpe → changed the visibility of the branch 3466926-discourage-use-of to hidden.
Rebased, errors were part of #3466982: Fix Failing PHPStan issues →
Created MR to fix. Patch here for composer.
b_sharpe → made their first commit to this issue’s fork.
Patch for composer for now.
This does not appear to be in 9.4.0
b_sharpe → created an issue.
@Prashant.c where are the conflicts? The fork is 1 commit ahead of upstream... Please provide more details.
@Prashant.c that's because it's not in core, it's in this project (recipes initiative) which will get moved to core. You can see it here: https://git.drupalcode.org/project/distributions_recipes/-/blob/11.x/cor...
Why only class? This applies to any attribute a plugin is defining. If a plugin defines <div id>
you now can no longer add ID's to any source edited divs.
I believe we either need an optout of the constraint as suggested in #53 🐛 [10.2 regression] CKEditor 5 breaks when "Source"/Source editing button is added and "Manually editable HTML tags" are specified Needs review or we need to re-evaluate why this constraint is needed in the first place.
Thanks, very helpful to debug, new patch should work for those cases.
b_sharpe → changed the visibility of the branch 3302833-improve-pluginnotfound-exception to hidden.
b_sharpe → changed the visibility of the branch 3302833-imporve-exception-3 to hidden.
b_sharpe → made their first commit to this issue’s fork.
I believe this can be closed due to 📌 Move RecipeDiscovery into RecipeConfigurator Needs review
b_sharpe → made their first commit to this issue’s fork.
@DamienMcKenna can you see 🐛 Required contexts without a value: taxonomy_term Active , since this commit there are floods in logs of this, but there's really no rational behind why we're logging this when the conditions are still allowed
Can confirm the same issue, flooded logs with context that is ignored anyhow. Going to post on 🐛 Add logger in applyContexts Fixed so possibly flagged to original committers
I am still having this issue on 10.3.2 with Admin Toolbar.
- Fresh 10.3.2
- Login and check page - get MISS, then HIT
- Install Admin Toolbar and give permission to user
- UNCACHEABLE
Some of these fixes were relating to the inherited docs, not sure what the full process is there, but it's now passing.
b_sharpe → created an issue.
Recipes should not become a content deployment mechanism. We need to improve default content tooling in the module and core so that this can happen.
Agree, but recipes currently do support default content, so how is a developer expected to deal with this?
With Recipes, I'd expect you require the recipe locally (which unpacks it's dependencies but not the recipe itself), apply it, export your config, commit and you're good to go.
With default content however, if the recipe requires the content to be functional (let's use the example of creating/setting the frontpage), then unless you're porting the DB to the next env, you're back to the same chicken/egg of content blocks in config. So how does this work?
Leaving recipes in the root composer.json then subjects them to being updated via composer update. Recipes are not intended to be updated and reapplied like this.
Makes sense, and agree.
Have you tried using data-replace-inner
as described on both the
project page →
and README?
Potentially related, I've removed the VERSION
constraint from the library due to
#2205027: VERSION in library declarations does not work for contributed/custom modules →
b_sharpe → made their first commit to this issue’s fork.
@FizCS3 You should be able to either use the preprocess or the twig template to achieve the result since the library is attached to all pages. You can do the same as in the mail template to set the data attributes: https://git.drupalcode.org/project/obfuscate_email/-/blob/2.1.x/template...
Makes sense, thanks!
b_sharpe → made their first commit to this issue’s fork.
@detroz can you give the HTML that's being used in the template?
b_sharpe → made their first commit to this issue’s fork.
All looks great, tests pass and expected results tested locally, RTBC
Everything looks great and resolved from previous review. Added one comment above about invalid sources. Leaving as NR to let others comment, but I feel this could be an easy fix/win. Current fatal is as such for reference:
In ServiceLocator.php line 137:
Service "json" not found: the container inside "Drupal\Core\Recipe\InputCollector" is a smaller service locator that only knows about the "config" service.