Adding a field to a table and accessing from a template

[ForestForTrees]

Hello,

I've done a little modification on my test forum that seems to be working, and I'd love to get some feedback to see if there might be some unintended consequences from it.

Basically, I added a pair of extra columns to a table provided by the XenTag Addon. These two columns store a link and some anchor text for each tag. These fields are accessed via the following XF Template code:

<xen:if is="{$tag.link} AND {$tag.link_text}">
<p>For more information, visit the following wiki page: <a href="{$tag.link}">{$tag.link_text}</a></p>
</xen:if>

The end result looks something like this:


From my perspective, the code works great. It's super simple, which I really like, and it allows me to add links to wiki pages from our tag pages - something that I've wanted for a while. I just wanted to get feedback from some more experienced developers about whether there might be some unintended consequences to making this change.

I'm aware of some serious shortcomings of this approach. Most notably, there is no way to add either the link or the link_text from within the XF software - I'll have to access MySQL some other way. I don't mind this, though, and would probably put all of the links in in a half hour using phpMyAdmin, so I'm not looking for feedback on that.

Basically, the code is running on my test forum and does exactly what I want it to. I'm just wondering if there is a serious problem that I haven't thought of. My gut says that if I am altering tables directly, that is something I should do only very carefully.

 

[ForestForTrees]

I forgot to mention the code I used to add the columns to the table. Basically, I just made them varchars. Here's the code for one (the other is similar): "ALTER TABLE `xf_tinhte_xentag_tag` ADD `link_text` VARCHAR( 300 ) NULL DEFAULT NULL ;"

 

[Paul B]

It's not the recommended way of doing it but it shouldn't cause any issues.
You will just need to be aware of any potential conflicts with future updates of the add-on.

 

[ForestForTrees]

Thanks Brogan, that is what I was expecting/hoping to hear. (It was easy to guess that it wouldn't be the recommended way as it's so hacky.)

How would the recommended way be different?

Side note: I just realized that as a precaution, I'd prefix the new column names, calling them "tw_link" and "tw_link_text" rather than just "link" and "link_text." It's too late for me to edit my original posts, though.

 

[Paul B]

Doing it properly would involve creating an add-on which extends the original add-on, allowing the fields to be populated programmatically or via a UI.

Prefixing the columns is a good idea as it is less likely to result in conflicts in the future.

 

[ForestForTrees]

Thanks.

There is already code in the addon to edit the tag descriptions, so I could extend that to possibly add an easy, permission based way for some users to add the link URL and link text for each tag. I haven't looked into it, but the tag descriptions are stored exactly the same way as the two fields I edited, so hopefully it would be a quite simple modification to allow people to edit three fields with the same code (i.e. tag description, tw_link, and tw_link_text) rather than just one (i.e. tag description).

 

[Paul B]

In its most basic form it would require:

• a template modification to add the new fields
• PHP code to handle the content entered in the fields
• changes to the datawriter to store the content in the database

Adding permissions requires more code and changes and would add a level of complexity.