(15 replies, posted in PunBB 1.2 discussion)

The only easy answer to the "why not a newsgroup" is to say I agree. There are some people who prefer to access a forum via email only, whilst others prefer via the browser. It should certainly be possible to accomodate both groups.


(15 replies, posted in PunBB 1.2 discussion)

Is there a way in PunBB to email posts to the forum? This would allow some members to read and respond without visiting the forum. As I understand, this is possible in that other BB.

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.


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.


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.