Forums

I'm not incorrect, I'm merely working along sensible lines. There is a point where supposed security is there for the mere sake of it, which I'll go into further after Jamie's post below.

Right. You have three possible scenarios that jump to mind offhand, (granted, there are probably far more).

One: Someone is flooding the login page with possibilities. Flood protection is far more sensible and useful than making them take N months to decrypt a password. Your password is safe but we'll just D.O.S the server.

Two: Your database has been compromised. A securely hashed password in this scenario is going to help how, exactly? Again, it's polishing a turd. If someone needs excessive levels of hashing, the mere fact that they know that also means that they will have the abilities to implement that.

Three: Some form of snooping. You think they're not going to crack the password at their leisure if they're that bothered about accessing that account?

If I'm missing some point about exactly what benefit an anal level of hashing will achieve, I'll happily digress once it's pointed out.

You can alter the session_save_handler to use a custom storage format, including the DB. Personally, I find a mix preferable. The inbuilt PHP session system for creating and destroying the sessions etc, but not relying on the session cleanup functions alone or on the stability of the session system, (it's quirky/buggy). The session functions create and destroy, but then control the information as you always have done.

All of the obsessive server side security measures are going to help how, the first time some numpty steps away from his desktop to browse on another machine whilst not locking the machine? Smart move. Go anal on password security and then leave all of the barn doors wide open once someone enters the barn, because we all know how normal users are so security conscious that they wouldn't possibly do a trick like that.

Very. The content of that is the primary heading/link shown by the search engines above the description, as a rule. You want to keep it succinct, but something a tad more than just FluxBB would be good. Something like:

FluxBB - A compact and optimised forum system

or similar would give people a good first glance notion without drawing it out/elongating it too much.

Btw, you really do want to change that paragraph on the homepage. This:

really should be:

The former makes it sound as if that's what you intended but it might not have gone that route, whereas the latter doesn't allow any suggestion of may or may not. It merely is.

Pretty much the same reason as Reines. Simplicity. It's a compact core system upon which to build, without having to remove tonnes of unnecessary cruft.

Tried MyBB recently, to see what all the hype is about. Bloody hateful system, IMHO. Inconsistent logic, an admin panel which can make one weep and a, (at that time), lead Dev, (who has recently parted ways with MyBB), who could swear blind that a bug wasn't a bug and a community which is unusual, to say the least. I'd still go with Flux any day of the week.

Are there any viable, (less arsey), alternatives to them? What payment method do you generally insist upon these days?

To strip it down to the basics, the licence doesn't make a monkeys difference as to whether someone will contribute back or not. The only difference it would make, in reality, is putting potential users off.

Around 95% of people who use software will never have the faintest idea how to code for it. Of the other 5%, (these values are approximations, before anyone asks for data sources), who can code, they know exactly what they're doing. If they intended to give back, they would do so regardless of licence. If they have no intention of, they won't, regardless of licence.
The only thing that would happen is that the Dev team would practically need to devote one members time to chasing down all infringements. Hell of a way to waste a Dev's time, in my book. GPL is fine. Even that's too restrictive, IMHO.

Ah. I thought the ticket system was for intended changes only. I'll get one added.

Edit: Have I done it correctly?

Just on a tanget, another thing that might be worthwhile incorporating into the email script? If a 55* code is returned for a recipient, would it not be worthwhile adding an active/inactive column to the user table and toggling that on a 55* response so that no e-mails are sent to that address again? If a site has a lot of users with invalid addresses, constant attempts to send to those addresses could theoretically end up with a system being blacklisted, tarpitted or similar. If an address receives a 55* at any time, it's a good bet it will do so always. It is supposed to be a permanent response, after all.

I'll see what I can knock together then. Might be a good opportunity to do a fallback to non-ESMTP mode too if EHLO isn't supported.

Bearing in mind that I'm not familiar with MySQL, other than username or password being incorrect, the only other thing which springs to mind is connections from localhost not being allowed in the conf file.

No idea. One of the others will need to guide you on that point. I can't remember a lot of the finer points of the Flux code. I was merely cleaning up that 'just usable' abortion of a script up from the first post for future use.

Edit: In fact, I'll post the new code on here to make sure there's a permanent copy on here:

<?php

/**********************************************************************/

define('PUN_PORTAL', 1);
define('PUN_ROOT', './');
define('PUN_QUIET_VISIT', 1);
require PUN_ROOT.'include/common.php';
define('PUN_ACTIVE_PAGE', 'index');
 
$page_title = array(pun_htmlspecialchars($pun_config['o_board_title']));
define('PUN_ALLOW_INDEX', 1);
require PUN_ROOT.'header.php';
require PUN_ROOT.'include/parser.php';
 
/**********************************************************************/

function pun_news($fid = false, $limit = false, $length = false, $truncate = false)
{
    global $lang_common, $db, $pun_config, $db_prefix;

    $output = '';
    $order_by = 't.posted';
    $max_subject_length = 30;
    $fid = (($fid) ? 'f.id='.intval($fid).' AND ' : '');
    $limit = ' LIMIT '.(($limit) ? intval($limit) : 25);
    $max_content_length = (($length) ? intval($length) : 500);

    # Fetch the topics.

    $result = $db->query('SELECT p.message, 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.'posts AS p ON p.id=t.first_post_id INNER JOIN '.$db_prefix.'forums AS f ON t.forum_id=f.id WHERE '.$fid.'t.moved_to IS NULL ORDER BY '.$order_by.' DESC'.$limit) or error('Unable to fetch topic list', __FILE__, __LINE__, $db->error());

    if ($db->num_rows($result))
    {
        while (($cur_topic = $db->fetch_assoc($result)))
        {
            if ($pun_config['o_censoring'] == '1')
            {
                $cur_topic['subject'] = censor_words($cur_topic['subject']);
            }

            if (pun_strlen($cur_topic['subject']) > $max_subject_length)
            {
                $subject_truncated = trim(substr($cur_topic['subject'], 0, ($max_subject_length-5))).'...';
            }
            else
            {
                $subject_truncated = $cur_topic['subject'];
            }
            $output .= '<div class="block">'."\n".'<h2><span>'.pun_htmlspecialchars($subject_truncated).' - '.gmdate('l, d F Y', $cur_topic['posted']).'</span></h2>'."\n\t".'<div class="box">'."\n\t\t".'<div class="inbox">'."\n\t\t\t".'<p><a href="'.$pun_config['o_base_url'].'/viewtopic.php?id='.$cur_topic['id'].'&amp;action=new" title="'.pun_htmlspecialchars($cur_topic['subject']).'">'.pun_htmlspecialchars($subject_truncated).'</a> - <em>Posted by '.$cur_topic['poster'].' at '.gmdate($pun_config['o_time_format'], $cur_topic['posted']).'</em></p>'."\n\t\t\t";

            if ($truncate == 1)
            {
                if (pun_strlen($cur_topic['message']) > $max_content_length)
                {
                    $max_content_length = strpos($cur_topic['message'], ' ', ($max_content_length-15));    
                    $cur_topic['message'] = substr($cur_topic['message'], 0, $max_content_length).'...';
                }
            }
            $output .= parse_message($cur_topic['message'], 0)."\n\t\t".'</div>'."\n\t".'</div>'."\n".'</div>'."\n";
        }
        print($output);
    }
}

/**********************************************************************/

pun_news(1, 5, 500, true);
 
require PUN_ROOT.'footer.php';

/**********************************************************************/

?>

http://fluxbb.fr/forums/index.php

It's correct. The is_guest is preceded by !, hence specifying that if is_guest false, continue. This one is wrong though:

- Show only to mod/admin: if (!$pun_user['is_admmod'])

Should be:

- Show only to mod/admin: if ($pun_user['is_admmod'])