🇦🇺Australia @pameeela

pameeela → created an issue.

This is looking great based on the screenshots! Don't wait for my review, happy for a front end tick to get this merged.

I would be opposed to adding a third provider within the existing recipe, since we already have the problem that it currently installs two modules but only uses one. This would make it three modules, only using one. Obviously, this is not scalable as other providers become viable.

Seems like we will eventually want to swap it around so you choose the provider first, and that applies the appropriate recipe with only the one module needed. Unless we instead opt to promote a single provider?

thejimbirch → credited pameeela → .

Accidental title update!

For me this is not just about frequency but topics. For example, I don't think it makes that much sense to post updates about new Drupal CMS versions to *existing* Drupal users, since there is no upgrade path. However, if there are more frequent posts covering more diverse topics, it doesn't matter as much.

I don't really have the answer but I do think it's worth a discussion of who this feed is for and what its strategic aims are, alongside any attempt to post more frequently.

Making it work both with and without autocomplete could happen if/when autocomplete is added back and we could repurpose the other issue for that.

Agreed that's separate, for now we just need to make it work without autocomplete.

@greg.1.anderson thank you, that makes sense and is very cool! I don't see why this wouldn't work with PB, since it manages changes via composer, so other than that it would just be config changes which are also covered.

Just hit this issue too, same as @aaronbauman where the order was different for authenticated and anon users. Declaring the dependency per #14 resolved it.

pameeela → created an issue.

I wasn’t saying PB/PM itself isn’t deployable, it obviously is (and it does degrade gracefully). I’m asking about how modules added this way to a dev environment would be deployed to other environments. Generally I’d like to know more about the development workflow of the customers who want this.

@greg.1.anderson I am curious about the customers who want to use this in development environments, since it wouldn't be deployable to production environments. Do you know if they are planning it use it just for experimentation/testing? Or is there another use case?

Finally had a chance to look at this and I think the best course of action is to remove autocomplete from search for now. The calculation for me is that the autocomplete suggesting individual pages is not providing that much value, and it's causing a huge performance hit.

If we can make it work without changing the performance I think it's a nice addition. But making it a separate recipe does not really solve the problem in my opinion. I still don't think it would be worth the performance hit of adding it. So if we can fix the performance, we can include it by default again. (Although, as noted in 🐛 Search broken without search_api_autocomplete Active , there would be work to ensure that it still could be turned off if needed.)

I understand the issue with the XB preview area being smaller than the design, but I don't understand why the text is so narrow in the current state? Seems like it should work OK at 1024px, here's an updated mockup with that width:

Added the 'previous leads' section and moved Suzanne and Martin (who also stepped down). Not sure if this is the right format though.

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

Are you saying that you created a new custom content type 'News', rather than using the content type provided by the Drupal CMS recipe?

If so, you likely either need to do some theming to make the existing card template work, or modify the content type's teaser so that it matches what the template expects.

The theme that ships with Drupal CMS won't necessarily work perfectly with new content types. It is provided mostly for demo purposes, we expect most sites will develop a custom theme.

pameeela → created an issue.

Thank you @kristen pol! Matching the Figma exactly is definitely not needed, happy to treat it as a more of a guide. This certainly looks close enough to me, based on the screenshots.

Sounds sensible, thanks for working through this one :)

Thanks for catching and reporting this!

Sorry folks, I didn't see this one until now!

I proposed a modification to make it a bit more generic so we don't have to update it a lot, and also following the lead of the Drupal core description:

Drupal is an open source content management platform powering millions of websites and applications.

We're not quite at the no code (or even low code) point yet so might be premature to call this out. Considering this is just what's in Composer, I don't think we should overthink it :)

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

Haven't seen any confusion so I'll close this now. FWIW we tried to change the author but couldn't because it's showing the author of the initial revision rather than the node author.

This was all done as part of other changes.

Declaring mission accomplished here :)

As track lead I declare this issue fixed :) Still a lot of work to do, but I don't think this meta is needed any longer.

I think we can mark this fixed, there is still lots of work to do but it's not really falling under a separate track.

Moving to the d.o project since that's where this content is. FWIW I tend to agree that "composable" isn't that meaningful to average folks but this may be a standard part of Drupal's marketing?

I'm not really clear on the use case for this. How would you know when the content you were looking for was edited last? Is the idea that you are searching for your own changes on a specific date?

Oops I meant to link to https://www.drupal.org/about/features/accessibility →

Yep, we're aiming for AA. Thanks!

Nice, thanks everyone!

pameeela → created an issue. See original summary → .

nod_ → credited pameeela → .

We're planning to use telemetry to get usage stats. I think it should stay as-is since it is built on Drupal 11?

Specify alpha for composer command

I've got it enabled too in the screencast, set to the default of 15 minutes. (The proxy cache settings shouldn't have any effect on the caching of things in the admin UI.)

Hey @pdureau thanks for coming back to this!

For my part, I don't really understand what it would look like to adopt this for Drupal CMS. I do realise that the two are not completely incompatible, but there are large parts of UI Patterns that would be somewhat obsolete with XB (in terms of providing plugins for other display builders like LB that won't be needed).

So given that as you say, it's not a display builder, what would this look like?

Hmm, I can't seem to reproduce this in Drupal CMS or vanilla core?

Thanks, agree this is confusing! Moving over to core though because this doesn't have anything to do with Drupal CMS really.

The Recipes tab currently is recipes available in the local code base. I think it's completely fine to have this title be customised, in fact, it probably makes sense to make it configurable. In a vanilla Drupal install, this is the core recipes. I don't think that 'Recommended' makes as much sense, since that's basically just the pieces of the standard install.

The other tab was just renamed 'Contrib modules' (in alpha8) which we've changed to 'Browse modules'. I feel pretty strongly about not using the term contrib modules, since it's an abbreviation of a Drupalism.

I think we all agree this whole section needs a rethink (in progress by the UX folks) so this is far from perfect but just thinking about what would make the most sense in the current context for a new-ish Drupal user who arrives here.

hestenet → credited pameeela → .

Ohhhh +1, I have been wondering about this but never managed to document it!

I'm not as sure as with the other platforms (Acquia, Amazee, Platform.sh) but I think it's the same story here that the file system is not writeable, so Project Browser can't be used to add modules in the UI.

As with Acquia and Amazee, I don't think this is feasible, since the file system is not writeable on this hosting platform.

Thanks for this info @tobybellwood! This seems like it should be a won't fix. It is possible to use PB to find modules and copy the Composer commands but not viable to use it for adding modules from the UI, along with the other hosting providers that don't have writeable file systems.

I don't think this is possible since the file system is not writeable. You can use Project Browser for searching but only to provide the commands, there won't be a way to use it to add modules via the UI. Unless I am missing something?

I did search and found https://dev.acquia.com/tutorial/how-enable-project-browser-your-drupal-site which shows it only works with commands. This suggests it can be done in the UI with a link to https://dev.acquia.com/tutorial/how-enable-automatic-updates-your-drupal... but this article confirms this could only be done locally or in another environment because it's not possible on Acquia.

Update the node title

Add a space in the title

surabhi-gokte → credited pameeela → .

Created an MR for this, crediting Jurgen for providing the initial model config.

pameeela → created an issue.

Consolidate Composer step

I tried out A2Hosting, but my conclusion is that setting up manually is not really worth documenting, considering how complicated it is compared with the Softaculous installer for Drupal. We should try to get Drupal CMS added as an option to that instead.

FWIW I got Project Browser working using the default Drupal 11 install and documented this in the guide → .

If we are able to get Drupal CMS as an option, much of this setup would be automatic and if we could even get the Composer path set by the installer there would be no manual steps required to use it.

Tweaks to steps for clarity

Was testing A2 for Drupal CMS and managed to get this working, documented at https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

I think that would make more sense or be more intuitive if there were an example in use already, but since we don't have one, it's a little strange to have it there. Also, Experience Builder should replace block layout soon enough, so might be better to avoid introducing it to new users.

Created 📌 Add test for front page meta tags Active for adding tests.

pameeela → created an issue.

Hey @s.halawani thanks for the suggestion!

I am a little unsure about placing this on the main dashboard because it does not seem like something that would be checked very frequently. I can definitely see a benefit it having it somewhere, but the main dashboard seems quite prominent?

Looks like this is fixed now.

@dydave thanks for this suggestion!

It is intentional that we are not using tabs for the node edit forms. I know this is quite common but in my experience, editors can find this to be a burden. I’ve certainly had my frustrations with what I call “tab hunting” to find the field I’m looking for. This creates an extra cognitive task every time you edit a page — first you have to scan the tabs and decide which tab the field you are looking for sits in. And if you guess wrong, then you do it again.

I can see some use cases for them where the form is really long, but none of our current content the forms qualify. The one place we are using fieldgroup is for the SEO fields, which are not in a tab but collapsed by default. This is based on them being edited more rarely compared with the main fields.

This blog post has some more detail: https://www.freshconsulting.com/insights/blog/uiux-principle-21-when-and...

A litmus test for whether or not you want to use them is to ask yourself, “If I printed out this page, would I want users to see all the information grouped together? Or would I want them to access each section separately?” If you want users to access each section separately, then using tabs is a logical choice.

I think it’s fair to say the node edit forms that we currently have would fall into the single page bucket based on this test. Not that it is the final word on this issue but we do think it aligns with UX best practice at the moment.

The reasons for this are documented in the content strategy → . We will be conducting user testing on this shortly.

Thanks, if folks have further suggestions to improve the docs, please create a new issue.

It’s intentional that it’s not enabled, but only because it’s not used. Nothing wrong with sites deciding to use it, but we didn’t want to ship with it enabled without using it.

We’re looking to add this as part of a developer tools recipe: ✨ Create a developer tools recipe for some advanced UI functionality Active

I think we probably won’t add it by default at this point but agree it’s super useful!

+1000 from me!

Tweaked the wording to try to make it super clear that DDEV is just one option. It's not *recommended* per se, it is just the one we are supporting.

But otherwise looks good to me!

smustgrave → credited pameeela → .

Well, as I said, this is decidedly a sub-optimal state where things are not yet consistent. But for me, the ideal scenario would be that a user doesn't have to Google a term they see in the UI to figure out what it means.

"Add on" is a common term with a widely understood meaning, and it is our hypothesis that this will be more meaningful to new users than "recipe" based on this alone. And again as I said, we are not "renaming" recipes, we are trying to normalise the user-facing language in the UI.

We will be conducting user testing soon and absolutely plan to test this. For my part, I would be quite shocked if non-technical users were confused by the term add-on because they wanted to understand functionally what it was. And I would also be shocked if the prompt 'Choose recommended recipes' even registered as something they would want to do, having no clue what it meant in this context.

Having said all of this, there is of course a chance we are wrong. But we are making these calls to align with not only the Drupal CMS strategy to make Drupal more accessible to non-technical users but also the de-jargoning Drupal → work that is being done by folks on the UX side.

Postponing since this is probably moot if we kill the launcher script as discussed in #3500131-17: launcher script appends -1 to every project created →

I'm inclined to agree now that there is dedicated Drupal CMS documentation for DDEV. The existence of this launcher script is (I think) also causing some folks to think that DDEV is the only way to install from the zip.

So probably we need to create a new issue to remove the launcher script in the next release, and coordinate all necessary updates to documentation. As part of this, we should also make it clear that DDEV is a suggestion and not a requirement.

And then we can close this as won't fix.

Adding credit from the duplicate issue that was closed.

Realised this was fixed in 🐛 Hidden fields accessible by keyboard navigation Active

@dave_______1 I am curious what you think we can do to update the existing language to make this more clear.

On the download page, we have:

Drupal CMS puts the power of Drupal into the hands of marketers, designers and content creators. You'll need php and composer to use the command below, or you can install with DDEV.

Which documentation led you to believe that you had to use DDEV? You are not the first person to provide this feedback and I would love to address it.

Hmm, yeah, I agree. The reason it wasn't made optional is that we don't have a great way to provide the option to users within the one recipe, and I think having a separate recipe just for autocomplete would be somewhat odd.

First thing I guess it to determine whether it actually can be provided as an optional add-on, even if it's a separate recipe? In some cases, things can't be split because there is no way to manipulate the config as is necessary.

Ahh thank you!

I prefer to keep this in the theme over ECA or Block Class mainly because it is theme-specific, and it's a one-off. We want to avoid adding modules that will possibly conflict with XB. And although I love a good ECA fix, this feels pretty random. I don't think we want to add the class always, and if we end up just adding it for this theme then that seems like it should just be in the theme where it's easier to find.

Screencast of the scroll without the CSS fix.

@mherchel

had to add home-specific CSS for an extremely annoying bug. There was a horizontal scroll on smaller screens with this change because there's a width: 100% coming from another place that is overriding the width: 1px that is set in visually-hidden. So overrode that with a width: auto for this block only.

Do you have another suggestion for how to fix this? (Note that there's an issue with the MR, I'll fix the path -- I was testing it just in base.css and didn't properly update it).

Credited @heikkiy for catching the variable duplication and posting in Slack.

No reports of this since the launch of 1.0 so maybe obsolete?

Although this looks nice in the design, it didn't translate that well to the actual demo content. We ended up updating the content type display to use the name field in the card but the logo in the full page display, so they don't both appear together. They would generally be saying the same thing anyway I think.

Given that this theme is really for demo purposes only, I don't think we need to pursue this any further.

As noted in the IS, these changes would be made in Smart Date so moving it there.

Steps added

There's no change to the appearance, it just uses a smaller image for (oh-so-slightly) better performance.

LGTM