Frequently Asked Questions

Author:Roalt Zijlstra - Date:8 May 2007
Answer:

The appointment-delete.php doesn't use the new permission system. So new users created in PBCS 0.7.0 and 0.7.0a will not be able to delete appointments.

If you upgraded PBCS 0.6.x to 0.7.0 then those older upgraded users can delete! Very confusing in diagnosing the problem.

This issue is solved in the 0.7.1-1 release. Get it from the download page.

Author:Roalt Zijlstra - Date:24 July 2002
Answer:
Edit the config/config.php file and go to the entries $groups[x] and add entries to the current ones. Be sure that you only use binary values ie. 1,2,4,8,16,32,64,128,255 and 512. You can go up to the value of 32768. Don't make more then 16 groups cause that will interfere with the predefined functions listed in the User Manager.

The fifth group would be defined with:

$groups[16] = 'Fifth group';

Author:Roalt Zijlstra - Date:22 June 2002
Answer:
As of PHP 4.2.x the default setting of a PHP-source build of the register_globals setting is 'off', which breaks PBCS. Edit your php.ini file and set it to 'on' to make PBCS work again.

The final 0.5 release of PBCS will work with PHP 4.2.x and you will have to upgrade to this release to get a working system.

Author:Roalt Zijlstra - Date:17 July 2002
Answer:
Due to the fact that PBCS uses the require_once() function it will not work propperly with php version prior to 4.0.4. So if you have php 4.0.4 and higher it will work. PBCS 0.4 won't work with PHP 4.1.x out of the box. You will have to add a line '@destroy_session()' just below the lines:

// Need the base URI to set the cookies. (Same code as in webmail.php)
ereg (\"(^.*/)[^/]+/[^/]+$\", $PHP_SELF, $regs);
$base_uri = $regs[1];
@session_destroy();

Author:Roalt Zijlstra - Date:Mid 2003
Answer:

Yes PBCS 0.6.0 works on Windows NT/2000/XP with PHP installed. Florence Gaullier reported that he got it working using the document \"A FRESH INSTALL WITHOUT THE INSTALLER SCRIPT\" with an added step which was to add a path in the php.ini for the PEAR libs.

This means that most problems come from the PEAR library not being in the include_path directive of php.ini. Edit the php.ini and let it point to '.:c:\\path\\to\\PEAR'

Author:Roalt Zijlstra - Date:11 April 2005
Answer:

There are some problems with PHP sessions in all versions of PBCS up to 0.6.2a. It has something to do with setting cookies of session variables, which used to work as it was implemented. Since PHP 4.3.9 the session code got more restrictive and PBCS session management crumbled

Symptoms are:

• First logins always fails, second login goes well.
• While creating an appointment you get an authentication failure after the appointment was added to the database.
• Clicking on the Yopy/Palm sync always results in an auth failure.

The actual files which contain errors are in the auth/ directory, hence I created a tar.gz and a .zip file containing fixed files. Get the tar.gz here or the zip file here
Unpack one of the two in your current pbcs tree. It will overwrite the files in the auth directory.

It is also needed to add the following two lines in the php.ini:

session.bug_compat_42 = 1
session.bug_compat_warn = 0

After applying the patched files and restarting Apache the login problems should be fixed.

Many thanks for pointing me to this problem goes to Menno Scholten of Moonen Packaging, additionally I got confronted by the problem after a PHP upgrade on the PBCS server at work (I work for Stone-IT that is).

Author:Roalt Zijlstra - Date:24 June 2003
Answer:

There have been more reports of updated Red Hat 7.2 and SuSE 7.x machines that after login they receive a blank screen. After a lot of research the problem lies in the PHP include_path which somehow doesn't find the PEAR library files.

To solve this you must edit the php.ini file and edit the line where 'include_path' resides. Change that line to 'include_path = \".:/usr/lib/php:/usr/lib/php/PEAR\"'. This is the setting for SuSE 7.2. Don't forget to add the '.:' part as this will make PHP seek in the current directory, which is default behaviour.

Thanks go to Maarten J H van den Berg and Florence Gaullier for reporting this to me and the comment section of www.pbcs.org

Author:Roalt Zijlstra - Date:21 March 2003
Answer:

It is possible that PHP is configured too tightly on default installs of SuSE and Red Hat. I received a mail of Urs Behlau mentioning two things in the php.ini config file. Thanks for the tips Urs!

First of all the setting 'register_globals = On' must be 'On' and not off.

Secondly it is possible that session information is not automatically stored. The setting to fix this could be 'session.auto_start = 1'. On SuSE systems the value is 0, hence breaking PBCS.

Edit your php.ini (in /etc or /etc/php4) to contain the above values, maybe you should still need the 'short_open_tag = On' setting too. However efforts were made to remove this dependency

Author:Roalt Zijlstra - Date:23 january 2003
Answer:

This is correct unfortunately. However I have a fix for this. Edit the util_funcs.php file and go to the get_week_nr() function and replace the code by the following:

function get_week_nr( $date ) {
$date_year = date(\"Y\",$date);

$first_year_week_day = date(\"w\",mktime( 0,0,0,1,1,$date_year ) );
if( $first_year_week_day == 0 ) $first_year_week_day = 7;
$first_year_week_day -= 1;

return intval( ($first_year_week_day + date(\"z\", $date )) / 7) + 1;
}

This should fix the incorrect week numbers

Author:Roalt Zijlstra - Date:4 September 2002
Answer:
On the documentation part there are updated instructions on installing PBCS 0.5.
However the default admin-password is 'admin'.

Author:Roalt Zijlstra - Date:26 September 2001
Answer:
Go to the config/config.php and set the variable $status_modification_protection to true and that will be all. Remember that Admins have the highest Status Level, so you should have a special Admin user and should not assign normal users the admin level.