What do YOU expect from the next major phorum release?

We are currently discussing on how to go forward with the next major release of phorum.
How we should build it, what should be included, what should be possible with it.

Therefore we are asking for your opinion:
What would you like to see in the next major Phorum release?

If you are a (module or other) developer
What kind of extendability, integration or other development support would you like to see in Phorum?

Just dream wildly ;-).

---

Thomas Seifert

Are you referring to 5.3, or one beyond?

Obviously beyond.
I'm referring to Phorum 6, 7 or whatever the next major version will be ;).

---

Thomas Seifert



Edited 1 time(s). Last edit at 11/12/2012 08:26AM by Thomas Seifert.

The main thing I'm hoping for is a database design that can support metadata for each post or thread, allowing users to rate, like, +1 or whatever you want to call it. The core rating system should be able to be overridden by modules for maximum flexibility.

[Speaking of which, I'd like a module interface that can create a table in the DB for its own data]

If Phorum can nail capturing this data in an efficient manner, then we'd be able to write modules such as "recommended threads" based on User A liking a lot of User B's posts, therefore User A may like some of the posts User B has liked. etc etc.

It also means Phorum communities can foster their own "reputation" metrics, especially if there is provision to downvote, unlike etc.

If the design for the ratings were made a bit more complex than just a numeric value then tagging could be implemented too.

If this is of no interest to the developers, then I would just ask that the bare bones be put in and module writers will do the rest. The current offically approved mechanism of storing metadata against users / posts etc is via a serialised field, which is no use for SQL queries. (that was the situation the last time I looked into writing a rating module anyway - maybe things have changed?)

I sincerely believe a flexible rating / tagging system built into the Phorum core would yield a host of genuinely revolutionary online communities - it would just make the ordering and filtering of posts so much more sophisticated.

/\dam

--
My notable Phorum sites:
Movie Deaths Database - "review comments" system mostly powered by Phorum
Learn Chinese! - integrated forum quiz

...and, from an admin maintenance point of view - upgrades to core and modules via the admin interface would be awesome.

Having said all of the above, a complete rewrite would worry me, as if it were too radically different then it could take module writers years to port existing modules. I'd hate to see our project community fracture between old and new versions.

/\dam

--
My notable Phorum sites:
Movie Deaths Database - "review comments" system mostly powered by Phorum
Learn Chinese! - integrated forum quiz

OK, totally random free-form thoughts from a developer perspective:

Although I am not huge fan of MVC, a platform like Phorum would actually greatly benefit from it. I would agree with your other post that Phorum could go in that direction (maybe I would elevate "could" to "should").

With more investment in MVC, I would do away with the silly template language and just work in views coded in PHP with a much richer API, and with an investment in OOP, the subsequent object model. It would not be overly difficult to write conversion scripts that could translate legacy templates into views.

Create a more intelligent module registration and installation system that does not require admins to create profile variables or actually do anything accept agree to install the module. Along the lines of what Sheik discussed about table creation and/or meta data definition, I would suggest a way more complete process in the core that defines a declarative method for developers to specify their storage needs. Module developers would then be discouraged from module code that creates tables or otherwise changing the DB layer themselves, because they can specify in a manifest what table(s) are required for their module, and in addition introduce a higher level concept such as an extension to a user profile, which is handled as an actual field (with data type) rather than meta data. There are probably a number of other similar higher level data storage concepts that could be supported similarly (partial list: Application, Forum, Thread, Topic, Event, etc.). An API available to module developers would allow us in our code to interact with our storage, rather than rolling our own DB code or using Phorum's DB interaction code (which IMO should be considered core and off limits). So storage specified in a module manifest, created by core during module installation, and interacted via module-specific API in our code.

OK, this is way out there, but here goes: most module and template (in the future views, right?) development can occur in essentially a glorified text editor (my favorite for these purposes is Komodo). That being the case, a developer UI provided in the Admin section would be very useful. It could provide lists - organized by core section - of hooks available to the developer with function prototype info, and I just select the one I want and the spiffy editor places a function block in my code, updates my info.txt (or the new improved manifest file) and I type merrily away in the code block. Same thing for core and module-specific API calls, and as well object model core objects. I know the core code very, very well, not because I really enjoy reading PHP by the fireside, but because I constantly search near and wide for useful functions and hooks in the core. Not everyone is as OCD as me :). This idea kind of eases the burden on API/hook documentation by the way. Let the system self-document and expose these things to us developers in this fancy editor.

Elevate event logging to the core and provide an API that can be used by modules to display their own events in their own settings pages.

Feature ideas

Make Google and Bing anaytics/webmaster tools ID's configurable to the Admin as part of the core, not dependent on a module/template. Also make population of forum and topic page titles / descriptions configurable (also part of the core) rather than up to the template designer or a module writer.

Social media sharing needs to be really fleshed out. It does not belong in the core, but a really robust and API-rich extension is needed. There are so many ways a forum integrator could use it beyond the simple Like buttons and tweet this post and such. There are too many use cases for a developer to anticipate and create "features" to please every Phorum admin. I like the idea of a social media extension defining object models and APIs available for module developers to build on top of. If Phorum shipped with a social media extension module, I believe module developers would use it to add more actual social features. Without the extension module, the learning curve, not to mention the amount of code that has to be written, is too much.

You did say dream wildly.... (Where's korsakov??)

I personally wouldn't make any 3rd party analytics part of the core. That kind of functionality screams "module" to me.

I like the idea of a Phorum-approved social media module to show the rest of us how it should be done!

Returning to the idea of upgrades via the admin, I was recently impressed with how Lemonstand (an ecommerce product) accomplishes this. So far it's seemed very painless. Lemonstand also has a dedicated procedure for module writers to alter the database semi-automatically (you just add your SQL to a config file).

/\dam

--
My notable Phorum sites:
Movie Deaths Database - "review comments" system mostly powered by Phorum
Learn Chinese! - integrated forum quiz

To be honest, in my opinon the core shouldn't be changed, it works perfectly?? Only code improvements for newer php/mysql versions, keeps phorum core clean and future-proof.
Please, dont upgrade because of upgrading, don't create another phpBB forum:)

The module system and using hooks, took me a while before i did understand the basics of it. Untill that moment, i did not realize how powerfull Phorum really is.
Apperently, you dont know what to improve in next versions, so you ask the users. It just means, you did a really good job!

For me, i just can think of 2 things to think about:

High priority:
Extend the documentation in a way, less experienced scripters can understand better, with howto code-examples.
I myself, have spent many, many weeks to get things done. I have got perfect support here, but i really think that most answers i got, belong in the documentation.Could save the developers team a lot of time.

Low priority:
Mail system: i do like very much, the Swiftmailer class for sending mail.
This could be in core, or via an intermediar function, in which i can choose a mailclass? Hard to imagine, but other people may prefer another mailclass:)

This is just a very personal point of view, i dont know if many users will be pleased with this.

Quote
Terradon
Apperently, you dont know what to improve in next versions, so you ask the users. It just means, you did a really good job!

Well, we also have many ideas but we want to know whats important for the users :).

Quote
Terradon
Low priority:
Mail system: i do like very much, the Swiftmailer class for sending mail.
This could be in core, or via an intermediar function, in which i can choose a mailclass? Hard to imagine, but other people may prefer another mailclass:)

What for exactly? What would you gain with using this class for mailing? The smtp mail module uses phpmailer for sending email which has a similar feature set to swiftmailer (we even used swiftmailer before in the smtp mail module).

---

Thomas Seifert

Several years ago, when i had to choose an email class, I read a lot of articles about phpmailer versus swiftmailer.
In that time, phpmailer had no active developement anymore. Now googling again, it seems phpmailer is in active development status again.

The first article i read today about swiftmailer:
[forums.phplist.com]

reading even more articles today, i think both classes are good, so it would be a waste of time to change this. No reason to change a winning horse:)

I would really like to see a better ability to move messages around in the forums.

Quote
agentabstract
I would really like to see a better ability to move messages around in the forums.

Care to give some examples?

---

Thomas Seifert

I want a move button on a message that I can either create a new topic in a different forum, or move the entire topic to a different forum.

A classic example from my site www.indestructibleclans.com (shameless plug):

We have a forum where people can apply to our clan. Once that application is approved we want to move that reply message to a topic inside the clan forum.

Another case would be that a string of general discussion forum posts will spark an entirely new forum. So after I manually create that forum I would want a quick way in the gui to move those topics into that new forum.

Correction I see you can move entire topics around. So it really would just be moving replies to a topic, which you can split off then move.

So what I want is a split off, move, then merge. In one action.

Quote
Phil Connolly
Make Google and Bing anaytics/webmaster tools ID's configurable to the Admin as part of the core, not dependent on a module/template. Also make population of forum and topic page titles / descriptions configurable (also part of the core) rather than up to the template designer or a module writer.

These webmaster tools stuff also loudly asks for a module in my opinion. It actually is just a simple HTML snippet which is added in the header. Also if it changes, a module can be easier updated.

Quote
Phil Connolly
Social media sharing needs to be really fleshed out. It does not belong in the core, but a really robust and API-rich extension is needed. There are so many ways a forum integrator could use it beyond the simple Like buttons and tweet this post and such. There are too many use cases for a developer to anticipate and create "features" to please every Phorum admin. I like the idea of a social media extension defining object models and APIs available for module developers to build on top of. If Phorum shipped with a social media extension module, I believe module developers would use it to add more actual social features. Without the extension module, the learning curve, not to mention the amount of code that has to be written, is too much.

Hmm, I'm wondering what exactly that base module should provide. What kind of object models and API's beside some Posts-API and Users-API are we talking about?

Maybe you want to join the effort alltogether? ;-)

---

Thomas Seifert

Quote
sheik
s. Lemonstand also has a dedicated procedure for module writers to alter the database semi-automatically (you just add your SQL to a config file).

Well. we got module database upgrades too which hook into the regular phorum upgrade process but I guess it just lacks documentation ;-).

---

Thomas Seifert

I'm getting requests from my users for a quick chat mod. I've been digging around in the forums here, and older discussions from previous versions and it doesn't seem that anyone has ever found a good solution.

What I want is a simple chat page that automatically uses Phorum accounts. When I say simple, I mean that too. Nothing fancy whatsoever. A box to type in text and a window where that text scrolls up.

I've personally moved from trying to find this solution, to trying to create this solution.

Does anyone have anything like this on their site, or has anyone integrated an available product or script to Phorum logins?

@agentabstract, please make new topics for new questions which are not related to this thread

---

Thomas Seifert

Sorry I reposted my topic in the Hack/Mods request forum. I felt this was a response to your initial question, but I see you have a forum that is better suited for such things. You can delete my post and our replies here if you like. Thanks for a great product.

Be very conservative. The current version gets a lot of things right.

A great strength of Phorum has been portability. This means sticking strictly to relational database for data storage and avoid data types within the database structure that are not easily transportable.

Maintain separation of data and presentation. You finally managed to get this right, don't mess it up as you start to get into mobile.

You need better presentation formatting for mobile devices (I do have the mobile template installed). I know it is getting to be a nightmare because of the sheer number of platforms but many of my users are now parsing their messages through their iPads or cell phones.

Whatever you do to accommodate the requests for integrating social media and web analytics do not do anything that jeopardizes user privacy. Make any integration opt-in on a per-user basis and keep it all out of core code.

Build an admin tool for automating backups. There seems to be some sort of philosophical bias among the star developers against doing this but it is really long overdue.

This things being said, imho Phorum is in a state that needs little further development for now. I think efforts of the star team should be devoted to expanding the adoption of Phorum. The single biggest barrier to adoption is a lack of integration modules for mating it to other software. Amember is a good example. Nothing fancy, mind you, just the basics of shared cookies, shared user database and a simple, stable integrated template.