26

(3 replies, posted in Feature requests)

By itself it's a bad idea, because some human browse the web without CSS support (blind people for one, but also some hand held device, etc.).

27

(52 replies, posted in PunBB 1.3 troubleshooting)

Yup please please, don't overdo the i18n system. Don't cut phrases into small pieces, and don't over-reuse phrases out of context.

Some languages have very different grammatical system, syntax rules, and such. It's much, much better to have to re-write a word a dozen times around while localizing, than having to go around the system or butcher the localization because of the system used.

28

(7 replies, posted in General discussion)

That's easy. 1+1=3, for very very large values of one.

29

(18 replies, posted in PunBB 1.2 discussion)

No, but before switching my active forums to 1.3 I will wait until it was deployed on a large scale without issue, plus some time necessary to re-create the stylesheets and turn some hacks into plugins.

But overall no, 1.2 has major issues bugging me.

30

(20 replies, posted in PunBB 1.3 troubleshooting)

Smartys wrote:

The problem of course is that we have to make assumptions about what variables are available to us for use (and I have a feeling that the code for generating the descriptions would be long).

The output isn't buffered? You can't ?go back? to set the string after you processed the content of the page?

31

(20 replies, posted in PunBB 1.3 troubleshooting)

Why not set an appropriate meta description? Dynamically, based on what's on the page (thread view, forums, view, etc.)?

MattF wrote:

It is risky though.

Especially when even the PunBB team doesn't switch these forums to 1.3 beta, or RC smile

PMD wrote:

This plugin allows you to quickly and easily make a database backup and then transfer it in a number of ways.

I don't know if DB is the only scope of this plugin, but if so it would be nice to rename it to a more precise title (to backup a Pun install, one has to save more than just the database).

In any case, nice work on the remote storage of the dump.

34

(25 replies, posted in PunBB 1.3 troubleshooting)

Smartys wrote:

Because it would very much go against the PunBB idea of being fast, small, and simple. And as Bekko said, some browsers don't support it, some users don't use Javascript, etc. Extensions are certainly free to implement AJAX-ish features, but I doubt we'll see them in the core.

On some cases, AJAX is lighter and faster than pure HTML (which one has to have, to degrade gracefully).

One Pun example on the top of my head is item sorting: when you reorganize your forum, it would be faster to just click and drop forums in the correct order than to input sorting key by hand, one by one.

Ok that one is not something done everyday so a full ajax framework written just for that isn't probably a good idea,  but you get my point. AJAX is not, by itself, automatically slower smile

hm2k wrote:

punBB should get the 10 things right that phpBB3 got so, so wrong...

Another, largely recognized as poor, forum software suposed wrong doesn't mean Pun _should_ correct it. maybe it's not under Pun's scope, for example? No?

* Page titles are still horrible, including the ?Index page?, very descriptive?

That may be a good one, I haven't checked it myself... I'm sure a lot of other people have but still, I'll look into it for my own curiosity and possible improvement reports.

* No XML sitemaps?

Given that's now a de facto standard, and more or less open, and given the fact 99% of forum user will want their forums indexed, having it in the core would indeed be a good thing.

Beside, it's not long or difficult to do.

* RSS is a major part of ?web 2.0?, yet phpBB 3.0 still hasn?t mastered them!

RSS isn't a major part of anything, and there's no such thing as ?Web 2.0?. On top of that, RSS specs are inexistant, to the point where some RSS author have given up and switched to Atom. Atom is good, but it isn't a major part of anything either.

* Unfortunately phpBB is one of the few notable forums out there, nothing else works quite like it.

Thank god most software don't work like phpbb.

But there's plenty of other forum software, some incredibly faster, ligther and more secure than phpbb. Pun is one of them, or maybe just The One.

* They pioneered things like bbCode which means users can add easy to understand markup to their comments.

bbcode is another thing phpbb will have to answer to when it's dead. bbcode that's just a lame, lazy developer who, once upon a time, thought: ?oh, allowing html is bad, it can break things. Ok I won't bother filtering out the bad or in the good, I'll just forbid everything <>. Oh, user are asking for some feature... bah, let's now use [], and some über limited syntax of a tiny part of the current html. Someone will fix this whole thing in the future?. And it stuck.

* It?s open source and GPL so it appeals to all the freetards out there.

Not much to do with philosophy. True open source software tend just to be cheaper to create, support, use, and overall of better quality.

There's exceptions everywhere, of course.

* There?s quite a large community that offer mods, styles and support.

Community support is vital for an open source internet software. Pun has quite a good community.

Overall, before spamming your things, and talking phpbb-ish only, maybe you should inquire yourself about where your post, and what it's about.

Googlebot follow the "nofollow" links. It just doesn't index them publicly.

This couldn't be done at punbb.org? Less forums/sites to check on a single topic would be better for everyone, in my humble opinion.

38

(12 replies, posted in PunBB 1.3 troubleshooting)

As long as vanilla Pun 1.3 send a proper 404 to the web server, any admin can direct that web server to generate whatever 404 page he wants.

I think one of the dev wanted to do Multigroup too.

There's also localized URL scheme.

40

(38 replies, posted in PunBB 1.3 troubleshooting)

Supermag, what about localized scheme, or custom scheme? Even if you dismiss the later (if it's custom, they should handle it themselves), the former can't be.

I'm not sure the dev can write something for every possible scheme there is. And I'm not sure that it's possible to load every scheme together, to have a redirect "from whatever -> to the current scheme".

And on tope of that, there's the matter of extensions... some of them will add new URL.

Maybe the dev could handle the redirect from raw to the current scheme in the core, and an extenstion could on top of the later handle switching from one scheme to another?

41

(4 replies, posted in General discussion)

It depends on your country. Things may be very different from Oregon US to France to Japan to Slovenia.

In any cases, regarding legal advice, you should go see a licensed expert on the field. ?I've seen it on a web board? is not an accepted apology in front of a judge, or an IRS agent smile

It's all about the common usage. 99.999999% of the time, when someone use b or i, they meant an emphasis.

On the other hand, doubling the number of tag, is confusing for the average user. Is one really wanted to add another tags, I think cite would be much more needed and appropriate for example.

Basically:

Newbie need to encode entities if they use one (&<>) in the description, which should be explained in the manual/install process and should be rare.

Advanced users need to be able to use tags in description, <cite> or <a> being probably the most common.

And it's more work to have it both way (encode automatically for newcomers, extended for the others).

Yup it's something already talked about in length in another thread.

45

(38 replies, posted in PunBB 1.3 troubleshooting)

Rickard wrote:

It should be noted that multiple links to the same content isn't really an issue unless more than one URL is used. This is a problem when migrating from one URL scheme to another, but that's it.

Which will be the case of nearly everyone when they update from 1.2 to 1.3.

Maybe you could do something like:

If a clean url scheme is used
And if current url is raw

Then process the raw url through the clean_url function
and send a HTTP permanent redirect header with the clean url pointer

With hooks in there, so that people could have extensions in there to do more redirect or whatever, if they want.

Will one conditional check (perhaps of a simple string, like "is the first word of the local part of the url ends with .php?" or whatever) slow things down that much?

46

(38 replies, posted in PunBB 1.3 troubleshooting)

And dashes are easier for the general population then underscore, and it's also easier to print or display on other medium (such as TV).

47

(38 replies, posted in PunBB 1.3 troubleshooting)

What for? Why would they do that?

48

(17 replies, posted in PunBB 1.2 discussion)

SuperMAG wrote:

by the way they use the same hooks and extensions system as punbb 1.3

But they don't use the same html designer. It shows hmm

But more to the point, one is open source, the other isn't. Nothing further to compare for me.

49

(38 replies, posted in PunBB 1.3 troubleshooting)

I was going to answer point by point, especially with that amount of wrapping around my meaning, I even read again the appropriate RFC. Then, I saw that I'm closed minded and xenophobic, so I won't bother.

50

(38 replies, posted in PunBB 1.3 troubleshooting)

Keulig wrote:

Jérémie, wikipedia uses urls as keys to its articles, whereas punBB uses numbers as keys to topics, that's why non-ascii chars can be stripped from our urls and it also makes urls more readable. (topic-1-jérémie is the same as topic-1-jeremie, but "jeremie" looks better in the adress bar of our navigator).

Yes, exactly. That's what I'm saying in this, and other threads smile

Quite frankly, that's because PunBB aim as fast and simple, and it was perceived that keying on an text key was too complex (more queries, duplicates, etc etc.). But again, extensions apply here.  If the basic, lowest common denominator used in vanilla URL scheme doesn't work for me, I can use my own, as complex as I want (well, if we trust the coders around here to request the appropriate hooks tongue ).