V4.2.0(3) to v5.0 Question(s)

hitechelp wrote on Tuesday, January 31, 2017:

We’re on Ubuntu 14.04 and OpenEMR 4.2.0(3) but could not get Patch_4 to execute properly using the login to run the SQL patch. It reports that patch 3 has been successfully completed. The login page still shows (3), so I’m sitting with Patch_4 loaded (unzipped) but database is apparently not patched. (see https://sourceforge.net/p/openemr/discussion/202505/thread/73ce7ca4/ )
Which begs the question, will I be able to update to v5 successfully when it comes out or will I need to fix this patch issue first? Also, will it be necessary to progressively update through 4.2.1 and 4.2.2 beforehand? And lastly, at what point would you recommend updating to Ubuntu 16.04? (14.04 is good until early 2019)
Thanks,

bradymiller wrote on Wednesday, February 01, 2017:

Hi David,

That’s odd. I took a look at the patch and the version.php is set up correctly and should show 4.2.0(4) whether you run the patch or not on the login screen (of course, you should run the sql_patch.php script to ensure bring in any database changes if there were any).
http://www.open-emr.org/wiki/index.php/Old_Outdated_OpenEMR_Patches#4.2.0_Patch_.289.2F2.2F15.29

Generally this means you unzipped the patch package into the wrong place.

What do you see if go to the admin.php script in web browser?

For version 5 upgrade, should be able to do a straight shot(of course, should test this out first before doing it on your production instance). I’d rec going to 16.04 after you are upgraded to 5 to ensure complete compatibility with php7 (note 4.2.2 is also php7 compatible, but several php7 bugs were fixed in 5).

-brady
OpenEMR

hitechelp wrote on Tuesday, February 07, 2017:

Hi Brady,
Yes, it’s very odd. The zip folder was placed in the /var/www/html/openemr directory and then (after cd ing there) the following command was run from the terminal “sudo unzip 4-2-0-Patch-4.zip” and “Y” to the overwrite prompt. The terminal display seemed to indicate the patch was unzipped (files scrolling by quickly were being reported as “inflating”. If it wasn’t unzipped to the proper location, I have not been able to find the location where it was unzipped. So perhaps it was never really unzipped at all. In the past I’ve handled patches remotely through Webmin with no issues, but this one would not unzip through Webmin. I had to go to the office and run unzip from the terminal.

I’m not sure how to go about viewing the admin.php script in Firefox in a way that shows you what you need to see. Port 80 is normally forwarded at my router to another device (I have to undo that to run the SQL login so I probably need to do the same for looking at admin.php?) For now I’ve downloaded a copy and opened it on my workstation.
Here’s the link to the screenshot.
https://drive.google.com/open?id=0B6_qxpCoBHlYRHk1TWlGRVE5NzA

Thanks,
David

bradymiller wrote on Wednesday, February 08, 2017:

Hi David,

The best place to do a sanity check is the version.php file. Specifically the $v_realpatch variable. Look at it in the patch file (it should be 4). And then look at it after you do the extract (it should be 4 and not 3).

btw the admin.php script is not working, but not related to the patch. it’s not being run through a php interpreter, so is just showing the text of the php code. Best to instead do the above sanity check in version.php anyways to problem solve this.

-brady
OpenEMR