Re: [ADDON] Articles
Reply #3 –
I thought about making an article / page system a while ago... (Never started developement, just a litte bit of brainstorming)
I'd extend the topics table with a column "topic_type" in order to identify the type of content.
1 = normal -> default topic layout
2 = blog -> blog layout
3 = static page (blog layout, but marked locked,'cause I don't like comments on static pages )
..
You could load various DisplayTemplate layouts depending on the type... the boads table could additionaly be extended with a "default_topic_type" column, thus you can "force" blog topics depending on the board the topic was started in...
Re: [ADDON] Articles
Reply #4 –
This is something I've worked ab it with..in my experience adding the type to topics can quickly get confusing, since blog posts AND normal posts share boards. I started with that in ViennaBBS but I opted to use rather a "boardtype" value in Protendo, so entire boards is one "type".
I did set a topics "type" too..but thats for custom actions wanting to use topics as "comments", linking them togheter that way. So far I think admin should just tend to where these "comments" topics reside, so I am not locking them to entire boards.
But for different topic types(articles, blogs even galleries for my part) work better as board-based I think.
Re: [ADDON] Articles
Reply #5 –
There are some issues with using too many boards, though, namely that {query_see_board} becomes a surprisingly large overhead if you're not careful. It's not bad on < 100 boards but it soon escalates when you start using other things as boards too.
Not to mention managing all the types of boards when you're getting into the realms of potentially allowing other users to create boards as well (without having access to the full boards management area), e.g. giving users a blog board each if they want, you need to be able to let them create it but only in the place(s) you want them in and not to be able to mess with anyone else's board(s). It's a complex task, doubly so if you want per board permissions to function for those...
Re: [ADDON] Articles
Reply #6 –
I am not looking to be a blog like that, it will be a blog only in the sense of presentation, that is, all other things are maintained as before. Full freedom for admin to set it up as they wish. If they want blog setup automatically I see that as a mod rather.
In that sense my added fields are only checked when fetching boards, and even have a switch to be ignored in boardindex if they choose. it will still follow through, so the template can make use of it and render the non-forum boards different if they like. For the custom actions fetching topics, they do it in a blog way mostly, that is: latest topics like a blogroll and only fetching the board names as "categories". It will be a large list of course, if they have many boards, so I am working to have some ways to solve the presentation of that. But the big query of boardindex is the same, minus the check of boardtype, and not at all when entering blog/gallery/etc areas.
Re: [ADDON] Articles
Reply #7 –
That's the thing, though... it's not just board index where this stuff is a problem. It's everywhere you have query_see_board which is in many places, not just the board index. It just so happens that the board index is the place you generally hit the pain first and foremost. But you hit it with any page load to any board, any topic, or any page where the URL contains either board= or topic= (e.g. action=dlattach)
The reason it's a pain point is because of what it contains, which is to say a WHERE clause consisting of b.id_board IN (1,2,3,4,5,6,7,8,9,10) for every single board you can currently see. Which means it's going to be optimised by MySQL into, effectively WHERE b.id_board = 1 OR b.id_board = 2 OR b.id_board = 3 etc. which means sequential tests on each row of the boards table that you're touching. (Which means, incidentally, the level limit clause is even MORE important on the board index than we might otherwise have thought.)
Too many boards, regardless of anything else, is a bottleneck.