Problem/Motivation
Found working on #3352851: Allow assertions on the number of database queries run during tests.
MariaDB [db]> SELECT FROM_UNIXTIME(created) FROM node_field_data;
+------------------------+
| FROM_UNIXTIME(created) |
+------------------------+
| 2023-11-07 21:42:54 |
| 2023-11-07 21:42:54 |
| 2023-11-07 21:42:54 |
| 2023-11-07 21:42:54 |
| 2023-11-07 21:42:54 |
| 2023-11-07 21:42:54 |
| 2023-11-07 21:42:54 |
Views like related recipes are ordering by created timestamp, but because it's the same, this can mean random results.
Steps to reproduce
Proposed resolution
Add a second to each node as it's created, or give them specific, fake, backdated dates.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 3399970-nr-bot.txt | 1.26 KB | needs-review-queue-bot |
Issue fork drupal-3399970
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3399970-umami-content-is
changes, plain diff MR !8670
Comments
Comment #2
markconroy commentedI wonder could we do something like a post install update that will cycle through all the nodes on the site and set them as created a day between each.
So if we have 30 nodes, then
---
Thanks to Code Enigma for sponsoring my time to work on this.
Comment #4
markconroy commentedSetting to needs review.
Comment #5
catchI think this is a good idea. We should open a follow-up for the default content import that comes with recipes to add some kind of created date offset key so that this could be done on import.
Probably also need an issue to convert Umami's default content to the new system.
Comment #6
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #7
markconroy commentedThanks @needs-review-queue-bot
Fixed, and setting back to needs review.
Comment #8
smustgrave commentedI get confused sometimes and not sure the rule of thumb for tests on Umami, know before we have skipped them as it's main purpose is to be a demo.
Re-ran the failing test but seems to be valid
Comment #9
markconroy commentedThanks @smustgrave, this took me a little bit of time to track down.
I've added a new commit to change the string that we should search for. This is because since we set the nodes to have different dates on them in the new install hook, the string we were searching for belongs to a node that will not make it to the front page listing.
The ordering for that view on the homepage is
Sticky at top of lists => Date added => node id
With the date added now changed, and the node id for this content item being 1, it no longer makes the grade :)
All tests are passing now.
---
Thanks to Code Enigma for sponsoring my time to work on this.
Comment #10
markconroy commentedComment #11
catch#9 is exactly the reason I opened this issue in reverse, not on the front page but in some other circumstances, the nodes shown on pages (maybe recommended articles or something) were different each test run..
Comment #12
smustgrave commentedThanks seeing all green. And suppose since the test had to be updated that can count as test coverage :)
Comment #13
catchOpened #3462758: Add a creation timestamp offset for default content against recipes so that if we added that feature, and eventually use recipe default content for Umami, we should be able to remove the install hook again.
Committed/pushed to 11.x, thanks!
Comment #15
catch