You are not logged in. Please login or register.
PunBB Forums → Posts by GUI
I don't use them, but I know a total of 1 person who does. I doubt it would cause much of a ruckus if they disappeared, but I think the people that do use them, like them. Is there any reason for removing them? Because even if it's only a tiny, tiny percentage of people using them, this doesn't really seem like a feature that adds much bloat.
But do whatever. Just be prepared to face the wrath of the 3 people who vehemently love them.
I wouldn't even attempt to make things work in IE 7 beta. Nobody currently using it can legitimately expect things to work. Plus, a lot of things will be fixed by the time it's actually released. I just read something good on this... ah, here it is. http://meyerweb.com/eric/thoughts/2006/ … ing-ie7b2/
Oh, oh, oh... My bad. Sounds cool. 
Maybe he is thinking that an extension could actually add something to the templates in which case it would have to add the same thing to all the templates including the custom ones.
Yeah, I think something like that. Again, I'm not really sure how it will all fit together, but you seem to be saying that things like PMs could be handled through extensions. It seems like the extension would have to include a template file of some sort for displaying the lists and messages themselves. But let's say that you have one theme installed that handles list display using tables, and one that displays lists using divs. If the PM extension displays things using tables, and the user is using the divs-based theme, then it seems like the PM system would show up completely unstyled.
I'm curious about the multiple styles thing. One thing I really like about PunBB is that everything is based on the same markup, so if I add a mod, and change the html in on place, I won't have to update the markup in each theme I have installed. Will it still be possible to have multiple themes that only differ by stylesheets, and still share the same html? Because if not, it would make me cry.
The only other icky spot I see, is how extensions will fit into the multiple sets of tpl files. While the nifty extensions (looks great, btw), might alleviate some of the need for updating the html in multiple themes, it could also become a problem if the extension always inserts a specific block of html code, and that doesn't really fly with a certain theme. But I have no clue what I'm talking about, since I don't know how things are really fitting together right now. I think I still prefer the idea of keeping markup sexy and uniform, and leave the themeing up to the style sheets, but that's just my uninformed opinion.
I've had this happen as well. And it just seems to happen to one user in particular. I was going to try to track it down, but never did. The user said it didn't happen on an alternate account he had, but after completely switching user accounts, it still happens to the new account. Me thinks it's something on his end, but I can't figure out what it might be.
This problem also screws with the pagination, because when the joins for viewtopic occur, the post data gets tripled (or however many times the user appears to be online).
Meh, I don't like changing the breadcrumbs. What you describe is actually how phpBB treated topic breadcrumbs, but before switching, I changed it to behave like punBB.
But now that you mention it, next/previous links might be nice since the text is a slightly easier target than those tiny numbers. You could just create two rows of stuff, and even throw in some next/previous topic links to fill in the empty space. I always liked those. Or something like that..
I've brought this up before, but I think I've finally tracked down all the last nagging problems. Basically, issues arise with a larger forum and the extern.php file. The RSS feeds hadn't been a huge issue because not all that many people use them, and they weren't getting hit constantly. However, when I went to place a listing of active topics on our front website, including extern.php would prevent the page from loading for 10-20 seconds, and it would eventually stall the entire server.
Here's a basic query for reference:
SELECT t.id, t.subject
FROM topics AS t
INNER JOIN forums AS f ON f.id=t.forum_id
LEFT JOIN forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3)
WHERE (fp.read_forum IS NULL OR fp.read_forum=1)
AND t.moved_to IS NULL
AND f.id IN(1,2,3,4,5)
ORDER BY t.last_post DESC
LIMIT 15The first problem with this is that with punbb's default indexes, the query is using the index placed on the moved_to column. This makes sense, but when it comes to sorting the results by either the last_post or posted columns, things take a very long time.
My first instinct was to place a multi column index with both moved_to and last_post. However, the problem with this, is that if you sort by the posted column, that index won't work (or vice-versa). And simply creating another multi-column index won't work either, since it picks the first index it finds that contains moved_to as the first column.
After a bit of head-banging, I found the solution is to join the topics table onto itself, so no multi-column indexes are needed.
With that taken care of, and indexes placed on both the last_post and posted columns, queries without a restriction on the forums perform quite nicely. However, as soon as you throw in a where clause on the forums, things break down once again. The solution is to change the forum's join from an inner to a left join.
So all in all, here are the changes I made to extern.php...
The $order_by variable becomes:
$order_by = ($_GET['action'] == 'active') ? 't2.last_post' : 't2.posted';The RSS query becomes:
$result = $db->query('SELECT t.id, t.poster, t.subject, t.posted, t.last_post, f.id AS fid, f.forum_name FROM '.$db->prefix.'topics AS t INNER JOIN '.$db->prefix.'topics AS t2 ON t.id = t2.id LEFT JOIN '.$db->prefix.'forums AS f ON f.id=t.forum_id LEFT JOIN '.$db->prefix.'forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.moved_to IS NULL'.$forum_sql.' ORDER BY '.$order_by.' DESC LIMIT 15') or error('Unable to fetch topic list', __FILE__, __LINE__, $db->error());The HTML query becomes:
$result = $db->query('SELECT t.id, t.subject FROM '.$db->prefix.'topics AS t INNER JOIN '.$db->prefix.'topics AS t2 ON t.id = t2.id LEFT JOIN '.$db->prefix.'forums AS f ON f.id=t.forum_id LEFT JOIN '.$db->prefix.'forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.moved_to IS NULL'.$forum_sql.' ORDER BY '.$order_by.' DESC LIMIT '.$show) or error('Unable to fetch topic list', __FILE__, __LINE__, $db->error());And then the following indexes added:
ALTER TABLE `topics` ADD INDEX `topics_posted_idx` (`posted`)ALTER TABLE `topics` ADD INDEX `topics_last_post_idx` (`last_post`)Yeah, I know, two additional indexes, boo.. but it seems well worth it. Queries now only take a fraction of a second, instead of 20 seconds. Smaller forums may not encounter this problem now, but it's only a matter of time.
Ah, thanks, both of your issues should now be fixed.
I really hate writing the mod readme files. I have no problem hacking up the punbb code, but when it comes time to create the mod file, it just feels antagonizing. This is often why little mods I create never see the light of day. In an effort to combat my laziness, I've come up with a little tool that helps. It's not perfect, and doesn't do everything, but hopefully with time the kinks can be worked out and it can become more robust.
So how does it work? First, you have to setup two punbb directories: a virgin installation with unedited files and a second with your mod you've developed installed. After you're content with your mod working in the second directory, you throw things off to this script. In short, it runs a recursive diff on the two directories and discovers the changes. Where it can, it will automatically handle things, or it might have to prompt you for a few things. After it's finished you should have a dummy readme file with the bulk of the work done. Some minor things might be wrong or off, but if you let me know what errors occurred, I can try to make the script better.
Now for the caveats... You have to be running *nix to use it (Mac OS X, BSD, Linux, etc). It depends on the Ruby and the diff command line tool. Error checking is nearly non-existant. If you give it bad input or anything else, don't be surprised if it explodes. This is my first little project in Ruby, so don't harass me too badly if the code is horrible, I'm learning. And, um, other stuff. Just ye be warned, this is an early version that seems to mostly work for me. I'm tired of looking at it, so I'm releasing it.
Grab it here: AutoMod
How to use: Setup the two punbb directories, one clean, one with the mod you want to create the readme for. Then from the command line:
ruby automod.rb clean_directory modified_directory output_fileI just remembered that as of right now, it will also wildly overwrite anything existing in the output file you hand it, so ye be warned.
Exactly. None of this makes much sense to me either. It's just that I don't have a ton of time to babysit the server to figure out what's going on, so instead me "fixing" things consists of me diving into the server and thrashing about until things are somewhat better. Perhaps not the best way to manage a server, but it seems to work. Wait, no it doesn't. 
Hopefully this summer I'll have some time to dedicate towards actually fixing stuff.
And Rickard has a semi-recent dump of the forums, so I'd also be interested in whatever results he comes up with.Or if I'm free this weekend, I can try running the same stuff on my server. The only one I'm semi-sure about is the poster_ip column not being indexed, since loading those admin pages has always been semi-slow. The other two problems, well, it makes sense why the queries are slow loading when I look at them, and look at the explain results, but again, why they're just slowing down now baffles me. Although one guy did mention that the "show posts since last visit" was always sorta slow, but definitely not to this extreme. Even stranger, the server is performing rather healthily. There are some spikes in MySQL's thread count, but other than that the server hasn't even gone over the 100% CPU usage mark. With phpBB it would hit over 180%.
You can usually increase performance by adding indexes, but you have to account the increased load these indexes put on the server during inserts and updates.
However, when the select queries are taking upwards of 30 seconds, usually I consider the possible insert/update performance hit negligible. 
The only thing I find strange is why these problems didn't rear their heads before. It's not like we've had a sudden and dramatic increase in load. I think MySQL has it out for me. Or perhaps I need to figure out just what I'm doing, and stop sucking at administering the server.
I haven't had time to really investigate any of these issues, but we've been having some speed issues, and there are just some of the culprits I've found. I mainly wanted to note what they were and what I did before I forgot. So ye be warned, this might just be me being index happy, but I seem to be in a never ending battle with MySQL...
The first issue I encountered isn't a huge deal since it's only from the mod/admin side, but still takes a noticeable hit. If you do a look up on a certain IP address, it can take some time, since the poster_ip column in the posts table isn't indexed. Indexing that seems to have fixed that up nicely.
Second issue occurs at least on the show new posts since last visit page, and maybe elsewhere. The problem arises in that it's using the forum_id index, which seems to make snese, but then when it has to go sorting it by the last_post column, that kills it. It seems as though adding a index to the last_post column will fix things nicely. It almost seems like a multiple index between the forum_id and last_post would be better, but things seem nice and peachy with just the last_post index (10-30 seconds down to a fraction of a second). Hm, and is the forums table even need to be joined on? Couldn't you just join the forum_perms directly to the topics table? Wait, this is all giving me a sense of deja vu.. Did I already go through all of this the last time I brought up indexes? Hm..
The last problem, which I haven't been able to tackle yet is the viewtopic.php. The query executes fine for relatively forums without a lot of posts, but in forums with a large number of posts, it can take a few seconds to execute. It's first limiting things by the forum_id, which is good, but then when it comes to sorting 8,000 records based on the sticky and last_post column, things turn not so nice. I tried a multi-column index, but MySQL didn't seem to like that.
In any case, these all might actually be due to my screwing around with the server and other funkiness. But, hey, maybe 1 out of 3 might help. I'm just doing some midnight rambling, but I'll try to confirm and further debug these over this weekend.
If it would be easier, I could hook you with an SQL dump of whatever stuff you needed. Unless, you had planned on importing the vBulletin database anyway. Whatever is easiest for you.
Although, I would think extern.php would still generate temporary tables on smaller boards, it's just that the effect wouldn't be as noticeable. But who knows how that crazy MySQL engine works, or if I screwed up indexing somewhere along the way.
Yeah, it was never as bad for me as everybody else was whining about. But occasionally I would experience some slow downs and MySQL was definitely not completely happy. Since fixing the viewtopic thing, it has been snappier, and MySQL has been acting great.
However, a fair number of temporary tables are still being generated by extern.php, but since we aren't being hammered with those requests, it's certainly manageable. Although, in its current state, extern.php isn't usable on the main website, since with that many hits, it really kills the server.
Hm, looks like 4.0.18. Which reminds me that earlier today, I was testing this on my local test server with the latest version of 4.1, and I thought I had discovered a much more elegant solution than all this forcing index crap. Although I think that might have had to do with not restricting which forums the topics belong to. Bah. My brain be fried. I'll tackle this again later this week.
Well, our forums have been running a day without the DISTINCT and it's been all peachy. No complaints of screwed up topics, and the server is much happier.
But semi-related, the extern.php is full of evil queries as well. A few months ago I tried to use it to show topics on our front page, but it immediately made MySQL go nuts, and slowed the load time for the front page way down. I soon discovered that the main query extern.php was calling was taking around 2 seconds to execute every time. I've finally got around to debugging it, and I think I have a solution. It's rather strange, but it seems to work. The culprit it seems is sorting the results based on the last_post or posted columns. I tried combined indexes, and all that jazz, but those only seemed to marginally increase speed. Strangely enough, it seems like using only a newly created index on the column your sorting by (ie last_post) returns near instant results. The main caveat being that MySQL doesn't want to use that index by default, so you have to force it. All very strange...
SELECT t.id, t.subject FROM topics AS t FORCE INDEX(topics_last_post_idx) INNER JOIN forums AS f ON f.id=t.forum_id LEFT JOIN forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.moved_to IS NULL AND f.id IN(4,2,5,29,10,15,16) ORDER BY t.last_post DESC LIMIT 10;The FORCE INDEX and the associated index being the only part I actually added. That consitently returns results within 0.00-0.01 seconds, compared to the 1-3 seconds previously. It seems like combined indexes would help with at least t.moved_to and t.last_post, but those seemed to have performance problems as well. I think. This all has me slightly confuzzled at this point, as I've been staring at this for too long.
I'm also wondering if you even need a to join the forums table onto this query, since you could easily join the forum_perms table using only t.forum_id. Switching doesn't seem to effect performance at all. Although, actually now that I think about it, since the last_post index is now being used on the topics table, it's probably wiser to join it as a separate table, so you can utilize its own index when restricting forums.
Another oddity was that the INNER JOIN of the forums table seemed to be creating the temporary tables. Switching it to a LEFT JOIN no longer generated temporary tables, but I think it ended up overall slower. Humph. I quit.
Anyway, I'll mess with this some more and clean it up later this week, if you don't beat me to it, and I'll let you know what I find out.
Our forums have recently been taking a performance hit. This may be completely unrelated to PunBB, but in any case, I went digging. I soon discovered that an extraordinary number of temporary tables were being created. Not only that, but they were nearly all disk based (even with an ample amount of memory allocated to MySQL's temporary tables). I finally found the culprit to be this query within viewtopic.php:
'SELECT DISTINCT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM '.$db->prefix.'posts AS p INNER JOIN '.$db->prefix.'users AS u ON u.id=p.poster_id INNER JOIN '.$db->prefix.'groups AS g ON g.g_id=u.group_id LEFT JOIN '.$db->prefix.'online AS o ON (o.user_id=u.id AND o.idle=0) WHERE p.topic_id='.$id.' ORDER BY p.id LIMIT '.$start_from.','.$pun_user['disp_posts']Even on my tiny test bed forum, every execution of this creates a new disk-based temporary table. Messing with indexes seems to do nothing, but removing the DISTINCT fixes things up. Looking at the query I can't really figure out why the DISTINCT is even needed. Making the query, um, non-distince doesn't seem to change the results either.
I'm still wondering why I hadn't noticed this before/why performance hadn't dragged before. It makes me think our problems aren't necessarily related to this, but creating a temporary table for every viewtopic.php seems bad. Unless, of course I've screwed up my files or databases, but I'm fairly sure my test bed is running a stock configuration.
I'm a huge fan of FreeBSD and its ports collection, but this seems like a bad thing to somehow mangle into working via an online administrative interface. You shouldn't be able to overwrite your files with the permissions your web server runs as. Plus, this would get infinitely more tricky with any sort of modded board. And if anything were to fail in the process, you might be left without a functioning board. Self updating tools just seem icky to me.
Now a FreeBSD port for PunBB might be a good thing, to at least make initial installs easy. And it could even do upgrades for unmodified boards.
As far as I know, UBB.classic was the old school forum software, where everything was stored in bizarro text-files, and static HTML files were generated from that. I built a UBB 5.x to phpBB converter that does most of the text parsing. If you wanted a copy of that let me know, and I'll try to dig up my most recent workings (the one on my website is fairly old).
Well, in any case, sorry to step on your toes. I'll try to get something out in the next few days.
Durn, why didn't I see this before I embarked on my own topic splitter/merger mod tonight? Nothing like duplicating efforts.
In any case, I built mine from scratch for 1.2, so, well, that might save you work from finishing out your version of this. Or you might take one look at mine, and declare it utter crap. Mine also does merging, which may not be desired, and I'm still trying to nail down a few of the nastier sides of merging. I'm not quite ready to package it up, but I can probably release it in the next few days. In the mean time, the moderators at our forum are beta testing it on our production forums. Yeah, I like to live on the wild side.
The following:
[quote="test"]This [i]is[/i]
a test[/quote](edit: imagine that quote tag without quotes. Otherwise I can't get it to display properly).
Will result in this:
This isa test
(notice the lack of line break)
It will happen with any tags inside of a quote, if the quote tag is referencing another poster, and is used without quotes. I haven't really looked into it, but some initial playings point to the need for an un-greedy thing on the quote regex:
$a[] = '#\[quote=("|"|\'|)(.*?)\\1\]\s*#i';(Line 70, on whatever version of the test board I have running.. but this problem is still in the latest).
But me thinks that acting ungreedily, that could cause problems with usernames with quotes and apostrophes in them, but I haven't had time to do much more with this.
I certainly didn't go the pretty URL route for search engine reasons, but somewhere in the transition from phpBB and ugly URLs to punBB and pretty URLs, Google started loving our forums. I'll even find our forums in the search results for random personal searches I do, and that never used to happen. I suppose you could also attribute it to the better XHTML markup of the pages, but something tells me page validity can't be weighted that much. Maybe search engines do like the pretty URLs. <shrug>
PunBB Forums → Posts by GUI
Powered by PunBB, supported by Informer Technologies, Inc.