Remove RDF module from the Standard profile

Stab at making TestBot go green.

I think it needs release snippet and change record, otherwise RTBC

Ah, thanks for making this issue. I've have updated Module or theme removal process to add a step for removing the module from profiles.

I am pretty sure the 'Needs product manager review' tag can be removed. All the sign offs happened in the policy issue. Specifically the product manager approval was given in #2152459-79: [Policy] Deprecate RDF module and move it to contrib and the tag removed in the following comment. Removing RDF from the standard profile is a natural consequence of that decision. Therefor, removing the tag.

Rerolled patch against 9.4.x branch & reroll diff added.

Greenifying TestBot.

Added draft CR and Release note snippet.

Changes looking good, CR filed, release note is valid

Updated patch with reroll diff attached.

6 of the 7 fails at #24 were unrelated to the patch, although the reroll missed one line of change (which triggered the 7th error).

I'll wait for the HEAD to pass the tests first to then queue tests on this patch.

Updated patch with reroll diff attached.

I have applied patch#7 for drupal 9.4.x dev.
Before applying the patch, the RDF module is a part of the installed module. after the patch, the module is part of the disabled(uninstalled) module.
I think as per the requirement of this issue, the RDF module need not be shown in extend list. But After applying the patch also, the RDF module is part of the list of extend. Can anyone suggest to me if it is wrong or not?

@Rinku Jacob 13 the module will still show in the extend list, it just won't be enabled when you install Drupal with the standard profile.

Patch looks great to me, just tidying up various tests that depend on RDF being in the standard profile.

+++ /dev/null
@@ -1,520 +0,0 @@
-class StandardProfileTest extends BrowserTestBase {

I think we might be losing some test coverage if we just remove this test. I'm wondering if we should just modify this test to install Standard and then install RDF on top of that, and run the same assertions?

I'm wondering if we should just modify this test to install Standard and then install RDF on top of that, and run the same assertions?

I can see your point about maybe loosing test coverage, but we can't change the test to install standard and whack RDF on top until RDF is removed from it first I think.

So maybe this is something for a follow-up issue?

Did not land in 9.4, so untagging.

Addressed #31

Needs a re-roll.

Rerolled the patch

Since 10.0.x-dev doesn't have the Aggregator module any more, we need a separate D10 patch.

#42 looks great - back to RTBC but since it's a straight re-roll I'll pretend it was already RTBC and commit it a bit later unless someone beats me to it.

+++ b/core/modules/migrate_drupal_ui/tests/src/Functional/d7/Upgrade7Test.php
@@ -28,6 +28,7 @@ class Upgrade7Test extends MigrateUpgradeExecuteTestBase {
diff --git a/core/profiles/standard/config/install/rdf.mapping.comment.comment.yml b/core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.comment.comment.yml

diff --git a/core/profiles/standard/config/install/rdf.mapping.comment.comment.yml b/core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.comment.comment.yml
similarity index 100%

similarity index 100%
rename from core/profiles/standard/config/install/rdf.mapping.comment.comment.yml

rename from core/profiles/standard/config/install/rdf.mapping.comment.comment.yml
rename to core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.comment.comment.yml

rename to core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.comment.comment.yml
diff --git a/core/profiles/standard/config/install/rdf.mapping.node.article.yml b/core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.node.article.yml

diff --git a/core/profiles/standard/config/install/rdf.mapping.node.article.yml b/core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.node.article.yml
similarity index 100%

similarity index 100%
rename from core/profiles/standard/config/install/rdf.mapping.node.article.yml

rename from core/profiles/standard/config/install/rdf.mapping.node.article.yml
rename to core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.node.article.yml

rename to core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.node.article.yml
diff --git a/core/profiles/standard/config/install/rdf.mapping.node.page.yml b/core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.node.page.yml

diff --git a/core/profiles/standard/config/install/rdf.mapping.node.page.yml b/core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.node.page.yml
similarity index 100%

similarity index 100%
rename from core/profiles/standard/config/install/rdf.mapping.node.page.yml

rename from core/profiles/standard/config/install/rdf.mapping.node.page.yml
rename to core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.node.page.yml

rename to core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.node.page.yml
diff --git a/core/profiles/standard/config/install/rdf.mapping.taxonomy_term.tags.yml b/core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.taxonomy_term.tags.yml

diff --git a/core/profiles/standard/config/install/rdf.mapping.taxonomy_term.tags.yml b/core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.taxonomy_term.tags.yml
similarity index 100%

similarity index 100%
rename from core/profiles/standard/config/install/rdf.mapping.taxonomy_term.tags.yml

rename from core/profiles/standard/config/install/rdf.mapping.taxonomy_term.tags.yml
rename to core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.taxonomy_term.tags.yml

rename to core/modules/rdf/tests/rdf_standard_profile_test/config/install/rdf.mapping.taxonomy_term.tags.yml
diff --git a/core/modules/rdf/tests/rdf_standard_profile_test/rdf_standard_profile_test.info.yml b/core/modules/rdf/tests/rdf_standard_profile_test/rdf_standard_profile_test.info.yml

diff --git a/core/modules/rdf/tests/rdf_standard_profile_test/rdf_standard_profile_test.info.yml b/core/modules/rdf/tests/rdf_standard_profile_test/rdf_standard_profile_test.info.yml
new file mode 100644

new file mode 100644
index 0000000000..4769b58fba

index 0000000000..4769b58fba
--- /dev/null

--- /dev/null
+++ b/core/modules/rdf/tests/rdf_standard_profile_test/rdf_standard_profile_test.info.yml

+++ b/core/modules/rdf/tests/rdf_standard_profile_test/rdf_standard_profile_test.info.yml
+++ b/core/modules/rdf/tests/rdf_standard_profile_test/rdf_standard_profile_test.info.yml
@@ -0,0 +1,7 @@

@@ -0,0 +1,7 @@
+name: 'RDF standard profile test module'
+type: module
+description: 'Test functionality for the RDF module on top of the standard profile.'
+package: Testing
+version: VERSION
+dependencies:
+  - drupal:rdf

I think we should consider moving the RDF config from standard to the optional folder in the rdf module and adding an enforced dependency on the standard module (yes it is a profile but for config dependencies we'll treat it as a module).

This way if someone installs the rdf module on 9.5.x on top of standard it is the same as doing so on 9.4.x.

I guess there is a slight downside when the module moves to contrib because the maintainers will have to deal with changes to standard / decide whether to continue to support it. But the 10.x supporting version of RDF could always decide to drop the standard requiring config.

This would allow us to remove the rdf_standard_profile_test module and just install RDF on top of standard in core/modules/rdf/tests/src/Functional/StandardProfileTest.php

Here's #45 implemented.

FWIW the contrib module maintainers will have the problem with #42 anyways… because they’ll have to decide what to do with \Drupal\Tests\rdf\Functional\StandardProfileTest and the weird test module…

The benefit of this approach is that there is less change for 9.5.x and the dependency on standard of this config is explicit.

Doh of course... this configuration belongs in standard's optional configuration. Then when we remove RDF from core we remove it from the optional config in standard and we're good to go. Then the Rdf contrib module maintainers can decide what to do with Standard test move it has moved to contrib.

Also as #4 mentioned we need to remove from Umami as well. We should have a separate issue to discuss that.

Hmmm actually being able to move the config completely out of standard is nice and keeps all the rdf stuff together... let's fix the tests in #46.

I wasn't sure about moving the config to standard, but it means no change in the behaviour when you install standard + RDF (until RDF is actually removed from core in 10.x) and looks pretty clean to me.

Just got one question about whether we should loosen the dependency to make RDF do something for some fraction of sites if it gets installed after the initial profile install. And a comment about scope that I don't think should hold things up here, even though technically our scope rules say it should.

1. +++ b/core/modules/rdf/config/optional/rdf.mapping.node.page.yml
   @@ -5,6 +5,9 @@ dependencies:
   +  enforced:
   +    module:
   +      - standard
   
   +++ b/core/modules/rdf/config/optional/rdf.mapping.taxonomy_term.tags.yml
   @@ -5,6 +5,9 @@ dependencies:
   +  enforced:
   +    module:
   +      - standard
   

   But does this really rely on standard profile or does it actually just rely on the existing dependencies, e.g. the page node type.

   E.g. if you have a site not based off standard, and you have a page node-type and then you decide to install RDF, shouldn't this config be installed?

   Similarly for the vocabularies.

   Or are we taking too much liberty there and placing too much emphasis on the happy collision of a node-type machine-name?

   The issue is that without this config, installing RDF does nothing. You'd install it and go, what did that do. And then go looking in the UI and find nothing. And as there's no UI to add a config so you would have to know to go looking for RDF UI module - https://www.drupal.org/project/rdfui. I am happy if the answer is yep, nothing 🤷 but figured I should ask

   Side note, I think the number of sites reporting usage of that module is probably a more reasonable estimate of the number of sites using RDF, plus/minus a handful who hand edited the YML.

2. +++ b/core/modules/rdf/tests/src/Functional/StandardProfileTest.php
   @@ -36,80 +36,118 @@ class StandardProfileTest extends BrowserTestBase {
   +   * The URI of the image to test.
   +   *
   ...
   +   * The URI of the term to test.
   +   *
   

   Are all these comment changes in scope? Technically no, but is it worth holding this issue up for, I don't think so.

3. +++ b/core/modules/rdf/tests/src/Functional/StandardProfileTest.php
   @@ -161,7 +199,10 @@ protected function setUp(): void {
   -    $this->drupalCreateNode(['type' => 'article', 'promote' => NodeInterface::PROMOTED]);
   +    $this->drupalCreateNode([
   +      'type' => 'article',
   +      'promote' => NodeInterface::PROMOTED,
   +    ]);
   

   Same comment here re scope

Yeah I think #52 would have been a very good idea when we added RDF to core, but less so now when we're trying to remove it.

Side note, I think the number of sites reporting usage of that module is probably a more reasonable estimate of the number of sites using RDF, plus/minus a handful who hand edited the YML.

/me looks at the usage stats 0.o

This is no different from the existing behaviour though? If you set up a site on minimal and then install RDF module, you don't get any mappings. IMO this is a feature request for the RDF module in contrib, and in fact it probably makes sense for rdf and rdfui to be combined in contrib, if anyone cares to do so.

Makes sense, lets move this forward

Saving issue credits
Crediting catch for 4 or 5 reviews and comms in slack
Crediting quietone for meta-issue and related issue wrangling
Crediting andypost for reviews and review of the change-notice and release note
Crediting lauriii for a review

Committed to 10.1.x and backported to 10.0.x

Committed the 9.x patch to 9.5.x

Published the change record - great work here folks