News:

Wondering if this will always be free?  See why free is better.

Main Menu

Writing modification, looking for advices

Started by jolly_roger, December 14, 2013, 05:19:47 AM

Previous topic - Next topic

jolly_roger

Hi everyone.

I am looking for assistance with writing an SMF modification. A friend of mine asked me to help him adding new feature to the SMF forum. I used to work with SMF forums a lot, but that was years ago and I already forgot everything :)

So, the mod I am working on would allow forum administrators selecting groups with restricted access to certain boards. Which means, members of those groups will be able to see or reply only topic created by them. While I don't currently have questions about implementing it, I'm concerned about sticking with SMF coding standards.

For instance, I've added a new column, called restricted_groups, to the boards table, which will actually hold an imploded array of group IDs (quite similar to member_groups field). So, the questions are:

  • As far as I learned, SMF mods are installed by modifying SMF core files (according to the rules in XML files). In this case, is it fine if I'll modify default database queries? For instance, I would like to add my column to the board query for the board editing and board index pages.
  • Is it actually a good practice to add columns to basic SMF tables?
  • Also, I would like to add new elements to the ManageBoard page. To achieve this, my mod modifies ManageBoards.template.php within the default theme folder. Is there a way to automatically add these options to all themes that have their own ManageBoards.template.php template? I'm thinking about regex, but the template structure may differ a lot

Thanks everyone in advance!

Arantor

The problem you will have is that it is not possible to enforce the way you think it will be.

The number of queries you will have to change, not just in the manage board area, but anywhere the directive {query_see_boards} is used is surprising, not to mention costly in performance terms.

Depending on the exact nature of what  you are trying to do, the SimpleDesk mod may be better suited.

jolly_roger

Quote from: Arantor Beeblebrox the First on December 14, 2013, 10:31:38 AM
The problem you will have is that it is not possible to enforce the way you think it will be.

The number of queries you will have to change, not just in the manage board area, but anywhere the directive {query_see_boards} is used is surprising, not to mention costly in performance terms.
Thank you for response. I understand that the amount of queries that needed to be edited is huge. Actually, for this moment I've already changed most of them (like search results, recent posts, unread posts, user's posts, board/message indexes etc) to additionally check if the user's groups are not restricted to see messages within the board (or, if they are, ID of member who started the topic should be same as current user's id). It is based on FIND_IN_SET (similar to query_see_boards), does it really slows down queries? I doubt there will be huge amount of groups.

Quote from: Arantor Beeblebrox the First on December 14, 2013, 10:31:38 AM
Depending on the exact nature of what  you are trying to do, the SimpleDesk mod may be better suited.
Thank you, I'll recommend him checking this modification. My friend is running a forum for his World of Warcraft guild. There is a board for applying to the guild so he would like to let the applicants see only their topics within this board. Sounds like SimpleDesk may suit his needs.

Arantor

Yes it is costly. I've already been down this road before and the performance changes are surprising, even though I actually rewrote the code not to use FIND_IN_SET in the first place to cut out one of the performance bottlenecks.

The problem is that while you only have a few boards that have this restriction, every other board also gets penalised.

jolly_roger

Quote from: Arantor Beeblebrox the First on December 14, 2013, 02:39:37 PM
Yes it is costly. I've already been down this road before and the performance changes are surprising, even though I actually rewrote the code not to use FIND_IN_SET in the first place to cut out one of the performance bottlenecks.

The problem is that while you only have a few boards that have this restriction, every other board also gets penalised.
Right, it makes sense. Is there any other way? By the way, if the second argument of FIND_IN_SET is empty (it's empty if restrictions are not set for board) would it still badly affect performance? Currently I have to create FIND_IN_SET condition for every member group: group ID as first argument, imploded array of restricted groups of board as second argument.

Arantor

That's why I suggested SimpleDesk; it doesn't use boards or topics (and thus doesn't have to deal with the usual headaches) - I spent a lot of time working on it to make sure it doesn't have the performance headaches that SMF does.

FIND_IN_SET is a construct you should avoid wherever possible because it ends up making every query a row by row table scan rather than using any indexes. It's something SMF has always done and will be phased out in 3.0 (I would have phased it out if I'd joined the dev team more than 3 months ago!)

Advertisement: