PunBB 1.2 - What's to come (Page 4 of 13)

because most of HOST providers not upgrade to PHP5.
But i like to punbb support SQLite for my project (Offline Articles) not named yet.

I for see some problems with the conversion to XHTML (Body: 5px margin, Forum 100% width), also i think the ability to integrate into CMS and other project will be MUCH more difficult then a HTML 4.01 design.

While i do agree that a better CSS design is a must, im not sure this was the path to choose.

...since i see from the screens that a forum is running, is it possible to get a private screening of what the future holds from a design standpoin (i wont signup, i just want to view source and concider the future of punbb in my current, and future projects)t? (shayne[AT]mars-project[DOT]com)

*also i think the scroll bars on the quotes suck, im hoping thats just a CSS preset div with overflow that can be removed*

Well, yes. Hosting companies will of couse be hesitant to upgrade when their current installation is working without problems, but 5.0 differs from previous upgrades in that it offers lots of new functionality, not just bug fixes and a new function here and there. I believe this, together with the fact that customers are much more demanding these days, will speed up the process.

I also think it differs quite a lot from country to country. I don't know of a single serious Swedish hosting company that runs anything prior to 4.3.0.

I don't get it. Why should it be more difficult. The best of the current generation CMS systems and almost all of the blogs are XHTML/CSS driven. In any case, properly written HTML 4.01 and XHTML are essentially the same. I could set the doctype to HTML 4.01 and it would validate fine. If you mean a move away from tables thats another mater. I've nothing against tables personally but why use them when there is something lighter, quicker, easier to code and more accessible available. Using a table for the message box when an H2 and a P would do the job seems like overkill.

What are you worried about in particular. I'm open to suggestions.

Soon.

The problem is that while the current systm works fine if PunBB is alone on the page it's a real problem if PunBb is sitting in a two or three column layout as it may well be if you are integrating with a CMS or blog. That leaves you with four choices; 1. wrap all wide posts i.e destory the code functionality, 2, display code in a different window, 3, cut it off with overflow hidden, 4, scroll it with overflow auto.  I chose the fourth option.  I'm not in love with it myself, it's a right royal pain to get right.  If you can think of a better idea I would love to hear it. My first option would have been to have code display as it does now but the box containing the code would float over any surrounding content not push it aside. I could only get it to work in one browser at a time.

BTW. Why did you use a spacer graphic on your site?
<div class="space"><!-- empty --></div>
.space {height: whatever}

So all alterations in the code has lead to the introduction of new bugs? I have no idea what you are trying to say. Of couse new bugs are introduced when old bugs are fixed. This is hardly anything PHP-specific.

I can't see what that has to do with anything, but sure, PHP5 might be what PHP4 should have been all along. I still think PHP4 is one of the best scripting languages for the web.

We'll see. I don't consider PHP5 such a huge upgrade and I don't think the Swedish web hosts will do either. I have yet to encounter a piece of code I've written that hasn't work in 5.0.

Sure, there are lots of bugs, but most of them are quite uncommon and hard to replicate. Then there are also bugs such as this one:

"shallow __clone copy behavior not documented in any place on php website"

Calling PHP5 unstable because it's website lacks documentation on a very seldomly used feature of the OO model is hardly fair.

I disagree. PHP5 will allow people to write object oriented programs in PHP. Something that was basically impossible with PHP4 (mainly due to the inability to do real encapsulation). I agree that the upgrade to MySQL 4.1 will be extremely important in the long run (because of the Unicode support), but 5.0 pretty much adds only stored procedures. SP:s are nice, but not that nice.

PHP5: Not the second coming. It is if your interested in XML.

Thats odd. Are you running Apache 1.3 or 2.0?

How is that? Stored procs have the advantage of separating database logic from actual code. If anything, I would say triggers are a pain in the butt. At least during development.

Functions would be nice, I agree. However, I don't think subselects are the holy grail. Pretty much all queries that involve subselects can be executed with the aid of some creative JOINs instead. The results is almost always faster. Subselects have a tendency to make developers lazy :)

right, that is my in principles

Stored procedures not good as like Triggers and "Forign key" especially when write plugin system or MOD
when you delete a forum you must delete all its topic, there is a plugin (or MOD) added new table and need delete all record in that table,
it's hard to modify code when you can add trigger(Forign Key) on table

the Stored procedures advantage is running in server but when you code PHP is also in same server the Stored procedures lost this advantage.

i agree, mysql support JOIN in DELETE statment so not need Subselects.

is mean that new features like function override etc... ?

not just (cascading delete), i meant like increase post count (Ranks) in a trigger

Someone asked a question about register globals on page 3, havn't been able to find this answer though.

So... are they on or off?

lol

Well I know its server dependant lol, I was just asking if its coded for register_globals off so thanks for the answer