Search options (Page 253 of 354)

It should give you a "Bad referer" message on all operations but updating admin/options.

I'm not sure what good stripping out http:// or https:// from the Base URL would do. The Base URL should contain http:// or equivalent because it is the URL to the forums used in all outgoing e-mail.

You need to update "Base URL" in admin/options. Also, if you've tinkered with cookie_domain in config.php, you will need to update that.

Fixed it! Here's a quickfix. Open up search.php and go to line 191. There, replace

if ($word != 'and' || $word != 'or' || $word != 'not')

with

if ($word != 'and' && $word != 'or' && $word != 'not')

As I pointed out in the other topic, quick reply is only enabled for registered users. The reason for that is that it gives people incentive to register. If they register, they'll get access to more features such as the quick reply.

However, the "register as you post" thing is kinda nice. I'll consider it :)

Could you try echoing out that query instead of executing it? I.e. replace:

$result = $db->query('SELECT id, poster, subject, posted, last_post, last_post_id, last_poster, num_views, num_replies, closed, sticky, moved_to FROM '.$db->prefix.'topics WHERE forum_id='.$id.' ORDER BY sticky DESC, last_post DESC LIMIT '.$start_from.', '.$disp_topics) or error('Unable to fetch topic list for forum', __FILE__, __LINE__, $db->error());

with

dump('SELECT id, poster, subject, posted, last_post, last_post_id, last_poster, num_views, num_replies, closed, sticky, moved_to FROM '.$db->prefix.'topics WHERE forum_id='.$id.' ORDER BY sticky DESC, last_post DESC LIMIT '.$start_from.', '.$disp_topics);

Where did you try this, in these forums or somewhere else? Also, which browser are you using? Can you try with a different browser?

And how does that differ from reading the file manually and then evaling it?

Edit: *hits head* Now I see what you mean. That's true. However, your method doesn't at all take advantage of the benefits of PHP accelerators such as mmcache, PHPA and Zend Optimizer.

I never said your board was slow. I just said using templates in that matter, or any matter for that matter (no pun intended), will be a lot slower than just outputting static markup.

Also, the average loadtime for your board doesn't tell me anything. 0.025 could mean it's blistering fast, but it could also mean it's incredibly slow. Heck, I can get huge boards like vBulletin or IPB to load that fast under the right circumstances. Loadtimes are only interesting when comparing them to other boards on the same hardware and with the same data. The variables that affect loadtimes are endless. What kind of hardware the board is running on, the versions of all used tools (Apache, PHP, MySQL etc.), whether a PHP accelerator is used or not, the number of users/topics/posts in the database, the number of board features enabled, what kind of concurrency was used when running the benchmarks (i.e. what value for -c when running apachebench), etc. etc. etc.

We could talk about this forever. The fact remains: PunBB will not have a template system in any forseable future. I have to draw the line somewhere if PunBB is to remain the "faster, smaller and less graphic alternative". PunBB 2.0 (whenever that may be) will most likely be styled completely with CSS and then a template system won't be needed.

Railer: The changes made in PunBB 1.1.2 were few and small, so there shouldn't be much problem installing it. If there are any problems, they will most likely be line numbers not matching up exactly.

Ok, jag antar att du har pekat domänen och eventuella subdomäner mot ditt IP. När du gjort det är det bara en fråga om att redigera httpd.conf. Min ser ut såhär för www.punbb.org och forums.punbb.org:

NameVirtualHost *

<VirtualHost _default_>
    DocumentRoot /sökväg/till/siten
    ServerName www.punbb.org
</VirtualHost>

<VirtualHost *>
    DocumentRoot /sökväg/till/forumet
    ServerName forums.punbb.org
</VirtualHost>

It's not the functions for loading/compiling etc. I consider a large addition to the code, it's rewriting every single script so that they utilize the templates.

You're executing no less than 8 preg_replace's for every single template and doing disk IO to load/save. I wouldn't call that fast when comparing it to direct static output. Say a page is built up of 20 templates. That equals 160 calls to preg_replace and 20 disk reads. That code will be MUCH slower than direct static output.

If I were you, I would save the compiled templates to disk and then just use include/require instead of loading them into memory and using eval(). That way PHP "accelerators" such as mmcache and Zend Optimizer can cache the PHP bytecode for the templates and your pages will generate much faster.

Something like this? http://punbb.org/forums/viewtopic.php?id=2821