🇦🇺Australia @pameeela

I created an issue in Dashboard already, should have commented.

pameeela → created an issue.

I agree this needs to be fixed in Dashboard, it will be a problem on all sites, not just Drupal CMS.

Ohhh I didn't realise that #1 meant that Redirect is actually causing this behaviour. So the core bug is only an indirect cause.

Oops, didn't finish writing the title.

Created 🐛 Updating page.front Active

pameeela → created an issue.

Thanks @sandip poddar, I think we probably need a different solution as the id will vary, e.g. for my site it is #ui-id-3. I haven't looked but perhaps we can add a specific class to the modal or the div and use that to apply styles.

which is not what users expect from a stable product

Does this mean that the >381,000 sites that are using webform should consider D11 unstable, because they can only use an alpha version of webform with it? I'm genuinely asking because although I completely understand the concerns, this feels quite far from the reality for most people building sites. If you were starting a new project today that had to use webform, would you really use D10 so that you had security coverage?

But it's not showing the module status, it's showing the recipe status which is hard coded to say it's covered. It's certainly not checking the status of the modules required by the recipe. If that's what we all agree should happen that's fine, but it's pretty far from what's happening now.

This isn't much of an issue right now because the only recipes that are available are either from Drupal core or Drupal CMS, so they are vetted at least. And until we figure it out, I think it's better to remove the inaccurate info.

pameeela → created an issue. See original summary → .

This is being addressed in ✨ Make all enabled sources exposed as local tasks Active

I think if we can't get that merged by EOD on Friday, we'll revert the local task ECA implementation.

It's not this one, it's related to 📌 Update default content to add moderation state Active

Adding non-existent permissions to a role is not allowed. The incorrect per  
  missions are "use basic_editorial transition archive", "use basic_editorial  
   transition archived_published".

But those permissions were removed. Something's not quite right.

Annoyed enough to actually look into it. So it's not recipe specific, and it's not because the page didn't exist when the config was set. You can reproduce it by setting page.front to any alias using drush, and you'll get the same redirect behaviour.

The form validation swaps the alias with the path, so this isn't running if the config is changed outside of the form. Wondered why I never saw this before but I realised that we would always set page.front to a node path on a project, rather than an alias.

I'm not going to go any deeper into the specifics of the redirect logic, but safe to say this is a core thing. Not sure whether to move this into the core queue or create a new issue for that, because I'd like to resolve this for Drupal CMS with a workaround in the meantime. I strongly suspect that ECA can come to the rescue here as a last resort.

pameeela → created an issue.

Not surprised you haven't seen it, before recipes it'd be nearly impossible to create this scenario without a great deal of effort. But now that I'm aware of it, it's really annoying me.

Per 📌 Hide logos on recipe source Active we won't have logos for recipes for now. Ultimately we'd like to have nice graphics and imagery for recipes to showcase their feature set, but we're not ready for this. And we don't want a lot of effort to go into creating logos if we aren't sure when they would be used.

So I'm marking this closed for now... if anyone feels it would be better as postponed that's OK, but I'm not sure that it will ever be needed.

I think it might be better to just remove the security coverage status from recipes. As far as I know, there is no official policy around this yet anyway. A recipe might contain a bunch of contrib modules, some of which are covered and some not. There are a few other nuances that make it pretty unclear how security coverage would even work for recipes.

In keeping with my strategy of doing something wrong just to get it started.... as suggested by @tim.plunkett, we can achieve this visually by just setting the logo to empty. It still outputs the div and img tag as empty which I think we need to fix.

pameeela → created an issue.

Well that seems like a really sensible idea?

It would be cool if we could find a way to disable installing via the UI in the ddev setup; but I'm not sure how yet.

kristen pol → credited pameeela → .

Updated content type base to disable these views by default.

This is diabolical. The Scheduler module adds these views for each supported entity type even if it's not enabled for any bundles of that entity type. I think a good workaround is to disable these views by default. It's extremely unlikely to me that anyone ever schedules the publishing of taxonomy terms or media and if someone is doing that they can figure out how to enable the views!

But this is also an ongoing issue in Navigation 🐛 Second level menu items can't be reached if they have children Active that we can't fully solve here but we can eliminate this instance of it.

Discussion of this going on at ✨ Create a mirror for external library dependencies for composer support Active

There's potential for a long-term fix, but not one that will be ready for 1.0. So I think we need to decide whether to try to handle this separately, for the moment, or live with the CDN implementation.

Probably @phenaproxima's call really: #3472226-12: Handle webform external libraries →

At this point it's really not about what's ideal but what we can do for the release. I'll update that issue to highlight the conversation here so we can decide on an initial path.

Did as described in all but event, which is covered elsewhere in the styling issues.

If anyone from this SWAT team wants a new debugging challenge: 🐛 Drupal Cms Front Page Hero image not visible in the first load / visit (needs a reload) Active

I sincerely apologise for writing CSS -- desperate times, etc etc. There was some grid weirdness, the grid-column style was not applying for anonymous users, and I reduced the gap as well to match the designs.

There is still way too much space between the title and the view, but I think we can tackle that separately as it's a global issue.

Echoing @phenaproxima's awe at the collaboration to get this fixed! Thanks everyone :)

There was some further discussion of this in Slack when it was originally proposed, but the main concern was around how to convey visually to the editor that the content is unpublished, so they don't worry about why it's appearing.

I discussed this recently with @lauriii and we decided that this ability to display unpublished content is somewhat of a Drupalism and probably not the expected behaviour. Quickly checked WP and Squarespace and both don't show drafts in the listings.

Our new card style also overrides the pink shade for drafts, meaning there is no indication whatsoever to the user; so for this reason I think for now we will standardise on using the 'Published' filter. We can revisit this in the future but we won't have capacity to modify it for 1.0.

Not 100% sure how to handle this issue but marking it won't fix to avoid confusion for now.

Don't think there was any disagreement on this so marking it fixed, thanks @mandclu!

@tonypaulbarker FYI it will be a true hero once we style it, right now it's just in the body because the page styling isn't done yet and the featured image isn't configured to display.

Fixed this, and I think maybe files don't work if they have a space in the name? Anyway, it's working now.

pameeela → created an issue.

In 📌 Update styles for exposed filters for blog and news view Active the card was created as a generic view mode and applied to project and case study as well.

There are some minor tweaks that we could make to add client info but I think I'm happy with 'good enough' for now. Adding credit here since Rikki covered a lot of ground in two issues.

@atul_ghate are you planning to update the config for this today? If not, I will do it as it is somewhat of a blocker for theming of listing pages.

As a result of the work done in 📌 Style blog/news teaser as cards Active and 📌 Update styles for exposed filters for blog and news view Active we now have a very lovely listing page that I think we can run with for 1.0! Adding credit here since Rikki covered a lot of ground in two issues.

From what I can tell, this only occurs when applying a recipe from command line. I don't think I've seen it when using PB, and just now I tried both (once each, but still) and only had the issue with cli.

Adding it as a target because the bug is causing a fatal error with the Blog recipe because it includes an RSS feed link in the view. If you install without blog, and apply the recipe from cli, clicking the 'Blog' link in the menu results in:

The website encountered an unexpected error. Try again later.

Symfony\Component\Routing\Exception\RouteNotFoundException: Route "view.blog.rss" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 211 of core/lib/Drupal/Core/Routing/RouteProvider.php).

I don't think this is a blocker necessarily, if it's true that it only happens when using cli.

Forgot to mark this NR.

Did this only apply to the views pages? If so I think it can be closed, since all of the child issues are addressed elsewhere, but the title seems broader than that.

Fixed in ✨ Listing pages Active

Fixed in ✨ Listing pages Active

Fixed in ✨ Listing pages Active

Fixed in 📌 Add test coverage for listing pages Active

Covered in 📌 Create a basic page for the contact form Active

But then how was it passing before? All that happened was the ID of the form element changed?

Tried to edit the IS down to make it a bit easier to read.

@rkoller could you please create separate issues for the page title and language concerns? These don't really seem related. Also FWIW the title of the first installer page has changed to 'Get started' so I'm not sure if this addresses your concern at all.

Fun! It failed, but it's a totally different fail than I'm seeing locally :) I am assuming that there's someone else around who can more efficiently debug Cypress tests than me so I'm going to leave this here for now...

I've done this, and I think I updated the e2e tests appropriately, but it's failing locally. I'm extremely stumped because the screenshots of the fails show a page called 'Website feedback' rather than 'Contact', with different field labels, and I have no idea why this would be the case. I'm just hoping that there's something weird going on for me and it will work in CI :)

@thejimbirch I haven't looked at how the form works but is it an option for us to default items to 'on' if we've configured them by default? Not sure how the state for this stuff is stored, sorry if that's a stupid question.

pameeela → created an issue.

pameeela → created an issue.

pameeela → created an issue. See original summary → .

A quick search suggested this might be a memory limit issue, but it was already set to 1024MB. I tried increasing it to 2GB and it still happened so don't think that is the path to success.

Browser shows:
[Error] Failed to load resource: the server responded with a status of 503 () (drupal-cms-hero.png.webp, line 0)

But this is more helpful from dblog:
Symfony\Component\HttpKernel\Exception\ServiceUnavailableHttpException: Image generation in progress. Try again shortly. in Drupal\image\Controller\ImageStyleDownloadController->deliver() (line 218 of /var/www/html/web/core/modules/image/src/Controller/ImageStyleDownloadController.php).

Backtrace:

#0 [internal function]: Drupal\image\Controller\ImageStyleDownloadController->deliver()
#1 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array()
#2 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(593): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#3 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext()
#4 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
#5 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(183): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#6 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#7 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle()
#8 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#9 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#10 /var/www/html/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle()
#11 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(201): Drupal\big_pipe\StackMiddleware\ContentLength->handle()
#12 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(138): Drupal\page_cache\StackMiddleware\PageCache->fetch()
#13 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(87): Drupal\page_cache\StackMiddleware\PageCache->lookup()
#14 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle()
#15 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#16 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#17 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle()
#18 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(709): Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
#19 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle()
#20 {main}

Thanks for this! The select list is a great improvement :) Just made a small tweak to the message but otherwise I'm RTBC.

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

Definitely want @tonypaulbarker to review this one :)

We should remove AdvAgg for sure, there is no D11 release as catch pointed out. I also agree that Honeypot and Scheduler don't seem related to SEO.

And it looks like it already links to Simple XML sitemap, I don't necessarily think the label needs to specify the module name, but maybe it's fine to avoid confusion.

Would be great to get this into our initial release if possible.

OMFG it's green!!!

Note to self: Don't do ALL THE THINGS in one issue, even though it seems easier! It's better to split things for sanity's sake, too much YAML for one person to handle.

I'm happy for this to be merged once the tests are satisfactory, not sure if that is now or not but putting it here either way!

Haven't tested this but I don't think it will really fix it, because something other than shortcuts can be the first link (e.g. 'Go to' from Coffee module) and that gets the active state if Shortcuts isn't present. It's not an issue with the Shortcuts link specifically, the issue is that whatever the first link in the toolbar is gets set to active initially.

But separately, the core toolbar should set the first link as active, regardless of what it is. And we don't want to interfere with that. So not really sure where this sits, considering that core says that you shouldn't use Toolbar with Navigation, but Gin requires it for now.

The news test still isn't working as expected, it seems to be failing on the LB overrides only. If I update the basic page node default display to have the news view, the test passes. So it's as if the fix in ✨ The default content importer should handle Layout Builder section data Active is not working in the test instance?

pameeela → created an issue.

pameeela → created an issue.