You are not logged in. Please login or register.
PunBB Forums → Posts by damaxxed
It depends on the MySQL configuration of the user's system:
1) query_cache_type = ON
MySQL caches every query, except ones flagged with SQL_NO_CACHE (e.g. query always changes SELECT SQL_NO_CACHE * FROM online WHERE logged<NOW()-60*5)
2) query_cache_type = DEMAND
MySQL only caches queries flagged with SQL_CACHE (e.g. query fetches rarely changed data SELECT SQL_NO_CACHE cat_name FROM categories)
No, it's not necessary to use rel="nofollow", I just wanted to save Googlebot's time ;-)
Yeah, NOINDEX is enough, but FOLLOW is really needless, because
1) afaik FOLLOW is standard and you don't need to explicitly use it
2) i can't imagine any single case, where the permalinked-post-page links to a page, which isn't linked by the topic view
1. It's my understanding that if the query cache is enabled, applications need to do nothing special to take advantage of it. Is that wrong?
You understood it right, it's my fault that I forgot to mention one thing: Only by using the cache-flags, the positive cache effect, can be achieved, when the user set query_cache_type = DEMAND - elsewise nothing would be cached, because that cache_type only caches on DEMAND
By using those flags, PunBB can work with both cache_types great.
2. The query you're referring to has inherently volatile data, since the table is updated anytime someone views a page. I'm not sure how much of a speedup you'll get even if you could try to cache the result of the query. Also, as you pointed out, there's decreasing accuracy as the online timeout increases, which is less than ideal
Well, that was the worst example i could choose.. (online uses the MEMORY engine under MySQL, there is no huge benefit by caching such a table) It think it would be best to forget the second half of my post ;-)
Hi
idea: Why don't you use the MySQL query cache to speed up queries? Especially static queries like the query that fetches the category names, would speed up.
I know, this is MySQL-specific, but I'm sure the other database systems have something comparable.
To optimize PunBB for both, query_cache_type = ON(caching all queries) and query_cache_type = DEMAND(only caching special marked queries), you could give each query flag:
* SQL_CACHE for queries that speed up much, when cached, e.g. the following query is executed 10x faster on my system after being cached
SELECT c.id AS cid, c.cat_name, f.id AS fid, f.forum_name, f.forum_desc, f.redirect_url, f.moderators, f.num_topics, f.num_posts, f.last_post, f.last_post_id, f.last_poster FROM categories AS c INNER JOIN forums AS f ON c.id=f.cat_id LEFT JOIN forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=1) WHERE fp.read_forum IS NULL OR fp.read_forum=1 ORDER BY c.disp_position, c.id, f.disp_position* SQL_NO_CACHE for queries that don't speed up or even slow down, e.g. queries containing the current UNIX-timestamp
SELECT o.* FROM online AS o WHERE o.logged<1205706380In this case, the system would NOT slow down under any circumstances, because "dangerous" queries are marked with NO_CACHE. The system can only speed up, because queries are being cached when the MySQL is ON or in DEMAND mode. If the query cache is disabled, MySQL simply ignores the cache-flag.
second idea: To optimize time-based queries like the one above, which fetches users, that were active during the last 5 minutes (time()-300), we have to make the condition change as less as possible. The trick is the following:
No condition like:
a < time()the idea: create 5-minute-steps
a < time() - (date('i')%5)*60 - date('s')this piece of code subtracts the time passed since the last 5min-mark from the current timestamp - result:
we get 16:45, on 16:45, 46, 47, 48 and 49. It requires only one cache update every 5min.
The bad side of it: on 16:46, it checks activity during the last minute.. By subtracting another 5min of it, we get the online activity for the last 5 - 9min. I think that timerange is acceptable.
Final code:
$last_step = $time - (date('i')%5)*60 - 300 - date('s');Hey
I used to love the simplicity and style of the old PunBB and now I love it even more 
Thanks for the new version.. I would like to contribute a little bit to the success of PunBB.
We all know that search engines dislike duplicate content. And we all know that PunBB produces a lot of duplicate content.. Just take a look at viewtopic.php?id=1. The topic view contains permalinks to each post - like viewtopic.php?pid=1#p1, viewtopic.php?pid=2#p2, ... On a full page, this means 26x the same content - not really healthy for the Pagerank.
My idea to solve it: No, please don't remove the permalinks, they're extremely handy. My solution is based on the tools, search engines provide us with. Simply add a rel="nofollow" to every post-permalink and a <meta name="robots" content="noindex" /> to each viewtopic.php?pid=X header. Now search engines won't scan the post-permalinked-pages and will only detect the content once => better rank
These are maybe 15 minutes of work, but definitely a boost of googliking
I'd be very happy if a hard-working dev would implement my idea.
Thanks
//edit: Damn sorry, The idea striked me as I crawled through the wrong board :-/
//edit2: Thanks to Neal for implementing it
Hi,
I'm trying to integrate PunBB 1.2.15 into my Wordpress blog. I successfully wrote a own login, logout and register page for the blog, but when I try to make a box in the sidebar that displays your punbb nickname and some links to the board, I always get that error:
Fatal error: Call to a member function query() on a non-object in ***\board\include\functions.php on line 129Line 129 of my functions.php is the following: (inside the set_default_user() function)
$result = $db->query('SELECT u.*, g.*, o.logged FROM '.$db->prefix.'users AS u INNER JOIN '.$db->prefix.'groups AS g ON u.group_id=g.g_id LEFT JOIN '.$db->prefix.'online AS o ON o.ident=\''.$remote_addr.'\' WHERE u.id=1') or error('Unable to fetch guest information', __FILE__, __LINE__, $db->error());When i debug it via debug_print_backtrace() it displays:
#0 set_default_user() called at [***\board\include\functions.php:111]
#1 check_cookie(Array ()) called at [***\board\include\common.php:118]
#2 require(D:\Web\seyken\board\include\common.php) called at [***\sidebar.php:21]
... (wordpress stuff)
This means that check_cookie calls set_default_user (where the error happens) on line 111 in funtions.php..
Now back to the error itself. It should be obvious that $db causes the error, when I look what exactly $db is in that set_default_user-function (with var_dump( $db ); ) it displays:
NULL
this means that $db does not exist in that function, although it should be available because of global $db, ...
Now i want to know whether $db is available in the function that called set_default_user or not, so I add my var_dump-code to the check_cookie function and it displays (again):
NULL
Strange, isn't it? Now i wanna see whether $db is available directly before check_cookie is called (added the code to common.php before line 118 and it displays:
object(DBLayer)#32 (5) { ["prefix"]=> string(0) "" ["link_id"]=> object(mysqli)#33 (0) { } ["query_result"]=> NULL ["saved_queries"]=> array(0) { } ["num_queries"]=> int(0) }
This means that the object is available there... This is the point where I don't understand it anymore, it seems obvious that global $db doesn't work, but why?
Can anybody help me with this problem? 
//edit: I thought it would maybe be because of the installed CAPTCHA-addon, so I installed PunBB completely new and the same error still occurs, but not in functions.php - in include/cache.php on line 84:
$result = $db->query('SELECT * FROM '.$db->prefix.'config', true) or error('Unable to fetch forum config', __FILE__, __LINE__, $db->error());i measured the time before and after the include:
$start_time = microtime(true);
require PUN_ROOT.'include/common.php';
echo microtime(true)-$start_time;ok now it's much better, i tested it on my localhost with many programs open. Now it's really better ( ~0.2sec ) - i think i can live with that ;-)
xconspirisist: i am using windows ( :-( ) on my localhost but it's fine now 
Yes you are all right - there was something wrong - but after a restart it went fine ( sorry for the circumstances )
Hey,
it's great that it's so easy to fetch the login-information from punBB but my problem is:
Sometimes ( e.g. every 3rd site view ) it takes about two seconds (!!) until PUN_ROOT.'include/common.php' is included. Yes that's a lot of time..
Now my question - i didn't find the part where $pun_user gets defined - could anybody write me a short script that simply fetches the user data of the logged in user and generates $pun_user without intialising unneed stuff?
Thanks
~ Max
PunBB Forums → Posts by damaxxed
Powered by PunBB, supported by Informer Technologies, Inc.