Also, i intend to return and edit it, as (hopefully) people will response.
this represents my thinking, not some absolute truth.
Chapter 1: What should be kept?
One of the important decisions should be, what parts of the existing system we like and should be kept?
The way I see it, here are (some of) the parts of current system worth preserving:
- SubBlue. strictly speaking, of course, SubBlue is not part of the exiting system. however, his clean, streamlined and beautiful design is probably the one single thing that sets phpbb apart more than anything else. twisi, retaining Subblue for future versions is key to the success of phpbb.
- dbal: Currently, phpbb supports probably more DB backend than any other bbs. there might be places dbal can be extended, streamlined, polished etc., but in general, it has proven itself so far, so we should keep (and nurture) it.
one small comment, though: if we think the backup/restore system should truly be part of phpbb, dbal should support it better. as it is now, the backup/restore has a lot of "if mysql/if posstgres" which it shouldn't.naderman wrote:Only thing I'd like to say something about is the dbal. I would like to investigate the option of using a proper ORM to finally get rid of SQL in frontend code. The current DBAL works pretty well as an underlying mechanism, but it doesn't support things like prepared statements. Doctrine seems like the best available ORM choice in the PHP world. We should certainly take the lessons we learned from building our own DBAL with us. We should then extend Doctrine to support all the DBMS we currently support.
- the templating system.again, it can endure some adding of features and whatnot, but in general it's a good system that should stay.
Principle #1: Everything is Custom
Currently we have two features that support "Custom": Custom user fields, and Custom bbcode.
in both cases the "Custom" part is an afterthought that was slapped on top of an existing system, so the code support large number of user fields and large number of bbcodes "in the core", and on top of that the custom user fields and bbcodes.
this is not as should be.
all existing bbcodes and almost all existing user fields should migrate under the "custom" part ("custom" is not a good name, IMO. maybe "expendable"?).
if the current "custom" system is not strong enough to support them (e.g., i can't see how the URL bbcode can be supported with current capabilities of the "custom bbcode" system), then the "custom" part should be developed and expanded to the point it supports all the needs of the system.
there should be no distinction between bbcodes that are part of the core system and bbcodes which the user added. there should be no distinction between user fields and custom user fields (except, maybe three or four most basic ones, say user ID, user type, and maybe password and nick)
Principle #2: Everything is a plugin
I doubt that many would argue against the assertion that a top-rate plugin system is a must.
(i hope, some time in the near future, to post another post with the outline of the plugin system *as i see it*)
i want to stretch this a little bit:
IMO, as many of the core features as practical should be implemented as plugins.
this has several advantages: first, it keep us honest about supporting strong plugin infrastructure: if the core developrs will have to jump through the same hoops in order to implement a feature, they will surely notice every kink and annoyance in the plugin infrastructure and will fix it.
this will also give a (somewhat) unified management interface: the "on/off" switch for a built-in feature will behave *exactly* as the on/off switch for a plugin, because the built-in feature *is* a plugin.
it will also make it very easy to promote good user-contributions into the core: it basically becomes a question of packaging and nothing else. once you package a specific plugin in the basic install, it becomes "core"
Principle #3: User selections come on top of the system, not replacing parts of it
the only example i have ATM is the "edit style" disaster which replaces existing css files instead of augmenting them.
this makes upgrades a nightmare, users lose their changes, and tears aplenty for everyone.
the "C" in CSS is cascading, which, as far as i understand the term, means that you can define the same thing multiple times and the latest one is the one to be used. users style choices should be kept in a separate CSS file, to be loaded *last*.
Principle #4: Good, sturdy and well-define API is a must
i do not know if i have to expand this assertion - it is kinda sorta obvious.
every service any plugin receives from the system (e.g., the plugin may want to ask the system: "is this user allowed to do X?", or, "what is the value of user-field Y?" etc.) is an API.
as stated above, i plan to revisit this post and add and edit stuff, based on new ideas i might have and on readers feedback.