I just installed the 2.7.1 tarball and walked through the setup procedure without incident. However when I log in I get the following errors where the PostCalendar should be displayed:
Warning: Smarty error: problem creating directory "/%%164/%%1643473877" in /var/www/openemr/interface/main/calendar/modules/PostCalendar/pnincludes/Smarty/Smarty.class.php on line 589
Warning: Smarty error: problem writing ‘/%%164/%%1643473877/default.html.php.’ in /var/www/openemr/interface/main/calendar/modules/PostCalendar/pnincludes/Smarty/Smarty.class.php on line 589
It seems to me that this is likely a permissions error so I have verified that the user apache is running as has read/write permissions. I have also been bothered by the fact that the directory is being created directly off of ‘/’ and not as a subdirectory in the /var/www/openemr/ or /tmp directories.
Line 589 in Smarty.class.php is for the trigger_error method and doesn’t really help me.
If anyone can shed some light on this error I would definately appreciate it.
Make sure the compiled and template directories under PostCalendar are world (or at least writeable by the web server). chmod -R nobody:nobody openemr/interface/main/calendar/modules/PostCalendar/pntemplates. That’s more than likely your problem.
I have even tried making the entire openemr directory world writeable just to see if that would work. (Obviously this is not permenant.) Still no dice.
It seems odd to me that the directories that are being created seem to indicate they will be within the ‘/’ directory and not within /var/www/openemr . Is that correct?
Also, I have a working copy of 2.7.0 prior to the migration to SourceForge.net that I downloaded from SVN which is working without a problem.
I am going to try to grad the latest from CVS this afternoon and see if this is still a problem.
We are going to be running this on a hosted machine that is on Debian Stable. We do not have the control necessary to install Mandrake over Debian.
We have a local machine that is running 2.7.0 from SVN updated on 2005/03/05. This machine has no problems whatsoever, so it has to be a machine specific issue, a new problem with the latest CVS, or some sort of globals.php goof on my part.
Which user does Apache use on Debian stable? This the calender directory and needs to be writable by Apache. On my Slackware this is nobody:nobody. On some distributions it may run as apache:apache.
Since Apache tends to have its own username and group for security purposes make sure that this is not what is goofing you up.
If you are not hosting the server yourself, does the system Apache web server actually have privileges to write anything in your folder? Again this may be a security related issue.
The server is a dedicated server, and we have root access. The reason that I said I can’t switch to Mandrake is that the provider will only support linux if the distro is Debian.
Snip from /etc/apache/httpd.conf:
User www-data
Group www-data
I have made the entire openemr directory world writable temporarily for debugging, and there was no effect.
ls -l /var/www/openemr shows the following:
drwxr-xr-x 11 www-data www-data 4096 Mar 19 22:13 .
drwxr-xr-x 3 root root 4096 Mar 22 00:46 …
-rwxr–r-- 1 www-data www-data 30 Mar 19 22:12 .htaccess
-rwxr–r-- 1 www-data www-data 18010 Mar 19 22:12 COPYING
-rwxr–r-- 1 www-data www-data 877 Mar 19 22:12 CREDITS
-rwxr–r-- 1 www-data www-data 22371 Mar 19 22:12 CategoryTreeMenu.js
-rwxr–r-- 1 www-data www-data 16937 Mar 19 22:12 ChangeLog
-rwxr–r-- 1 www-data www-data 80060 Mar 19 22:12 ChangeLog.old.cvs
-rwxr–r-- 1 www-data www-data 22885 Mar 19 22:12 DocumentTreeMenu.js
drwxr-xr-x 2 www-data www-data 4096 Mar 19 22:13 Documentation
-rwxr–r-- 1 www-data www-data 6699 Mar 19 22:12 INSTALL
-rwxr–r-- 1 www-data www-data 133 Mar 19 22:12 controller.php
drwxr-xr-x 2 www-data www-data 4096 Mar 19 22:13 controllers
drwxr-xr-x 2 www-data www-data 4096 Mar 19 22:13 documents
drwxr-xr-x 2 www-data www-data 4096 Mar 19 22:13 images
drwxr-xr-x 2 www-data www-data 4096 Mar 19 22:13 includes
-rwxr–r-- 1 www-data www-data 1171 Mar 19 22:12 index.php
drwxr-xr-x 14 www-data www-data 4096 Mar 19 22:13 interface
drwxr-xr-x 8 www-data www-data 4096 Mar 19 22:13 library
-rwxr–r-- 1 www-data www-data 13789 Mar 19 22:12 setup.php
drwxr-xr-x 2 www-data www-data 4096 Mar 19 22:13 sql
drwxr-xr-x 14 www-data www-data 4096 Mar 19 22:13 templates
I am still extremely concerned that the base directory in the error path is ‘/’ and not main/calendar/modules/PostCalendar/[other subdirs] as seems to be normal.
Which seems to discribe a basic smarty can’t create directory error. When I do what that article suggests I get past the initial create directory error, but still have the cannot write default.html.php error. Also, notice that the last two subdirectories from the error in the wiki is the same as the whole directory from my error:
"/%%164/%%1643473877".
Seems to me this should be looking in a subdir of "modules/PostCalendar/pntemplates/cache/"
I just checked and all of the values and entries from defaults.sql are present in my local mysql database. However the version of MySQL in Debian is pretty old and the database.sql script had some errors because of the CURRENT_TIMESTAMP function. I had to remove CURRENT_TIMESTAMP from the defaults on the ‘documents’, ‘pma-history’, and ‘notes’ tables and re-run the script.
OK, I have a bit more info. After putting some debug lines into openemr/interface/main/calendar/modules/pnincludes/Smarty/Smarty.class.php I found that in the _write_compiled_template function the $compile_path variable only contains:
/%%164/%%1643473877/default.html.php
This variable is passed from _process_template which gets it’s value passed from the fetch function.
Where does Smarty.class.php get its compile/template directory information from? Could I have a typo in globabls.php or perhaps I am missing some records from mysql?
A reinstall from the CVS worked? I havent used the tarball and have the same problems on SuSe 9.0 (apache uses wwwrun and www). My Line 589 errors went away with the creation of cache and compiled.
Question: what is an old MySQL for database.sql? Maybe we need to revisit minimum requirements again.
Alfonso
It is possible that creating those directories was what did it. I do that as part of my install process. It is possible that I could have fudged it the first time. Not sure.
Debian Testing comes with MySQL 4.0.20 and Debian Stable comes with MySQL 3.0.x.
The tables that have "default CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP" do not get added to the database, and as soon as the defaults are taken out of database.sql it works properly. Per the MySQL reference manual in 4.0.x the TIMESTAMP fields should default to NULL, and MySQL will update the value when records are created/updated. However, in 4.1.x the currently used procedure is recommended. I am not sure if 4.1 also allows the previous behavior or not.
I had to install mysql from unstable to have it working fine with the last mysql mods.
Even though, I had also to modify few lines which were giving errors in the database.sql.