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

Command icon 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:

Comments

catch created an issue. See original summary.

catch’s picture

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

gábor hojtsy’s picture

Issue summary: View changes

Also add the blog feature aspect to the issue summary to underline why these need to go.

catch’s picture

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

catch’s picture

Status: Active » Needs review
catch’s picture

Status: Needs review » Needs work
gábor hojtsy’s picture

catch’s picture

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

gábor hojtsy’s picture

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

gábor hojtsy’s picture

Issue summary: View changes
gábor hojtsy’s picture

Status: Needs work » Needs review

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

gábor hojtsy’s picture

Issue summary: View changes
smustgrave’s picture

Status: Needs review » Needs work

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

acbramley made their first commit to this issue’s fork.

acbramley’s picture

Rebased 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

Drupal\views\Exception\ViewRenderElementException: Invalid View name (mih1o9vq) given. in Drupal\views\Element\View::preRenderViewElement() (line 46 of core/modules/views/src/Element/View.php). 
acbramley’s picture

Status: Needs work » Needs review

Looks like the error in #16 was local only.

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Other instances I saw in #14 appear to be addressed. Believe this one is good to go

  • catch committed b5c577dd on main
    task: #3589894 Remove the archive, glossary and recent content block...
catch’s picture

Status: Reviewed & tested by the community » Fixed

Committed/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.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

gábor hojtsy’s picture

gábor hojtsy’s picture

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