I am going crazy over a problem with tags in Omeka 2.3. I hope someone can help!
I have not been able to easily find documentation on what tag names are invalid in 2.3 (or any Omeka version). So far, it seems to be the following, in my testing:
-- tags cannot be just numbers (ex. 1941)
-- tags cannot have spaces (ex. Here Is a Tag)
-- tags cannot be certain random words (ex. Assassinations...but then Assassination works fine. ??)
These tag naming problems are showing themselves both in the Omeka admin area and in the CSV Import plugin:
-- In the admin area, if I try to rename an existing tag to, say, 1941, the save simply does not 'take' -- no errors.
-- In the admin area, if I am editing an item and adding an above offending tag, the site throws an Omeka error (with stack trace) when save the record: 'Name: That name is already taken for this tag.'
-- If try to import records with the above offending tags, the import dies and I get the same error as above in the log: 'Name: That name is already taken for this tag.'
We have tags in our system with spaces in them that were added when we were on Omeka 2.2.3. Did the tagging system get buggy on 2.3?
Thanks in advance for any insights!
So there are tags in your installation which were populated via CSV import?
Yes. But the tag problems are currently happening with both the CSV Import plugin and the Omeka admin area. Both give an Omeka error, *not* a plugin error.
None of those things are forbidden for tags: numbers are okay and spaces are allowed. More or less the only thing not allowed is whatever the delimiter character is set as (usually a comma).
The error message is a clue to what must be happening: your Omeka install thinks you're adding a new tag, but it's actually the same as one that already exists and that's causing an error.
I can't reproduce your problem, though. The previous problems we've seen that are like this have been about differences in letter case, and some changes were made to Omeka 2.3 to fix those problems. The only thing I can think of as the problem here is with spaces: if your tags have trailing spaces after them (possibly because of how they were added with CSV Import) I can see a way that there would be a problem when we try to check if the tag already exists.
Thanks John. I'm actually trying to add items that contain new tags, not existing tags, so the tag name is definitely not already taken as the error indicates. (Even if the tag *was* already in the system, why wouldn't it just add the tag to the item I am importing?) I just meant that we had tags with spaces in them prior to this issue, and now I can't add tags with spaces (or all numbers, or random words like "Assassinations").
FWIW, in Omeka 2.3, I can't make changes to existing tags by simply changing the case. It does not register the change.
My data is clean without trailing spaces, so I don't think that is the problem.
Even if the tag *was* already in the system, why wouldn't it just add the tag to the item I am importing?
This would be the exact problem: Omeka looks in the database to see if it should be trying to add a new tag or use an existing tag. When two tags differ by trailing spaces only, Omeka doesn't see them as the same tag at this step, but it does see them as the same when it tries to add the new tag, so it complains that the name is already taken.
I've been able to confirm a problem with trailing spaces, but not the problems you're describing with tags only containing numbers and the like. From what you're describing, I'm tempted to say that the problems do indeed all stem from tags that are already in the system. If you try to add a tag that's all numbers but is some random new number like 194111, do you get the same problem?
Adding the tag '194111111' to an item in the Omeka admin GUI works. But, no tags related to '1941' (such as '1941' or '1941 ') are visible on the /admin/tags page. Why would the system say it's there when it's not? Is it there but hidden for some reason?
Okay, that's some evidence that it's mostly the problem I think it is at play with the spaces and comparison problems. I've put up a very small change to Omeka's development code that should fix that problem, so we should be able to get rid of the problem in a 2.3.1 release.
As for the tags being in the system but not showing up in the Tags panel, I believe that page is designed to only show tags that are actually assigned to at least one record. In other words, there can be "dormant" tags assigned to no records that are still in the database and could be silently causing your problem. I'll look into possibly modifying the Tags page or at least providing an option to show the tags with zero records.
Thanks John; I think this is definitely a bug in Omeka that needs to be addressed.
Please make sure your code checks for spaces *anywhere* in the tag, not just at beginning/end (trim). I went into my database backend and found the tag '1 9 4 1'. It must have gotten inserted for one of my test import runs (and obviously the data got messed up somewhere in that process, hence the spaces). I have long since deleted the records associated with my test imports, but apparently in that delete process, the tags stay behind, hiding in the database but not showing on /admin/tags. Then the bug with spaces in the tag comparison functions are preventing me from using those tags now.
I am very comfortable editing directly in mysql. For now, is it 'safe' (as far as the Omeka app architecture is concerned) to delete those rows with bad tags in the tags table so I can move on with my project? Or, I guess I could just rename them without worry for sure.
I really appreciate you helping me talk through this!
If you're comfortable working with MySQL, deleting the rows for tags that aren't being used at all would be safe. Keep in mind, though, that the same set of tags is used for Exhibits, so you'd want to be sure anything you deleted wasn't being used at all, not just for Items.
Another short-term route if you're comfortable applying a patch would be to apply the fix to your copy of Omeka so the comparisons would work correctly.
The patch seems to be working well. Thanks so much!!