Display category-related recipes when seeing a recipe full page

Nice feature!

I would suggest, on a design perspective, do either:

1. Leave more space above the block.
2. (I'd prefer this one) Create a new white (and separated) region that contains this block.

Yeah, sorry, I meant "visual region". If that's too complicated I'd be fine with option 1, which is adding more margin on top of the block so it's visually separated from the content and perceived as "extra info".

+++ b/core/profiles/demo_umami/config/install/views.view.related.yml
@@ -0,0 +1,301 @@
+        type: grid

Let's remove 'grid' here and set it to 'Unformatted list'. Then in the views CSS field, add grid--3 as a class (this is what we do for the layout of the articles and recipes pages).

Once that's done, and the extra spacing requested by @ckrina I think this will be ready for RTBC.

Patch attached to address items from #8

This looks perfect to me, and is working fine even with CSS aggregation turned on. Screenshot here for CSS aggregation:

Looks like we are missing a Spanish translation:

@lauriii Not everything in Umami is translated. That is by design to show what happens with fallbacks when items are not translated.

Although translation fallbacks can be useful in certain situations, I don't believe they're appropriate in this case as they can create confusion and give the impression that something is broken or not finished. Even if we have the capability to do something, it doesn't necessarily mean it's a good fit for the particular use case. Fallbacks could make sense as a backup solution or when handling dialect translations. However, in many scenarios, they tend to result in a subpar user experience.

@lauriii The screenshot you uploaded (Spanish) seems to have the very same recipes as the screenshot I uploaded (English). What translation is missing?

And should we create a follow up issue to have that translated, instead of allowing it to hold up this issue. Also, remember, this is a demo site, not a real live site so maybe it's okay if there's a translation missing.

"Related recipes" title, "Difficulty" label and value of that field, and the "View recipe" link are missing a translation. I think we should be able to get that resolved with @penyaskito without the hassle of a follow-up 😇.

It's certainly not a live site but it's something people use to give demos about Drupal. I agree that there's a balance between good and perfect but something like missing translations may appear unfinished, and I don't think that's a the impression we want to give. I think an alternative solution which balances both needs could be hiding the block on the Spanish translation, in the case that we can't get the strings translated.

Committed 1c7e6e6 and pushed to 11.x. Thanks! Also cherry-picked to 10.1.x since Umami is forever experimental.

Looks like this has broken HEAD of 10.1.x and 11.x but only for pgsql:

1) Drupal\Tests\demo_umami\Functional\DemoUmamiProfileTest::testDemonstrationWarningMessage
Behat\Mink\Exception\ExpectationException: Current response status code is 500, but 200 expected.

/var/www/html/vendor/behat/mink/src/WebAssert.php:794
/var/www/html/vendor/behat/mink/src/WebAssert.php:130
/var/www/html/core/profiles/demo_umami/tests/src/Functional/DemoUmamiProfileTest.php:74
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728

If we look at the HTML-artifacts (https://dispatcher.drupalci.org/job/drupal_patches/194048/artifact/jenki...) we see a:

Drupal\Core\Database\DatabaseExceptionWrapper: Exception in Related recipes[related_recipes]: SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input syntax for type bigint: "31,22,13" LINE 5: ...recipe_category.field_recipe_category_target_id = '31,22,13'... ^: SELECT "node_field_data"."created" AS "node_field_data_created", "node_field_data"."nid" AS "nid", "node_field_data"."langcode" AS "node_field_data_langcode" FROM "test58917544node_field_data" "node_field_data" LEFT JOIN "test58917544node__field_recipe_category" "node__field_recipe_category" ON node_field_data.nid = node__field_recipe_category.entity_id AND node__field_recipe_category.deleted = :views_join_condition_0 WHERE (((node_field_data.nid != :node_field_data_nid OR node_field_data.nid IS NULL)) AND ((node__field_recipe_category.field_recipe_category_target_id = :node__field_recipe_category_field_recipe_category_target_id))) AND (("node_field_data"."status" = :db_condition_placeholder_1) AND ("node_field_data"."type" IN (:db_condition_placeholder_2)) AND ("node_field_data"."langcode" IN (:db_condition_placeholder_3))) ORDER BY "node_field_data_created" DESC NULLS LAST LIMIT 4 OFFSET 0; Array ( [:node_field_data_nid] => 1 [:node__field_recipe_category_field_recipe_category_target_id] => 31,22,13 [:db_condition_placeholder_1] => 1 [:db_condition_placeholder_2] => recipe [:db_condition_placeholder_3] => en [:views_join_condition_0] => 0 ) in main() (line 19 of index.php). 

EDIT: Looking at the code (or rather lack of any) in the commit, it's more probable this has "just" uncovered an already present bug.

Thanks @Spokje, reverted to sort out PostgreSQL.

This happens because the generated query seems to be:
(node__field_recipe_category.field_recipe_category_target_id = :node__field_recipe_category_field_recipe_category_target_id))) and the replacement pattern is [:node__field_recipe_category_field_recipe_category_target_id] => 31,22,13

As @penyaskito said, we are not separating that, so $this->value = [$this->argument]; which will have actually just one value, so will make the query use "=" instead of "IN".

Maybe all we need is "break_phrase: true" added to the new view.

Just created an MR with the changes that were initially committed (and then reverted) plus the suggestion of changing "break_phrase" to "true".
https://git.drupalcode.org/project/drupal/-/merge_requests/4708/diffs#3f...

Will trigger tests for MySQL and PosgreSQL.

All tests are green now for the three DB types.

Please review and also test manually.

Tested with a fresh install of Umami with MR 4708 applied
Going into a recipe I see the related ones

See

LGTM!

Committed dbb54ac and pushed to 11.x. Also cherry-picked to 10.1.x since Umami is experimental. Thanks!