Search options (Page 6 of 28)

Extension also offer much more flexibility, and less overhead for for core dev team, less support.

I disagree with Rickard on the need and importance of such a feature (and a few other, such as multigroup), however having a semi-official extenstion doing it is quite ok if there's a good tool to deploy, manage, and update extenstion on PunBB (I don't want to have to do it by hand on several multiple install, like TXP, it's a time eater). I'm pretty sure such a tool won't be here at 1.3, so it give us something to bother them about for 1.3.1

<hn> have much more meaning then font-size (which has exactly none).

But I'm pretty sure, at some point there will be several extenstion that will allow any bbcode you could think of

Besides, what css would you use with size=xx attribute? Remember you can't use pixel-width font size in CSS, thanks to MSIE.

I never had any issues with it. My main hosting (and my old main one, too) do gzip almost everything on the fly (including all html, xml, css, js for sure... I think it skip it for images, video, and the like). If your UA can't handle it, there's a mechanism that take care of it (it doesn't get sent gziped).

Frankly, a server that doesn't gzip most files nowadays... not a good server. From the server point of view, it's mostly a good thing : a little more cpu for much less bandwidth, and faster transaction closing. From the user point of view, it's all beneficial... pages load much more faster.

The only case I can think of where someone might consider not doing it, would be if he had a dedicated box already cpu limited and more bandwidth (and I mean, like 50 to 200% more) available for free. That may seems as a good trade off for him, but he would only slightly delay a needed cpu upgrade, and punish his users. And with cable and some dsl subscriber having download quota in some countries, it's very much unpleasant to them.

On the thread view, check the end of the page. There, you'll see the moderation tools: sticky, move, etc.

True, to be as useful as possible, a wiki require some planning ahead, and a tight hand at first to get everything organized (or this can turn into the old Mediawiki's wiki).

But whatever the front and/or tech selected, a way to include the community (or part of it) in it would help free some time for the dev team to code more

Textpattern and Mediawiki have it in core, to name just two software I use frequently; I'm sure there are a lot other ones.

Seems perfect. Thanks.

With a proper documentation, maybe something user improved like a wiki?

Extension writers would have to internationalize their plugin anyway, wouldn't they? Or more exactly, they either would (and in that case, if they can account for specific lang string, I think they can account for specific localized clean URL string... they are all strings after all) or wouldn't in the first place (and in that case, it doesn't really matter).

I understand this is a little more work, and you want to get 1.3 out of your system right now, but as a forum user and/or a forum owner, how would you feel if the punbb.org URL where in Euskara, or Chinese? See what I mean?

Beside, even if it's not a PunBB core capability, I believe a lot of non English forum owner will edit their rewrite file to localize them (it doesn't require any PHP skill), and some lang pack author would provide them anyway. So if that would break extension because it was not planned from the start, well, they will break for some people anyway

Hence my first question in my first post...

Sorry about the sidetrack. I just wanted to be sure I read the revision correctly, and to point it out the issues with it.

That's the biggest issue yup, but not only.

It also means that every external link inside PunBB would be almost force opened in a new window for everyone, and that's just wrong behavior, that kind of thing should be controlled by the end user, not the software writer or the webmaster.

In my opinion:

- tagging external link (but I wander how you decide what's external and what's not... if we are on forums.punbb.org, would www.punbb.org/download/ for example be external?) is good, people could use that ground to build tools on it (and I would say, adding an "external" class with the rel attribute would be nice too).

- opening specific links as popup (like contextual help, smiley selection, things like that) is good too. But I would do it with the window.open() method, to avoid using a wrong DTD attribute, and because Firefox for example would open these popup while opening _blank in a new tab (less helpful here).

- forcing default PunBB behavior to open any external link on a new window (at least, trying to) is bad; again this should be the sole decision of the end user. And it -might- +will+ conflict with site-wide policy and existing tools on link, external links, and rel="external" links.

If you want to offer the new window capability to your users (because they are bugging you to... a classic thing), I would suggest going (vanilla, official extension, or personal extension; as you prefer) the checkbox way (add a small checkbox somewhere on the UI that says "Open external link in a new window?", unchecked by default, and use a cookie to keep that data).