🇦🇺Australia @pameeela

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

@mherchel it should be pretty easy if you use: https://github.com/phenaproxima/xb-demo

And I've just been copying the components over to test them.

Tried to test the fix but it no longer applies.

Also tested with this and it worked :)

Any chance of this getting another look before Atlanta?

Looks like legacy-project is slated for removal in Drupal 12. 📌 Remove drupal/legacy-project as a starting point for Drupal 10 Postponed

I can only imagine that they are using it because doing it "properly" can't be (easily/generically) automated on shared hosting? But I guess we could try to look into what that would require?

Although I understand the concerns, I would also say that the two use cases raised of moving hosting and finding documentation are certainly secondary to being able to use Drupal at all on shared hosting.

Found my way here through testing Drupal CMS on shared hosting. Many of the shared hosts provide an automated installer inside CPanel that does a one-click install of Drupal, and now Drupal CMS.

However the addition of Drupal CMS led us to figure out that the vanilla Drupal install is using legacy-project, which is almost certainly to avoid having the /web subdirectory. (Drupal CMS does install with /web, which has obvious and undesired knock on effects in the shared hosting context.)

Just noting this as something we should be aware of if we remove it.

Without designs for the relevant widths, which I don't think we're going to get, this could keep going. So in the interest of getting it done I'd suggest:

1. Setting an aspect ratio on the image so it's 2/1 on all screen sizes (this fixes the too tall issue)
2. Updating the existing logic for min-width: 700 to be 1000 instead, keeping the current full width styles as-is
3. Creating a new breakpoint for min-width: 695 (this is the editor size) that has a reduced hero__data container to prevent it from covering most of the image

Thanks @mherchel, this is way better generally. Unfortunately I don't think these updated styles work well within the XB context.

This is the editor view (the image is too tall I think):

This is the preview (the image is mostly covered by the content block, and this is currently the widest available display):

To be sure the previous styles did not match the designs, but the designs didn't consider the XB context which is quite specific and restrictive. And since this is specifically for the demo, I'd rather build for that for now?

This makes perfect sense to me!

Wrong file! Actually updated now :)

Added the design to the IS, note that I've removed the CTA link because this won't work well in XB currently, with the restricted width that we have. So for simplicity let's leave it out for now.

I made some minor tweaks to the spacing and image size that for me gets this to "good enough".

Agree it's awkward in the editor view, which is <700px; but let's see if we can figure that out as a separate matter by making the space larger. It looks decent in the preview.

Preview:

Editor:

pameeela → created an issue.

Working now after a rebuild, thanks @kristen pol!

Actually discussed with @lauriii and he recommended that we just remove the page title block from the page so I'll make an issue for that in the XB demo repo.

I've pushed a fix for the paragraph element but haven't touched the title yet, wondering what folks think about how we should handle it.

pameeela → created an issue. See original summary → .

Looks like this change was recent in 🐛 Adding the Image component results in a state considered invalid Active , I am guessing this will be obvious for someone who knows so I won't waste time trying to figure it out....

pameeela → created an issue.

Just did another rebuild and I'm not seeing the issue now, no idea what happened yesterday!

Sorry I see alpha9 is the latest release! Let me try again and see what happens.

Yeah OK, it's set to ^2-alpha9 -- so unless we pin it on the 1.0.x branch I think we need a fix?

Updated to remove the user menu issue as that is fixed.

pameeela → created an issue.

smustgrave → credited pameeela → .

Looks like this was introduced by 🐛 Fatal when entity type doesn't exist (anymore) Active but this should be handled since node is installed?

pameeela → created an issue.

I think I can RTBC this!

thejimbirch → credited pameeela → .

Oops

What's the difference between a project, module and extension in this context? All three terms are used within just the tab labels and page titles under the Extend menu? Will our marketeer persona understand the difference or just get confused?

I totally agree with this sentiment, however, we can't address these fundamental issues by renaming pages and tabs. To this end we are working on a full overhaul of this section and its IA. We are still in the early planning of this so I don't have any issues to point to yet.

Also, these pages come from three different places: core (Extend and Uninstall), Project Browser (Recommended and Browse modules) and Automatic updates (Update and Update extensions). AU already has an issue: 📌 Update tab and page title to be more clear Active and ✨ Consider displaying the core and extensions update forms on one page Active is also relevant. PB is moving super fast and frequently, so I think this is a moving target and not really worth addressing until it gets a bit closer to stable. If you want to propose a change to the core 'Extend' tab, I'd suggest you create a core issue with the specific change you are proposing.

I appreciate that marking this 'won't fix' may seem strange since the changes are totally sensible, but there's nothing that we can do about this in Drupal CMS itself.

This would have to be done in core's Navigation module. It's still under active development.

🐛 "Update" and "Update extensions" displayed under Appearance Active was created first.

Should we call this something generic like Accordion? FAQ seems like a use case rather than a name for the component. But I haven’t checked what is more common.