Now that OpenEMR is pretty much self-contained with respect to not requiring 3rd party applications like SQL-Ledger, it has occurred to me that we might start thinking of a recipe to upgrade future OpenEMR releases for installations hosted without root access.
I’m wondering if the MySQL tables could be modified for the newer OpenEMR version without disturbing the existing data, then the entire /openemr directory replaced with the new release.
Maybe this is already being done and I’m missing an existing howto.
hey,
Definitely possible. I have actually gone through the process (via bash scripting) in order to make the next ubuntu/debian package auto upgradable. If somebody wants to take the project on of doing this in the setup.php script I can definitely guide them to what exactly needs to be done.
Overview of steps needed to upgrade:
1)backup web folder and database
2)move openemr web folder contents somewhere else
3)unpackage new version to openemr folder
4)run upgrade script (would place this in the setup.php, input:previous version and path of old openemr))
-scrape sql info from old openemr/library/sqlconf.php file
-scrape several vital variables from old openemr/interface/globals.php file
-place sql info into new openemr files (sqlconf.php, gacl/gacl.ini.php, gacl/gacl.class.php)
-place vital variables into new interface/globals.php file
-run the sql_upgrade script (automate it so no need for input if possible)
-run the acl_upgrade script
-copy old documents directory (along with several other places that have user stuff) to new
DONE
Best place to put this script is in the setup.php file. To start would make two functions there. One that collect the variables from old openemr and place into an array. And one that would take this array and write these variables into the new openemr files. Once these are done would just be a matter of minor re-organization of setup.php file to allow upgrading to be an option.
Again, if anybody’s up for doing this let me know. I can supply exact variable, places, files etc. required.
One thing I would recommend for the future. Don’t bury the configs and data locations mixed in with the code to run the application. The simple model of a directory hierarchy that looks (for example) like this would make updates a lot easier:
openemr/
openemr/application/interface (etc …)
openemr/configs (all of the globals.php, sqlconf.php, graphic logo’s, etc.)
openemr/data (edi, documents, era, etc…)
Then you just replace the applications dir entirely
Config file changes can still be merged and or updated using and upgrade.php type script.
Really all that external file data should be a blob in the database anyway.
hey,
Agree it would be nice. This is actually causing some hardship in the UTF-8 conversion side because globals.php(which contains the UTF-8 a user flag i want) clashes with php-gacl stuff because it brings code along with it. So have to place a separate redundant flag in gacl’s config file. I think we should attack this issue after somebody minimizes the globals.php file and puts most these settings into mysql. Then we should only be down to several config stuff that needs to be hard-coded.
-brady
If directory structure isn’t constant from one version to the next then that would be a problem. But aside from the nearly 40 mb upload, replacing the entire application isn’t that serious of an operation. The really big issue is in maintaining existing data in MySQL while being compatible with the newer OpenEMR version.
As long as the MySQL database tables are updated to accept information from the new OpenEMR version, the newer version could be uploaded and dovetail with the database with no problem. The MYSQL table update could be in the form of a text file containing a list of INPUT commands, which could be applied using using phpMyAdmin (commonly included with cPanel).
A comprehensive upgrade utility would be the best solution though.
Actually there’s already an openemr upgrade database script in the main openemr directory:
sql_upgrade.php (for main openemr)
acl_aupgrade.php (to ensure gacl access controls are updated)
But, as in my above steps, these are just part of the upgrade process.
Directory structure changes would be straightforward to deal with in upgrade, but would be easier to untangle all the hooks by migrating most of settings from interface/globals.php to the sql database first.
If you know php, I could help you with adding the upgrade mechanism to the setup.php script.
The solution to my UTF-8 encoding issue actually twisted my arm to improve the installation/upgrade process. The php-gacl part of the setup now gets it’s information from the openemr library/sqlconf.php file (this is where i placed the utf-8 flag). Hence, no need to configure/modify phpgacl’s configuration files anymore during setups or upgrades.
It would be great if people tested out install process via the CVS snapshots at oemr.org (gets posted around 8:00 AM pacific time). While your at it test out the UTF-8 encoding stuff by basically inserting chinese or any other funny characters you can think of everywhere into the program (users, notes, passwords etc…). At this point in time, I’d consider our CVS version to be highly unstable.
Rod,
Perhaps I was being over-dramatic (it was late, and hat lots of caffeine in me). Its tested fine in my development environments. But the UTF-8 encoding stuff just seems squirrely to me, and would be nice to get testing in multiple diverse environments since it involves the database. Really just trying to dissuade any users from deciding to use the current CVS in a production environment, which has happened previously during the 2.9-3.0 developement span.
-brady
Yep,
I think I’m responsible here for the subject branching. To get back to the original subject, the upgrading has now become much more palatable. Here would be the scheme:
Overview of steps needed to upgrade in FUTURE openemr versions (note this is not for current version of openemr):
1)backup web folder and database
2)move old version openemr web folder contents somewhere else
3)unpackage new version to openemr folder
4)run upgrade script (would place this in the setup.php, input:previous version and path of old openemr))
-copy openemr/library/sqlconf.php from old version to new version
-collect the 2 web path variables from old openemr/interface/globals.php file and place in new file
-run the sql_upgrade script (automate it so no need for input if possible)
-run the acl_upgrade script
-copy old documents directory (along with several other places that have user stuff) to new
DONE
For the non-vital options, the user should also compare their old includes/config.php and interface/globals.php with new to ensure set up the options the same (don’t recommend replacing these files with old, since there are always changes in these in every release).
So, you’ll note, we no longer have to deal with gacl config files anymore. pretty cool.
