Display category-related recipes when seeing a recipe full page

I got a nice PM today on Slack:

Hi Christian, I just want to let you know my appreciation about the Related Content block you reported (https://www.drupal.org/project/drupal/issues/3312072).

Aside of the kind words which I appreciate, this validates that providing this as an example in umami is needed. I'll prioritize getting this in.

+++ 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

Love it!

Attached screenshot and updated it in issue summary. CSPell is complaining about the css rule, but don't know how we could change that taking into account that the css rule comes from the layout builder block class.

Not sure how that is related to this issue, but the style isn't applied when using core css aggregation.

Minor adjustments to the view (changed id, add human readable label, added description). Renamed css class per the view changes. Added css generated name to dictionary.

The previous problem with css agreggation enabled still applies.

The last submitted patch, 12: 3312072-umami-related-recipes-block-12.patch, failed testing. View results →

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

That MR was an accident :_)

penyaskito → closed merge request !3864

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.

New install of umami with the patch applied.

(ddev drush si demo_umami --yes)

The only missing translation is the title of the block.

@lauriii I don't think we are using anything for interface/config translation in umami aside of localize.drupal.org. In that case we can't translate that string until this is released with at least an alpha.

The last submitted patch, 12: 3312072-umami-related-recipes-block-12.patch, failed testing. View results →

Test failure seems unrelated, back to RTBC

The last submitted patch, 12: 3312072-umami-related-recipes-block-12.patch, failed testing. View results →

Test failure seems unrelated, back to RTBC

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). 

Thanks @Spokje, reverted to sort out PostgreSQL.

Requeued the patch with pgsql too.

We will need a new issue for that. Haven't created that yet, but I'm looking at this. Sounds similar to 🐛 Drupal\Tests\file\Kernel\Views\RelationshipNodeFileDataTest fails on HEAD with PostgreSQL Fixed , just that this would be when the Tid argument/default_argument is used in views.

Still don't have a proper patch, but the problem is here:

diff --git a/core/modules/views/src/Plugin/views/argument/NumericArgument.php b/core/modules/views/src/Plugin/views/argument/NumericArgument.php
index b40817b1a2..2a8af51b1b 100644
--- a/core/modules/views/src/Plugin/views/argument/NumericArgument.php
+++ b/core/modules/views/src/Plugin/views/argument/NumericArgument.php
@@ -90,7 +90,7 @@ public function titleQuery() {
   public function query($group_by = FALSE) {
     $this->ensureMyTable();

-    if (!empty($this->options['break_phrase'])) {
+    if (!empty($this->options['break_phrase']) || TRUE) {
       $break = static::breakString($this->argument, FALSE);
       $this->value = $break->value;
       $this->operator = $break->operator;

The value is "123,12,3" but we are not separating that, and considering a single value instead.

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!

lauriii → closed merge request !4708

Automatically closed - issue fixed for 2 weeks with no activity.