Problem/Motivation
Node module ships with several views in config/optional. These are to some extent 'demonstration' views that show what you can do with views, but they're not used by anything in core. Also the three covered in this issue assume a blog site is being built that needs a post archive and a glossary. While they are not used, they show up in the views UI, get discovered and parsed every time etc. Pretty sure they date back to views from Drupal 6 or possibly even earlier. Sites that are not blogs need to explicitly remove these. While we can keep the views for testing purposes, we should not make the UI more complex by including these use case specific views.
We have a lot of views in core that are actually used - admin listings etc. There's also Drupal CMS which has a whole set of different views. Something like glossary or archive which are very complex but not necessarily what someone would use on a site could potentially move to examples module.
Steps to reproduce
Proposed resolution
Remove the views from the default shipped views list. Adapt tests to use the specific views when needed (eg. node block testing and dedicated testing for glossary features or archive view features).
Remaining tasks
Review.
User interface changes
Some default (disabled by default) shipped views will be removed.
Introduced terminology
None.
API changes
None. Only concerns default shipped views and tests around them.
Data model changes
None. Only concerns default shipped views and tests around them.
Release notes snippet
The default Glossary, Archive and Recent content views that assume a blog-like site but were not enabled by default are not included anymore on new installs.
LLM disclosure
LLM was used to accelerate the development of this MR, everything was deeply reviewed though.
Issue fork drupal-3589894
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:
- 3589894-remove-the-archive
changes, plain diff MR !15752
Comments
Comment #2
catchThis came out of a slack discussion with gábor hojtsy so adding credit.
Also discussed product manager approval in slack so that's pre-granted in this case.
Comment #4
gábor hojtsyAlso add the blog feature aspect to the issue summary to underline why these need to go.
Comment #5
catchOK a few tests depend on at least one of these. Haven't looked in detail yet but probably easiest to move them to test fixtures if tests are referencing the specific views, if it's only tests validating default views in core and similar we can drop them from those of course.
Comment #6
catchComment #7
catchComment #8
gábor hojtsyComment #9
catchFound some more views to remove, as with this issues some tests use them, so separate issue for now #3592672: Remove the who's new and who's online views.
Comment #10
gábor hojtsyI took a stab at resolving the tests. Based on my assessment the glossary and archive views had tests for how they function, so I made sure to have both as test views for that reason. Also the glossary view had too much mention in the views UI test, but I needed to make a little adjustment to how it was ordered there. The recent content block also had one test, so I restored that as a test view too.
Comment #11
gábor hojtsyComment #12
gábor hojtsyDone with adapting all the tests. The views UI default test was the trickiest as it assumed the glossary view and also had some weird outdated stuff. I needed to reorder some of the enable/disable testing due to how the new picked frontpage view is currently enabled by default which necessitated IMHO cleaning up the remaining uncommented parts of the test which are wishful thinking I think in the test either way.
Comment #13
gábor hojtsyComment #14
smustgrave commentedDid a search for views.view.archive
Appears to have a test in RecipeRunnerTest and InstallerExistingConfigSyncDirectoryMultilingualTest that still reference it.
It's just a comment but ConfigEntityStorageInterface uses this view for an example.
Comment #16
acbramley commentedRebased and fixed a bunch of tests again that were updated to reference the frontpage view which has since been removed as well.
core/modules/views_ui/tests/src/Functional/DefaultViewsTest.php was again a massive PITA, I reset it from main and instead of updating everything just changed references to the test_archive and test_glossary views, however the very last assertion is failing due to a 500. I've run out of time to figure out why today.
Error was
Comment #17
acbramley commentedLooks like the error in #16 was local only.
Comment #18
smustgrave commentedOther instances I saw in #14 appear to be addressed. Believe this one is good to go
Comment #20
catchCommitted/pushed to main, thanks!
Was going to backport to 11.x but this has a lot of commit conflicts. We can probably leave it on main but re-open for backport if you think it should go there too.
Comment #22
gábor hojtsyAdded change record at https://www.drupal.org/node/3614831
Comment #23
gábor hojtsyRe the 11.5 backport, I think its fine to keep on main only. It may be that modules / distros rely on these views like they were on the content type recipes.