Automated Drupal 11 compatibility fixes for wordpress_migrate

This is an automated patch generated using Upgrade Status and Drupal Rector. Please see the issue summary for more details. A merge request (MR) is also openend and updated.

It is important that any automated tests available are run and that you manually test the changes.

Drupal 11 Compatibility

According to the Upgrade Status module → , even with these changes, this module is not yet compatible with Drupal 11.

Currently Drupal Rector, version 0.20.1, cannot fix all Drupal 11 compatibility problems.

Therefore these changes did not update the info.yml file for Drupal 11 compatibility.

The compatibility issues that Upgrade Status found after the Drupal Rector fixes were applied are attached to help you resolve them manually.

Leaving this issue open, even after committing the current patch or merging the MR, will allow the Project Update Bot → to post additional Drupal 11 compatibility fixes as they become available in Drupal Rector.

Debug information

These packages were used to generate the fixes:

1. drupal/upgrade_status: 4.1.0
2. mglaman/phpstan-drupal: 1.2.9
3. palantirnet/drupal-rector: 0.20.1

This is an automated patch generated using Upgrade Status and Drupal Rector. Please see the issue summary for more details. A merge request (MR) is also openend and updated.

It is important that any automated tests available are run and that you manually test the changes.

Drupal 11 Compatibility

According to the Upgrade Status module → , even with these changes, this module is not yet compatible with Drupal 11.

Currently Drupal Rector, version 0.20.2, cannot fix all Drupal 11 compatibility problems.

Therefore, these changes did not update the info.yml file for Drupal 11 compatibility.

The compatibility issues that Upgrade Status found after the Drupal Rector fixes were applied are attached to help you resolve them manually.

Leaving this issue open, even after committing the current patch or merging the MR, will allow the Project Update Bot → to post additional Drupal 11 compatibility fixes as they become available in Drupal Rector.

Debug information

These packages were used to generate the fixes:

1. drupal/upgrade_status: 4.3.2
2. mglaman/phpstan-drupal: 1.2.11
3. palantirnet/drupal-rector: 0.20.2

I've updated the module to D11 and kept D9 and D10 compatibility. I did one of the backwards compatibility issues differently than rector and found another similar issue. I lightly tested it on D9/D10/D11. The two methods I added at the end of SourceSelectForm can be changed once D9 is no longer supported.

I and someone in the Slack channel (https://drupal.slack.com/archives/C226VLXBP/p1726971471014629) had a problem where the protocol of the uploaded file was set to 'public://', but that wasn't resolved to 'http://'. I assume it was resolved in the past but behavior changed somewhere. I didn't look into that, I just changed the code to resolve the URL.

I also made a factory to create instances of WordPressMigrationGenerator and made that factory a service.

@tolstoydotcom I was reviewing this work since this module is failing automated D11 testing.

FYI there is a related issue 🐛 Protocol "public" not supported Active on the public protocol problem.

Your patch seems to be missing the definition of WordPressMigrationGeneratorInterface as well as a wordpress_migrate.services.yml

That's odd, I'll update it tomorrow. I'll also test out #5 on the other thread.

An abridged def is:
namespace Drupal\wordpress_migrate;

interface WordPressMigrationGeneratorInterface {
public function createMigrations(array $configuration): void;
}

and the services file:
services:
wordpress_migration_generator_factory:
class: Drupal\wordpress_migrate\WordpressMigrationGeneratorFactory
arguments: ['@entity_field.manager', '@plugin.manager.migration', '@file_url_generator']

Thank you tolstoydotcom , thanks to msielski we should be clear of public protocol issue. 🐛 Protocol "public" not supported Active .

Open to advice about best move here w D11.

I can rework my patch to have the missing parts, it does work on D11.

However: the rector patch uses the backwards compatibility layer. My patch instead tests if things are available. That's not an issue if you don't want to support D9.

Should I post a new patch?

I am pretty unfamiliar with the backwards compatibility layer to be honest. I think we should probably hold onto Drupal 9 support if possible. Thank you.

Thanks everyone for working on this. "hold onto" means keep doing something, which slightly contradicts the first part of the sentence ... But I assume the decision is "No D9 support"?

I think that will be fine. After all, Drupal 9 reached end of life November 2023 https://www.drupal.org/about/announcements/blog/drupal-9-is-end-of-life → .

That is fair enough ressa regarding D9 EOL. Maybe the best move is, tag another release as "the last D9 supported release", and after that, include this patch.

Here's an updated patch. It should work with D9/D10 but I only tested D11 this time.

@tolstoydotcom I tried applying the patch against wordpress_migrate 3.x-dev@dev but it failed to apply. Do you have other patches applied?

Composer gives me the error:

Gathering patches for dependencies. This might take a minute.
  - Installing drupal/wordpress_migrate (dev-3.x b0ebd6d): Cloning b0ebd6d586 from cache
  - Applying patches for drupal/wordpress_migrate
    patches/d11update-3435726-13.patch (D11)
   Could not apply patch! Skipping. The error was: Cannot apply patch patches/d11update-3435726-13.patch

A src/WordPressMigrationGenerator.php.rej file was generated with the conflicts:

--- src/WordPressMigrationGenerator.php
+++ src/WordPressMigrationGenerator.php
@@ -196,12 +203,12 @@ class WordPressMigrationGenerator {
   protected function createContentMigration($wordpress_type) {
     $dependencies = [];
     $content_id   = $this->configuration['prefix'] . 'wordpress_content_' . $wordpress_type;
-    $migration    = static::createEntityFromPlugin('wordpress_content', $content_id);
+    $migration    = $this->createEntityFromPlugin('wordpress_content', $content_id);
     $migration->set('migration_group', $this->configuration['group_id']);
-    $source                   = $migration->get('source');
+    $source = $migration->get('source');
     $source['item_selector'] .= '[wp:post_type="' . $wordpress_type . '"]';
     $migration->set('source', $source);
-    $process                = $migration->get('process');
+    $process = $migration->get('process');
     // Path alias generator.
     $process['path/alias'][] = [
       'plugin' => 'str_replace',
@@ -224,12 +231,12 @@ class WordPressMigrationGenerator {
       'replace' => '',
       'regex' => TRUE,
     ];
-    $process['uid']         = $this->uidMapping;
+    $process['uid'] = $this->uidMapping;
     $process['body/format'] = [
       'plugin' => 'default_value',
       'default_value' => $this->configuration[$wordpress_type]['text_format'],
     ];
-    $process['type']        = [
+    $process['type'] = [
       'plugin' => 'default_value',
       'default_value' => $this->configuration[$wordpress_type]['type'],
     ];

If you clone https://git.drupalcode.org/project/wordpress_migrate the patch should apply cleanly.

Maybe use a Gitlab fork, to streamline the process?

AFAIK, the link in my last comment is where the latest code is. If anyone wants to test it, just:

git clone git@git.drupal.org:project/wordpress_migrate.git
cd wordpress_migrate
patch -p1 < d11update-3435726-13.patch

@tolstoydotcom, thank you, I was testing against the dev branch. Patch applied fine for me against 8.x-3.x and everything is working well on Drupal 10.3.6.

Okay I fumbled around a bit (issue forks are a little tricky) on MR 19 but I think this encompasses your changes tolstoydotcom and a few small small type-safety changes. I think we can roll this in unless someone catches an issue that needs attention.

It will need a re-roll against 8.x-3.x head and ideally cleaning up a few of those flags, which may need some more dependency injection added in constructors to get rid of \Drupal calls. There is currently a merge conflict popping up.

I count five instances of \Drupal:
- in README.md. I don't think that should be replaced
- in a drush function. Unless that's changed to use classes, that can't be injected.
- in SourceSelectForm. I didn't inject that because getFileValidators will be reworked so the Drupal call is no longer needed once the module doesn't support D9
- in ImportWizard. I don't know if there will be a conflict with how ctools does things. If there is, this might have to remain.
- in ImageSelectForm. I can replace that.

I'll post another patch over the weekend that deals with the last two items.

Increasing Priority, since it is placed under "Major issues" header in 🌱 Plan for wordpress_migrate 8.x-3.x beta release Active , so I am also adding that as parent issue.

@tolstoydotcom and @ressa thank you for digging around this weekend. It was suggested to me by @dinarcon that we could split up the patch (MR19) to simplify matters somewhat by moving the new interfaces / service / factory / validator over to that issue (unless they are absolutely necessary to get Drupal 11 working).

I have filed a new issue ✨ Add interfaces, service, factory and validators Active to cover these things. If that is objectionable or duplicative I would say, alright let's proceed as we have been - and I would change the new issue to cover a smaller refactoring. However I think this will be helpful to consider.

I based this on the latest dev version. I injected services in the last two places I listed in #23. I didn't deal with the drush code. It'd be great if we could freeze changes to dev for a while, test the patch on D9/D10/D11 (I only tested in on D11), and then deal with drush etc.

To use:

git clone git@git.drupal.org:project/wordpress_migrate.git
cd wordpress_migrate
patch -p1 < ../d11update-3435726-26.patch

Oh this is really looking look great. Thank you for this elegant workaround for D9. I think we can just tag the final D9 release before applying your patch. I can test it on D10 and D9 tomorrow as well.

Hoping we can get a fix on duplicate users ( #3123393: Users are duplicated (Integrity constraint violation) Duplicate entry → ) before tagging the next release.

on SourceSelectForm.php . the IDE doesn't like !empty but I think 'isset' is a little better.
if (isset($constraint_definitions['FileExtension'])) {
Also I was able to get a TypedDataManager in the __construct() here to replace the \Drupal notice in getFileValidators.

on ImportWizard.php $tempstore_id needs a parameter type.

Thank you for working through this as I reshuffle a bunch of stuff and try to get nearby code fixes in there. I think we can freeze for a day or 2 unless someone has a quick fix for broken users. Really appreciate all this work.

Having trouble getting the git push to the MR to work but anyway here is the patch with a few adjustments noted above. Awesome stuff thank you!

I made a MR, please review.

Thank you baltowen I was also wondering about that one and not sure if it is a string but, if it works it is probably fine.

I might cherry pick some of the smaller changes out of this patch to apply before the larger patch on D11 so we can get some of it into the next tagged release this week. I will also try and get some more testing. We are nearly there folks!

Yes, $tempstore_id is a string See https://git.drupalcode.org/project/ctools/-/blob/8.x-3.x/src/Wizard/Form...

Okay I have been able to finish the cherrypicking of several items from this issue into 8.x-3.x, and then rebased the MR to match the new 8.x-3.x, which has scaled down the size of the rest of the patch at least a good ways. Thanks for bearing with me, I won't do any more cherry picking from here. Excellent work everyone!!

hongpong → closed merge request !12

The last pipeline was failing. It looks like during a merge @baltowen's phpcs fix was lost. I cherry-picked c636be41 and pushed. This should make phpcs pass.

Tested the latest code and was getting a fatal error when starting the wizard at /admin/structure/migrate/wordpress_migrate

The website encountered an unexpected error. Try again later.

ArgumentCountError: Too few arguments to function Drupal\wordpress_migrate_ui\Form\SourceSelectForm::__construct(), 0 passed in /var/www/html/web/core/lib/Drupal/Core/Form/FormBase.php on line 82 and exactly 1 expected in Drupal\wordpress_migrate_ui\Form\SourceSelectForm->__construct() (line 25 of modules/contrib/wordpress_migrate/wordpress_migrate_ui/src/Form/SourceSelectForm.php). 

I pushed a new commit passing the missing parameter.

This is an automated patch generated using Upgrade Status and Drupal Rector. Please see the issue summary for more details. A merge request (MR) is also openend and updated.

It is important that any automated tests available are run and that you manually test the changes.

Drupal 11 Compatibility

According to the Upgrade Status module → these changes make this module compatible with Drupal 11! 🎉
Therefore these changes update the info.yml file for Drupal 11 compatibility.

Leaving this issue open, even after committing the current patch or merging the MR, will allow the Project Update Bot → to post additional Drupal 11 compatibility fixes as they become available in Drupal Rector.

Debug information

These packages were used to generate the fixes:

1. drupal/upgrade_status: 4.3.6
2. mglaman/phpstan-drupal: 1.3.2
3. palantirnet/drupal-rector: 0.20.3

Tested this with Drupal CMS 1.0.2 and the posts titles are imported but the content is ignored.

I think we can bring the patch in. I am testing in Drupal 10.4 11.0 11.1 to finally put it to bed to this point.

However re xpath note I believe we need a better body field picker in Drupal 11.1 (similar to the other field pickers in the wizard) . New issue added ✨ Add body field picker w default to wizard & processing Active . It works in Drupal 10.4 and 11.1 with the default 'body' field but it doesn't warn the user if this situation isn't connected.