Trouble with PostNuke

shortname wrote on Wednesday, December 28, 2005:

I have gotten rid of most of the pesky errors OpenEMR encountered on my OpenSuSE system, but I still cannot get PostNuke to work properly. I have changed two of the include statements in pnAPI.php (the two statements above pnSessionSetup) to get rid of error messages that were complained about earlier in the thread “pnsessionsetup problem”, but I now get the message “Session initialisation failed.” Apparently this is the message I’m supposed to get if pnSessionInit() fails, but I don’t know what file the function pnSessionInit() comes from, and even if I did, I’m new to php and I probably wouldn’t be able to debug it.

Any help would be greatly appreciated.

Thanks,

Jeremy

drbowen wrote on Wednesday, December 28, 2005:

Which PHP version are you running?

The Calendar uses a modified post nuke module and Smarty Templates.

Most of the post nuke related problems end up being related to people running PHP 5.

Currently we are running PHP 4.4.1.

shortname wrote on Wednesday, December 28, 2005:

I believe I’m running PHP 5. I’m not sure how I’d figure out which version I’m running on a SuSE box though: I usually use Gentoo Linux, and I’m still new to SuSE.

Even if I do figure out which version of PHP I’m using, how would I switch? Is there something in YaST? or YOU?

shortname wrote on Wednesday, December 28, 2005:

Ok. I’m apparently running 4.4.0-6.6 I’m not sure how I’d downgrade to 4.4.1, but I’ll keep working on it.

shortname wrote on Wednesday, December 28, 2005:

All righty: apparently 4.4.0-6.6 is the one and only version of PHP available in OpenSuSE. Given that this is slightly older than 4.4.1, I’m no longer sure what my problem is (it probably isn’t PHP5 related). Any ideas?

drbowen wrote on Wednesday, December 28, 2005:

In a command line try this:

#rpm -qa | grep php

OpenSUSE apparently ships with PHP 4.4.0

Any PHP 4.0 and higher is usually OK.

An error message like:

Fatal error: Call to undefined function: pnsessionsetup() in /srv/www/htdocs/openemr/interface/main/calendar/includes/pnAPI.php on line 410

Is also frequently associated with incorrect permissions on the two directories:

/var/www/htdocs/openemr/interface/main/calendar/modules/PostCalendar/pntemplates/compiled /var/www/htdocs/openemr/interface/main/calendar/modules/PostCalendar/pntemplates/cache

Make sure the two directoried are owned and writeable by your web server.

shortname wrote on Thursday, December 29, 2005:

Ok. I’m using a version of PHP above 4.0 and below 5. (4.4.0-6, I think) and I have given the proper permissions to both cache and compiled (as well as default, just for good measure). These changes don’t seem to help. Any further suggestions would be (once again) greatly appreciated.

Thanks much,

Jeremy

sunsetsystems wrote on Thursday, December 29, 2005:

For what it’s worth my (virtual) test mechine is using PHP 4.4.0 (on Ubuntu) and is not having any such problems.  So I don’t think this is a PHP version problem.

– Rod
www.sunsetsystems.com

shortname wrote on Thursday, December 29, 2005:

Whoo boy: That can’t be good. Either I’ve created a problem while fixing the errors, or it’s something very SuSE specific. I’ll see if I can find the offending lines of code. If I do figure out what part of the PostNuke scripts are causing the problem , I could use your help debugging them: seeing as I’m very new to PHP.

Thanks,

Jeremy

shortname wrote on Thursday, December 29, 2005:

All right. The function that returns the error "Session initialisation failed" seems to be the function pnSessionInit() in the file pnSession.php, which is located in openemr/interface/main/calendar/includes

Any help would (yet again) be greatly appreciated.

Thanks,

Jeremy

shortname wrote on Thursday, December 29, 2005:

Ok. I’ve done a little more poking and prodding, and it appears that while most of the PHP related things my OpenSuSE are version 4.4.0-6, others are 4.4.0-6.6, which has apparently created conflicts. As soon as I can switch to the alternate 4.4.0-6 packages I’ll let you know: hopefully this will fix the problem.

shortname wrote on Friday, December 30, 2005:

I’ve switched all of my PHP related stuff to 4.4.0-6, and this doesn’t seem to help. To help you help me (seeing as I’m out of ideas) here are the notes I’ve been keeping as I work on this problem:

Project notes: Things to remind me what files were given modified permissions, and what fixes were necessary to get OpenEMR up and running.

When setting up OpenEMR, the file library/sqlconf.php must be given world writeable permissions for a short period (chmod 777 sqlconf.php). The permissions should then be made secure with the command (chmod go-rwx sqlconf.php)

Several changes should be made to the file interface/globals.php:

$webserver_root = “/srv/www/htdocs/openemr”;

Change the line line in interface/main/calendar/includes/pnAPI.php used to define pnadodb/adodb.inc.php to read:

‘/srv/www/htdocs/openemr/interface/main/calendar/pnadodb/adodb.inc.php’;
change the lines in interface/main/caldendar/includes/pnAPI.php near pnsessionsetup() to read:

‘/srv/www/htdocs/openemr/interface/main/calendar/includes/pnSession.php’;
‘/srv/www/htdocs/openemr/interface/main/calendar/includes/pnUser.php’;
Change the line in interface/patient_files/summary/stats.php near Controller.class.php to read:

“/srv/www/htdocs/openemr/library/classes/Controller.class.php”);
Give ‘/srv/www/htdocs/openemr/interface/main/calendar/modules/PostCalendar/pntemplates/compiled’. world writeable permissions with chmod 777.

Note: tried “chmod 777” on cache and default as well as compiled, to no avail.

Note: tried downgrading some php-related modules to 4.4.0-6 from 4.4.0-6.6: it didn’t work.

And that’s all I’ve been able to fix so far.

shortname wrote on Friday, December 30, 2005:

Ok: yet another update. I have tried chmodding everything in the entire EMR folder “777” and session initialization still fails, so I know it isn’t a permissions problem. I tried recompiling apache after downgrading some PHP modules, and that didn’t help either. It looks like it must be something SuSE specific: a few people in the another thread mentioned they’re having similar troubles on their SuSE 10 boxes. I really don’t want to have to give up on SuSE just because of some obscure error. Do you have any more ideas?

Thanks again,

Jeremy

sunsetsystems wrote on Wednesday, March 22, 2006:

This may help somebody.

I just installed OpenEMR on a SuSE 10.0 system and resolved these problems by changing the value of include_path in php.ini from "/usr/share/php" to ".:/usr/share/php".

Also it was necessary to increase memory_limit from 8M to a larger value (I used 32M).

– Rod
www.sunsetsystems.com