Move operation

I have a slightly different approach to this missing piece of functionality.
My patch does not have ability to move terms from one vocabulary to another. I tried to replicate the behavior as close to 7.x version as possible (and there this "move to another vocabulary" was made via Double Tree).

My patch also uses system autocomplete path instead of a custom one. And it also prevents from circular hierarchies (uses the same algorithm as the 7.x version).

I' ve reviewed #6. Looks decent, but got a feature request on top of it (this should prolly be a separate issue).
Currently we are only able to select terms from the current vocabulary when selecting the 'move' functionality.
What i would like to do is first select a vocab and then select the term. (move terms from vocab A parent Y > > to > > vocab B partent X.
Could do it via a custom module, but would be great if this is included in this module.

Subscribe Rob C's request.

I added move operation for vocabulary it is not perfect but you can now move a term to another vocabulary without parents.

Patch rerolled against latest dev.

Thanks for the contribution! This is a great start and adds much needed functionality towards a release.

Some thoughts:

Vocabulary to move the term to

I have very strong reservations about this. Since Terms are first class entities, differing vocabularies could contain fields, methods and properties that do not exist in the target vocabulary. This could lead to a loss of data (or worse) when you attempt to change the Entity type. This seems like an edge case that shouldn't be included here. I would suggest this gets removed entirely from the module.

Keep Old Parents

Should this philosophically be included as part of a move operation? It seems to me that the checkbox changes the operation from 'Move' to 'Add a New Parent'. This can already be done from the Term edit form. I'm open to discuss adding another button to the bar to explicitly provide this functionality, but I'm not convinced it should be included in the Move Form.

General Thoughts:

• It occurs to me that the move operation could become onerous if many Terms were selected. I would prefer to do this in a Batch.
• It would be nice to have a message display that informs the user of what was done. Something along the lines of "The term was successfully moved from Parent A to B"
• A cancel button on the form would improve the accessibility/UX.
• At a quick glance, I notice a few coding standards issues in the patch. I would like to keep any new contributed code passing standard linting.

Please do note that the move button has been disabled until this functionality has been completed.

#2960794: "Move" Button is not functional

Any further patches in this issue should include removing the CSS to show the button.

Will this patch be committed to the -dev version?

Here's a reroll of the patch in #10 which works great, thank you Insasse. I needed the functionality to move terms from one vocabulary to another.

Other than changes to allow it to apply and work with the latest 8.x-1.x code, this patch also removes the CSS hiding the move term— in order to make testing easier.

Marking "Needs review" to kick the test bot into gear. I know there are several areas that need work still (cancel button, success message, maybe coding standards, ...i think it's fitting to get this in and try to get batch operations done before #606344: Possibility of "select all" finally gets in!)

Vocabulary to move the term to

The argument for keeping this: the 80% use case for taxonomy is non-hierarchical vocabularies with no extra fields. The move operation is only useful for non-hierarchical vocabularies if it can move between vocabularies. And if there are no extra fields, there won't be any problems in moving them.

The ability to switch the vocabulary a term belongs to has existed in Drupal for more than 12 years; the last nine or ten years that capability has lived in Taxonomy Manager.

Would a reasonable compromise be to include a warning about code customizations of vocabularies likely breaking the move operation plus looking at the vocabularies for extra fields and locking those that do (allowing this to be overridden easily with custom code, say, a hook implementation for evaluating safe moves)?

Small improvement on patch 15.

When not selecting "keep parent" it would not actually remove the previous parent so i made sure to remove those parents before adding the new one.

This might imply that we can remove the "loadParents" call as it seems the previous parents are already in there but i have not done enough testing to validate that is true for all cases.

Small update on previous patch where it would add the root term as well to parents which it should not

Reapplied and reordered previous patch from #18 to latest 2.0 dev branch

Seems to work for simple case with no parent term selection involved

when you properly select the vocabulary and autocomplete rebuilds the form to give choices for parent terms the following error appears

The website encountered an unexpected error. Please try again later.

Symfony\Component\Routing\Exception\InvalidParameterException: Parameter "taxonomy_term" for route "entity.taxonomy_term.edit_form" must match "\d+" ("" given) to generate a corresponding URL. in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 204 of core/lib/Drupal/Core/Routing/UrlGenerator.php).
Drupal\Core\Routing\UrlGenerator->getInternalPathFromRoute('entity.taxonomy_term.edit_form', Object, Array, Array) (Line: 293)
Drupal\Core\Routing\UrlGenerator->generateFromRoute('entity.taxonomy_term.edit_form', Array, Array, 1) (Line: 105)
Drupal\Core\Render\MetadataBubblingUrlGenerator->generateFromRoute('entity.taxonomy_term.edit_form', Array, Array, ) (Line: 762)
Drupal\Core\Url->toString() (Line: 132)
Drupal\Core\Form\FormSubmitter->redirectForm(Object) (Line: 79)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 593)
Drupal\Core\Form\FormBuilder->processForm('taxonomy_manager_vocabulary_terms_form', Array, Object) (Line: 321)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 573)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 158)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 80)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 706)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

if the vocabulary is selected with keyboard arrow keys there is no rebuild of the form and submitting the form moves the term(s) to the selected vocabulary on top level

Needs more work leaving it here for someone with more time to explore further

The error in #19 was caused by the search terms function in the toolbar firing when the vocabulary widget reloaded the form. The functionality of that toolbar action would be better handled by an explicit submit button that makes it clear what it is doing rather than setting the submit handler for the whole form. I removed it in my merge request.

Moving this to needs review as I've resolved the error that was being thrown.

I've installed taxonomy_manager dev-2.0.x and the patch from #19. I get the dialog to enter the destination vocabulary but as soon as I click on the option in the autocomplete for taxonomy name the form disappears and I get the error:

Symfony\Component\Routing\Exception\InvalidParameterException: Parameter "taxonomy_term" for route "entity.taxonomy_term.edit_form" must match "\d+" ("" given) to generate a corresponding URL. in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 204 of core/lib/Drupal/Core/Routing/UrlGenerator.php).

If I use the keyboard to navigate the autocomplete, I can then submit the form ok.

#24 +1

@dustinleblanc I don't see any patch in your comment. Seems like you kept it for your merge request. Would it be possible to post the patch here so we can review?