You are not logged in. Please login or register.
PunBB Forums → Posts by Spartanicus
Pages 1
Just in case I'm missing something, what are the various functions provided by the "icon"?
I'm contemplating removing it from the code, afaics its function can be implemented in a simpler way by moving the "inew" class to the adjacent link to change the colour of the linked text.
I'd prefer to move all PunBB top menu's to my site's side bar. This worked fine for pages that use the main.tpl template simply by moving the <pun_navlinks> hook, but pages that use the admin.tpl template the "Admin menu" is inserted as part of the main content via the <pun_main> code hook.
Would it be possible to move the admin menu so that it is inserted by the <pun_navlinks> template code hook instead?
Never mind, I found the culprit myself by comparing my modded admin_categories.php against the original (a "." in the wrong place as a result of a mod to reformat the generated page title).
Probably as a result of my modding, selecting Admin -> Categories now produces a blank screen. Problem is that I can't link it to anything I did. All other admin functions seem to work fine.
I tried enabling debug mode, but no errors are shown.
The address in the address bar changes to http://mysite/forums/admin_categories.php, but nothing is produced (no page source).
I don't want to reinstall since that would result in loosing all my mods.
Any tips on how to go about debugging this issue?
Very easy to do actually. Just open header.php and change line 148 from:
(code snipped)
Just add a case for each of the *.php pages you want to have different H1 content :)
Thanks again for your help CodeXP, that's a considerable improvement. But I now realise that fully fixing this issue may require a lot of work which may be beyond the scope of a reasonable mod.
Afaics what needs to happen is that on pages other than the page generated by index.php the level of each header needs to be bumped up one level. On the page generated by viewforum.php for example what is currently the <h2> content (i.e. the name of the forum) should actually be the <h1> content.
This cannot be achieved with the type of mod that you suggested.
I am not happy about the current <h1> content on pages other than the index page. Pages on a site should all have unique <h1> content.
Currently if you were to use a bot to generate a site map, pages would be indistinguisable due to all pages having the board title variable as the <h1> content.
Only the index page should have the board title as the <h1> content, the search page should use "Search", the login page "Login" etc.
I'd like to mod 1.2 to achieve this, if someone could help with modifying the pun_title section of header.php that would be great.
Errm, you currently do
Not with JS disabled (haven't tried with it on).
I prefer not to login to a board until I have to, to post a message for example. When loggging on when on a forum page I get the index page after that, I'd like to be returned to where I was.
IMO the HTML title content is displayed in the wrong order in PunBB 1.2, it should list the most important content first (the reverse of how you'd list it in a breadcrumb bar). This also ensures that the most relevant bit will be visible on a (typicaly fairly narrow) browser tab.
In the process of changing this around in the source I also noticed what IMO is an omission, the title output of viewtopic.php is "Message title / Board title", IMO it should be "Message Title / Forum title / Board title".
To get viewtopic.php to include this, and undaunted by the fact that I am not PHP literate I copied and pasted this section from viewforum.php into viewtopic.php:
// Fetch some info about the forum
$result = $db->query('SELECT f.forum_name, f.redirect_url, f.moderators, f.num_topics, f.sort_by, fp.post_topics FROM '.$db->prefix.'forums AS f LEFT JOIN '.$db->prefix.'forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id='.$pun_user['g_id'].') WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND f.id='.$id) or error('Unable to fetch forum info', __FILE__, __LINE__, $db->error());
if (!$db->num_rows($result))
message($lang_common['Bad request']);
$cur_forum = $db->fetch_assoc($result);and then I changed the $page_title line into:
$page_title = $cur_topic['subject'].' - '.$cur_forum['forum_name'].' - '.pun_htmlspecialchars($pun_config['o_board_title']);This displays a forum name, but it is the wrong one. Any tips on how to do this proper?
This doesn't qualify as a "must have" feature, but personally I'd like to see navigation support via <link> elements natively supported in PunBB 1.3.
<link> elements allow a UA to map keyboard shortcuts to limited set of predefined navigation actions. The ones that I've found useful are: "home", "copyright", "author", "first", "up", "last", "prev", and "next". An example would be <link rel="next" href="?id=23&p=2">.
The accesskey attributes used by PunBB 1.2x have the drawback that if supported the keys are likely to be specific to that one site (one type of forum software in the case of PunBB), they are likely to interfere with a UAs native keyboard shortcuts, and there are very few shortcuts that can be considered safe for use if an author wants to avoid clashing with the native keyboard shortcuts defined in the various browsers. This is why the accesskey attribute is widely considered as harmful to accessibility. A <link> based navigation system doesn't have any of these drawbacks.
For most sites it is difficult to argue the practical usefulness of inserting a <link> based navigation system. IE has no support for it, and most people who use UAs that do support it will not be aware that a site offers such a system due to their browser being configured not to show the <link> navbar. Web discussion forums are IMO an exeption, many users use a certain forum site often. The site's forum introduction message and "Help" section could point out such a feature, explain the benefit, how to use it and what browser's have support for this feature. It brings Web based forum/application a step closer to the facilities offered by a local application.
Opera has some keyboard shortcuts pre-assigned to certain <link> actions (four from the above mentioned set in Opera 8.x, two in Opera 9), more can be configured by the user IIRC. Mozilla Suite/Seamonkey has native support for <link> based navigation, AFAIK there are extensions for Firefox. I haven't checked on the current level of support for coupling keyboard shortcuts to <link> actions in the Mozilla family of browsers. I don't know about the support in other browsers.
The link elements would have to be generated programatically, AFAICS this should be easy to do and not require any significant resources.
One example of a useful purpose would be to enable users to use the keyboard to navigate to the next page in a multi page message thread or multi page index. Or use the mouse via the <link> navbar that Opera and Seamonkey have. It may also be possible to use client side Javascript to dynamically redefine the action of for example a "Next" link to move to the next message instead of the next page if a user has used a fragment identifier link to bring a particular message in a thread to the top (by checking the address in the address bar for the presence of the fragment ID).
Apart from enabling keyboard navigation there is also the advantage of bringing structure to a site which otherwise is only a collection of pages to for example search engines. For example the pages of a paginated discussion thread can be linked together. I doubt if any SE actually makes use of this information, so on this aspect there are probably currently no practical advantages from doing this.
I agree that PunBB silently failing when a client does not access cookies is bad. We need to work on that for 1.3. That doesn't mean we should implement session support though. I strongly dislike URL-propagated session IDs. They're ugly, insecure and it just feels like a big hack.
Great to learn that the silent failing issue is being considered for a fix. I'd like to stress that I'd be quite happy if PunBB were to ask a user to allow cookies for a site if they are rejected initially. I'd also again like to mention that I do appreciate the currently clean PunBB URLs.
I'm all for spambot protection, but as someone already pointed out, I don't believe there are any good protection schemes that are also truly accessible.
Perhaps my worry about being spammed will turn out to be unfounded. The current spam protection method of emailing a password to a user does create a bit of a barrier in itself, it requires users who try to avoid spam to trust the forum's administrator not to use the provided email address inappropriately.
Indent offset for PHP generated HTML to fit into existing site code (use the indentation from the template?)
More consitent indentation of <div>sRickard wrote:Finally someone who's on my side! I've been referred to as the indentation nazi
For what it's worth I certainly appreciate the indentation, after a bit of experimentation the PunBB code is now an almost indistinguisable part of my site code.
Once again thanks for having done such a fine job.
I'm not really arguing with you to turn it on, I just want to know why you turned it off.
Privacy concerns, I don't want to be tracked. Nothing to do with shady activities, I primarily object to the type of tracking used to gather information about my interests and the consequent targeted advertising.
Selectively dealing with cookies is a royal bother, so the easy way is to simply not accept any.
Note that I am well aware of other tracking methods based on IP logging and/or reverse DNS, but few go to that length.
Spartanicus wrote:Btw, there is no XHTML1.2.
No, but there is a PunBB 1.2.
Ah, since your remark was made whilst discussing HTML vs XHTML I took it to be referring to that.
Spartanicus wrote:People switch stuff off for a reason, telling users to stop doing that or arguing that "there's nothing wrong with cookies" is not a good solution. Usually when I encounter a site that insists on cookies (or javascript) I find a better site, did I mention that I'm the obstinate type?
Yeah, it's just that, nobody has every given me a valid reason to turn them off. Right, if you want to turn them off for some pages, not my problem, but give me at least one reason why not accepting cookies on a board that you want to log in to?
There you go again, arguing with a user about their choice. Not a good solution. My site development philosophy is to not rely on any optional technology, that includes CSS, images, javascript, cookies, Java, Flash etc. etc. The PunBB developers have made a considerable effort to produce accessible forum software with fine results. The reliance on cookies and the "switch them on then" or "what's the problem" response is therefore rather suprising. This isn't about catering to my particular quirks, blocking all cookies is not uncommon. While it may only be a single digit percentage of people doing this, as I've stated before I consider not relying on optional technologies a fundamental mark of quality authoring, figures don't come into it (even though a few percent most certainly matters a lot in my trade).
Spartanicus wrote:Everything, or nothing, depending on your angle. This isn't a discussion for this board, my opinion on XHTML is documented here: http://www.spartanicus.utvinternet.ie/no-xhtml.htm
Those arguments are all true, but that doesn't provide a reason to go from XHTML to HTML, does it?
If the reasons in favor of a technology are bogus then adopting the technology is unwise, if only not to further the bogosity.
As long as it's semantically correct, valid and accessible, what's the problem? (Yes, 1.2 lacks some accessibility, I'll give you that
)
Certainly structural and semantic correctness is what it is really about, but HTML has the exact same features to express those. Btw, there is no XHTML1.2.
I don't see the problem with cookie dependancy in itself, but yeah, a message telling whoever turned it off to activate it would be neat.
People switch stuff off for a reason, telling users to stop doing that or arguing that "there's nothing wrong with cookies" is not a good solution. Usually when I encounter a site that insists on cookies (or javascript) I find a better site, did I mention that I'm the obstinate type? 
But the drawback of the alternative will probably be that a session ID will have to be stuck on the URL. This would degrade the currently very clean PunBB URLs, but if used only for clients that do not accept cookies I'd consider it a big plus.
I've participated on forums that employ at least 3 different sorts of board software, all of them work without me having to accept cookies. At least a routine should be used to check if cookies are accepted (by immediately reading it back), and the user informed that PunBB doesn't work without cookies if that fails.
The markup, along with all CSS will be rewritten for 1.3, very much with accessibility in focus. The above things will be addressed, accesskeys removed.
Nice to know that development is continuing and that these issues were already known. Meanwhile it was not much work to remove the accesskeys from the current version.
What's wrong with XHTML?
Everything, or nothing, depending on your angle. This isn't a discussion for this board, my opinion on XHTML is documented here: http://www.spartanicus.utvinternet.ie/no-xhtml.htm
Will probably never happen, since once a protection is in there by default, it will be bypassed by every bot in a matter of days
PunBB seems more vulnerable to spam bots than some other forum software (using CAPTHCA's for example). I'm not suggesting that there is a 100% effective method, but the amount can be drastically reduced.
PunBB not being the feature bloated software that most people go for, it seems to be appreciated by a niche market. I'm guessing that the resulting lower installed base doesn't make PunBB systems an attractive target to write the type of bot routines for that would be required to defeat the more sophisticated bot protection methods.
It will be easy to install your own protection though with the new extension system.
Not an option for me as a non programmer, unless there is an existing extension.
More granularity for board features (for example board stats inclusion, although easely removed from the code)
Sorry, don't get this one
PunBB places some type of user statistics info on one of the main user pages that I didn't find useful. It would be nice to be able to disable that through the administration panel, rather than having to cut it from the code as I did.
After experimenting with ikonboard, e-blah and PunBB I've realised that only PunBB offers the sort of quality that I was looking for. As someone who is very particular about quality (aka an anal twit I didn't like certain things about PunBB initially, but compared to the others that I've tried it is streets ahead. So PunBB it is for me, I'm a convert.
.
I'd like to thank everyone involved in making PunBB into what it is for having done such a fine job.
Positives
---------
Templates
Formatted/indented HTML
Nice URLs and titles!
Header usage resulting in good document outline (very rare)
Good quality UI
Not just valid HTML Strict code, but skillfully crafted HTML and CSS (very rare again)
Street lenghts ahead compared to e-blah and ikonboard (which are not the worst by some margin)
Being the anal twit that I am, I have to have a moan:
Not my choice
-------------
Cookie dependency, silent failing if not enabled
Definition list usage (not used semantically)
Float "CSS layout" (not a good way to create a page layout)
Accesskeys (harmful to accessibility)
XHTML instead of HTML (easy to change tho)
CSS to verbose & fragile (difficult to integrate into an existing site design)
And my
Whishlist
---------
Spambot protection
More granularity for board features (for example board stats inclusion, although easely removed from the code)
Single step creation of a new forum and it's name
Option to not to offer users to choose a stylesheet (deleting all but one of the CSS files works, but it's a bit silly to offer a choice of one)
Indent offset for PHP generated HTML to fit into existing site code (use the indentation from the template?)
More consitent indentation of <div>s
Finally the provisional result of my wrestling match with PunBB's code (the actual board is not online yet): http://homepage.ntlworld.ie/spartanicus/punbb.png
And there isn't a way to get around the use of cookies (since session cookies are still cookies) without doing something like putting the session ID in the URL.
Out of curiosity, why is it unacceptable?
a) Not relying on optional components being enabled on the user system is a fundamental rule of web authoring.
b) A not unsignificant number of users will have JS and/or cookies disabled, or have it disabled for them with no option for the user to turn it on. Currently PunBB fails silently if cookies are not enabled on the client system.
Afaics punBB relies on both JS and cookies being enabled, either is unacceptable to me.
Has anyone created a modified version that removes this dependency?
Pages 1
PunBB Forums → Posts by Spartanicus
Powered by PunBB, supported by Informer Technologies, Inc.
