Import permalink as URL paths

Here is the 7.x bug thread on related URL import issue. #2869595: link is not getting imported to url_alias table

I think it hasn't been hammered out yet. Take a look here for related techniques:

• https://evolvingweb.ca/blog/migrating-aliases-and-redirects-drupal-8
• https://www.calebthorne.com/blog/drupal/2016/07/16/drupal-8-migrate-path...

As noted in there, one approach might be to make the URL paths a wholly separate migration step - the other option is to do it with the node imports.

This module works better for me than the other available modules which import form a WP database. I am grateful for the module, and think it is good and worth of attention, especially now that Gutenberg is pushing some users away from WordPress, IMHO.

One advantate of the module is that getting imports of path aliases working is from WP xml export of content if fairly easy. (With alternative approaches which import directly from a WP database, importing aliases is more difficult.)

Migrating permalinks into Drupal aliases works if you add the following migrations/wordpress_content.yml:

source:
...
  fields:
...
    -
      name: link
      label: 'The link value'
      selector: 'link'
...
process:
  path/pathauto:
    plugin: default_value
    default_value: 0
  path/alias:
    plugin: get
    source: link

However, note that you either need a string replace in the 'process', or you need to go through your .xml file and make the following two changes:
1. change '<link>http[s]://example.com/...' for the new path, perhaps '<link>/...' or '<link>/blog/': Drupal 8 requires the path alias to be a relative link starting with a '/'. Any <link> values starting with 'http' or anything other than '/' will cause the node import to fail.
2. change '.../</link>' to '...</link>'. Drupal requires the path alias to end without a '/'. An imported path alias ending in '/' will not cause the import to fail, but each node will have to be resaved before the alias works.

I tweaked the code from John_B a little and got it working - thanks for that John_B! Disclaimer: the yml files need to be edited after they're created to replace "https://www.example.com" with the correct value for the website.

This includes an extra str_replace plugin call to remove the trailing slash on WP paths.

An updated comment.

Thanks for figuring this out! If someone else can confirm it works I will roll it in.

I think it still needs work to allow the hostname to be controlled from the setup form, I was working from a custom migration so could control that part myself.

Thanks for various contributions. Since I was among those who needed this feature, just checking in to say I am following some issues here but not currently able to work on WordPress migration. It is on the back burner for various reasons, one being that I have been hit with very high maintenance and debugging costs on a couple of D8 sites, so have advised other clients to review plans to move content into D8.

I ran into a tiny conflict with a patch from Implement file/attachment migration for Drupal 8, since it also modifies wordpress_content.yml. I tried writing an alternate patch based on #9, which would work with the file/attachment patch, but I ran into issues. So ignore this patch, LOL, and the one in the next comment. It's getting late and I am making silly mistakes.

Update; I can't actually get this to apply. Maybe I will come back to this. Ignore for now.
And thanks DamienMcKenna, for #9. Works beautifully, with modification of the domain name.

Anyone having problems with this working after URL aliases were split off into their own entity in D8?

Still works fine! Tested on 8.8.4.

Just cost me a couple of hours finding out I needed to delete and redo the complete migration to get my changes in.... Any solutions, pls let me know.

Reworded the last patch and added the core urlencode plugin as it sounded like a good idea and added some regex for dealing with wordpress unpublished content (paths were not openable by Drupal).

Played with it again, added the base_url field to the wizard and the base_url as a source. Sadly cannot get the str_replace plugin to actually remove the url... Any idea what I am missing?

Ok, finally figured out a way to do it and it works now as intended. Please review.

Sadly there are some non-fatal errors involved, hopefully they will be resolved in the issue below:
https://www.drupal.org/project/drupal/issues/2978664

Re-rolling the patch against 3.x-dev version (92b9172)

Thanks, did you have any success in testing this?

The patch in #23 doesn't work. The reroll is not correct, some code has been misplaced.

New reroll made from #21.

The code works great, thanks splash112

If the user was not filling the new source URL, it is blocking the migration because null is not acceptable for the str_replace plugin. I just added a check that the url_base is not empty before starting to do the replace logic. 'skip_on_empty' plugin is in core so no new dependency.

+ $process['path/alias'][] = [
+ 'plugin' => 'skip_on_empty',
+ 'method' => 'process',
+ 'source' => $this->configuration['base_url'],
+ ];

While i understand the modification in #26, it unfortunately causes no path/alias to be imported at all from my testing. #25 works fine.

#25 works fine here too. I'll update the status so that this might get some more action.

Ok adding pathauto as a new requirement since it doesn't work otherwise. Re rolling from #25 and updated requirements and the new Base URL field to have more informative description.

Thank you damienmckenna, splash112, caspervoogt, phjou, ivrh, bserem, tabestan, john_b, apmsooner! Well done.

It seems like I did not correctly get the Drupal contributor credits on this commit to work (eg here / here ) .. Titles on the merge requests seem to form the whole commit message, didn't realize! I am sorry folks particularly as this was a long multi year process.

Thanks everyone, this is a great feature to get into the module!

Since there has been quite a few improvements since 8.x-3.0-alpha6 released 24 September 2023, perhaps an alpha7 release could be considered?

https://git.drupalcode.org/project/wordpress_migrate/-/compare/8.x-3.0-a...

@hongpong: I think you can add credit later on ... Checking the users with missing credit in this issue, I think everyone deserves recognition...

If the below is not correct, perhaps the documentation could get an update, or an issue created, to fix it?

Use the checkboxes and Commit message field to generate a suggested commit message for the issue. While issue credits may be modified after the commit, commit message mentions can only be changed by amending the commit message (for git commits that are not yet pushed) or with reverting the commit and making the correction in a new commit (for commits that are pushed). Drupal.org prohibits the use of git force push to release branches, so making commit message changes that way is not possible.

From https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett...

@ressa Alright how about let's 1) update the documentation README regarding the base url field, and 2) move the permalink code into a new function within the same file? That function is already huge and I think would be better divided up anyway, to make development easier, fewer merge conflicts and so on.

Then everyone can be credited on that commit and hopefully it will be added to the Drupal contribution credits brain. (as far as I can understand what they say, it is not possible to attach credit to previous commits because 'force' push is not possible.) Again I am sorry about the 'credit' issue particularly since this took a lot of work to sort out!

Regarding a new release alpha7 I would hope to get both the pluggable extensions, and the Drupal 11 fix, onto the codebase before a release. However obviously many things are broken with alpha6 so, if we cannot get those sorted within a few days, then yes I think it would be fine to tag a new release within the next week regardless.

I took a closer look at the Granting credit text, and it look like it's possible to give credit by simply checking the names under "Credit & committing", and saving the issue, also after changing status to Fixed. Perhaps you could try it?

Check and uncheck the names of users listed in the box, depending on whether they contributed to moving the issue towards resolution. The credits will appear on the user and organization profiles when the issue status is changed to fixed, or when it automatically changes to closed fixed.

As I understand it, the Git commit crediting option is for the commit message in Gitlab, not the actual crediting ...

I think your plan sounds great. Getting pluggable extensions and Drupal 11 ready first if possible, before a new release makes a lot of sense -- depending on if it's too demanding, or not.

attempting to update credits, thanks ressa!

You're welcome! As we both agree, the Granting credit to issue contributors documentation page was a bit ambiguous, I had to study it closely to understand it ...

So I have updated the text and included links to #3185576: Remove issue credit suggestions and #3226881: Do not automatically credit people who upload files to an issue, attempting to make it clearer. What do you think about it now @hongpong?

@ressa yeah that is way easier to understand cheers!

Thanks for checking @hongpong, that's great!

The readme is updated significantly (including all contributors to date added), the pathauto / path alias function is extracted to a new function processUrlPathAliases. Thanks everyone.