1

(11 replies, posted in Feature requests)

Things that are often customized and that can be centralized should be in one central place imo; ease of use smile With an upgrade you don't lose your changes smile

2

(11 replies, posted in Feature requests)

Exactly, just use the config.php as the external file smile

3

(11 replies, posted in Feature requests)

Sure, that's another way, but this is such a common thing: why don't centralize it?

4

(11 replies, posted in Feature requests)

Damned tongue So much for my brilliant idea :+

Another thing that could be handy: get the smiley-array's out of the parser.php and into the config.php, so you don't lose the changes with a upgrade.

5

(11 replies, posted in Feature requests)

function do_smilies($text)
{
    global $smiley_text, $smiley_img, $pun_config;

    $text = ' '.$text.' ';

    $num_smilies = count($smiley_text);
    for ($i = 0; $i < $num_smilies; ++$i)
        $text = preg_replace("#(?<=.\W|\W.|^\W)".preg_quote($smiley_text[$i], '#')."(?=.\W|\W.|\W$)#m", '$1<img src="'.$pun_config['o_base_url'].'/img/smilies/'.$smiley_img[$i].'" alt="'.substr($smiley_img[$i], 0, strrpos($smiley_img[$i], '.')).'" />$2', $text);

    return substr($text, 1, -1);
}

Mind the "src="'.$pun_config['o_base_url'].'/", this helped me integrate the parsingfunctions into my site a lot faster smile Maybe it's a handy thing for 1.3 smile

6

(11 replies, posted in Feature requests)

Yeah, I searched for it prior to starting topic smile

Anyway, have you ever looked at the parser.php. That's quite a lot of work for a cpu to do smile

7

(11 replies, posted in Feature requests)

True, thanks for the tips offcourse, but that's not truly my point. Ofcourse you can edit everything yourself, \o/ @ opensource, but why not just implement it. I'm trying to get a discussion going that is about the ad- and disadvantages of this measure. Is it worth it and what is against it, etc smile

8

(11 replies, posted in Feature requests)

Just wondering why it would be silly, because you're not saving the same thing twice. You are saving the data that come out some functions that move a lot of data around and that cost a lot of cpu-cycles.

The "you can do it yourself" is the easiest thing to say offcourse, but with every update this is a problem: you have to keep track of each modification that has been made in that release to the files that affect your functionality. But more important is that other users can also profit from such a modification. smile

9

(11 replies, posted in Feature requests)

Well, I don't fully agree to that actually. I don't know if your are familiar with the forums of www.tweakers.net, but they are very very large. A database of 20GB+, more than over 150.000 registered users and miljons of posts. They are using forumsoftware called react, which uses both parsed and unparsed versions to improve the performance, and it performs like a madman.

The database will get bigger, but that wouldn't be a problem, things like the correct key's and index'es are much more important than the size of the database itself.

10

(11 replies, posted in Feature requests)

I don't see the problem of the edit function; I forgot something: The idea is offcourse to save the parsed version ánd an unparsed version of the post smile Space, well, will that really be a problem?

11

(11 replies, posted in Feature requests)

I just took a look at my newly installed PunBB-forum, but I noticed that you don't save a parsed version of the posts. This means that with every hit you have to replace all the smileys, links, etc which can be timeconsuming.

PunBB has some goals of which performance is one if I understand it correctly. I think this would fit in that strategy because it can cause a nice performanceincrease smile