rayaz wrote on Saturday, April 02, 2011:
Hi,
Restoring a back up from OEMR 4.0 in Kubuntu 10.10 returns an error …Error: The phpGACL directory path ’ $phpgacl_location = dirname(__FILE__).’/…/gacl’;’ does not start with ‘/’.
Please help
Regards
Rayaz
rayaz wrote on Saturday, April 02, 2011:
Hi,
An update, just looked at the tar file and it contains three files now: openemr.tar.gz and openemr.sql.gz and phpgacl.tar.gz. Is that important?
Regards
Rayaz
rayaz wrote on Monday, April 04, 2011:
Hi,
I really do need a solution, unfortunately I upgraded before fully checking the restore functionality. Now I am left without any recourse to a restore if anything happens to my main computer. Also I cannot restore my daily backup to my laptop.
Regards
Rayaz
bradymiller wrote on Tuesday, April 05, 2011:
hi,
What happens if you unzip the file, remove phpgacl.tar.gz, and then rezip it (without the phpgacl file)?
-brady
rayaz wrote on Tuesday, April 05, 2011:
Hi,
It still throws up an error: Site ‘default’ already exists in ’ /var/www/openemr/sites’.
Regards
Rayaz
sunsetsystems wrote on Tuesday, April 05, 2011:
Unless you are adding another site to the tree at /var/www/openemr then you need to first delete or move that old directory out of the way (assuming, of course, you do not want to keep it).
sunsetsystems wrote on Tuesday, April 05, 2011:
Regarding the first error, if you answer Y when asked if you want to specify new names and locations, then you will be given a chance to provide a valid path for the phpgacl directory.
rayaz wrote on Tuesday, April 05, 2011:
Hi,
OK, I removed the old openemr directory at /var/www and did a restore after entering the full path for phpGACL directory: /var/www/openemr/gacl. It worked.
But in this method of restoring has two differences from my previous restores in 3.2:
1: Have to delete /var/www/openemr everytime I restore
2: Have to provide a pathway to phpGACL everytime I restore
Thats a lot of work for daily restores to my laptop from my office computer!
Regards
Rayaz
sunsetsystems wrote on Tuesday, April 05, 2011:
It would not be hard to customize the restore script to do both of those things automatically. This is the kind of problem that shell scripting is designed to solve.
rayaz wrote on Tuesday, April 05, 2011:
Yeah, but the point is the restore script worked very well without modifications in version 3.2, so having to redo the whole thing is kind of counterproductive!
Rayaz
sunsetsystems wrote on Tuesday, April 05, 2011:
Restoring in 4.x is a bit different than in 3.x, due to the need to allow for multiple sites. That’s why you now have to explicitly delete the directory if you are not adding a site to it. The phpgacl thing might be a bug (not sure), but use of an external phpgacl is strongly discouraged anyway.
rayaz wrote on Tuesday, April 05, 2011:
Okay, so how would I go about scripting the restore script for my needs?
Rayaz
sunsetsystems wrote on Tuesday, April 05, 2011:
If you want to be self-sufficient, start with this:
http://tldp.org/LDP/Bash-Beginners-Guide/html/Bash-Beginners-Guide.html
Alternatively, consider hiring one or more of the vendors here for your various support needs. They put much effort into improving OpenEMR and will appreciate your business.
rayaz wrote on Friday, April 08, 2011:
Hi,
Managed to be self-sufficient! But thanks to Brady for taking out the phpgacl save bug in backup.php.
Thanks Rod, for the guidance
Regards
Rayaz
octort wrote on Thursday, April 14, 2011:
Can someone post the new restore file? I am getting the same errors. Thanks!
bradymiller wrote on Friday, April 15, 2011:
Hi,
The bug was in the backup script. I’m assuming you’re using OpenEMR 4.0. Here’s the link to the new backup script (replace your current openemr interface/main/backup.php file with below file):
http://github.com/openemr/openemr/raw/rel-400/interface/main/backup.php
-brady
bradymiller wrote on Friday, April 15, 2011:
hey,
Just released a new 4.0.0 patch, which includes the fixed backup.php script:
http://www.openmedsoftware.org/wiki/OpenEMR_Patches
-brady
tmccormi wrote on Friday, April 15, 2011:
Brady - when we patch a release, ie: 4.0.0 shouldn’t we be rolling the release patch #, ie: now it’s 4.0.3 I think.
It’s very hard for end users to tell if the source code has been patched
3 digit release # is intended for that purpose, ie: MAJOR.MINOR.PATCH
At the very least we should update the version.php
$v_major = ‘4’;
$v_minor = ‘0’;
$v_patch = ‘0’;
Maybe the branch names (in the future) should be rel-40 leaving the patch level as internal?
-Tony
bradymiller wrote on Sunday, April 17, 2011:
hey,
More thought would need to put into this. For example, isn’t a version also kept in the database and would this discrepancy break Rod’s admin.php stuff. Also, the ubuntu package for the next version would need some changes to support this. Would need time to test/debug which currently don’t have.
-brady
tmccormi wrote on Monday, April 18, 2011:
Rod’s stuff is about Database version not the release version, I think. Curious how this would break the Ubuntu package install? Seems very odd that the version number would have any effect on the installer since you are not generation paths that are version specific, to my knowledge.
That said I don’t ever use the installers, too limiting for my installs which are not ‘single’ instances and would never use the default paths and db names in any case. So … I don’t have an experience with them to draw on.