Users are duplicated (Integrity constraint violation) Duplicate entry

Probably related:

Notice: Undefined index: default_author in Drupal\wordpress_migrate\WordPressMigrationGenerator->createMigrations() (line 103 of /app/web/modules/contrib/wordpress_migrate/src/WordPressMigrationGenerator.php)

when making 2+ migrations on the system. Bumping to major seems serious.

And #3131949: Author migrate: Error: Call to a member function toUrl() on null in rdf_comment_storage_load()

The undefinex index is just a coding error. It's look for a default author in case you chose NO to importing users, and since you didn't defined a default_author it's looking for something that does not exist.

The issue I believe lies here:

      $this->authorID = $this->configuration['prefix'] . 'wordpress_authors';
      $migration      = static::createEntityFromPlugin('wordpress_authors', $this->authorID);
      $migration->set('migration_group', $this->configuration['group_id']);
      $migration->save();
      $this->uidMapping = [
        'plugin' => 'migration_lookup',
        'migration' => $this->authorID,
        'source' => 'creator',
      ];

It would seems it's just creating users but never checking if they already exist in the Database.

Sorry, I don't have time to create patch. To avoid it, try to add new process to wordpress_authors.yml:

...
process:
  uid:
    -
      plugin: entity_lookup
      entity_type: user
      value_key: name
      ignore_case: true
      source: author_login
...

And replace code mentioned above to this:

      $this->uidMapping = [
        'plugin' => 'entity_lookup',
        'entity_type' => 'user',
        'value_key' => 'name',
        'ignore_case' => 'true',
        'source' => 'creator',
      ];

The only thing on rollback action, you will deleted existed users.

still getting stuff like this

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'themereviewteam-en' for key 'user__name': INSERT INTO "users_field_data" ("uid", "langcode", "preferred_langcode", "preferred_admin_langcode", "name", "pass", "mail", "timezone", "status", "created", "changed", "access", "login", "init", "default_langcode") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14); Array ( [:db_insert_placeholder_0] => 6 [:db_insert_placeholder_1] => en [:db_insert_placeholder_2] => en [:db_insert_placeholder_3] => [:db_insert_placeholder_4] => themereviewteam [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => themereviewteam@gmail.com [:db_insert_placeholder_7] => America/New_York [:db_insert_placeholder_8] => 1 [:db_insert_placeholder_9] => 1732512346 [:db_insert_placeholder_10] => 1732512346 [:db_insert_placeholder_11] => 0 [:db_insert_placeholder_12] => 0 [:db_insert_placeholder_13] => [:db_insert_placeholder_14] => 1 ) (/var/www/html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php:817)

maybe we can get some check like EntityExists in the process of it (since 8.9)
https://api.drupal.org/api/drupal/core%21modules%21migrate%21src%21Plugi...

I created a MR mapping the uid, please review.

Ok, got my commits and branches a bit messed up, but I think I finally sorted things out...

I tested @baltowen commit (after rebasing the branch against 8.x-3.x) and the error is gone. For this, I used the wp-import-5-loremipsum-2024-11-25.xml file in https://gitlab.com/HongPong/wordpress-test-imports While MR #30 technically fixes the issue, I think we should go with a slightly different approach.

MR #30 will allow overwriting users based on their usernames. That could lead to account take over or at regain access that had been revoked.

The wordpress_authors.yml migration uses the email based on the XWR file. If a matching username is found, the email will be changed and someone else can get access to the site via a password reset link. Also, the migration sets the status to 1 always which means the user is active. A user that had been blocked would have their account reactivated if that username is present in the XWR file.

I propose we do not allow overwriting existing accounts. In MR #31 I expand on @baltowen's commit to add a safety check to prevent user accounts from being overwritten.

By the way, I included a message to indicating that is is not allowed to overwrite user accounts. For some reasons, those messages are lost when running the migration from the UI. When doing it from Drush, the messages are preserved. This is unrelated to the issue being discussed here. Still I wanted to point it out in case someone looks for the messages and does not find them.

I was able to get one 'updating existing users is not allowed' message to print by running the loremipsum XML twice. it ignores all of them but it only gives one message, in my case at
/admin/structure/migrate/manage/my_wordpress7lorem/migrations/my_7loremwordpress_authors/messages
under the 'messages' tab for authors.

Processed 16 items (0 created, 0 updated, 0 failed, 16 ignored) - done with 'my_7loremwordpress_authors'
Messages:
ollie.medhurst Informational my_7loremwordpress_authors:_skip_existing_user: Updating existing users is not allowed.

I think we can commit this for now and make note that, the authors skipped, do not each generate a message.

Thank you everyone, another nasty bug squashed. baltowen, dinarcon, lobodakyrylo, uridrupal, splash112!!