Problem/Motivation

Core is about to add a default content export system: #3532694: Add a command-line utility to export content in YAML format

It is extensible and modules can integrate with it by means of an event. Pathauto should integrate with this new system.

Proposed resolution

It is possible that nothing will actually be necessary; core naïvely exports the Path field items, only removing the non-portable path ID.

But if it turns out that core is not exporting the Pathauto flag, then Pathauto should subscribe to the new PreExportEvent and wrap around the core callback for path field items, ensuring that the flag is preserved on export.

Issue fork pathauto-3535498

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:

About issue forks

Comments

phenaproxima created an issue. See original summary.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Title: [PP-1] Integrate with core's default content exporter » Integrate with core's default content exporter
Status: Postponed » Active

The core blocker is in!

dieterholvoet’s picture

dieterholvoet commented

FYI, it seems like core is not exporting the Pathauto flag by default.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented

That's because it is a computed property, which core ignores by default.

Pathauto could force the property to be exported by overriding the export callback for path field items. That's doable by subscribing to PreExportEvent.

dieterholvoet’s picture

dieterholvoet commented
Status: Active » Needs review

dieterholvoet opened merge request !185

dieterholvoet’s picture

dieterholvoet commented

Pathauto seems to be causing issues with default content. Drupal\pathauto\PathautoItem::postSave() makes it so its parent method, Drupal\path\Plugin\Field\FieldType\PathItem::postSave(), is never triggered when pathauto is enabled. This causes aliases of translations to sometimes not be imported.

dieterholvoet’s picture

dieterholvoet commented
Related issues: +#2973478: Aliases are not created for affected translations

It seems like #2973478: Aliases are not created for affected translations fixes this problem. With a patch from that issue, aliases for all translations are generated during import. That does mean that the exported alias is not used and instead a new alias is generated, but that might be acceptable in context of Pathauto.

csakiistvan’s picture

csakiistvan
Primary language Hungarian
Location Budapest, Hungary
commented

@dieterholvoet — could you clarify the last sentence of comment #8? "The exported alias is not used and instead a new alias is generated" only holds for pathauto: 1 items; for pathauto: 0 the exported alias is used verbatim, which is what this MR makes possible. Also, should #2973478 be a dependency rather than related, if the translation import fix is required?

✅ Tested and works — applied MR !185, rebuilt caches and exported two nodes with core's Exporter: the path field now carries pathauto: 1 / pathauto: 0 and no pid. An export → delete → import round trip kept /my-hand-made-alias on the manual node; the same YAML without the pathauto lines replaced it with /article/manual-alias-test.

Notes
  • The translation scenario from comment #7 was not covered.
dieterholvoet’s picture

dieterholvoet commented

Did you mean it strictly for the automatic case?

Yes

should #2973478 be marked as a dependency here rather than just related, if the translation import fix is required?

Yes, it's needed when dealing with translations, but that doesn't mean we can't merge this before that one.