Adding an extra field to Post, and make that available in Display.

[darrenbeige]

I'm wanting to add a dropdown field to Post.template.php. I can generate the HTML and add it to Post.template, that's all fine.

What I am unsure about is how to then retrieve that data, when anyone is viewing the topic.

How can I do this? If possible, I'd love for the field to be editable afterwards, and via JS quick edit.

NOTE: I want it per-topic, not per-post, so I assume the topics table is something to do with this.

[Arantor]

You have to pick up the data in the Post.php file, where the rest of the form is grabbed.

Yes, it'll go into the topics table, meaning you'll have to expand on that table too somewhere.

Then you'll also have to modify Display.php to capture it when displaying the thread, plus Display.template.php to display whatever it is.

More details would probably useful.

[darrenbeige]

Sorry for not being clearer, but I'm trying to do this myself. I'll probably fail (and will then have the SMF community to fall back on) but for the time being, thanks Arantor.

[darrenbeige]

Well, I haven't got very far, and now I'm stuck. I've managed to hook into my db, and run my query, which returns an array of data. I use this array to create a select box which is now present and only displayed when starting a new topic (by checking if $topic is empty). The select is named 'related_article'.

That's how far I've got. I don't really know how to continue. Guidance is appreciated. From what I can see, I think I need to add another element to $topicOptions, and edit createPost() to accept the new option. Update the smf_topics to include an extra column (related_article). Then, I need to update some query in Display.php to make the added data available to Display.template.php.

Thanks,

[Arantor]

That's basically what you would do. Unfortunately I don't have access to the source to experiment as I'm not at home until next week

[darrenbeige]

No problem. I appreciate help at all. Should I be adding the new column to smf_topics or smf_messages?

[Arantor]

Depends on what the field represents?

If it's applicable to the entire topic, which it sounds like it is (given it's going in $topicOptions), it goes in smf_topics.

[darrenbeige]

Yeah its a per topic thing. Whilst other users are able to 'edit' the data (outside of Post.template.php), the data applies to the entire topic, not per message. In a way, its kinda like a very customized tagging system. (I know there is a mod for tagging posts, but I looked at it - modifying it to do what I wanna do would probably take longer than doing it this way, and this way I learn too)

What do you think is the best way of storing a list of data (eg array("item1", "item2", "item3")) in a mysql field? Serialization?

[Arantor]

Depends on the type of data it is, exactly. Is it a predefined list of tags?

[darrenbeige]

Sort of. The user can only pick from a list of different 'tags', but the list will grow in size as the content database increases in size. Equally, for manipulation purposes, I think leaving it as a serialized array is the easiest idea - I can then access the original array pretty easily.

It might help in the future if I explain what I am actually building. In a nutshell, its a system where a user can assign forum topics to content articles that exist on my main site. Therefore, in a section at the top of a topic, users can click through to the article (or articles) the topic is discussing (if any). By doing it like this, it also means I can perform a DB query from within my main CMS (handwritten), and display a list of related forum topics in the articles info.

In essence, what is being stored in the DB is basically an array of ids which correspond to the relevant articles, which will be parsed through the DB to retrieve titles etc.

[Arantor]

If you're doing that, don't even bother serializing it. Just create a table of tags, that contains the topic number and the tag - one row per tag.

Then when you query, you just query that table where the topic id matches.

[darrenbeige]

Its impractical. It's much easier to do it the way I'm intending. I don't know if I explained it correctly to you, but to me this seems pointless, when I can just add it to another column in the smf_topics table.

[Arantor]

Adding a text field to one of the busiest tables in SMF is widely impractical in performance terms. A straight join on primary key is much faster.

[darrenbeige]

I never really thought of performance. Thanks for pointing that out. Whats a good way of cloning a select and inserting it directly below the previous one? (Javascript obviously)

[Arantor]

Again, depends what you're trying to do.

If you mean copy a select (and give it a new name in the process, at least if you hope to store it), your best option is actually to create a new one, iterate through the contents of the existing one, then attach those to the new one, if that makes sense. Should be enough examples of doing that visible from Google (I don't have any examples I can drag out right now)

[darrenbeige]

For interest only, why would adding it to smf_topics make it so much slower? Adding one text field (varchar 60) surely can't it slow it down THAT much? Remember, I will be using this field regularly in the same places as where smf_topics are loaded anyway. Plus, whilst the fields may be modified occassionally its not going to be a majorly updated field.

For the JS clone of a select, I have a working function in Firefox, but haven't tested in any other browsers yet.

[Arantor]

Actually, yes it would, since it's still more data that has to be moved through whenever the topics table is being involved, which is in loads of places (offhand, board index, message index, thread view, recent posts, stats, who's online, print view)

Being updated regularly or not isn't so much of an issue, but the more you have in a table the slower that table by definition becomes; if it's a fixed width field (like a numeric column) it's not quite so bad, but if it's variable width it's another field MySQL has to step through to calculate length to the next row.

Where are you planning to use this? If it's just in message index and display view (and not print view), I'd suggest you keep it in its own table, especially if you build it as a true many-many relationship (i.e. tags table, topics table, topic_tags table, where only the first actually holds text in this case)

[darrenbeige]

Currently, I'm probably using this field:
        - Display.php
        - RecentPosts.php
        - MessageIndex.php (if I can make it fit nicely)
        - Print view (topics only)
        - BoardIndex.php (planning a section below RecentMessages)
        - Elsewhere in my main site : article view, category view

I've made a decision. I'm gonna stick it in smf_topics for now, and see if its THAT much slower (anymore than 1/4 of a second is an issue), then go from there.

Regarding checking if Post.template.php is a new topic or not, checking if (empty($topic)) does not work if I'm replying to a topic that has no replies already. How can I prevent this from happening?

[Arantor]

Check to see how in Post.php and Post.template.php how it gets the subject; if there's a subject on starting the template, it's a new topic invariably.

[darrenbeige]

Check to see how in Post.php and Post.template.php how it gets the subject; if there's a subject on starting the template, it's a new topic invariably.

Thats what I did. In Post.php, the value is set here:

Code Select Expand

elseif (empty($topic)) {, however running that in my code (Post.template.php) returns true if the topic has no replies. I have counteracted this by setting a variable in the elseif and checking for that variable in Post.template.php