The latest checkout from CVS gave my a PHP5 ONLY version of this file:
library/classes/Filtreatment_class.php
I’ve modified it back to work with PHP4 but not committed the change to CVS. I’d like to but I haven’t made the time to fully test the code. I “just made it work” in my environment.
Now, I plan to upgrade our Organization to PHP5 in the next few months but right now I can’t justify the time cost. So please, everyone, be mindful that there are still PHP4 users out there. Perhaps the author of Filtreatment.php can chime in with the reason PHP5 is required for the code?
No, there is no battle between PHP4 and PHP5, but I can easily explain this.
Even the backward compatibility is important, in this case (with this class), I noticed that it’s used only by us (the programmers for Dutch version). It was just a quick and temporary solution to some security problems for openEMR in the past. I never intended to promote it in all the openemr code.
Anyway, even if we try to keep compatibility with php4, the new code we develop is only for (at least) php5. PHP5 has a better OOP support and as a programmer I want to take fully advantage of it.
I made recently an upgrade from php4 - php5 for our server and it took me about 15 minutes. Why do you think the upgrade is so time consuming ?
For your problem: We just can put two version of the file, one for compatibility and then select what we’ll include (function of php version).
Upgrading to PHP5 is simple and easy… if you’re only running OpenEMR.
But what happens what you’re running over a dozen different web applications written but several dozen different developers?
Several of those web applications have been running flawlessly for 5 years on PHP4. I did try an upgrade to PHP5 once and it lead to about 4 hours of hand-editing source code in 40+ different files. At that point I threw up my hands and went back to PHP4. If I had a staff or even just one other part time helper I could make the transition. But in my situation I’m the sole IT person for 3 servers, 150 workstations, and 180 users spread across 6 sites in southeastern Connecticut, USA. Time is preciously slim for doing upgrades unless they are mandatory.
Anyway… I do agree that PHP5 is way better than PHP4. I’m looking forward to getting there later this year.
No, I think upgrading to php 5 is simple and easy if your applications are prepared for that and you have some time available for them …
If they are made for php4, then yes, you could end with hours of source code editing. I even noticed that together with the php update I was forced to an mysql update (I was using yum, not compile from the sources), and then I discovered some sql statements which weren’t mysql 5 compliant.
I think it’s worth it. PHP4 soon will be history, 5 is better and 6 is on the way.
So far, I’ve seen no rational argument for not supporting php4(ie. any specific php5 programming spec that are required). By forcing php5 in the next version, it’s just gonna make the upgrade more of a headache for people still using php4. Even when the security updates stop, I think we can let the end-users decide whether that’s important.
I guess I just don’t see the point of breaking something unless there’s a valid reason.
if you want to continue using php4 and Filtreatment, just do it! Transform this class to be php4 compliant and use it.
The future development for this class and for the rest of the Dutch code will be based on at least PHP5. This code is separated so for the rest of the world, it doesn’t matter too much if we’re using 4 of 5.
Anyway, I see no reason why you shouldn’t (at least) try to upgrade to php5. It’s not such an headache (maybe only for very old apps); but for sure, security problems will be soon.
p.s. oh, and it’s not breaking something, it’s just progress.
It’s not that we are trying to force PHP5 as much as supporting PHP4 is getting harder.
If I understand correctly, Christian added library/classes/Filtreatment_class.php to fix some security problems for the Dutch billing system. If I also understand correctly, he doesn’t seem to care which version (PHP4 or PHP5) of Filtreatment_class.php is being used.
Also, what Jason is saying is that one of the developers (possibly Cristian) keeps over writing the Filtreatment_class.php back to the PHP5 only version.
Christian, What version of the Filtreatment_class.php are you using and can you get by on the PHP4 version?
Yes, I put in the cvs the class version for php5 (but only for the first time, I didn’t overwrite anything lately ).
In this situation, Brady can transform this class into a php4 version to use it with his system. Please, leave the php5 version also in there, because some of the users will want to use it as well.
Now, it’s almost a painless procedure to get back to php4, but on the future, this class may contain php5 specific features and functions, so there is no guarantee that would work.
If we decide to not support backward compatibility to php4, then that’s fine, but it should be a decision made with some thought, and not by one developer.
I still haven’t heard any specific reasons why we should drop support for php4, and I especially don’t see the reason to break support of php4 because of one class right before a new version release of OpenEMR. It sounds like Filtreatment_class.php is supposed to be only used by the Dutch billing system, but I’m wondering then why CFAPress had to transform it to php4?
I think you misunderstood this issue; no one decided to drop support for php 4. Yes, there were some discussions, but the openemr will be with php 4 support for this year at least.
In the main we are forced to make code compatible with 4, but for our subprojects (for example Dutch System), we just agreed that we’ll be using at least php 5.
If the community still wants to use this class, just make the php 4 version. If it doesn’t, no problem at all. If CFAPress wants to tranform it to php4, very good!
I just ran across this also when upgrading OpenEMR at a PHP4 site. In this case going to PHP5 would be awkward, as OpenEMR is not the only PHP application installed.
Cristian, are you saying the Filtreatment class is not necessary for non-Dutch users? If so, why do globals.php and login_frame.php always include it? Because they do, OpenEMR as currently in CVS is broken for all PHP4 users. I think that’s what all the complaints are about.
Also, for what it’s worth, the incompatibility appears to be caused only by the use of “private” and “public” keywords, which do not seem to be necessary.
I am curious. What are the functional differences differences between Filtreatment_class.php and the ADODB AutoExecute() ?
I know I am not expert on these issues, and my question may seem silly, but fools rush in where angels fear to tread.
At least superficially, Filtreatment_class.php, mysql_real_escape_string(), and ADODB AutoExecute() are all used for similar purposes (help improve security by checking the file for validity and providing protection from SQL injection.)
The version of Filtreatment_class.php is dependent on the PHP version.
ADODB AutoExecute() is a server side stored procedure that improved MySQL security and is independent of PHP version. It also helps the long term goal of database independence.
Would not upgrading ADODB to adodb-498-for-php and using AutoExecute() be a more generalizable solution that would help improve OpenEMRs database independence and side step the problem with Filtreatment_class.php ?
).