Problem/Motivation

Using our custom domain_path database table for storing domain aliases implies duplicating a lot of code that could simply be reused or extended if we used the core path_alias table like the domain_unique_path_alias module is doing.

It will also allow to use the bulk update/delete mechanism of PathAuto.

Proposed resolution

Remove all unnecessary duplicated code and the custom domain_path entity type.

Issue fork domain_path-3564844

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

mably created an issue. See original summary.

mably’s picture

mably commented
Issue summary: View changes

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

mably opened merge request !61

mably’s picture

mably commented
Status: Active » Needs review
mably’s picture

mably commented
Issue summary: View changes
mably’s picture

mably commented

MR 61 has been rebased. Could you give it a try @lincoln-batsirayi?

idebr’s picture

idebr commented

The domain_path table is not removed in MR 61 in the database updates. Is this in scope?

mably’s picture

mably commented

Shouldn't we wait a bit before removing the table, just in case users need to rollback the update ?

We could remove the domain_path table in a later update:

/**
 * Uninstall the obsolete domain_path entity type.
 */
function domain_path_update_10007() {
  $definition_update_manager = \Drupal::entityDefinitionUpdateManager();
  $domain_path_type = $definition_update_manager->getEntityType('domain_path');
  if ($domain_path_type) {
    $definition_update_manager->uninstallEntityType($domain_path_type);
  }
}

@idebr what do you think?

mably’s picture

mably commented
Issue summary: View changes
idebr’s picture

idebr commented

In the Drupal ecosystem, the source data is typically removed when database updates are completed, but ultimately it is up to the project maintainer. It is possible to write a test for database updates that could put assertions into code for debugging later, see for reference: https://www.drupal.org/docs/drupal-apis/update-api/writing-automated-upd...

Perhaps a follow-up issue to remove the original table at a later point in time, eg. before a stable release, would suffice in this case?

mably’s picture

mably commented

I'll create the follow-up issue as soon as this issue gets merged.

mably’s picture

mably commented
Issue summary: View changes
lincoln-batsirayi’s picture

lincoln-batsirayi commented

I've been testing this and this has been looking good but I’ve seen this error / warning after saving a page having added a domain to a page:

Warning: Undefined array key "language" in domain_path_domain_source_alter() (line 138 of modules/contrib/domain_path/domain_path.module).
mably’s picture

mably commented

Hi @lincoln-batsirayi, problem should be fixed in 2.x. I rebased MR 61.

Could you give it a try?

  • mably committed 75e1ade8 on 2.x 
    feat: #3564844 Switch to using the default core path_alias table instead...
mably’s picture

mably commented
Status: Needs review » Fixed

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.

mably’s picture

mably commented
Related issues: +#3570553: Remove the deprecated domain_path entities

Follow-up issue has been created to remove the deprecated domain_path entities.

#3570553: Remove the deprecated domain_path entities

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.