Posted by ponyxprs on April 2, 2013 at 5:20pm
For this new project, would it be better to use the existing node in core or create a custom entity for forum posts?
-
existing node uses extra tables to add forum functionality and tracking, this adds table look ups and updates
-
a custom entity couild be made to hold all data in one table row per post, but do we lose some traditional Drupal functionality with other modules if we don't use the built in node?
And what should be recorded per post?
I firmly believe poster IP address needs to be recorded. Can we have core updated to include this for all nodes as well? Or wil we have to record this just for forum posts?
John
Comments
Node
Good question, as there are still a lot of modules which are supporting nodes only and among those there may be some, which are crucial to forum community.
Yep, it will add lost of extra overhead, but if I need to choose to develop an extra module or just upgrade VPS - I will just do that 99 times out of 100
drupal+me: jeweler portfolio
My personal vote would be for
My personal vote would be for fieldable entities. Compared to nodes they have little to no overhead and on large to medium sized forums lookup time will be a major issue.
The one functionality entities are missing at this point is version control. I can see how this feature could be useful for some site developers - on the other hand this function is currently lacking on many other forum solutions as well, so it doesn’t feel like a deal-breaker to me.
Of the many modules which support nodes only we would need a list to see which of them make sense to use in a forum environment. That said... to me it seems as if entities will be the future of drupal in the long run and seeing this is not a project to be finished in a week’s time we should take that into account.
What should be recorded?
I would say the bare minimum of what’s needed to get the forum up and running plus some normalized data to help with the lookup time. User can add more fields depending on their own needs and as they see fit and modules can expand the schema with fields relevant for their particular functionality.
+1 for fieldable entities, as
+1 for fieldable entities, as this is where the future is.
Isn't it the point of Artesian
Hi,
Did you take a look at "Artesian" project, by Michelle (sandboxed in http://drupal.org/sandbox/Michelle/1361070)? Wasn't it the point of http://drupal.org/project/brain_forum as well?
Yes Artesian has been
Yes Artesian has been discussed, however Michelle has stated that for now she does not have the time to work on it, and it may be some time before she does.
@ Brain_forum, my understanding is that it is unfinished, and original devs do not have time, due to other projects.
What's the benefit?
I've been dealing with fields and entities lately. Currently I cannot see a clear difference between a fieldable entity approach and the node approach. The first - obviously - involves more coding, of course. What's exactly the overhead of nodes compared to fieldable entities?
My vote goes for non-fieldable entities. Strict stiff table structure. I'm not sure that even entities are needed. Strict table with views api support would do just fine. Optimal approach from a performance perspective.
Well, it will be fast as
Well, it will be fast as lightning, but:
-If posts are table rows, then we are throwing 100% of all node/entity related Drupal modules out of the window
-If posts are entities - then maybe 20-50% of all usable modules will be available, as most are too little maintained to be rewritten for full entities support
-If posts are nodes - then all of them are ready for you
Exactly the opposite is about the speed... Well, as for anonymous readers - it will be no problem, as there are many caching solutions available
drupal+me: jeweler portfolio
Speed is of importance.
Speed is of importance. Members will not wait around forever waiting for a topic to load, no matter how good the content is.
I am not sure how the speed compares, but you have 2 queries compared to only 1 . Will it matter? Not sure?
As far as strict tables,I'll guess the fastest, but what are we losing. What really needs to be part of a forum post? If it is a 'minimal' entity with only the necessary fields, it should be efficient.
What modules would need to interface with a forum post?
Queries count is not
Queries count is not important - it is important the front end speed. If a properly tuned drupal page takes 1second to load for registered user, 1 extra select query (with indexes) will be less than 1% of difference.
Currently I am using BOA Nginx, which really made me believe, that drupal can be really fast.
drupal+me: jeweler portfolio
A Question of Speed
My major concern with the speed right now is that we have no field experience with forums build entirely with nodes. While we can make educated guesses if such an approach would slow down large forums or not, we can’t tell for sure.
What I see is that traditional forum solutions go to a great length normalizing data just to avoid additional lookups and joins and while we may not want to follow their schemas too closely we have to admit that they have years and years of experience developing forum software we don’t. In the last months I have been looking through different forums and of those I studied all normalized data to a certain degree. They wouldn’t have added those and stuck to them if they wouldn’t expect some performance advantage.
Where does that leave nodes which have all their fields in different tables? Can’t be ideal.
I will admit I can’t predict if the entity solution would be x% faster than the node solution without having extensively tested the both of them. Maybe the node approach is perfectly alright. And here is my problem with it – the ‘maybe’. We know entities will be faster than nodes. How much? We can’t exactly tell, but with entities we are on the save side and that is for certain. Caching is all nice and good but I would rather write code I know is fast opposed to one caching and a good server maybe make perform alright.
With the amount of time coding a forum takes I am not sure I want to rely on a ‘maybe it will be alright’.
Unfortunately nginx is not
Unfortunately nginx is not offered everywhere. Unless this forum, and Drupal really, can run quickly on your basic shared server with apache/php/MySql the user audience will be small. I am not saying it has to run on a free shared host with minimal resources, but it shouldn't need a VPS either. And secondly, let’s think about the "use" of a forum post. When a user posts a message to our Drupal forum, bedsides having it a post in a forum, what else do we want to be able to with that information?
John
I will stop here. In my
I will stop here. In my personal opinion, the most important things for successful online forum (community) are in this order:
1. People-members. You cannot build an community site if nobody visits it. It is CMS agnostic, so Drupal has nothing to do with it.
2. Ability to engage members: polls, "hot-posts", "most active users", "who is online", "what articles related to this forum post", "other most similar threads","user who visited this post also visited this one", "most replies this month" and so on. If all the modules capable doing this are ignored - It it not worth more than existing Vanilla forum bridge.
...
...
...
15. Ability to run on shared hosting. I do not see a problem investing 20$/month for 2GB RAM VPS and configure it for speed of my particular installation, if already invested many hours into developing a site. There is no need for another empty crappy unmaintained forum site.
Anyway, there is a great example of Commons installation, they managed to do most (but not everything!) community things just right. Sadly it is not based on pure forum concept, but can be a great stating point.
This is my personal opinion, and I am building couple of forum related communities on OG, and most of things are working pretty much better than I expected.
drupal+me: jeweler portfolio
I agree with #1, and will add
I agree with #1, and will add content to that. However i do not think #15 (run on shared hosting) should be so far down the list
Can you share the link to the commons example?
John
I have no particular example,
I have no particular example, but if you download latest 3.x installation package of Commons and try it - it may seem as a good starting point. When my own production-ready examples will be ready, I will post in this group that is for sure.
Yep, shared hosting for community is not an option. You will be kicked out for server overusage anyway as your forum starts to grow. If we are talking about 5-10 post per day forum, then I am taking my words back as this is not community and can be run even on Raspberry Pi.
drupal+me: jeweler portfolio
+1 for fieldable entities.
+1 for fieldable entities. Forum has lots of nodes (threads) I'd like to keep aside from the other content of the site. But additionally to that forum has a huge amount of comments that in case of nodes will seat in the comments table. I wouldn't like that to happen.
I also believe fieldable
I also believe fieldable entities would be best, as that would fit in to drupal's base structure best
Even if speed is an issue and the storage is a key factor for a good forum, I don't think this is the main issue about building a great forum. The most important part of building a forum is the user, administration and moderation interfaces.
I've been using many kinds of forum software all over the place, and what differs a bad and a good forum is the manageability.
The possibility to create good rights management and maintainability in a easy worked way might be the whole key to the best forum software. If this part is great, the speed can always be worked on.
Other than the basic fields
Other than the basic fields needed to record a forum post, what fields do you think we need? I can see something for a Poll, and file attachments, I could be missing something though....
John
Ok, if we go with an Entity,
Ok, if we go with an Entity, the following modules need to work the Entity as well:
(Think basic for now, we can work on anti-spam and other stuff as we go)
Pathauto (Pretty URLs)
XML Sitemap (for ease of search engine indexing)
Meta Tags (Search engines as well, but becoming less and less)
It will need a WYSIWYG editor
Flags (to report innapproprate content)
What else?
John
In no particular order or
In no particular order or importance also:
Userpoints ecosystem, Radioactivity, Recommender API - I hope it is still maintained, Search API, Context/Panels, Display Suite, syndication and aggregation ones, Clean Pagination, Localization and related, Entity cache, Field validation, something to insert picture into wysiwyg textarea, Quote, something to notify on email, Fivestar or another powerful voting module, social buttons, all the most popular Views plugins, Statistics - preferably something which will work in heavily cached environment and count with JS, Sub-pathauto, Redirect, Token, Boost/Varnish/anothercache, also whole bunch of access-permission related, Field Permissions, JS callback, Mollom/Spam if posting allowed for anonymous and or course the kings of all the moderation related tasks: VBO and Rules.
Some of them have full, some partial, some no support for entities.
drupal+me: jeweler portfolio
Thanks, I will have to look
Thanks, I will have to look into those
John
Did some sorting
Maybe we can compile a list to see what works and what doesn’t? I tried to some basic categorizing as well as add some module which came to my mind, but some others need more researching.
The following modules work with entities without modifications or add-ons:
Entity Cache, Entity Reference, Field Permissions, Field validation, Fivestar (since D7), Flags, Meta Tags, Radioactivity, Search API, Rules, Vote up/down, the majority of field modules
These work but could need some additional code:
Views + VBO – out of the box views can work with entities in a generic fashion, if the entities are properly described to the Entity API views will be able to work with entities in a more useful way.
The following modules are/seem unrelated to either node or entity content:
Redirect – redirects to a url, no matter the content
Varnish/Boost – I could find no limitations saying it only works with nodes, but I could have missed it
Limited entity support
Pathauto/Sub-pathauto – there seems to be basic entity support, but if the issue queue is any indication it is still somewhat buggy. We would need to test that.
The following modules are supposed to be extended by other modules to integrate with their functionality the way OG and some other modules do:
User Points, Recommender API, Mollom
-> hard to say how much work this kind of integration takes though.
No entity support
XML Sitemap
Statistics
Quote – not working with entities, but won’t work out of the box with a node based forum either unless we want to redublicate the node + comments approach of the core forum.
Other
Tokens – The entity API can provide tokens for entity fields – if there are other requirements regarding entity tokens we should discuss it.
I hope that will help sort the list out. If I made a mistake somewhere let me know :)
Christina
Nodes
I'm gonna put a vote in for nodes just because that would be different. LOL
forum + notifications and responses
I'm not sure if this is the best place to ask this question, but would we want an architecture that can support email notifications and forum posts / responses via email and, if so:
Would there be a reason not to try to use or adapt existing modules?
If using / adapting existing modules, do any of them work with entities?
There are still people who are used to email-based listservs and a forum that can support emails can provide the best of both worlds and could allow people to finally migrate away from listservs.
Jonathan Sibley
Personal & Executive Coaching and Psychotherapy
Helping people to do better, be better, and feel better
I had some experience with
I had some experience with this with phpBB's mail2forum MOD(as a forum admin). If I remember correctly, outbound from the forum was pretty easy. It was the inbound that was tough to configure. If I recall, you needed an e-mail address for each forum and maybe a cron job picked up the mail, maybe.... It has been 10+ years since I played with that. it might be worth looking into again. you can put in a feature request here http://drupal.org/sandbox/ponyxprs/1959196 but it will be towards the bottom of a ever growing list, but it will be a heads up for potential features.
Also if anyone would like to add to the feature requests, feel free to add one. Sometimes you can get caught up working on something and forget about something else. Even if you think it is a basic feature, add it.
Forum notifications can be
Forum notifications can be made with Message module.
It is not out-of-the box, but very suitable module for activity related events
drupal+me: jeweler portfolio
Ability to email to a discussion is critical my purposes
We use listserves for our discussion groups and would really like to move to something that would have a better web experience (community or bulletin board), but we cannot do that at the expense of the ease of someone being able to communicate via email. Being able to choose to send and receive emails from a discussion group is essential for us.
Lots of our users are older and want things dead simple. Remembering a password is an obstacle for many of them.
Sorry, meant to reply to "forum + notifications and responses"
Post Schema
Can we talk about what data should be recorded in a post already? Should we open a new thread for this discussion?
I guess we can start at this
I guess we can start at this topic => http://groups.drupal.org/node/292418