I think unfortunately due to the way CK5 was rebuilt to not utilize any dialogs there's no way to make alterations without creating your own custom CK5 plugin to do what you need. It's a pain not being able to make quick alterations via a form alter anymore.
pameeela → credited carsoncho → .
This was mostly working, but we're using autocomplete widget so I've modified the selector to also target the autocomplete widget as well. Additionally, I added an align-self to fix the group listing title to also be centered.
carsoncho → made their first commit to this issue’s fork.
hestenet → credited carsoncho → .
We had a conversation around this a couple weeks ago in slack at the Distribution Modernization Initiative meeting. Posting here for posterity.
As a TL;DR for the naming convention for recipe names some of us liked the idea of [drupal_entity_type]_[unique_name], i.e content_type_blog, content_type_event, etc. We also had the thought of trying to stick close to what core provides for it's config naming scheme as that will help us as developers mentally keep track of things. One thought was to even include periods in the name like core does, for example node_type.event as a recipe. We hadn't tried it out, but maybe recipes will allow folder names to include periods in their names? TBD.
Also, from a developer perspective imagining them in a list in a yaml file where you have to maintain that is something I think we want to keep in mind as well. It will get hard to tell what recipes are doing if we don't have a standard.
I personally like the idea of where [#10] is going, but we would really need to align on the verbiage used. Allowing for folks to mix-and-match will make it very difficult to quickly determine what a recipe is doing.
Regarding the Recipe types and classification portion of this IS I think needs to be broken off into a separate issue from the naming convention discussion of this issue.
To add my thoughts though, I'm personally a fan of [#18] with the concept of providing "kits" to get folks off the ground quickly. A great example is the module Smart Date Calendar Kit → that @mandclu maintains. This to me is what an ambitious site builder is going to look for and gravitate to more. They don't want to think about node types or setting up views. What they want is functionality that will provide them value out of the box with little to no additional configuration needed.
Recipes can be any shape and size and that is part of the problem we're running into when we talk about how we classify them. As developers we should want to and probably start looking at having small recipes to establish generic content / paragraph types quickly and then look to extend those in more functional kit-like recipes.
At a high level I see we have 3 basic categories:
- Scaffold / Skeleton / Foundational Recipes - These are the low level "provides XYZ content/paragraph type" recipes
- Functional (Kit) Recipes - These build on top of the lower level recipes and provide additional functionality (event calendars, workflows, etc.)
- Site Recipes - These include everything above, like what Standard recipe provides
There's lots of room for additional sub-types within these 3 basic categories, but in my head that's where I see big distinctions between the size and scope of recipes.
I've added docblock info for those new methods. Ready for review.
What quality signals for recipes can we use to promote the 'best' ones in the project browser?
I believe there should be a governance group that would validate and promote 'best in class' recipes. These ones I would envision show up on the homepage of Project Browser when browsing available recipes or when creating a new site from scratch as these ones would be "verified" (maybe even with a badge in their recipe thumbnail to show this) by the governance group/community to work well out-of-the-box.
Another metric I presume we can use would be a "sites installed" count like we have for modules. This is one metric I was taught when staring out as a Drupal dev when validating quality and support of a module and I presume the same would apply for recipes as well. I'm not certain how D.O calculates the "sites installed" metric on module pages, but presumably we'd have that same capability as well?
Trying to put myself in the shoes of a brand new person to Drupal but an ambitious site builder looking to start using Drupal having something that tells me "this will work well and has been tested" would certainly give me a vote of confidence when trying to choose a recipe.
How do we manage duplicated effort on recipes? (For example, having multiple recipes for building a news site)
Maybe we start with a Meta page discussing what folks would find valuable as a recipe and create child issues that would be in the individual recipes themselves? If we start from what the wireframes showed in us Project Browser we'd have a couple we could start to look at immediately. Then would need to determine what exactly comes with those recipes.
One of the issues I keep coming back to regarding this is how do we prevent running into duplicate machine names of field names. This seems like something we'll constantly run into without a managed effort to prevent it.
Another area I think needs thought around is the size and scale of recipes. A recipe could be something as small as a paragraph component with fields while another could be effectively a fully built out site with multiple content types, views and various view modes. And in that scenario how do we keep from re-inventing the wheel when it comes to those smaller components, i.e simple "card" paragraph type effectively duplicated across multiple recipes?
Maybe the best way to prevent that duplicated effort is to create small bite-sized recipes like what Standard install recipe has done for each content type and make those available ASAP to the Cookbook Page →
I'm very curious to hear other's thoughts on this.
What I think is remaining is the tests updates. I see there's a few failing due to configuration tests as it's noting that the core.entity_view_mode.* config files have been changed and updated. This is to be expected given the hook_post_update_NAME() being included here.
Drupal\FunctionalTests\Installer\InstallerExistingConfigMultilingualTest::testConfigSync
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
'create' => []
'update' => Array (
- 0 => 'system.mail'
+ 0 => 'core.entity_view_mode.node.teaser'
+ 1 => 'core.entity_view_mode.node.se...result'
+ 2 => 'core.entity_view_mode.node.se..._index'
+ 3 => 'core.entity_view_mode.node.rss'
+ 4 => 'core.entity_view_mode.node.full'
+ 5 => 'system.mail'
+ 6 => 'core.entity_view_mode.user.full'
+ 7 => 'core.entity_view_mode.user.compact'
)
Is the right thing to do here update the tests so they expect all those view mode configuration changes? Testing is an area I'd like to be able to contribute to more so any information folks can provide is much appreciated.
carsoncho → made their first commit to this issue’s fork.
This all looks correct to me. Config inspector is reporting this at 100% now. Is the reason this is back to Needs work because of the pipelines failing?
[#3] The idea would be to extend Symfony's Constraint rather than copy and duplicate. Extending it would then allow for us to have the generic functionality and would be BC.
Just got to testing and it all looks great to me! I'm no longer getting the duplicate markup that I noted above. Apologies for the delay on that. Thank you for your prompt response to fixing the issue!
RTBC!
carsoncho → created an issue.
I certainly can! Thanks for getting on this so quickly! I'll report back later today with my findings.
carsoncho → created an issue.
carsoncho → changed the visibility of the branch 3392621_3168966_combined_10.1.x to hidden.
carsoncho → changed the visibility of the branch 3392621_3168966_combined_10.1.x to active.
I've started a issue fork against 11.x and have re-rolled #6 against it. I haven't added any test coverage for this yet. That's a little out of my wheelhouse, but I would love to learn!
Additionally here a patch for 10.2.x
carsoncho → made their first commit to this issue’s fork.
Add Schema:Article field for Thing->url
carsoncho → created an issue.
carsoncho → created an issue.
Adding some clarification to the summary.
carsoncho → created an issue.
carsoncho → made their first commit to this issue’s fork.
Is it possible to support both CKEditor 4 and 5 within the same module version? I see now there's a 3.x and 4.x version that both support Drupal 10, but support ckeditor versions separately. Is there any reason we couldn't have both ckeditor versions working in the same version?
carsoncho → created an issue.
Reroll of #58 against the latest 1.x version
carsoncho → made their first commit to this issue’s fork.
@heddn now that Groups has a proper Drupal 10 release → would you be able to review the MR?
Uploading patch that resolves this for the 3.x branch.
carsoncho → created an issue.
I believe this issue is related to 🐛 TCA is causing entities to be save twice Active .
We were running into this on a Drupal 10.1 site with version 3.0 of TCA and TCA node enabled along with core's workflows and content moderation modules. With TCA enabled I was running into issues where I was not able to edit the current revision. It kept loading the published revision although in the revisions tab it showed revisions being made. Secondly each revision that was saved after enabling TCA caused the revision ID to increment by 2 which I found odd. I believe this is caused by the node being saved twice which is noted in 🐛 TCA is causing entities to be save twice Active . Once the patch was applied from 3375544 these issues were resolved.
This patch does not appear to work with. I'm attempting to get a multivalue term reference field to output the term names in a list with this [webform_submission:values:multivalue_term_reference:array:entity:name] and it's being output as "Term 1 (1)entityTerm 2 (2)".
I am doing this via custom code with a custom WebformHandler that's calling on the webform submission handler's token service.
Any thoughts?
Is it also expected behavior that a content author can create an invisible anchor like what appears in #71? It appears that the invisible anchor can only be deleted via editing the source.
Closing. This appears to be fixed in latest dev.
carsoncho → created an issue.
carsoncho → created an issue.
Adding patch which is based on the open MR. Further work still needs to be made, but much closer to supporting CK5 now.
What still needs to be resolved:
1. Creating our own `drupalInlineMedia.toolbar` plugin rather than extending it. Current implementation clobbers selected view modes together
2. After changing the view mode the preview displays, but doesn't replace the old media inline item causing the same item to be displayed multiple times.
carsoncho → created an issue.
I'm running into the exact same issue using Drupal core 9.4.12 and svg_image 3.0.1. Here's a patch based off the MR.
Hi @jurgenhaas, I was curious about the status of this. Is there any help that can be provided to push this forward? I was about to create a separate issue to ask how one might go about achieving a view showing notifications for the currently logged in user.
In my case I would like to utilize the danse_content_moderation module to create Events for users when nodes transition through their various workflow states. To that end, I would like to create a view that shows the user their recent notifications and provide a link to the node revision. I'm not sure how to go about that currently.
It's my understanding that the Event stores a reference to the entity that triggered the creation of the Event as well as including the relevant info as part of the Payload. However, there's no way to utilize the Reference or Payload as a relationship so I don't have a way to create a link to the node's revisions.
In my head I see this as a view of Notifications with a relationship to the Event. The event relationship could then open up a relationship to the Payload's reference (in my case a content moderation state) which in turn can be used for a relationship to get the node's revision. Is there a better way to implement this or is my thinking here correct in your mind.