Bulk generate should be able to recreate aliases

I'd expect that bulk update should support *updates*.

Sorry, I somehow thought it would update those aliases.

Not sure then, adding that would make that form a lot more complicated and it would also complicate the API's quite a bit.

One way to do that already is to use the action, e.g. through views bulk operations. However, that's currently limited to a single page (unless someone ported that feature from views bulk operations already).

Note that This issue is about D8 and the module already contains an update alias action in 8.x.

Now that Token is able to play with books correctly, I wanted to rename all book aliases, but unfortunately, this is not doable without first deleting *all* aliases for type = content (wow, I only want to do it for type = book). So I think the tab should be renamed "Bulk regenerate", because if we are able to delete all aliases of a given type and then create aliases for this same given type, then we are able to do it in one shot (at least from a user perspective). But we should be able to select article/book/base page/etc... separately instead of 'content' as a whole. And as mentioned in issue #2451307, we should be able to limit the mass create/update/delete to nodes with Set URL alias automatically' set to true only.

Would my proposal be accepted?

I'm not sure what the right mix of features is, I don't want to make it too complicated.

I would start with two options, which can also be combined: "Update existing alias", and "Force generation of aliases", the second option alone would force it for those without an alias yet and the combined it would force for all.

Per bundle selection might be better for a follow-up.

As commented, there is also the views action, so you could create a view of book nodes and apply the update alias action, which will actually force-update existing aliases. That currently doesn't support batch to process large data sets but might still work better for your use case.

I have a working patch. I need to test it a bit more first (and sleep a bit ;)). I will upload it tomorrow.

I didn't update PathautoBulkUpdateTest.php yet, because it will depend on the UI. So an initial review would be welcome.

It passes all tests locally except PathautoNodeWebTest for an obscure reason:

Uncaught PHP Exception InvalidArgumentException: "Invalid database prefix: " at core/lib/Drupal/Core/Test/TestDatabase.php line 81

But I get the same error message with my patch backed out, so the reason for this failure must be elsewhere.

So PathautoNodeWebTest fails on my machine but not here!? I'm jealous. :)

Updated patch, now including tests for the new feature.

Great work.

I was wondering for a second if this could cause the batch to loop forever, but we already handle that with the ID > current condition, so that should be fine. Ignoring the fact that this logic can only work for entities that have positive integers as ID's and not UUID's or so, but that would already be completely broken for them and this doesn't make it worse.

I guess a separate option to force re-generating the aliases, even if previously the user opted out might make sense, but lets do that in a separate issue.

We already have a number of related issues around bulk delete/update, and we could pick one of those to additionally also implement a force checkbox (We'll have to adjust some titles/descriptions added here but that's fine). You're welcome to look into that too. What would also be a great help for getting another beta or even a release candidate out would be to check for existing related issues and either set them to closed (duplicate) or postponed needs more feedback to try the latest dev and see if that fixes their problems.

The only thing I don't like is hiding the action inside the results through batchStart(). Lets pass that along to batchProcess() and make a new, explicit argument in batchUpdate(). That makes this an API change, but it is one anyway, otherwise existing implementations might not respect this new settings and would be "broken". This kind of forces them to update and respect it and it also gives us the perfect place to document the various values on \Drupal\pathauto\AliasTypeBatchUpdateInterface::batchUpdate().

Passing $action to batchProcess() and batchUpdate() was my initial idea, but I thought you would be against it due to the API change. Happy to see we have the same idea on this. :)

Here are both the updated patch and its interdiff.

Awesome, committed.