Because Ian Hickson use twisted plot and exception to make a point he has already decided on his mind before studying the subject?

Ian Hickson wrote:

Yes, I said _most_ authors. If you are one of the few authors who understands how to avoid the issues raised in this document and does validate all their markup, then this document probably does not apply to you

Ok fine, then why bother us with it? We know what we are doing, thank you very much, go back to bed.

Ian Hickson wrote:

Also note that I would personally suggest that even advanced authors not use XHTML sent as text/html, since many authors copy and paste markup from others and thus may easily end up copying the valid XHTML markup but using it as HTML4.

Fine, make it a personal recommendation. Do not write and advertise such a personal, weightless comment, and title it ?Sending XHTML as text/html Considered Harmful?. Considered implies some kind of authority, you don't have it (yup, being paid by Google to work on HTML5 doesn't go with an ?boss hat?).

Myself, I make the opposite personal recommendation. XHTML 1 strict (sent as text/html or not, doesn't matter) is easier to validate, so it's better for newbies (people who don't validate their html/xhtml are not newbies, there are either idiots or morons). It's also compatible with xml, which make it easier to integrate with advanced tool, and probably the future (?probably? because HTML5 took a different turn, but we'll see).

Mainly, it's an opposition view thing (and the fact that the document linked by you shouldn't be put online without a strong context). He thinks (being a WHATWG member does that to you) that we should improve HTML. I think the whole thing is flawed from the start (despite its incredible achievements) and will never have proper support from UA vendor, and we should move to something else entirely (xml was a nice candidate, however I don't have preferences) that will enforce validation and proper specs.


And to be honest, this is a über-anal-geek discussion. On a basic level, for everyday use, HTML or XHTML are exactly the same thing. So it doesn't matter for 99.999999% of its user that PunBB is written in XHTML or HTML, as long as it uses strict doctype and validation.

svo wrote:

So here there is a way to apply a secure one-way password approach by using Javascript SHA1 and MD5 libraries.

You can't use javascript to do anything important, because some UA don't have javascript (enable, or at all).

Anyway, I think security related suggestions and possible hole are supposed to be mailed to Rickard, to avoid giving idea to the script kiddies around.

228

(6 replies, posted in PunBB 1.2 troubleshooting)

Usually, password don't matter. An user can request a new one.

If you have issue with it after a bad dump, you can randomize the passwords to fill the database.

UH... I missed the date of Rickard's post wink

Rickard wrote:

It should also be noted that I'm considering phasing out MD5 all together in 1.3.

That's good news smile

Right now, I'm guessing a lot of people are waiting for 1.3 to come out, at least in a beta stage. It's the calm before the storm smile

232

(4 replies, posted in PunBB 1.2 discussion)

This is not a feature request.

And, what's your budget? smile

It's possible to ransom code, it's possible to get a group a share a dev's cost, it's also possible to sell code. The GPL doesn't prohibit any of these.

But I'm not sure you'll find people willing to pay for an extensive mod when 1.3 is in the work, except if one needs it right this year.

234

(6 replies, posted in PunBB 1.2 discussion)

And sometimes it's needed to simplify style weight, or to create something specific. But doing it for every class/id rule isn't good practice.

235

(13 replies, posted in General discussion)

I read ?Moved to?...

I need a new reality filter to help me when I'm sick hmm

236

(13 replies, posted in General discussion)

UH... that's a feature request?

I think he's just looking for a ticketing system similar to PunBB...

237

(5 replies, posted in PunBB 1.2 troubleshooting)

Yup, check the cron. 5AM seems like a good time to have a heavy backup, or something like that, scheduled.

BBcode is still, unfortunately, the basic for a vast majority of user.

Beside, most of the user of other markup language or typographic helper (Textile, Markdown, etc.) already have a board under BBcode that will need conversion of some kind.

So, it's pretty much plugins... and people to write them.

I think it could be done as a plugin in 1.3.

Look for the charset used in the web page that embeds it.

If you have a mysite.php script that calls /punbb/extern.php, mysite.php (and everything around it, such as the potential default charset used by your Apache) should have the same charset as your PunBB.

I do a HTML display of PunBB topics with extern.php on a full utf-8 website (both PunBB and the web page are in utf-8) and it worked well without any code modification or anything complicated; just because I used the same charset all the way.

You need to have a PunBB's charset that handle these characters. If you can write them into your PunBB forums and post, and have the page validated by the W3C validator, then your fine here.

Then, you need extern.php to use the same charset as you PUnBB forum.

Use the same charset from the beginning to the end of the server's handling. And of course, a proper charset that will handle those characters, such as utf-8.

243

(31 replies, posted in Feature requests)

Agreed, your English is pure abomination smile

I'm pretty sure it wouldn't help at all for potential security purpose.

However, the goal to have only one code base to maintain is quite nice, yup. But it might get tricky if the database doesn't follow the multiple-forums scheme. Because a plugin could, for example, store things into the database. Teh you'll have forum A with the plugin in the DB and the code, and forum B with the plugin only in the code.

I guess it depends on how hooks are handle.

I might suggest transforming this feature request into a ?support multiple forum with one PunBB install? one, and if accepted let the dev look for the best way of doing it.

244

(31 replies, posted in Feature requests)

I'm curious, what's would be the purpose?

There's a Merge Forums plugin that worked fine for me.

Seems interesting. Could be a nice boost to a young CMS, and a remainder for the old ones and less young that things are moving.

I did try last week a software that did some kind of semi auto update (beside confirm it by hand it does all by himself); which was really, really nice indeed. Can't remember the damn soft's name sad

Maybe it was Typolight?

Since it's interpreted, the source will already be available to him on his server smile

I didn't say it was something bad, just pointing out what the GPL does.

Oh and if you mod PunBB or integrate some of your code, it has to be GPL to. If it's external and somewhat rely on PunBB code, then it's a more complex area. But for a friend, don't need to hammer your head. You can do whatever you want pretty much, as long as you don't restrict the freedom of your friend/client and the freedom of PunBB.

The only thing is, your friend have the ability/freedom to read, edit, and distribute your PunBB setup and PunBB by itself.

250

(4 replies, posted in Feature requests)

Good point. So it's not one "area" or "post" that's needed, but one by language. It's default content would be the standard help (localized, as now). But the "post" structure of the help would mean the admin can edit, customize, expend, rewrite each and everyone of them.


Overall, the thing with the current system is that you can't edit it at all without at least some PHP knowledge (a very minimal knowledge is not enough, it's a little more than that). And being able to customize, rewrite, edit the forum's help is not an advance feature; imho it's a very very basic one.

If what I propose isn't clear, I can try to clarify it.