yehster wrote on Tuesday, September 24, 2013:
It’s going to take a patch to rename the password_hash function defined in OpenEMR to not conflict with PHP 5.5’s version, and it’s unclear if there are other potential issues with 5.5 that may arise.
Suggest that you downgrade to 5.4. From what I can tell 5.5 comes from a test repository anyway.
jackfruit501 wrote on Tuesday, September 24, 2013:
Thanks for the quick reply. I have installed openemr-4.1.2 successfully on my external harddisk running Ubuntu 13.04 with php5.4.9-4. I will wait for the patch before I migrate back to Fedora 19 & php5.5.3.
Jackfruit501
bradymiller wrote on Tuesday, September 24, 2013:
It’s only a matter of time before php steals the password_salt() function also. There must be php spies among us 
-brady
meddev wrote on Tuesday, September 24, 2013:
Sometimes the shotgun approach to troubleshooting fails me…
Good catch Kevin!
fsgl wrote on Tuesday, September 24, 2013:
AJUTABILISSIMUS ET LARGISSIMUS YEHSTERUS EST
Thank you, MedDev, for being part of the cavalry riding to the rescue.
This was like cutting the Gordian Knot.
Ok, Latin->Greek, if we are talking about Macedonians.
Είναι το πιο χρήσιμο και το πιο γενναιόδωρο.
yehster wrote on Tuesday, September 24, 2013:
Your shotgun either grazed the target or at the very least flushed it out.
A search for more details on SELinux is what lead to my discovery of PHP 5.5 conflicting password_hash function. A larger set of differential diagnoses is generally more likely to result in finding the correct one.
samuelelliot wrote on Wednesday, October 23, 2013:
I’ve been running PHP 5.5 for over a month now. When I was attempting to install OpenEMR, I ran into the error “Cannot redeclare password_hash() …” Now without “downgrading” to PHP 5.4 we can get OpenEMR working with just a few steps.
Keep in mind this issue is due to a new CORE PHP function “password_hash” being added in the PHP 5.5.0 release and conflicting with an OpenEMR user defined function of the same name. If by some chance you have other applications running on the same system which make use of the new PHP CORE function, this work around will make those applications fail. If you have PHP MPM setup with Apache MPM Prefork, then you should be able to localize this change to the OpenEMR Virtual Host.
In keeping with improving OpenEMR, a solution that would correct this is implementing Namespace for the application, or renaming the function. It was common practice in PHP before Namespace adaptation, to see application function names proceeded with an application specific prefix. In this example “password_hash” would become “oemr_password_hash”, and with only a handful of locations in the code to change this would be an efficient modification without seriously hindering any backwards compatibility.
NOTE: If we look at the fact that namespace is becoming the defacto standard for name collision correction, as it is in many languages, then implementing namespace would be the correct way to solve this issue. Keeping in mind that it would be a larger change to the whole of the project.
yehster wrote on Wednesday, October 23, 2013:
I already have a commit for that does exactly that with oemr_password_hash, and for consistency I also renamed password_salt to oemr_password_salt.
Haven’t pushed it to master yet.
The problem with using namespaces is that Brady and Rod insist on backward compatibility all the way to 5.2.x, which doesn’t support them.
bradymiller wrote on Thursday, October 24, 2013:
Hi,
Regarding namespacing, appears that it would involve another resource intensive code walk through; I am pretty sure this is the first time this has happened to the OpenEMR codebase. The problem is Kevin is too good at naming functions (mine would of been something like create_password_hashy, thus would be safe from php thieves since such a poor name). We could decide to implement that all new functions need oemr_ before or _oemr after them unless the function names are already way too long.
-brady
OpenEMR
samuelelliot wrote on Friday, October 25, 2013:
I realized that my temporary work-around doesn’t work. I thought it did, because I failed to revert the naming changes I made. Even though the internal function is disabled, it’s still defined… thus the same error will occur “Cannot redeclare password_hash()…”.
http://www.php.net/manual/en/function.function-exists.php#67947
This is a known issue since 2005 and as of this year it was assigned and is being looked at.
https://bugs.php.net/bug.php?id=31875
The only correction for this is Namespace or naming change.
yehster wrote on Friday, October 25, 2013:
Thanks for the update. That’s too bad about disabling functions not working.
https://sourceforge.net/p/openemr/code/ci/fee4dee9618cb169d1656add0f5b01030aae6e4d/
I’ve pushed the oemr_ implementation (and the verification of password has with each session access) to the official repo.
jackfruit501 wrote on Friday, November 01, 2013:
Hi Kevin,
I upgraded Ubuntu 13.04 to Ubuntu 13.10. Now I have the same problem as in Fedora 19 … I cannot login either with admin or my other users. I tried a fresh install with openemr-4.1.2.tar.gz but the setup stopped (http://localhost/openemr/setup.php?site=default) with a blank screen.
(I removed openemr in /var/www/ and dropped openemr at the mysql server for the fresh installation of openemr-4.1.2)
Jack
yehster wrote on Friday, November 01, 2013:
Ubuntu 13.10 uses PHP 5.5, so you won’t be able to use 4.1.2 without a patch to address the password_hash function name collision issue.
If you use the 4.1.3 development tip, it will work though.
jackfruit501 wrote on Friday, November 01, 2013:
Thanks for the prompt reply. Just curious, when will openemr-4.1.3 be out?
Jack
bradymiller wrote on Friday, November 01, 2013:
Hi,
The bug that keeps on giving
I think this bug will kill installation and also kill the ubuntu package?
May need to release updated 4.1.2 packages along with the typical 4.1.2 patch for this fix. Thoughts anyone?
-brady
OpenEMR
tmccormi wrote on Saturday, November 02, 2013:
Yes it is required .10 is rolling out all over the place
Tony McCormick
503-330-2239
On Nov 1, 2013 4:17 PM, “Brady Miller” bradymiller@users.sf.net wrote:
Hi,
The bug that keeps on giving
I think this bug will kill installation and also kill the ubuntu package?
May need to release updated 4.1.2 packages along with the typical 4.1.2
patch for this fix. Thoughts anyone?
-brady
OpenEMR http://www.open-emr.org/Ugrade database 4.1.1 to 4.1.2https://sourceforge.net/p/openemr/discussion/202505/thread/d9b59b41/?limit=25&page=2#7132
Sent from sourceforge.net because you indicated interest in
OpenEMR / Discussion / HelpTo unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net
bradymiller wrote on Saturday, November 02, 2013:
Hi,
Just issued a 4.1.2 patch with this fix. Getting it into packages will be very simple, but will await some more testing (note I tagged it with v4_1_2_3 to make easy to use in script below to build the packages).
http://www.open-emr.org/wiki/index.php/Steps_for_an_official_release#9._Build_the_tar.gz.2C_zip_and_deb_packages_from_v4_1_2.
-brady
OpenEMR
fsgl wrote on Saturday, November 02, 2013:
Jack,
Have you been able to get patch 3 into the package to resolve the problem with Ubuntu 13.10 & Fedora 19 ? If not, the insertion should be imminent and then you can use Brady’s package.
Kevin provided the Php 5.5 incompatibility fix.
Let us know how you fared.
jackfruit501 wrote on Sunday, November 03, 2013:
Hi fagl,
After using 4-1-2-Patch-3.zip openemr-4.1.2 worked as usual in Ubuntu 13.10. I will test Fedora 19 when I am in the office tomorrow.
I found the administrator cannot remove a user.
Thanks for the perseverence. Very much appreciated.
Jack
jackfruit501 wrote on Sunday, November 03, 2013:
Hi fagl,
Just to add, installation using patch 3 worked on a fresh installation of openemr-4.1.2 in Fedora 19 like a charm. Upgrade from 4.1.1 (14) failed however.
Regards to all and thanks again.
Jack
