🇦🇺Australia @pameeela

Last child meta is closed, I hereby declare Drupal CMS 1.0 complete :)

Going to close this because there is some work being done on the larger AI strategy that will define what happens post v1. No need to update this issue I think.

OK cool, agree with removing it and the test for caching also sounds like a great idea :)

So I think this depends on 📌 Add documentation section for automatic updates Active and we can update the link (in AU) once we have something to link to.

Or should this be closed as a duplicate of 📌 Improve messaging to users to backup database Needs review ?

smustgrave → credited pameeela → .

We don't currently have any releases planned for 1.x, as we are now focusing on 2.x. So I think the main thing we should look at is testing existing functionality with 11.2 alpha/beta?

Wow what a pain. Agree on not hard coding it.

Do we really need a copyright meta tag? I have never once done this in 14 years of building websites.

@yautja_cetanu I'm triaging all of the existing meta issues as they were all pretty much delivered for 1.0 and I'm keen to close them out so we can start documenting what's happening for 2.0. Would you be able to update this issue to summarise the state of things in 1.0? And if needed, create a new meta for the ongoing work?

We got what we needed for 1.0 and Navigation is very close to stable now, so closing this one off.

This was successfully delivered for 1.0 so I'll close it off for now. We should separately scope out any future work needed for this track for 2.0.

Crediting @tonypaulbarker but feel free to credit anyone else who should be!

This was successfully delivered for 1.0 so I'll close it off for now. We should separately scope out any future work needed for this track for 2.0.

This was successfully delivered for 1.0 so I'll close it off for now. We should separately scope out any future work needed for this track for 2.0.

This was successfully delivered for 1.0 so I'll close it off for now. We should separately scope out any future work needed for this track for 2.0.

Closing this off since the planned 1.0 scope was delivered and we have a plan for the rest! But we should create new issues as needed.

Closing this off as the 1.0 scope was delivered.

Closing this off as the 1.0 scope was delivered.

Closing this off as the 1.0 scope was delivered.

Closing this off as the 1.0 scope was delivered.

Thanks @baddysonja!

Thanks everyone for your input! After reading all the comments, I think it probably doesn't make sense to introduce this to Drupal CMS at this point. For sure, SPP is great for existing sites and will be for those using the legacy node form for a long time to come. But since Drupal CMS is a starting point for new sites, and we are now working on 2.0 as the XB-ready version, I don't think it is the right fit.

We do have Views UI enabled by default for now.

Gin got a stable release for 1.0, I'd consider that a huge success :)

This didn't go ahead and will be pretty much entirely in the XB remit, so I'm going to close this off.

This didn't go ahead as described for 1.0, and the current work being done in this area doesn't really align with the original vision of just having a recipe. So I'm going to mark this closed, and will create new issues to capture the new work as it develops.

This was successfully delivered for 1.0 so I'll close it off for now. We should separately scope out any future work needed for this track for 2.0.

Don't want to mix this up with the 1.0 tracks, we'll have to figure out how to group these in the context of the new and ongoing work. Not sure what that is yet!

This was successfully delivered for 1.0! Plenty more to do but I think we should scope that out when we get to it.

This is completed as far as we planned for v1, with the Acquia trial live. Future work should be done in new issues.

I think we should close this off, since all of the existing tracks were aimed at 1.0. There is obviously work still ongoing but I think we should start fresh.

I'll work on that, but in the meantime I would not worry about updating this.

Closing this one since 1.0 is complete. Ongoing product marketing will be owned by Nick and Ryan from the DA.

Agreed, no objections raised on Slack either.

@drumm great question re: category, I was not even thinking, but of course the field is not on general projects.

I'll try to get consensus on this. I do think the module categories will be applicable, as in many cases recipes are providing an optimised setup for a single module or a few modules.

The separately, we can try to resolve the classification. I wouldn't block this on those tasks, but I think we should be able to decide at least on reusing the categories pretty quickly.

I agree with @quietone that this isn't actionable as a Drupal core issue, perhaps it would be most suited for https://www.drupal.org/project/promote_drupal → where the marketing is discussed?

smustgrave → credited pameeela → .

Considering that the Ludwig project page recommends using Automatic Updates instead, I'm marking this won't fix.

Please, consider the use of the Automatic Updates contrib module instead of Ludwig!

The Automatic Updates contrib module has a stabile release now. It is a long-term Drupal UI solution for package management. So, try it and find out if it works for you. If not... you can come back to Ludwig always. :)

I think that between Project Browser and Automatic Updates, this is largely solved?

Nice! Thanks for linking back to it.

Thanks @drumm, FWIW I definitely think there is value in having the listing page before that lands, as most recipes will be brand new for now. But I will try to move that forward as well.

pameeela → created an issue.

Ah, thanks for the heads up! I'll create an issue for adding the logo.

pameeela → created an issue.

Thanks!

pameeela → created an issue.

Thought about this some more and I think it might be better done as a warning in the status report? The dashboard feels quite prominent considering it really only affects sites with events. @penyaskito reminded me we can do this with ECA too, I forgot.

if after install the timezone is set to UTC, we add dashboard notice to verify that the timezone is set properly.

Not really sure how we would go about doing this in Drupal CMS? Definitely seems worth tracking the issue of timezone handling, but I think anything like this would need to be done in a contrib module (or core I guess but unlikely). Is there an existing contrib module that would make sense?

Separately is there a feature planned for notices/warnings on the dashboard? Right now it only supports blocks, right? I think this may come up as part of the onboarding research and user testing that the UX folks are currently doing.

@d34dman this is a cool feature but it's super technical, and not really suitable for our target audience. We are aiming for default features to be things that ~80% of sites would use. This module currently reports 8 sites using it, so I think we can gather from that statistic that it is not an 80% feature.

I can't seem to reproduce this -- can you attach a screenshot? This is what I get:

Thanks, I had no idea it used a separate logo.

Or change the easy email theme to use the front end logo by default and only use a custom logo if it is overridden.

This makes a lot of sense to me, it seems like setting a custom logo is an edge case. Moving over to the module queue though since it'll have to happen there.

Update Project Browser to beta

The only hesitation I have with this is the workspaces stuff which will replace content moderation. I'm not 100% sure how Diff fits in with that? I'll see if I can find that out at DrupalCon.

And if we do add it we'll need to add Diff Plus → as well :)

kristen pol → credited pameeela → .

kristen pol → credited pameeela → .

kristen pol → credited pameeela → .

@garphy a decouple recipe would be awesome! But not something we will ship with Drupal CMS anytime soon. We don't want to be seen as gatekeepers of recipes, which can be contributed just like modules. We don't want to try to make Drupal CMS everything for everyone because it's not scalable, so we want to encourage the community to build the recipes that make sense for them.

Filled in CR.

Didn't read the comments properly, I've updated the CR with info.

I was blown away to see this already working in 1.x! So cool to get these minor but so important improvements happening :)

Do we definitely need a CR for this? Tagify is added in the same release as this change.

Filled out CR

Done.

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

I don't remember, might have used the lenient endpoint or might have just used the branch with the automated fixes.

Should I add this fix to 📌 Automated Drupal 11 compatibility fixes for hubspot Needs review instead?

CR published.

Looks good to me! Never occurred to me to ship as webp since they get converted in image styles but no harm in doing so.

@geek-merlin thanks for this suggestion! It's unlikely we would ever ship with something like this, as (to me) it seems well outside of the 80% use case for sites.

We won't ship with features like this already included but expect users to be able to easily add them via Project Browser. So definitely agree that Drupal integration is a great idea, but unsure of the role of Drupal CMS specifically in this.

Thanks for picking this up. I think the gist is that we ship with a working setup using PHP but we recommend that users set up SMTP. I should have documented it for myself when I made this issue....

FYI as I can't fix it myself, the username 'pameela' (with two e's) often gets mistaken for mine (three e's) and gets free credit! (Just noticed this one when fixing up another one!)

kristen pol → credited pameeela → .

But the AI module has a stable release, so it's covered like any other module. So do you just mean the special treatment to highlight that it's included in Drupal CMS?

Thanks

Opting for Tagify in ✨ Enable Tagify in Admin UI recipe Active

I think this has been addressed for now across other issues referenced as related.

I think this was worked out between this and other discussions. I'll close so any new conversation is based on updated info.

We decided to go with CRs instead of release notes, is that documented anywhere?

Any reason not to commit this?

No one else has reported this, and I've never seen it either. @darren oh is this an ongoing issue?

Wow, amazing progress on this in one day :)

I agree that a simpler approach would be ideal, at least initially, and that base fields are less of a concern. FWIW my intention was pretty much what @phenaproxima described in #13: just that this widget is the default when a new field is added, but not 'enforced' or imposed beyond that. It should definitely be configurable per instance still as needed.

So anyway, yes let's use this issue to update the existing config to use the widget, and worry about the default stuff separately in the module itself.

And thank you @kristiaanvandeneynde @gxleano and @rajab natshah for your rapid collaboration on this!

I have no objection to optimising the actual files. @greg boggs would you be able to provide them? I don't have Photoshop :)

Thanks, I agree that setting it to be the default should be handled separately. Also agree with @phenaproxima that this should be done by Tagify and not ECA. That approach makes sense for reapplying recipes but it seems a bit overcomplicated for this instance.

Agree this sounds good, it was always on the list but just slipped! In addition to adding it to the admin_ui recipe, we also need to update any relevant field config to use the widget I think?

It would be great if, once installed, entity reference fields used the Tagify widget by default instead of the standard autocomplete. I've never looked into this but I assume it's possible? Similar to how the media library widget takes over the default for media if it is installed?

This is one thing I am always slightly concerned about when it comes to opting in to improvements, because any new fields created by the user will default to autocomplete, which is probably pretty confusing!

Ah OK thanks for confirming.

@kristen pol where are you seeing those instructions? Starting from a git clone of cms is not supported. If you want to use git you have to use the drupal_cms project.

I meant to update this on Friday to say, this can actually go in as-is because we are going to use the demo design system for the Atlanta XB demo. So if needed, we can refine this component for XB specifically at a later date.

Not totally sure about this. The new multilingual work is quite different from the original multilingual recipe track, so I think it's worth considering how we frame it. I'll chat with those involved and come back to you!

With this patch, I'm able to open the media library in the Drupal CMS XB demo! But now I'm hitting the original issue in 🐛 Cannot upload new image in media library Active where nothing happens when I upload. Is this unexpected?

Oh, thanks -- good idea since I keep referencing the wrong one!

Did a quick review of the actual components and left comments. Note though the CSS also needs a review.

Combine core-dev and drush into one composer command

Remove reference to Starshot using Drupal 10.3