The next major version of PHP is currently releasing release candidates and is expected to be released in November. PHP 7 is significantly faster and ships with many new features such as a strict mode, return types and more. Despite all these big changes the number of backwards incompatibility are minimal.
However OpenEMR has code that was deprecated back in PHP4. We need a cleanup run… This is a great job for someone new to the project. OEMR will provide a free license of PhpStorm the first two individual volunteers (not company based) that want to take this on.
I have been thinking about starting a crowd funding effort for this.
One of the previously deprecated, now removed items is the mysql library, replaced with the mysqli library. Given that the mysql library is so central OpenEMR’s functionality, addressing that item alone, besides any other compatibility issues requires caution and attention to detail.
What is the starting point? This will be an issue for everyone so can we break it up into managable chunks. The stuff that is already deprecated should be fixed first (IMO) before any new items are tackled.
The Idea, to start with is to use PhpStorm which has excellent reporting (in line and batch) to identify the issues and fix them. Anyone with moderate PHP skills could do that with out knowing much. If for some wild read we get a ton of volunteers we can break it up in to subdirectories. Needs to be do and delivered is small doses anyway.
We can ignore phpmyadmin, Zend and some other things that are entirely third party.
Been dreading the loss of the mysql library, which I am guessing is the largest issue for openemr with php7. We’ve discussed possible solutions to this intermittently over the last couple years. Here’s a summary of the mysql issue and discussions with some interesting links: http://www.open-emr.org/wiki/index.php/Active_Projects#Convert_connector_to_MySQLi_or_PDO
The MySQL API conversion is hopefully not a big deal, since as noted the calls are centralized. Needs some analysis. There may also be opportunities for performance gains and that may entail more work.
Although the sql functions are mostly centralized, there are many different ways those functions can be called, with and without binding, with and without logging as examples.
Furthermore the calendar code does not use the functions from sql.inc.php for its database calls in many places.
Proper testing would also mean needing to exercise each of the different methods changed in sql.inc.php.
The issues involved are a much bigger deal than the simply identifying the backwards incompatible calls using PHPStorm.
Did ZH avoid using Zend\Db\Adapter or build logging and other functionality on top of it?
If Zend is here to stay, is it possible to use that adapter as a base and build a transitional layor of most commonly used functions in the current code? Benefit will be additional functionality like query profiling will be automatically accessible.
1.Some thoughts on the options of Zend vs adodb/mysqli.
—Zend:
Z&H built a query function using Zend that is very versatile:
In theory, this zQuery() function could be wrapped in all the openemr sql functions and could drop adodb. However, dropping adodb would take some work since there are places in the codebase that directly call adodb library rather than use the openemr sql functions. If could get this to work, this would be ideal and more clean (it also does not suffer from the annoying “exponential insert counting bug” during logging that caused issues and required workaround in adodb).
—adodb/mysqli:
It would be easier to dismiss this if adodb is no longer supported, but adodb is still going strong, so guessing they will be supporting php7 then:
https://sourceforge.net/projects/adodb/files/adodb-php5-only/
This would likely be quickest route since simply changing from mysql to mysqli in adodb (so just need to convert the sql wrappers and also ensure the “exponential insert counting bug” is well managed). If go this route, then would definitely also make sense to update the adodb library.
2.Regarding the postcalendar and phpgacl which use their own way of database queries. Note these are each centralized and use their own respective adodb libraries (I know this from when we converted OpenEMR to support UTF8). So, dealing with those should not be much of an issue. Likely best route will be to instead run the queries through openemr’s wrappers(and remove their corresponding legacy adodb libraries).
We started work on the PHP7/MySQL updates. Our approach will be at Brady’s direction:
Modify all places (except for in the centralized library functions) that use any mysql_connect native functions (including the mysql_real_escape_string() function) and have them intead use the current openemr functions in library/sql.inc.php and library/formdata.inc.php(don’t modify these central functions, though; can work on that later when know what framework will go to).
Modify all places that do magic quotes (except for in the centralized functions and interface/globals.php) to use the current openemr functions in library/formdata.inc.php.
Modify all places that use the adodb library directly(don’t modify the library/sql.inc.php script though) to instead use the centralized openemr mysql functions in library/sql.inc.php (and don’t worry about the postcalendar and phpgacl modules).
The last step will be to “uncomplicate” the openemr mysql functions (note they now support returning either a recordset(adodb) or a record(mysql_connect) to prevent breaking places in OpenEMR that still use native mysql functions). This is something that the developer shouldn’t work on until above 3 steps are completed, though.
Doing the above will:
Give the developer whom works on this an appreciation for the current mysql mechanism, which will make it much easier when decide on the route to go (the conversion will be more about finesse than brute force).
Be applicable very quickly (ie. will get committed to the official codebase quickly as the developer works on it in small pieces).
Allow the community to make a good decision on which mysql library/framework to go with, which will then require very little work.
That’s excellent. Can Samdarsh Jalali be assistance as well here?
Also I have attached a ZIP fle that contains a full HTML “site” that is a inspection report for all OpenEMR. I excluded phymyadmin and Zend. This is just based on php 6 as I don’t have the tool for php 7 installed yet, but it is interesting and might be something interns could use to fix minor bugs and “bad code” above and beyond the deprecated things.
The MySql updates should be done this week as per Brady’s guidance.We will be starting the PHP7 renovations directly after. We will be using PhpStorm’s code inspector for guidance.
I would be pleased to be of assistance in any way. I am relatively new to this scene and have just installed OpenEMR. With a little guidance though, I will be able to make substantial contributions.
Once you do that set up a project that uses your local git clone of openemr and start taking a look at the inspection messages. You can run a code inspection report or just look at the yellow bars on the right margin of any file you open and see if you can fix the identified issues. Some of the will not be relevant, like the ones related to SQL language reference which is just a helper tool.
You can configure inspections to just be syntax which might be helpful to start to start with. select Code->Configure Current File Analysis and move the slider to Syntax
Hi Tony,
Can phpstorm be configured to only show the drop-dead issues from php7 (ie. not all the other noise), since can then first focus on the things that will break. After fix these critical issues, then could separately work on the other non-critical issues.
-brady
