Problem/Motivation

The D8/9 Core RDF module already migrates data from the D7 Core RDF module.

The D7 contrib Schema.org (schemaorg) module and it's Schema.org UI (schemaorg_ui) submodule extend D7 Core's RDF module by:

  1. Declaring the schema RDF namespace (i.e.: in the <html> tag)
  2. Adding the schema.org url to the entity content as RDF metadata
  3. Providing a way for Features to export RDF mappings
  4. Providing a UI to map Schema.org types to Drupal node types and fields

There is only one major version of the schemaorg project (7.x-1.x). As of the latest release (7.x-1.0-rc1), neither schemaorg nor schemaorg_ui declare their own database tables nor store their own data (they both use D7 Core's RDF module to load and store any data they handle). However, they do write variables; which \Drupal\migrate_drupal\MigrationState's plugins discover; so when the Drupal migration wizard gets to the "What will be upgraded?" step, it incorrectly lists both schemaorg and schemaorg_ui as "Modules that will not be upgraded".

Steps to reproduce

  1. Download and Install Drupal 7.84 with the Standard install profile
  2. Download the Schema.org module version 7.x-1.0-rc1 and install both the Schema.org (schemaorg) and Schema.org UI (schemaorg_ui) modules.
  3. Go to /admin/structure/types/manage/page and in the Schema.org settings vertical tab, set Type = WebPage. Click Save content type
  4. On the database, run SELECT * FROM variable WHERE name LIKE '%schemaorg%';. Note you see results like...
    +---------------------------------+----------------------+
    | name                            | value                |
    +---------------------------------+----------------------+
    | schemaorg_ui_type_article       | s:0:"";              |
    | schemaorg_ui_type_page          | s:7:"WebPage";       |
    +---------------------------------+----------------------+
    
  5. Download and install drupal-9.4.x with the Minimal install profile. Enable the RDF (rdf) and the Migrate Drupal UI (migrate_drupal_ui) modules.
  6. Go to /upgrade. Follow the installation process. Note that in the "What will be upgraded?" step, both the D7 "Schema.org" (schemaorg) and "Schema.org UI" (schemaorg_ui) modules are listed as "Modules that will not be upgraded".
  7. Perform the upgrade.
  8. Export config. Note rdf.mapping.node.page.yml shows that the schema:WebPage type was successfully mapped here (note, however, this was achieved by D8 core's \Drupal\rdf\Plugin\migrate\source\d7\RdfMapping migrate plugin looking at D7's rdf_mapping table.

Proposed resolution

Update core/modules/rdf/migrations/state/rdf.migrate_drupal.yml to declare that Core's rdf module migration from the schemaorg and schemaorg_ui modules is finished.

Remaining tasks

  1. Write a patch
  2. Review and feedback
  3. RTBC and feedback
  4. Commit

User interface changes

None

API changes

None.

Data model changes

None.

Release notes snippet

Mark migration status from schemaorg and schemaorg_ui modules to rdf module as finished

Comments

mparker17 created an issue. See original summary.

mparker17’s picture

Issue summary: View changes
StatusFileSize
new686 bytes

Here's a patch. Reviews welcome.

mparker17’s picture

Status: Active » Needs review

I should mark this as "Needs review".

quietone’s picture

Category: Feature request » Bug report
Issue tags: +Bug Smash Initiative

This is a migration issue, so moving to the migration system component where the migrate maintainers work. Since the state file appears to be wrong, changing to a bug.

quietone’s picture

Component: rdf.module » migration system

Forgot to change component.

gauravvvv’s picture

StatusFileSize
new381 bytes
new424 bytes

Fixed linting error in patch #2, Attached interdiff for same.

mparker17’s picture

StatusFileSize
new718 bytes
new367 bytes
new453 bytes

On my machine, the patch in #6 regresses the behavior fixed in #2, because the machine name of the module is schemaorg, not schemaOrg (letter-case matters in this instance).

Here's a patch based on #2 that adds the word "schemaorg" to cspell's ignore list for that file instead.

quietone’s picture

This is interesting. I don't recall this particular case being discussed when the migration state was added. How many other modules are in the same situation?

Instead of patching core this can be handled by updating the Schema.org project page. Anyone doing due diligence on the results on the Review form can then discover that the result is OK.

mikelutz’s picture

Status: Needs review » Closed (works as designed)

Yeah, I think this is a semantics issue. "Modules that will not be upgraded" does include modules that have no data to migrate, as expected. I would consider a follow up to see if it's important to put a system in to separate modules that won't be migrated from modules that have nothing to migrate, but I don't think we need to add this to core. Feel free to comment if I'm missing something.