What actually happens to a content type's term reference field if you (1) edit/change a taxonomy term or (2) delete a term (considering the taxonomy is part of a live content type)?
I'm wondering as I'm considering giving users the ability to add to taxonomies if the term is not already available. If I'm correct I think if I allow them to add new terms in can add them to (A) a new taxonomy (which easily distinguishes the new terms to check) or (B) to the end of the existing taxonomy (which I ever I choose).
However, as in the original question I'm wondering what effect such changes would have considering they are used in a content type. So in my example I would be letting them add to a 'job type' taxonomy. So what would happen if in the instance someone added 'film runner' but (1) had spelt it wrong so I had to edit it to the correct spelling or (2) I decided to delete it because it was not relevant? Would this mean that in instance (1) - editing it - the content type's term reference field would simply be updated to reflect the new edit? In the case of (2) - deleting the term - what would happened then? Would it mean the content type's term reference field would be empty?
Additionally, how would this effect Views in the sense that the Taxonomy Term might be used for an exposed filter? In (1) - edited - would this have any effect or would it simply be updated with new change? In (2), would it mean that the exposed filter would just no longer have that term on deletion?
Any advice would be greatly appreciated.
Thank you
Stephen
Comments
Hi stephen, If I am not
Hi stephen,
If I am not wrong, suggest one thing that you can create a custom module which takes the taxonomy term data from user end. Once added it will go for moderation and admin will approve it. Content can't be create with that term unless it is approved by admin.
Thanks
In instance 1, the term
In instance 1, the term reference field holds a reference to the tid, not the name of the term, so you can change the name as many times as you like and any content tagged with it via term reference fields will still be tagged with it. The views exposed filters should update themselves to show the new name but otherwise work exactly as before.
In instance 2, I'm fairly certain that when a term is deleted, all the values of term reference fields that refer to it are also deleted. I'd need to run tests / look though the code / run it by someone older and wiser to be 100% sure on that, but I can say that whenever I've deleted terms there hasn't been any residual after-effects as a result. And yes, your views filter would no longer show the term after deletion.
Paul.
PQ is correct
Hi Stephen,
What PQ says above is true.
Taxonomy terms are stored against an ID field ('tid'), and it's the tid that's stored in any content field. So if you change a term's spelling, nothing changes as far as the content's data is concerned. Any views should just show the new spelling when the page is refreshed.
The same for deletion I think. I think when a term is deleted, all fields containing that tid are set to null, so nothing is selected (or remove it so there's one less selection for a multi-value field).
This should be easy to test, try it for yourself.
Letting users add new terms might be a bad idea. If runner is already in the database as 'film runner' but a user adds 'runner' because they didn't see it then you now have 2 values to manage. You'll have to change any nodes using the new term over so they both get reported on properly in views, then delete the newly added term, and there's no guarantee that someone won't do it again. It's just more work for the site admin.
PQ is obviously Right. But
PQ is obviously Right. But problem will be for admin.
Lets see:
user 1 added a content content-1 having term "film runner"
user 2 added a content content-2 having term "runner"
user 3 added a content content-3 having term "runner film"
if term name "film runner" is right, admin has to edit the content-2 and content-3 to term "film runner" before delete the terms "runner" and "runner film".
One thing that can mitigate
One thing that can mitigate this is the use of the autocomplete field type, in conjunction with time spent educating the client to look at the suggestions while typing. In some issues like this there is a compromise to be struck between admin flexibility and enforced data integrity. I like to have faith that with a bit of education users will get it right 99% of the time, and I provide them with a procedure for fixing any issues that occur the other 1%.