Search options (Page 74 of 77)

Personally, (I wouldn't presume to say this is how the PunBB Dev's think), the .tpl files, (which is an abbreviation for template), presents a standardised layout, whilst making parts, like messages, configureable. With the exit calls, they are placed within a script to prevent it from carrying on any further. This is usually to define what you want it to do before exiting, rather than what the script wants to do before exiting. I would presume, (and this is a personal presumption), that the exit is probably tied in to limit what debug info is outputted.

If you modded your installation to use that method, it probably would kill your spam off either completely or to a negligible level. However, was not the point of this thread with regards to including standard spam prevention techniques within PunBB? If, for example, that mod was incorporated within 1.3 when it finally leaves R.C status, the thing would be cracked within a week. It is then not a deviant technology, but a core mainstream one. The fiscal benefit for the bot scripters would mean that it was viable to concentrate on it once that occured.

I'm beginning to make a bad habit of answering my own questions. To remove the parent forum table/post settings, the following is needed in viewforum.php. The parent forum then acts as a container for the sub-forums with no visible posting abilities or topic/thread table of it's own.

Around line 93:

if($db->num_rows($subforum_result))
{

After add:

$substatus = '0';

Around line 222:

<div id="vf" class="blocktable">

Before add:

<?php
if ($substatus != '0') {
?>

Around line 390:

$forum_id = $id;
$footer_style = 'viewforum';
require PUN_ROOT.'footer.php';

Before add:

}

Just a quick note. Found out that I've left a couple of settings in the gus_gallery.php and gus_listview.php scripts from when I was testing them. All they are are the slots and upload allow settings for those two pages, so nothing detrimental to stability or suchlike. They will, however, override the config file settings, so delete the following two lines from the above named scripts:

$gvupload_allow = 'yes';
$gvupload_slots = '2';

In gus_gallery.php they are lines 66 & 67. In gus_listview.php they are lines 75 & 76. Apologies for the minor oversight.

Look through the thread for the PM mod. It's in there.

Sorted that last bit. The query is already there, so starting at line 58:

if (($pun_user['g_delete_posts'] == '0' ||
        ($pun_user['g_delete_topics'] == '0' && $is_topic_post) ||
        $cur_post['poster_id'] != $pun_user['id'] ||
        $cur_post['closed'] == '1') &&
        !$is_admmod)
        message($lang_common['No permission']);

That block above needs the following line adding: $cur_post['post_replies'] != '' ||

so that it looks like the following:

if (($pun_user['g_delete_posts'] == '0' ||
        ($pun_user['g_delete_topics'] == '0' && $is_topic_post) ||
        $cur_post['poster_id'] != $pun_user['id'] ||
        $cur_post['post_replies'] != '' ||
        $cur_post['closed'] == '1') &&
        !$is_admmod)
        message($lang_common['No permission']);

Thanks again for the advice.

Matt

Is that $cur_topic['post_replies'] variable/element already available in delete.php, or will it need to be introduced?

Right. Almost there. That works a treat. Only two deviations I need are that I want to differ the delete and edit settings from the global ones for forums that are post topic only, so that delete is disabled but edits are allowed indefinitely. So, would I need to adjust viewforum.php and viewtopic.php for this? Would it suffice to, if post_replies = 0, to set the following two within the script as below to allow the above?

g_delete_posts = 0
g_edit_subjects_interval = 0

Thanks again,

Matt

Edit: Just been delving, and it appears that it's viewtopic.php and edit.php tht will need some slight alteration?

That was the one which looked most promising, but had various problems. Firstly, the PunBB authentication is for mysql only, and secondly, I couldn't get to grips with it's use within the first hour. I work on the motto that if I cannot figure it out within the hour, the less technical ones have no chance. Ease of use is the primary concern, and the forum usage is now second nature to them.

Why? If they haven't come back to check, it would appear they don't care if there are any replies or not.

'modifictions' That really is a classic mistype.

Why not just make a hidden admin account if you want to be online without user visible admin status?

You are incorrect. That is not good. That is merely taking a broken system and trying to prevent it from becoming broken even further quickly. What's even worse is that it has a highly detrimental effect on legitimate use.

Adding any type of spam protection has problems. For one, I believe it deviates from PunBB's basic design philosophy? Secondly, whatever system one chooses will become only partially effective within time, leading to requests for further additions. Where does one stop? Three, one solution will never be okay for all.

At the end of the day, PunBB appears to have more of a *nix based philosophy than a M$ one, which is to provide a secure base system without needless bells and whistles that can be altered precisely to meet ones needs. It does not start off as a bloated system with countless needless parts which impact reliability, configurabilty, security and speed.

For goodness sakes, it can be adapted with several hours work. A modded version of your own can then be used to create all your own installs. You only need to do the job once.