smd_tags: unlimited article, image, file and link taxonomy

aswihart · 2010-07-24 21:40:06

Hi Stef, this plugin in sick, thank you for sharing your talents with us. I’m eagerly awaiting the upgrades mentioned above coming down the pipeline.

First, thank you for including Autocomplete feature, this really enhances usability with a huge pool of tags. Now, I’m trying to edit the Autocomplete options (autoFill: false, matchContains: true, minChars: 3), but I’m unable to successfully edit the Plugin code for some reason, when I hit save I just get a blank screen and the changes aren’t saved. I remember running into this in the past with certain plugins, but I don’t remember what the problem / fix was. Any thoughts? Maybe I could try ied_plugin_composer (will try and report back when I get a chance).

Again, thanks for another great plugin Stef. Obviously I’m late to the party, but I do tend to lag behind discovering the brilliance of your plugins by a couple years, so I’m actually a little ahead of schedule on this one!

Last edited by aswihart (2010-07-26 01:47:09)

aswihart · 2010-07-26 01:55:39

merz1 wrote:

I have to think (decide) about the point more structured tagging though.

One element that I would consider “structured tagging” in smd_tags that is very useful for the site I’m working on is being able to associate categories with tags and then filter the tags on the “Write” tab by selecting categories. This provides a novel dose of “Write” tab customization within the category hierarchy, similar to what bot_write_tab_customize or sed_section_fields provide for different site sections. By selecting a child category just two levels deep, the number of tags available to select from goes down exponentially and instantly becomes a much more relevant vocabulary for Autocomplete to reference (or a much tidier multiselect box).

And the other “structured” enhancement over tru_tags is of course the tag hierarchy, which adds a much needed extra content hierarchy within Textpattern, in addition to sections and categories (while Drupal for instance allows an unlimited number of hierarchical taxonomies). Both of these features are very helpful when you have thousands of tags that exist on a spectrum of specificity and may or may not be correlated with the separate category hierarchy.

And finally, it is excellent that smd_tags exists independently, leaving the Keywords, Category, Section, and Custom Field areas open for additional content taxonomizing / typing with tru_tags, rss_unlimited_categories, adi_menu / cnk_section_tree, and glz_custom_fields.

There’s *just one thing*— when filtering tags on the “Write” tab, I need it to work one way but it currently does something a little different— I need it to show tags that are associated with any category up or down (but not across) the category hierarchy (grandparents, parents, self, and children— no aunts / uncles, cousins, or siblings). Currently, tags are filtered so that you only see those associated with categories down the hierarchy (self and children). The current behavior results in hiding “generic” tags that are unassociated with any category. It would be great to have a new category-association behavior option:

to show tags associated with any parent of the selected category (including “generic” tags that would by default be treated as assigned to an imaginary “god” category).

While the plugin does associate any child tags of a “category-associated tag” with the same category, what I’m asking for might be accomplished by somehow mirroring that behavior on the category side: associate any child categories of a category associated with a tag with the same tag. So, unassociated tags, treated as being associated with a make-believe “god” category, would actually be associated with all categories.

This may initially sound unintuitive and not useful, but in practice, this is the behavior that is needed sometimes. The issue I’m having (referencing my medical site in progress) is, say your diagnosis (tag) is bowel obstruction, while you have categories for stomach, small bowel, and colon. You don’t want to assign bowel obstruction to one of those specific categories, because it could apply to any of them, so you instead associate it with the gastrointestinal category. Unfortunately, when you do this, and you select small bowel on the “Write” tab, bowel obstruction gets hidden.

Another nice feature, which may be more complicated to implement, would be to limit available tags to those that don’t contain any children. This is another hierarchy behavior that will be preferred in some cases and has been created in different forms in various plugins. It would cut down on some of the “Write” tab tag bloat that would come with the more lax tag-category-association behavior I’m asking for.

Bloke · 2010-07-26 08:09:03

aswihart

Thanks for the props on the plugin. It’s been a real chore getting it this far but I’m determined to see it through eventually. Regarding your updating problem, it sounds like the plugin is too big for your host’s POST limit so it’s just getting whcaked when you save. ied_plugin_composer may fix it but if it’s a hosting issue then you’ll get the same result. Try it and see.

If that fails, let me know and we can approach it a different way: namely I’ll send you the PHP template file of the plugin and you can set up a plugins directory from your advanced prefs. If you then upload the plugin to that directory and disable the one from the Plugins tab you should be good to go. You can then edit the plugin in its raw format from ied_plugin_composer and it’ll save it as a file directly. One thing: I can’t remember if I auto-delete tags on plugin deletion (I don’t think I would, but you never know with my brain), so to be on the safe side I wouldn’t delete the original plugin just yet in case it removes your tagging. Backup first anyway.

Regarding your other conundrum, I’m glad you have found the category filtering useful. With the next version I have hit a stumbling block with very large tag sets: currently, the auto-complete loads all the tags onto the Write tab (in a hidden div). This is a major problem with a lot of (>1000) tags because it slows the page load time significantly.

So, during the restructuring of the tagging back-end and the live search filter (which I may extend to standard search at some point too in case things get too slow) I’m thinking of using an AJAX request to populate the hidden div so it only fetches the tags you actually need for auto-complete to function. Of course, if you choose not to use category filtering then all tags will still be loaded on the Write tab, but I figured if you made your bed like that, you can lie in it :-)

Your second proposal is something I never considered. Well, not in that form at least. I did go down the road of a ‘global’ tag group which is equivalent to your ‘god’ idea. Any tags in this group are available across content types and would not be in any category. Thus they would always be present and always available. Unfortunately, a major snag in the logic caused me to abandon that idea. Perhaps one day I’ll approach it with fresh eyes and it’ll be easy.

For now I think I’ll adopt your idea of adding an option to look both up and down the tree. That does make a lot of sense so I shall put it on the TODO list, thanks.

The other thing I need to fix in this department is what happens if you choose a bunch of tags from one category, Save the article, and then change the category. Currently the old tags are left dangling, still associated with the article. I think when you Save it just adds the new tags to the ones already assigned but there’s no way of removing the old tags short of selecting the original category and deselecting the original tags, then re-selecting the new category. I see this as a bug: I think it should delete the old tags when you save. Do you agree? Also, when changing category I should probably remove the tags associated with the old category from the box if you are using Textarea mode. I don’t think that happens either right now. Until you save, the tags are still ‘there’ (associated with the article) so it’s not a hard chagne until you commit to it, but it’s still an unexpected outcome, imo. I’ve definitely got some work to do in this department.

Thanks for taking the time to write about this. Your site seems like it was made for tagging so I’ll do whatever I can to get the new version in some usable state — even if it’s not on general release — and let you play with it.

aswihart · 2010-07-26 15:29:07

Thanks for your detailed response Stef. I can understand the slowdown that might occur with Autocomplete when you have thousands of tags to load, and I think it would actually be preferable behavior in that case to force the author to select a category first (category-association mode only of course) before you load the tags for Autocomplete to reference. You could either gray-out or completely hide the text box until a category is selected.

For not wanting to lose my tags, I will follow your advice about leaving the plugin installed when trying out the raw PHP. Maybe if you do in time come up with a new version you wouldn’t mind letting me play around with, you could just set those few Autocomplete options for me that I mentioned a few posts back. The Autocomplete autoFill: true option can be buggy and unusable when you have Quick Tag set to strict (inserts the same term multiple times, seems to only pay attention to the last character typed) .

Thank you for considering the option to look both up and down the category tree!

You raise an important issue about what to do with article tags chosen and saved from one category after changing that article’s category. One perspective is that if you chose those tags to begin with, they might still be relevant to the article you’re working on, even if they are not valid tags for the new category you’ve selected. But to avoid confusion and the kind of hassle you described in order to get rid of those tags if not wanted, I agree it would be best to automatically deselect the tags when changing categories.

Other more involved behaviors would be to a) leave the previous tags set and keep them displayed for manual deselecting, regardless of what category is chosen, or b) only leave the previous tags set if they are available in the newly selected category (e.g. a child of the previous category). I can imagine both of these behaviors would be tricky to implement, and again, automatically deselecting the tags on changing categories would be the most straightforward way through this “bug”.

curiouz · 2010-10-16 09:36:58

I’ve a problem with smd_tags 0.31 in combination with TXP 4.3RC1. When I try to delete an image I get the following error:


Fatal error:
Error: '' is not an integer
textpattern/lib/txplib_misc.php(613) : eval()'d code:474 assert_int()
smd_tags_multi_edit()
textpattern/lib/txplib_misc.php:655 call_user_func_array()
textpattern/include/txp_image.php:678 callback_event()
textpattern/include/txp_image.php:344 image_delete()
in /public/sites/www.circustreurdier.nl/dev/textpattern/lib/txplib_misc.php on line 2304

When I disable the plugin no error appears…

Last edited by curiouz (2010-10-16 09:37:55)

jpdupont · 2010-11-10 17:40:16

Hello …
On a fresh new 4.3.0 install, tags part don’t show if I have no categories …

birdhouse · 2011-01-15 18:05:06

Getting this error on the frontend using the SMD_tags plugin.

here is the error code:
Deprecated: Function split() is deprecated in /Volumes/Dev/TXP/birdhouseinteractive.com/textpattern/lib/txplib_misc.php(638) : eval()’d code on line 1396

Thanks for all the amazing work,
jason

birdhouse · 2011-01-15 18:06:11

Oh…and I am running php 5.3.2

thanks!

update –

And php was the problem. moving to 5.2 fixed it. Great plugin…thanks again.

Last edited by birdhouse (2011-01-15 19:58:40)

Bloke · 2011-01-16 12:46:22

birdhouse wrote:

Deprecated: Function split()

If you want to continue running PHP 5.3.+ then swap out any split() calls in the plugin for explode(). I don’t think I’m using any other deprecated functions (though I may be using ereg_replace, can’t remember, which is slightly more difficult to fix).

For those still waiting, this plugin is going to get some TLC soon because I need it for an upcoming project (hehe, no act is selfless, right?) The dev version I have is packed full of new stuff, but it’s still too slow to release as a product: I have some refactoring behind the scenes still to do to allow multi-edits to work more efficiently, and a couple of bugs to track down.

aswihart · 2011-01-17 22:26:13

Looking forward to it!

pieman · 2011-01-20 16:59:44

Hi Stef

Just spent half an hour investigating this beast. It’s quite immense – I’m looking forward to using it. Here are some hastily assembled thoughts. I haven’t tried the output tags, these comments relate to the admin usage. And some of it might be blown away by the new version you have in the pipes, but here goes anyway.

On the usability of Manage Tags

The role of the Create & Save buttons are kinda close and so are the buttons – it’s too easy to overwrite existing tags by clicking Save instead of Create.

How about this bit of disambiguation:

On page load the fields should be blank so you’re free to create your next tag at will.
- The Save button (now reading “Save changes”) is visibly disabled, because you’re Creating. The Create button (now reading “Create new”) is active.
Enter your tag title/parent/linked cat, hit “Create new” and the tag is added to the list. But the fields are now empty so you can jump back to step 1
If you want to edit an existing tag, you click on it first (or even better, an explicit ‘edit’ link next to it) to populate the fields. The “Create new” button is now visibly disabled, and “Save changes” is active

On autocompleting

As far as I can tell, with “Enter tags using: Text area” in your plugin prefs, without jQuery autocomplete correctly installed it’s impossible to add any tags in an article/image/file.

Autocomplete is good, but I expected clickable tags below textarea (like tru_tags), otherwise, where to start? Have I done something wrong or is this by design?

On tags tied to cats

If tags are tied to cats, when no cat is selected in Write tab (or file or image edit screen), all tags are shown.
- That gives the CMS user free reign to use tags out of context. I mean, if the site editor has grouped them by cat to apply some control over how their staff apply tags then this seems like a big hole in the firewall.
If tags are tied to cats, they I think they should be automatically linked to the cat’s children too, no?
- Often I use cats in a section-specific way. I realise this isn’t the point of categories, but sometimes it fits quite well. I’ll make parent categories (matching the name of the section that its children are meant to be used in. These parent categories aren’t meant to be selected, they’re masquerading as optgroup label="Section name", so it’s easier for the CMS user to see which categories are designed to be used within each section. In this scenario (which I concede might not be a widely used one) it would be useful to be able to tie a tag (and its children) to a parent category (an optgroup) and for those tags to be also tied to the category’s children.

I’m not going to even read that last one back to myself because I’m scared it might be nonsense. I can show you an example if it helps :-)

On infinite nesting of tags

Maybe rather than infinite nesting, have 2 tiers: ‘tags’ and ‘groups’.

Then if ‘group’ is tied to a Txp category, add a preference about whether or not to display the group name in the Write/Files/Images tabs. This is kinda optgroup-flavoured again.

eg. Musical sub-genres

Let’s say I want to be able to tag some mp3 downloads in the files tab according to musical genre, and I want to get geeky about it. I have a TXP file category called “Reggae” and want to show the sub-genres as tags when this category is selected in the Files edit screen.

In the current version of smd_tags I make some new tags for the sub genres (dub,dancehall,roots) and link each one individually to the Reggae file category. It works.

But now imagine it scaled up. I have 8 top-level categories, each containing 8 sub genres.

In the Manage Tags screen, the Reggae flavoured tags (all associated with the TXP file categories individually) are all mingled in with the subgenres of rock, techno, soul etc.

…
…
dancehall
detroit
disco
dub
…
metal
punk
rap
roots
….
…
etc.

You’d be playing Where’s Wally before you knew it.

To make it more manageable, how about this: I first make a tag titled ‘Reggae’. Then I make some new tags about the sub-genres of reggae and make them children of the Reggae tag. Having children turns the parent tag into a ‘group’ title. Now in the tag management screen you can see a hierarchy.

Reggae
–dub
-dancehall
–roots

Neater I think. Now we tie the whole ‘group’ to a category, and are able to set a preference that the group name shouldn’t be displayed in the Files edit screen. The view in the Files screen is the same, but the Manage tags screen is a whole lot easier to use.

Bloke · 2011-01-20 22:14:49

pieman wrote:

The role of the Create & Save buttons are kinda close and so are the buttons – it’s too easy to overwrite existing tags by clicking Save instead of Create.

Yes I’ve done that myself in the past so it maybe needs disambiguation. As an adjunct / excuse for the behaviour, my intention was to build the system for rapid tagging. The idea was that if you were making a bunch of tags you create one by typing its title (the name is auto created) and hit Enter. It’s saved as a new tag but remains in the edit window and focus is returned to the Title box. If you type another one and hit Enter you get a new tag. If at any point you assign a tag to a parent and hit Save the parent remains selected after Save and focus is returned to the Title box again. Thus any subsequent tags you type and hit Enter will all be created underneath this parent. The current credentials are also retained when you switch content types.

The upshot is that when you’re mass-creating tags you can just type a tag, hit Enter, type Enter, type Enter… and smd_tags repeats whatever last settings you had [EDIT: and the new version allows multiple tags to be created in one go all under a single parent by comma-separating the tag names]. If you are creating the same tags across content types you can just type it once, click to the next content type and hit Save / Enter and it’ll be created there too under the same parent (if it already exists, or at root if not). That was just a way to rapidly copy tags between types because I couldn’t figure out how to create a ‘global’ tag (moi? lazy?!)

When clicking a tag to edit it, the act of clicking it is the pre-confirmation that you want to edit it (hence no confirmation, even on delete) BUT to save it in the same slot after editing it, you must click Save. The Create button always trumps Save (if you use Enter on the keyboard). This default action also makes it fast to create new tags because you can click one that’s in the same group as one you know you want to create next, type a new name over the current one and hit Enter: all the other credentials (linked cat, parent tag) are cloned and you get a new tag.

Having said that I can look into your proposals and see if I can figure out how to retain rapid tagging without making it so easy to clobber your existing ones. Any further thoughts welcome in light of the above confession.

without jQuery autocomplete correctly installed it’s impossible to add any tags in an article/image/file.

Correct; at the moment it should allow existing tags only. Textarea+ mode allows new tags to be created.

Autocomplete is good, but I expected clickable tags below textarea

Yeah. That’s where me and tru_tags differ in outlook. A list of tags can be had using the List option and it works exactly the same as the clickable list in tru_tags, with the exception that you can’t add new ones. But the Textarea modes were originally considered to only be typey typey. As you say, perhaps not the most useful mode, but if the list of tags is large, typing a single character will give you some hints via autocomplete which I thought would be enough of a starting point.

Having said that, as it stands at the moment the list of acceptable tags are still loaded into the page because they need to be there for autocomplete to compare against. So there’s nothing stopping me making them visible in some manner.

This system does actually incur problems when the list is large — say you have a thousand tags. The page then slows down appreciably so I was looking into ways of using autcomplete via AJAX or something.

To me, a thousand tags ceases to be useful (who would scroll through them all to find the one they want?), but some people on the forum think otherwise so I should be able to cater for this eventuality, despite my own personal misgivings. Perhaps being able to choose Textarea & List as a fifth option might help?

If tags are tied to cats, when no cat is selected in Write tab (or file or image edit screen), all tags are shown.

Yep, that’s one of three known category bugs in the current version. The second is the other one you spotted: the fact that the child cats aren’t considered. I think both those are fixed in the next rev. The third which you haven’t found yet, and I don’t think is yet fixed, is that if you write an article, choose a cat, choose some tags, Save, then change cat and choose some more tags, the existing tags still remain in force (if you switch between cats after saving a second time you’ll see the old ones appearing highlighted in the List view). Gotta be a way round that somehow; just trying to figure out the best way to handle it.

Maybe rather than infinite nesting, have 2 tiers: ‘tags’ and ‘groups’.

Interesting. I’ve actually got some more work to do on the admin side tag list because the way it’s currently laid out (in a table, by either row or column) is actually pretty crappy for showing hierarchy. I got so engrossed in making it happen that I didn’t consider the implications. Stupid and short sighted of me.

What I’d like to do to remedy this is to offer a third display option: “new column (or row) when top level parent changes” (aka ‘group by’). Thus you’d get a list of tags exactly the same way you see them in the current TXP Category tab, except that each time the plugin hit a parent category immediately under root, it’d get its own column (or row if that’s your thang). I think that’ll be a lot neater and a lot easier to manage so I’ll give that a whirl.

I hadn’t considered allowing you to include/exclude the parent (on the Write/Images/File/Link tabs I assume?). I might look into that as well; it’s conceivably a common use case.

Also, choosing to sort the list either alphabetically or in a hierarchical manner on the relevant tab might be useful. Currently the only way you can see the hierarchy is if you choose ‘Select’ mode. If you prefer the List format then (I think) you get an alpahebtic list which destroys your hierarchy. Even if they were grouped with a dividing line or there was some other visual indication that a bunch of tags were in a group it’d help. I’ll have a think about that too but if you have any ideas here please throw them at me.

You’d be playing Where’s Wally before you knew it.

In the next version of the smd_tags pane there’s a Live Search feature. Type in the box to filter the list by either title, name, parent, category or ‘all’ of the above. And when you’ve filtered your list you can then choose to Delete, Assign to Parent, or Link to Category on the ones displayed. It’s very handy.

Thanks for all your thoughts. Always useful to make me think about exactly what I’m doing!

Last edited by Bloke (2011-01-20 22:27:33)

Textpattern CMS

Textpattern CMS support forum

#109 2010-07-24 21:40:06

Re: smd_tags: unlimited article, image, file and link taxonomy

#110 2010-07-26 01:55:39

Re: smd_tags: unlimited article, image, file and link taxonomy

#111 2010-07-26 08:09:03

Re: smd_tags: unlimited article, image, file and link taxonomy

#112 2010-07-26 15:29:07

Re: smd_tags: unlimited article, image, file and link taxonomy

#113 2010-10-16 09:36:58

Re: smd_tags: unlimited article, image, file and link taxonomy

#114 2010-11-10 17:40:16

Re: smd_tags: unlimited article, image, file and link taxonomy

#115 2011-01-15 18:05:06

Re: smd_tags: unlimited article, image, file and link taxonomy

#116 2011-01-15 18:06:11

Re: smd_tags: unlimited article, image, file and link taxonomy

#117 2011-01-16 12:46:22

Re: smd_tags: unlimited article, image, file and link taxonomy

#118 2011-01-17 22:26:13

Re: smd_tags: unlimited article, image, file and link taxonomy

#119 2011-01-20 16:59:44

Re: smd_tags: unlimited article, image, file and link taxonomy

#120 2011-01-20 22:14:49

Re: smd_tags: unlimited article, image, file and link taxonomy

Board footer