Topic: Making PunBB More Local Customizable . . .

Greetings,

This is my first post to this forum. I appologize if I'm stepping in the middle of anything.

I picked PunBB because it seemed leaner than that other P..BB product, and I intend to keep using it. However, I'm wary of upgrading (I believe I'm at 1.2.4) because I've had to make a few local customizations to shoe-horn the forum into the web site I support.

All of the shoe-horning involves whether to display or not display something. This involved editing either index.php or one of the files involving the theme building. The next time I upgrade, I will lose all of these. Also, when I tried to tweak a theme, I found that the number of CSS tags involved quite daunting--and I have years of experience in developing web site.

What I'm asking is for a fundamental redesign about how PunBB handles display. There is a bare-bones of what is needed to display to make a presentable forum--and that which should be optional.

Regards,
Ben

2

Re: Making PunBB More Local Customizable . . .

Moving to PunBB discussions.

3 (edited by Jansson 2005-07-18 22:59)

Re: Making PunBB More Local Customizable . . .

I'm not quite sure what your asking for. Maybe you should give an example of 'a fundamental redesign about how PunBB handles display'. Do you mean a more complete template system? Do you want the CSS to be more simple and not as much tweakable? Btw, I think a change to the CSS is coming for 1.3. Ask Paul for further details.

And for your upgrading problems, there is hdiff files to download and make the changes yourself. And after that, just run the upgrade scripts in order to update your database.

Re: Making PunBB More Local Customizable . . .

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.

Re: Making PunBB More Local Customizable . . .

BenWilson wrote:

What I'm generally seeking is system that allows for upgrades that require little effort--and that won't clobber local configurations.

A system like that is currently being developed, by me, for PunRes.org. Read this thread for more info: http://punbb.org/forums/viewtopic.php?id=4974


BenWilson wrote:

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.

PunBB is, as you may have noticed, free of tables. Atleast for designing purpose. This means, that the CSS currently controls most of the design. And what I've understand, will control even more in 1.3. Thats why, a better template system isn't really needed, as it will only make the forum less fast, which is the sole purpose of PunBB.

BenWilson wrote:

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.

The IP is not shown to members as default (only admin/mods). And I'm quite sure that this is possible to change in the admin. You don't even have to change a variable. I don't know what you mean with moderators. You mean under the forums? That list is not showed if no moderators are added to the forum. And if there is no users in the moderator group. Im quite sure you won't notice that group either.


BenWilson wrote:

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.

There is an example_config.php in the extras/ directory in the PunBB package. And that only contains db connection information. All other configuration is done via the admin, except the debug constant which is declared in common.php.


BenWilson wrote:

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.

Since you've been in the business for quite some time, I'm sure you've heard of Object Oriented Programming. And I'm quite sure that's what this wiki system uses. This means that you can't get this kind of functionality in PunBB if you're not to rewrite the whole thing from scratch. Here are some comments from Rickard about PHP and OOP: http://punbb.org/forums/viewtopic.php?id=7206

I hope that answered some of your questions smile

Re: Making PunBB More Local Customizable . . .

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

Re: Making PunBB More Local Customizable . . .

BenWilson wrote:

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.

Yes, that would be really great. But would such system slow down? I don't know, please tell me. However, doing such small things to the code only takes about 5-10 minutes if you are fairly used to the code. And if your not, I bet someone here on the forum will help out.

This is how you remove the moderator list:

Find line ~132, index.php:

<?php echo $forum_field."\n".$moderators ?>

Change it to

<?php echo $forum_field ?>

Simple as that.


To remove the IP for everybody:

Open viewtopic.php and comment out these lines:

Line ~249:
$user_info[] = '<dd>IP: <a href="moderate.php?get_host='.$cur_post['id'].'">'.$cur_post['poster_ip'].'</a>';

Line ~261-262
if ($pun_user['g_id'] < PUN_GUEST)
            $user_info[] = '<dd>IP: <a href="moderate.php?get_host='.$cur_post['id'].'">'.$cur_post['poster_ip'].'</a>';

Re: Making PunBB More Local Customizable . . .

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?

"Programming is like sex: one mistake and you have to support it for the rest of your life."

Re: Making PunBB More Local Customizable . . .

I too would like to see PunBB made more flexible - in my case, a template system would cover 95% of all the changes I normally make, which is usually simple stuff like showing/hiding various details etc. ... stuff that really doesn't take much time to change, but makes it hard or impossible to upgrade to newer versions without starting over every time.

I personally would like to see PunBB using the Smarty template engine:

http://smarty.php.net/

it's the best template engine there is; and it "compiles" all templates into native PHP scripts transparently, which means near-zero overhead for general usage. I've been using it for years, and it's much more efficient, and even simpler, than using simple HTML with embedded PHP statements.

using a system like this, anyone would able to add/remove information in seconds - and upgrading would be as simple as unpacking the updated source files without unpacking the default templates.

I would get on the case myself and perform the integration, but I don't have time ... plus the fact that, if I went ahead and did this, there would soon be an updated version of PunBB, and I may have to start over to integrate the changes, same way I have to start over on customized PunBB installations now...

I really would be thrilled to see PunBB supporting a "real" template system - total separation of layout and content would, imho, take PunBB to the "next level" smile

Re: Making PunBB More Local Customizable . . .

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 wink

Re: Making PunBB More Local Customizable . . .

The big question is whether we want to take PunBB to the "next level". Adding Smarty support might increase performance, but it would also increase the complexity.

"Programming is like sex: one mistake and you have to support it for the rest of your life."

12

Re: Making PunBB More Local Customizable . . .

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.

Re: Making PunBB More Local Customizable . . .

I've started looking at smarty because ExponentCMS, I recently installed, use Smarty ... And ExponentCMS supports subthemes, and that would take care of that 2nd disadvantage, as then the subthemes could have ony css changes (or that's how I understood it would work, haven't tested, yet)

Advantages:
* A bunch of people know smarty already, so a wider userbase could 'help' with styling.
* Integration with other 'tools' also using smarty might be easier (like, PunBB and ExponentCMS would probably be fairly easy to look very similar, if they get themed in the same way)

Disadvantages:
* "Outside dependancy": If a serious flaw comes up, they would probably need to fix it first. If the group would split up and leave the project, it could become poor, and no control over compatibility for later versions. (as you might not have something to say about how it should look in the future)

14

Re: Making PunBB More Local Customizable . . .

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 smile

15

Re: Making PunBB More Local Customizable . . .

Paul wrote:

Advantages:
.........................
8. Marketing. For some reason end users seem to like the idea of skinning via templates probably because it's what everyone else does.

Actually it is the easiest way of skinning, maybe that's why everybody else does it.
smile
Sure the whole thing looks more "grown up" if you separate code from html, but on the other hand that's waht it really is then.

Paul wrote:

Disadvantages:
1. More complexity so a longer development cycle

I don't believe so.
I work for 6 years with a (self made) template engine now and once you know the basic tags it is so much faster to develop... No need to sink knee deep into html tags just because you have to apply a security fix, no need to touch the code just because you want to make things look totally different, and most of all, it is much, much easier to develop extensions if code is code and html is html.

Paul wrote:

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.

But easier to maintain if you combine these two.
There can be template changes and style changes, right?

Paul wrote:

3. Possible integration problems where a different templating system is already in use.

I've never heard of incompatibilities with two template engines. It might just get confusing.

Paul wrote:

4. Can't think of anymore which is interesting in itself.

Now, this is a disadvantage smile

Rickard wrote:

The big question is whether we want to take PunBB to the "next level". Adding Smarty support might increase performance, but it would also increase the complexity.

Do you really think so?
Sure, it looks a bit more complicated at first but then again, isn't upgrading/modding much easier with a template system?
I surely would love to follow punBB onto that level and I would help reaching it if wanted.
I am used to projects where code and html are always stictly separated and it's so mauch easier to maintain...

I see your point though, for the absolute newbie it might look a bit heavy. But is a full blown BB system the best project to start with for a complete newbie anyway? smile

The German PunBB Site:
PunBB-forum.de

16

Re: Making PunBB More Local Customizable . . .

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.

17

Re: Making PunBB More Local Customizable . . .

hcgtv wrote:

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.

Sure enough.
Smarty is a heavy weight, I think it would be possible to incorporate something in to punBB handling the template parsing.
That also avoids the dependancy on third party projects.

The German PunBB Site:
PunBB-forum.de

18

Re: Making PunBB More Local Customizable . . .

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.

19

Re: Making PunBB More Local Customizable . . .

Paul wrote:

Disadvantages (cont.)
5. PunBB looses some of its distinctiveness

Don't think so.... I truly believe you can do something easy and professional and that will still distinct punBB from all those really badly writen boards out there, template driven or not.

Paul wrote:

6. Loss of quality controls. There will be some truly awful templates produced.

That's for sure smile
But you don't want to see some of the styles I made...

Paul wrote:

7. I will have to rewrite all the sodding markup - again.
8. Rickard will have to rewrite all the files - again.

Well, that sounds like your very personal disadvantage I admit.
For the rest of us I still think it would be a benefit. wink

The German PunBB Site:
PunBB-forum.de

Re: Making PunBB More Local Customizable . . .

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.

"Programming is like sex: one mistake and you have to support it for the rest of your life."

Re: Making PunBB More Local Customizable . . .

Rickard wrote:

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.

I agree. PunBB wasn't made to be versatile. It was made to be simple and fast. I love it that you can just download PunBB, put it on your server, run the install script and get it running in seconds. If you need extreme functionality, there is options. The price you pay is slower development (PunBB only have one developer and still bugs are fixed relly fast) and a slower software.

I don't see why a template system would help you with updates to the php source code. On phpBB for example, you have all kind of functions you'll possibly need so there is a big chance that you'll only "remove" some functions with the templates. Then it's easy to just apply the updates to the php source code. But in PunBB? There is a bigger chance that you will add a couple of features instead, and that would be both in the php source and the templates. So then the update problem isn't solved by a template engine.

22

Re: Making PunBB More Local Customizable . . .

Rickard wrote:

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.

You are absolutely right, and that's why I finally chose it. The more features you have the more likely it gets that you will have security holes somewehere. And it's more difficult to handle as well.
However, changing the way punBB outputs pages does not mean adding features.
It's just the way html and php code is handled.
I do not even know if it would/could make punBB faster but I do know it makes the whole thing more readable.
What is wrong to go with the bunch in this (and only in this) respect?
In my opinion PunBB can still be the easiest and fastest system.

Jansson wrote:

I love it that you can just download PunBB, put it on your server, run the install script and get it running in seconds.

You could still do that. Templates do not  mean that it makes the whole thing more difficult to install.

Jansson wrote:

If you need extreme functionality, there is options. The price you pay is slower development (PunBB only have one developer and still bugs are fixed relly fast) and a slower software.

I think there is a mix up between the way the board is spit out to the user and the wealth of features it should have.
For me, this discussion is only about the structure of the code. Not more.
And I believe that with a template system there would be more people who could help developing the whole thing.

As for smarty:
I think this one is a bit too much.
It has its own syntax and is not always easy to understand for the beginner.
Plus, with all its tags it puts way too much programming in the html templates.
What makes a template system so strong for me is the distinction between logic and markup and in this respect smarty doesn't really make it.

The German PunBB Site:
PunBB-forum.de