Making PunBB More Local Customizable . . .

Moving to PunBB discussions.

Sounds like I didn't make much sense, but you figured it out in large part. I'll try to be more descriptive. I'm in law school, and I am studing for exams this week--and I'm online during my few breaks. :-)

What I'm generally seeking is system that allows for upgrades that require little effort--and that won't clobber local configurations. At then end of all my rambling I'll state more of my "problem." But, I presently support at least a half-dozen web sites via open-source tools, and I need a fairly streamline way of keeping the software current . . .

First, a simpler CSS--which I gather is on the slate for 1.3. That would be greatly appreciated.

Second, it would be nice to have a template system where somebody non-conversant with PunBB code, but familiar with HTML could go in and quickly put together a template. I've not had the luxury of time (lately) to figure out PunBB's approach, so I apologize if the system is easier than I'm making it out to be.

The other is partly because I'm getting "spoiled." I use a wiki to manage several web sites I support. It's easier as a geek to support others when they're not asking me to be a secretary. Anyway, I use PmWiki (@pmwiki.org). It has a design goal of allowing administrators to upgrade software without clobbering local customizations--much of which is in configuration.

An example of this would be the ability to turn off display of such things as IP and forum moderators. In PmWiki they use variables such as $EnableIPDisplay or $EnableModeratorsDisplay, which are set to true by default. however, by making the variable false in a configuration file, it immediately deactivates that feature. Conversely, in PunBB, to do each of these I've had to remove a variable from a file or two. So, I suppose I'm suggesting adding a few more configuration variables that allow toggling of more-or-less optional features.

How PmWiki preserves this is that it expects all local configuration to be in a /local directory--and it never writes files in that directory. A sample-config.php is dropped in the application root directory, which then may either be deleted or line-by-line incorporated.

Additional modules are added in a "cookbook" directory, which also is never written into by an installation/upgrade. These modules are called recipes.

PmWiki also expects that administrators won't muck with its core software. It does this by allowing methods and functions to be replaced by recipes. The underlying mechanics, I believe, is by assigning the PmWiki-default function to a variable that the local configuration can change to the local function. Granted, a forum is less likely to need this level of sophistication as much of what a forum does is fairly straight-forward.

Sorry to have written so much. I think I started rambling.

You can't believe that if I've been professionally programming for 7 years that I've not heard of OOP? I'd thought of coming back with a "never heard of OOP, is it anything like Java or C++," but I thought you might take that a little too seriously.

The mechanics PmWiki uses to supplant functions does not follow PHP OOP. I'm not sure why, but their approach is to store the function name in a variable and then allow the local site to replace it. It's not true inheritance, but it's lean. And, it allows PmWiki to get the job done using functional programming while mimicing enough of OOP to smooth of the rough edges.

My point was I have clients who do not want moderators to have their names listed, or to have IP addresses listed--even if their display is limited to administrators. And, I would like a tool that is flexible enough to allow me to toggle off a feature rather than require me to muck through the code to weed it out.

In terms of CSS--it's great that PunBB doesn't use tables. One of my criteria. However, how many different ids and classes are needed to accomplish the job? My point was that, IMHO, that the themes that I've seen were more complicated than they need be. Although, that seems a staple of a lot of OS projects. The plumbing gets too complex without enough refractoring. Then again, I used to drive my subordinates nuts for forcing them to rewrite code when they were violating DRY.

I did not know where PunBB was and where it was going regarding my two issues, so I posted to the forum to get a heads up. In general I'm greatly pleased with the product, but I'm never bashful to point out something that might need some looking into. Although, I'm just as likely to get a "yeah, we know and we're working on it" sort of response.

Regards,
Ben

I don't have time to write a lenghty response right now, but regarding easy upgrades. Why not use the patch files? You say you maintain a half-dozen websites using open source tools. If that's true, you must have used diff/patch a million times already, right?

PS: eliminating the current template system and replacing it with Smarty, would already speed things up tremendously - Smarty is infinitely faster than the "search and replace"-kind of template system currently used in PunBB

Would the performance increase actually be noticable. If a page appears to load instantly how can you make it appear to load even more instantly. Isn't it perceived speed that matters not actual speed.  Off topic but I suspect the biggest performance boost would come from the database searching end of things rather than templating particularly on very large boards.

Advantages:
1. Easier to write markup
2. More flexible
3. Lighter markup (templates don't need to be so flexible if you are not relying on css to style them so you need less markup to do the job).
4. Less css (because each template is a one off design)
5. Targeted templates for accessability, print, handhelds etc (again reduces the amount of markup and css because it doesn't need to be a Jack of all trades)
6. Don't need to update the templates when the core code is updated
7. Theoretically easier to integrate into an existing site though I'm not totally convinced about that.
8. Marketing. For some reason end users seem to like the idea of skinning via templates probably because it's what everyone else does.

Disadvantages:
1. More complexity so a longer development cycle
2. Harder to maintain. It's more work maintaining a dozen templates than it is maintaining a dozen stylesheets in those cases where new versions also include template changes.
3. Possible integration problems where a different templating system is already in use.
4. Can't think of anymore which is interesting in itself.

Frank H: I suspect the sub themes are colour schemes. At one point I did think a similar thing would be good for PunBB though I never got around to suggesting it. At the moment PunBB appears to have six styles but in reality it only has one style with 6 different colour schemes. Oxygen.css, Sulfur.css etc are clones of each other, only the imported colour scheme is different. It would probably be more efficient to have one style e.g. Classicpun.css and then 6 colour scheme files called Classicpun_oxgen etc. In the prolife drop down only the colour scheme files would show up so you have

Classicpun_oxygen
Classicpun_sulfur
Newpun_blue
Newput_red
Minima_organge
Minima_white

The advantage would be (ignoring base.css) you get your 6 themes out of 7 files instead of 12 files and don't have the tedious job of having to update Sulfur etc whenever there is a change to Oxygen.

OK. I know, I'm off topic as usual

Going with Smarty would probably add more time to a development cycle and adds yet another layer to keep tabs on. Similar to going with ADODB or something similar for a database layer.

I like the idea of abstracting out the templates and styles and I think it can be done without relying on Smarty or any other outside mechanism. I've become accustomed to handling the mods I make and I'm used to the upgrade cycle by now but in order to faciliate new users, a simpler method would indeed help out.

Advantages (cont.)
9. Class/id names could be in the template designers own language so it is easier for them to maintain.
10. Integration again - if somebody absolutely has to drop PunBB into the middle of some antique DW template they can produce an appropriate skin to get the job done.

Disadvantages (cont.)
5. PunBB looses some of its distinctiveness
6. Loss of quality controls. There will be some truly awful templates produced.
7. I will have to rewrite all the sodding markup - again.
8. Rickard will have to rewrite all the files - again.

I'm just afraid adding a big ol' template system would make PunBB less of what it is now and more of what every other bulletin board is. Remember, feature creep is our biggest enemy.