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:
- Declaring the
schemaRDF namespace (i.e.: in the<html>tag) - Adding the schema.org url to the entity content as RDF metadata
- Providing a way for Features to export RDF mappings
- 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
- Download and Install Drupal 7.84 with the Standard install profile
- Download the Schema.org module version
7.x-1.0-rc1and install both the Schema.org (schemaorg) and Schema.org UI (schemaorg_ui) modules. - Go to
/admin/structure/types/manage/pageand in the Schema.org settings vertical tab, set Type =WebPage. ClickSave content type - 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"; | +---------------------------------+----------------------+ - Download and install
drupal-9.4.xwith the Minimal install profile. Enable the RDF (rdf) and the Migrate Drupal UI (migrate_drupal_ui) modules. - 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". - Perform the upgrade.
- Export config. Note
rdf.mapping.node.page.ymlshows that theschema:WebPagetype was successfully mapped here (note, however, this was achieved by D8 core's\Drupal\rdf\Plugin\migrate\source\d7\RdfMappingmigrate plugin looking at D7'srdf_mappingtable.
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
Write a patch- Review and feedback
- RTBC and feedback
- 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
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 3256621-7--mark-rdf-to-schemaorg-migration-complete.patch | 718 bytes | mparker17 |
Comments
Comment #2
mparker17Here's a patch. Reviews welcome.
Comment #3
mparker17I should mark this as "Needs review".
Comment #4
quietone commentedThis 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.
Comment #5
quietone commentedForgot to change component.
Comment #6
gauravvvv commentedFixed linting error in patch #2, Attached interdiff for same.
Comment #7
mparker17On my machine, the patch in #6 regresses the behavior fixed in #2, because the machine name of the module is
schemaorg, notschemaOrg(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.
Comment #8
quietone commentedThis 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.
Comment #9
mikelutzYeah, 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.