downliner wrote:

Thanks for the replies Ian and seva smile I will take a look at the link and see how it works out.

If you do find any more information Ian I would appreciate you posting your findings smile Thanks!

Will

Will,

I have had a hack at the register.php and profile.php to add a new section with a new field and add this as a mandatory field to the registration process. This is far from complete, but may be a start. This was completed on punbb 1.28, so line numbers may change with other versions. I have tried to keep the field names pretty generic, but obviously you will want to change them,

1) Add the new field to the database.

Add and extension column to the user table. For this example, we will add the following info:

x_extension    VARCHAR(45)

2) Update the registration form

At around line 372, we need to add a new section to reflect the new field. Note that this will be added to the registration page, but you may just want to only add it to the users profile. However, this may be a good way to ensure the usually actually fills it in !

            <div class="inform">
                <fieldset>
                    <legend><?php echo $lang_prof_reg['New Section legend'] ?></legend>
                    <div class="infldset">
                        <label><?php echo $lang_prof_reg['Field Name'] ?>: <?php echo $lang_prof_reg['Field info'] ?>
                        <br /><select id="x_extension" name="x_extension">
                            <option value="choose" selected="selected">Please choose</option>
                            <option value="1">1</option>
                            <option value="2">3</option>
                        </select>
                        <br /></label>
                    </div>
                </fieldset>
            </div>

This example uses a simple pick list with a couple of values; however, can be easily changed to relfect different fields and input methods.

At around line 170, the following definition is required:

    $x_extension = trim($_POST['x_extension']);

    if ($x_extension ==  'choose')
        message($lang_prof_reg['Field mandatory']);

This code will declare the new variable and also check to make sure the user has selcted a value.

Now on about line 183, the SQL will need to be updated to add the new column.

I added x_extension as follows:

$db->query ... users( ..., x_extension) VALUES ( ...  \''.$x_extension.'\') ...
Updates will also be required to the /lang/English/prof_reg.php file to include the new fields.

'Section legend'        =>    'The name of the new section',
'Field Name'            =>    'The name of the new field',
'Field info'                =>    'The sentance that is displayed next to the field name on the form.',
'Field mandatory'        =>    'Please choose a photographic brand. This field is mandatory.'

It is worth testing the registration process to ensure that the correct data is written to the database.

3) Now for the profile updates, which I have to say are even more of a hack big_smile

Open up profile.php, and on line 1473, add the following. This addes a new section and also uses the same code as register.php to display the pick list of options to the user.

    else if ($section == 'newsection')
    {
        $page_title = pun_htmlspecialchars($pun_config['o_board_title']).' / '.$lang_common['Profile'];
        require PUN_ROOT.'header.php';

        generate_profile_menu('newsection');

?>
    <div class="blockform">
        <h2><span><?php echo pun_htmlspecialchars($user['username']).' - '.$lang_profile['Section New Section'] ?></span></h2>
        <div class="box">
            <form id="profile7" method="post" action="profile.php?section=newsection&id=<?php echo $id ?>">
                <div class="inform">
                    <fieldset>
                        <legend><?php echo $lang_prof_reg['Section legend'] ?></legend>
                        <div class="infldset">
                            <input type="hidden" name="form_sent" value="1" />
                            <label><?php echo $lang_prof_reg['Field Name'] ?>: <?php echo $lang_prof_reg['Field info'] ?>
                            <br /><select name="form[x_extension]">
                                <option value="1"<?php if ($user['x_extension'] == '1') echo ' selected="selected"' ?>>1</option>
                                <option value="2"<?php if ($user['x_extension'] == '2') echo ' selected="selected"' ?>>2</option>
                            </select>
                            <br /></label>
                        </div>
                    </fieldset>
                </div>
                <p><input type="submit" name="update" value="<?php echo $lang_common['Submit'] ?>" /><?php echo $lang_profile['Instructions'] ?></p>
            </form>
        </div>
    </div>
<?php

    }

Around line 827, we need to add a new handler for the profile section.

        case 'newsection':
        {
            $form = extract_elements(array('x_extension'));

            break;
        }

This extracts the posted value for update in the database. The update is via a nice piece coding, so we do not have to hard code anything here.

Now, around 885 we need to update the sql that selects the user details to populate the profile when it is first displayed. I have added the new column to the end of the user declarations.

$result = $db->query( ... u.x_extension, g.g_id, ...

Add the following to lang/profile.php to add the additional field.

'Section New Section'            =>    'Section Name',


This adds a new section to the profile page ... but its not finished yet ...

Open up include/functions.php and on line 310 add the following:

                    <li<?php if ($page == 'newsection') echo ' class="isactive"'; ?>><a href="profile.php?section=newsection&id=<?php echo $id ?>"><?php echo $lang_profile['Section New Section'] ?></a></li>

This will add the necessary menu item.

Now, all being well, this should work. Note that it is a pretty messy solution, and it really is my first attempt at giving it a go, so it may be possible to improve it a bit.

Best of luck, and let us know how you go,
Cheers, Ian

2

(12 replies, posted in General discussion)

TextPad http://textpad.com/ is pretty good, and offers loads of configuration options with good syntax highlighting. It is only available on Windows platforms, though.

Cheers, Ian

3

(19 replies, posted in General discussion)

I have not used it in a production environment, but PHPList http://tincan.co.uk/phplist seems to get some good writeups. Its software requirement seems similar to PunBB, and its also open source with no limit upon recipient numbers, etc.

I am unsure how easy it is to integrate with PunBB (querying the user table) though. It would be cool to integrate it into the PunBB register.php and profile.php files. big_smile

Cheers, Ian

Will,

I have a similar requirement and have dug around the code looking for the best way to implement this.

Adding fields to the registration process is pretty easy, just adding a section to the register.php (copying an existing section works okay), and adding some extension columns to the users table. This is quite a clean update and can be separated out during an upgrade.

The real tricky part comes with your profile requirements. I have looked through profile.php many times, but it seems that the only way to tackle this is with a bit of open-heart-surgery, as it will mean a lot of changes to all parts of profile.php. This will result in a real messy update.

I wonder if there are plans in a future release to include more customistation options through the admin screens to add sections and profile fields. However, the tricky part is the level of validation required for each field and that there would be no real way of developing a generic field, as each users validation and formatting requirements would be so different. i.e. I would like a date field greater than 1900 but only until today, you would like an 8 character string, all uppercase. I guess you could add generic text or int fields.

Unless we hear otherwise, the only way will be to hack the profile.php (and respective language files) to add the additional sections. This is not ideal, but to allow you to meet you site requirements, may be the only way.

I am currently playing around with profile.php and will post my findings.

Cheers, Ian

There have been quite a few posts about the syndication of forum posts externally to the forum, i.e. onto a home page. The best tool is the extern.php file that is included with punbb. This allows both html and xml (rss feed) syndication of forum posts, and has a number of additional parameters (forum id, number of posts) to allow you to customise the returned posts.

Search for extern.php on these forums for other ideas or look at http://punbb.org/docs/dev.html for the official syndication documentation.

Cheers, Ian

6

(8 replies, posted in PunBB 1.2 discussion)

Smartys wrote:

Except that's not the kind of thing 99% of people would want or need at any point, so it wouldn't get implemented like that tongue
But what you're suggesting is basically what I suggested, except you're having another variable be the prefix rather then hardcoding it into the files, which is fine as well

Many thanks for the reply ... big_smile

I have done some more digging (and this thread http://punbb.org/forums/viewtopic.php?id=8755 - thanks to Connorhd) and the following seems to work.

To test it, I installed 2 forums, one in the /master directory with master_ as the prefix, the other in the /slave directory with the slave_ prefix. Both were installed in the same MySql database.

On line 76 of /includes/dblayer/mysql.php file of the /slave forum, I added the 2 following lines to point the slave user and group sql queries to the master user and group tables.

   $sql = ereg_replace($this->prefix ."users", "master_users", $sql);
   $sql = ereg_replace($this->prefix ."groups", "master_groups", $sql);

There are the obvious cookie problems to overcome, but keeping the cookie_name, domain and seed the same across the master and slave forums seemed to do the trick.

The avatar directory would also need to be shared, perhaps a directory outside of both forums.

I will need to check through all the other tables to determine what else needs to be shared, but this seems a pretty good start.

Cheers, Ian

7

(8 replies, posted in PunBB 1.2 discussion)

Smartys wrote:

The alternative is to rewrite all calls to '.$db->prefix.'users to a hardcoded prefix in one of the boards

Would an alternative be that during installation, the install script asked for 2 prefixes, one for the user tables and one for the forum tables. Then, all references in the code to the user prefix can be changed to reflect the new user prefix, therefore supporting the requirement for multiple forums with a single shared user table in a single database. I have not scanned the punbb code to determine the feasibility of this, so I may be 'off target'.

Cheers, Ian

Hi there,

I am in the process of looking at the design for a site that caters for both English/Chinese users. I have chosen punBB due to its lack of bloat, good performance, flexibility and general high quality of coding.

I have a question about the best way to architect such a solution, and have come up with a number of ideas. Assume that the English/Chinese sites can be separated (i.e. no 'real' requirement for cross-site users - but would be nice for users to be shared for possible future site additions), and they would be hosted on the same domain (either separated by folders 'domain/en/' 'domain/cn/' or sub-domain 'en.domain' 'cn.domain').

** Single install of punBB using UTF-8 to allow posts in both language. Not ideal due to both language's being displayed on the same page. This one is rejected !

** Separate install of punBB (using separate language packs), with separate databases and users. May increase the manual admin overhead, but also minimises the changes required to core punBB code, aiding upgrades, etc. I like this option for its simplicity, but it does separate the sites a lot, and it would be good to have some user commonality between the two.

** Separate install of punBB (using separate language packs), with a single database and single user table. The database would use different prefixes to allow it in the same schema, but both punBB instances would point to the single user tables, perhaps by changing the config of the second site to point to the user tables of the first. Is this technically possible with punBB ? I have developed such a solution using phpBB, but found significant issues with their cookie management, and the overall 'bloat' of phpBB was not to my liking. This would also allow different themes/css to be used.

I am pretty new to this, so am looking for help with any other options that could be available that could allow such a solution, but without resulting in too many changes to the core code, as I would like to increase the ability to perform upgrades, etc.

Cheers, Ian