On release version of 4.2.0 code, when an administrator selects "administer" a node option, the taxonomy terms that are assigned to that node to not properly select the nodes original taxonomy term specification. If the admin changes any content on the page, they *must* also select the correct taxonomy term to insure that when they "submit" the changes, it remains properly classified.

The behavior of the "administer" options should be such that the existing taxonomy term for that node is properly set as the selected entry in the list of terms. Then - if the admin wishes to change the taxonomy term, they can, but if they do not need to (as often as the case may be) then the term will not get accidentally reset with no information.

This has caused a MAJOR issue on our website, as a lot of our admins don't know this is happening, and a ton of our content taxonomy classifications have been incorrectly reset, causing items to get shuffled around and not to be properly visible.

I'm not 100% that I've set the "Area" of this bug correctly, I believe it's the node system that's responsible for the /admin/node/edit/ area, so that's why I chose that as the Area classification.

Comments

moshe weitzman’s picture

moshe weitzman commented

Can anyone reproduce this behavior. If this were really happennning
everywhere, there would be wild screams. I think this is a local database
problem.

shane’s picture

shane commented

Any ideas on how I might be able to confirm if this is local DB issues or not? I'm happy to do what I can to test this and either squash this bug...

moshe weitzman’s picture

moshe weitzman commented

Study the HTNML which is emitted on the edit page. Especially look at the
form items for taxonomy. Do those form elements really have no value? Or is
there a value but that value doesn't appear in the list.

I suspect that you have shuffled around your vocabulary->nodeType mapping
and now what you expect to be shown for terms is no longer valid for that
node type.

shane’s picture

shane commented

Unfortunately - that's not the case. The Taxonomy terms have not changed (with the exception of adding 6 new tersm about 4 months ago), in about 8 or 9 months. I upgraded from 4.1.0 to 4.2.0 - that's when the issues started occuring.

The 4.1.0 code didn't have this issue. All of the taxonomy terms appear in the selection box, it's just when the edit page is brought up, the selection is changed to "". Worse of all - it appears to be intermittent - about 1/2 the time it switches back to "" - the rest of the time it gets set to the original taxonomy term item that was entered by the original poster. The Drupal code and the MySQL database are all on the local machine. The system is running extremely light loads (a couple dozen hits per hour) - with a Dual processor P4 1.8 Ghz, 2 Gigabyte memory, all 180 mbit/sec SCSI disks platform.

moshe weitzman’s picture

moshe weitzman commented

What type of nodes are these? They are not item nodes, are they (item is a
contrib module). I think taxo terms get overwritten sometimes in this
module. Also, two bugs have recently been patched related to missing taxo
terms. One where the queue module was deleting existing terms and the other
where xtemplate was mispresenting terms for some nodes.

i don't know if these are related to your problem.

shane’s picture

shane commented

So far I've only noticed it in the Event module, but I haven't looked at any of the other modules that utilize taxonomy that closely yet.

shane’s picture

shane commented

Hmmm, Just noticed that if a user posts a new event, and it goes into the queue to be voted on, I vote on it to post it, then the Taxonomy classification *also* gets reset to "none". Maybe this issue is only present in the queue system? It seems that the above problems *only* occur on the first time an administrator selects "administer" or edits the node in some fashion.

Even though a node doesn't need to be actively voted on by the queue system, does it still get managed by the queue system once, before being taken out of the queue? Does that make sense?

moshe weitzman’s picture

moshe weitzman commented

Pleasse diable the queue.module and see if you can reproduce this behavior. Also try this with a story or blog node instead of an event. I think the problem is in queue but I'm not sure.

moshe weitzman’s picture

moshe weitzman commented
Title: "Administer" node feature resets taxonomy selections to default » "Administer" node feature resets taxonomy selections for event module
Project: Drupal core » Event
Component: node system » Code

This is probably fixed with Kjartan's new event.module for 4.2. Please verify and close this bug as needed.

killes@www.drop.org’s picture

killes@www.drop.org commented

This is fixed for 4.3. I don't think anybody will want to fix it for 4.2.

killes@www.drop.org’s picture

killes@www.drop.org commented

Marking as fixed. 4.3 is the stable relase.

Anonymous’s picture

(not verified) commented

Automatically closed due to inactivity (marked fixed for 14 days).