Tags

[michaelcullum]

Allow tag creation, search by tags etc.

[imkingdavid]

Currently, I don't see how tags are linked to blog posts. How do we plan to do this?

[michaelcullum]

Tags will have a tag id, a list of tag ids will be attatched to each blog article, I'm not sure how much of that has been done.

[imkingdavid]

@erikfrerejean let's discuss tag implementation here.
@unknownbliss right, but we're not going to be doing the comma-delimited string on the blog post table.

Should we instead do something like a "tag instances" table or something (similar to my TMM mod that has prefix instances to allow parsing tokens within prefixes attached to specific topics)?

In other words, the table would look like this:
phpbb_blog_tag_instances {
tag_instance_id INT(whatever) AUTO_INCREMENT NOT NULL PRIMARY_KEY,
tag_id INT(11) NOT NULL DEFAULT 0,
blog_id INT(11) NOT NULL DEFAULT 0,
}

The query (I haven't had a chance to sit down and figure it out specifically) would basically select all tag instances that have the blog's ID, and then join them with their corresponding tag details on the tags table.

Does that make sense or am I overthinking this?

[erikfrerejean]

That is the thing I'm thinking of, but drop the tag_instance_id column as it doesn't add anything. This table is simply used to cross reference blog and tag IDs. When adding a key to both columns it should be sufficient quick enough. Then indeed in the "load" method for posts join the tags table to the posts data through this lookup table to find the proper tag IDs.

So without that column I'm +1 on this proposal. We can always "fancify" it down the road if we feel like ;)

[michaelcullum]

Oops, didn't see this:

#66 (comment)

[michaelcullum]

I never said have a comma separated list. I said on the UI side the user creating/editing the blog post would enter a comma separated list. They've got to enter it somehow.

As erik said, drop the tag_instance_id. Not all tables need a primary key. But add a unique key for the two columns.

Not a complicated query. SELECT the tag_id WHERE the blog id = blog_id. Then a loop for each row, then it would be the array of tag ids for that blog id. Vice versa would give a list of blog ids where that tag is used...

[erikfrerejean]

I never said have a comma separated list. I said on the UI side the user creating/editing the blog post would enter a comma separated list. They've got to enter it somehow.

Use a "multi select box" for that. So the user can simply select the tags. Manually inserting them is a pain.

[michaelcullum]

What about when users want to add new tags? We don't want tags to become like categories and be ACP managed.

[erikfrerejean]

Just use a system like "labels" here. Make the last field a text area which is used to create new tags (yes might be a pain to get to work non-javascrip, but for those we can fall back to the "full manual" version).

[michaelcullum]

So you propose that we implement the comma based system and a JS one? That contradicts your point? A commas based user input system would probably be easier to code than a labels system like the one on here....

[erikfrerejean]

So you propose that we implement the comma based system and a JS one? That contradicts your point?

Sure it does technically speaking as there isn't a change in the way they are handled in the backend. However seeing from the user a comma based system is a pain and really shouldn't be used anymore (its just there to provide a graceful fallback for those of us that don't have javascript enabled), the fast majority of users shouldn't be bothered with such a system though.
Needing to do something like that manually just creates a mess of tags (capitalisation, typo's, which tags did I already have? etc)

A commas based user input system would probably be easier to code than a labels system like the one on here....

Hardly the "hard" part is the front-end which with a bit of help from jQuery shouldn't be that awfully hard as well. On the back-end the two will be handled exactly the same.