1

(9 replies, posted in PunBB 1.3 bug reports)

It is indeed pun_stop_bots, which is a shame because it's the only effective method to stop bots, since captcha recognition is passed like it was child's play nowadays and my forum gets tons of spam if I disable the smart questions of that extension but enable captcha.

So well, the problem lies in the fact that a hidden input is used for the message field, which is silly since a text message may as well include double quotes (", " html entity), which break the value="" definition to one character before the first double quote occurence (hence the message is truncated).
Easy but ugly workaround (it works, so who cares):

Open extensions/pun_stop_bots/views/question-page.php

Where it reads:

<input name="<?php echo $hidden_key; ?>" value="<?php echo $hidden_value; ?>" type="hidden">

insert instead:

<!--<input name="<?php echo $hidden_key; ?>" value="<?php echo $hidden_value; ?>" type="hidden">-->
<textarea name="<?php echo $hidden_key; ?>" style="display:none"><?php echo $hidden_value; ?></textarea>

then refresh hooks from administration/extensions, and you're good to go.

HOW TO TEST:

Before workaround, try to post as guest a message containing one or more double quotes, it will get truncated before the first double quote.

After workaround and refresh hooks of extension, insert the same message, no more truncation.

you don't need to setup this extension, it's automatically active after installation, and sends out notifications as soon as someone who's not the admin writes a post; the behaviour cannot be changed unless you manually edit the source code.

bump: update to the language files

...wait a second, I just reviewed the code of the extension, and the admin email address is not taken from the forum_user['group_id`] thing... that's just a check I make to avoid sending to the admin notifications of his own posts. I've forgotten my on code tongue
Anyway, apart from the mail() function being used instead of forum_mail() of which I know nothing, and do not have the mental energy to look into (;)), all the variables passed to it are legit punbb variables:
$forum_config['o_admin_email'] is the admin email address as specified in the config array of punbb
$forum_config['o_board_title'] same as previous for the forum title
$base_url and $new_pid are values that are defined prior of calling the extension's hook and refer to the "root" of the forum url and the "mysql_insert_id" of the last insert query of the last post...
so if you're getting the mail sent to that other user it is because $forum_config['o_admin_email'] points to that address instead of the admin's address.
I'd still like to be pointed to the documentation of forum_mail in order to decide if it has benefits, especially regarding this situation of yours wink

you're both right, but I have NO idea about your issues big_smile
The mail address as specified has been suggested by Grez, who indicated it would be better to use the mail address of whoever user is registered as "admin", instead of the user id 2, which is the default admin id but could not be the admin after all in an existing punbb installation.
So @keydog, the user whom the mail is arriving to, must be registered as "admin" in said forum (the "right" one, as I'm accessing just the DB tables that belong to the forum in which the extension is installed into), maybe there are two admin users in there and my extension is fetching the address of the first one it finds, which may not be the one you're looking for?

@nhodges
I'd be happy to update the extension to make it more punbb compliant, alas I have no idea how the forum_mail() function works, and what are its benefits over mail(), but if explaining that is a matter of a minute and you're willing to go over it, I may as well update the code.

seriously, I alone manage 3 websites of my own, and I do this in my free time since I'm a dentist, so I already know I wouldn't be participating at all. My activity in here will be just to give back to the community those things that I would do anyway, for myself because I need them, that is a nice italian translation, and maybe in the future a mod to validate sef urls, but after that I'll probably be gone big_smile

not much needed probably, maybe helping a little. Googlebot checks the first 70chars of a webpage title, so as long as the topic title stasrts at the beginning of the <title> tag, the keyword weight shouldn't be changed even if there are other things after.
Anyway, I bumped into that request already, didn't participate it as it wasn't a priority for me, anyway such a tiny change is surely something to be considered in next release, maybe with a checkbox in settings, if not else, to make the title cleaner; anyway, IMO that should be a no-brainer to modify for punbb developers who already know the code big_smile

And regarding my fix, I'm not saying I will surely work on it, nor that it will be very soon, what's sure is that SEF url validation IS a priority for me so I will be at least willing to correct that wink

ahah well, and I'd need 36 hours per day for that! big_smile

9

(25 replies, posted in Feature requests)

Grez wrote:
ephestione wrote:

Even if I'd be dead curious to see how a completely <div> driven forum would perform

Actually, you can - this forum doesn't use tables at all big_smile

yup  roll
Came back here exactly because of that, I was checking the output source to verify something else (first time I do with punbb) and I just now realized what you say... well props for PunBB!
I was betting every forum out there was based on tables... this leaves me plenty of space to customize the layout in the future if I so decide.
To OP, for instance, you could have a special css load when mobile browser is detected, that  defines:

span.icon{display:none}

10

(25 replies, posted in Feature requests)

KeyDog wrote:
ephestione wrote:

the mobile browser detection worked

How do you do that? What script/code?

this is what you need http://detectmobilebrowsers.mobi/

fantasma wrote:

ah ok, when have you place update files in wiki page?

they are already there. I updated the file punbb-1.3.4-italian.zip, download it again from the wiki page and it's the newest version.
If I will update the translation in the future, when I write here about the update, it means that file in the wiki has been already uploaded in the new version.

fantasma wrote:

what?

just like I wrote, I used the <board_title> parameter tag in all the templates, but it only works in a couple of them, and is not recognized in the others. So I corrected that and removed the parameter from the non supported templates

Thank you for putting this into code wink
I knew my approach was over-simplistic, as it basically assumes you installed punbb fresh, or something like it, and doesn't take into account other admin users.
It was between 1am and 2am while I was coding this and it was a straing enough, for a total newb of punbb, to find out the globals for admin mail and board name tongue
Will update it right away wink

I made, briefly tested and hence released a mini-extension that, whenever a user who's not the admin (uid!=2) posts a new reply/topic anywhere in the forum, sends a mail to the preconfigured admin mail with a link to said message.

It is only recommended to forum admins who manage very "silent" forums and want to be warned of new activity when it occurs instead of having to check regularly.

More information (english) can be found here: http://www.ephestione.it/punbb-e-mail-n … extension/
una descrizione più approfondita (in italiano) si trova qui: http://www.ephestione.it/it/punbb-e-mai … extension/

The extension's zip has been uploaded to the wiki 1.3 extensions list, http://punbb.informer.com/wiki/lib/exe/ … extensions (which only contains PNG files actually, this goes beyond my comprehension, anyway the uploader accepted my zip file, so you can find the pun_newpost_mail_notify.zip file in there.
Here's the direct link (thanks KeyDog wink) http://punbb.informer.com/wiki/_media/p … notify.zip

v 1.1 8/8/2010 later that morning, updated as per post #2 by Grez, thanks tongue
v 1.0 8/8/2010 1am very first release

Another update. Corrected an assumption error I made in mail templates.
I thought that <board_title> was always substituted with the forum title, but apparently that's not the case and it can only be used in some mail templates but not all. Removed that tag from the non working templates.

bella fantasma wink
Thank you for the aknowledgement and website link! Possible new updates will be posted in this thread as ups, and uploaded to the usual wiki page

Updated the pack, revisited all the mail message templates, plus corrected several other errors.

I give credit to whoever is the author, maybe you can just pop in something like "ephestione ha corretto molti piccoli dettagli nei file".
Actually, I plan to correct several other things in the future, for example in user profile settings there is "Identita" instead of "Identità" and things like this were all over the translation.

19

(25 replies, posted in Feature requests)

Mobile browser layout is a nice topic.
CSS is the key obviously, even if CSS and tables do not really go hand by hand, conceptually, and that's why divs are now the only "pro" way to design websites; still, tables are kind of obligated for a forum, since they are for "tabular data" and a forum is exactly that. Even if I'd be dead curious to see how a completely <div> driven forum would perform, possibilities would become endless big_smile
That being said, all you need would actually be a "style", with no special additional functions, as the mobile browser detection can be made with an external script and the style can be preconfigured if an $ismobilebrowser variable is set; or that could be made into an extension that automagically detects mobile browsers and switches to mobi.css.
So, take a CSS that you like, oxygen is simple enough, and, alas, work it out from scratch redefining the sizes in px, maybe setting the leftmost <td> to width:0; or display:none, who knows.

Anyway, I just out of curiosity tested my website with pubb. As I've managed to dynamically integrate punbb, so the other php code that triggers for website header and footer html code still works, the mobile browser detection worked, and move the sidebar menu to top, leaving all horizontal space for punbb. After that, everything is "as normal". I sometimes browse XDA from my HD2, and the experience is the same, the page is perfectly visible in opera mobile 10, by scrolling to click navigation links, and zooming in the text is reflown nicely.
Cosider that keydog is right, in the future a lot of users will browse with mobile phones (I myself get quite some hits from iphones -hate them- and blackberries, even if not by far close to 20%, more like 2%), but mobile phonesof tomorrow will have plenty of a resolution to display a "normal" webpage with no hassles, wvga is still 800px wode in landscape mode, same as the old 15" crts, which were widely used up until not long ago. Netbooks are 1024px wide, so that doesn't make that huge of a difference.


EDIT: the official punbb forums really need to install garciat's gravatar extension tongue

The "Views" and "Replies" column headers in forum view could be made into links to order ASC or DESC the topics by number of views and by number of replies. The "Last post" header would need to be given the same function obviously, to restore the default order.
Just thought about it, since I finally completed the migration from my old forum, and I was curious to see which threads got the most "early views" from google

For a true SEO of punbb, which goes past the frivolousness of the SEF URLs, there is something which I was convinced was implemented already, but actually isn't.
Having search engines index "junk" on your website is not productive; by "junk" I mean everything which is not content related, for example the login page of the forum, or the subscribe "popup" page.
Those do not even need to have a SEF URL, they should not be visited by search engines at all.
Adding "NOIDEX" in a meta tag apparently has no effect other than on private implementations of google search, so it would definitely be a good idea to have all links to "not content rich" pages ignored via a "rel=nofollow" attribute.
Example:

<a href="[...]/punbb/login.html">

becomes

<a href="[...]/punbb/login.html" rel="nofollow">

This same thing should be done, as previously stated, for "service" links, login/logout, subscription/unsubscription, search, and all the lilkes.
Maybe it doesn't really help significantly with search engines, but I see a lot of "elegance" in the PHP code of punbb, so there is no reason to add even this one more bit of "delicacy" to the source tongue

Thank you for the positive suggestion wink
I may be bright, but I am a dentist with time on his hands thanks to the approaching vacation period. I am bound to work it out somehow sooner or later, even if only after the launch of the migrated-to-punbb forum. I won't miss to publish my solution in here to be used maybe a starting point for next release

hey there wink
I'll be dead honest here: I didn't bother to check whom that translation was by, I just went to the official download page of this website (informer.com) and downloaded it, noticed there were several things I didn't like, and corrected it for my personal interest. Then I thought I might as well share it; in case I circumvented any "distribution lock" for the translation, I am sorry, you can remove the link from the wiki page yourself.

By the way, I didn't complete the italian translation; the strings that were left in english are still in english (the admin panel, shortly). I did correct a lot of "brutte espressioni" though, as well as other errors. I also updated the stopwords list to an italian stopwords list, as you can read in the previous posts of this thread.

every single self-made SEF url fucntion of every site I manage has this kind of check, after all SEF URL validation is always a good thing, otherwise it isn't really SEF wink
Implementing it when you already know the base code (in my case, I wrote the code of my websites, so i would know big_smile) is a no brainer; on the other side, having to learn the mechanics behind rewrite.php and all its includes, in order to devise a method to update it and mantain its basic functionality and at the same time adding your required feature, is utterly bothersome, to say the least big_smile
I'd definitely prefer having an official update addressing that issue, and for the time being I could write an external php script that intercepts the calls to /forum/topic([0-9]+)(.*)$ and checks whether $2, stripped of -p([0-9]+)$ if that's the case, matches with the url-friendly title of the topic no. $1, if yes transparently redirects to the topic url, otherwise adjusts the url and redirects to that.

Obviously, all this is IF I can find the time. Which is not certain at all. Also considering it would be a very temporary and ugly solution, and I don't like to waste time on temporary things.

too lazy to check first if there was a wiki upload tongue
sent it right away, removing link from first post