When you do an initial checkout this always downloads the most recent changes.
Initially we ask that new developers to the project submit their code changes to Rod Roark or Andres Paglayan (andres@paglayan.com) for a review of the code. They will commit the changes for you. After they get a feel for your code they can give you commit privileges. We do this to make sure that the developers who have commit privileges know what they are doing and not making basic errors that can cause problems with security or maintainability of the code.
This is in no way a reflection on your development skills but is more of a "honeymoon" period to make sure major flaws are not being unintentionally introduced.
The OpenEMR community is very open and we welcome contributions of code as you are proposing. We ask that the code be released under the General Gnu Public License to keep the licensing consistent. Code should be clearly commented as to what it does with a statement that is being released according to the General GPL, the developers name and basic contact information.
We are using the ADODB abstraction layer to help us transition to supporting multiple SQL databases. We have decided to avoid using Smarty Templates. You may see Smarty Templates in use but we are trying to deprecate the use of this code. The ADODB abstraction layer is really the only abstraction layer that we want to use. Not because we think it is so special but just to get uniformity of the code. We try to avoid introducing abstraction layers unless there is some unavoidable reason to do so.
Back to cvs:
The problem gets trickier as a developer with commit privileges. Obviously you have to do the initial checkout. After making changes to a file that you would like to commit you need to refresh the working copy of your OpenEMR on the local hard drive.
shell$ cvs update
Gives you the latest changes.
shell$ cvs diff
Gives the differences between you’re current working copy and the lastest on the cvs repository.
cvs update and cvs diff become important tools before making commits. There is a lot of information on the use of cvs at sourceforge:
There is one remaining bug that is rather major that I haven’t been able to figure out.
Under PHP5 under Administration / practice / documents it takes you to a blank page.
So, currently under PHP5 you are unable to store patient documents at all.
Someone correct me if this isn’t the case for everyone and is an issue only I am experiencing.
I do believe Andres confirmed that he has seen this behavior as well.
What are the issues with Mysql5? I’ve heard of issues here and there, but I’ve got it running on 5.0.22 and I haven’t seen any issues.
Now I’m worried that I just haven’t run into any yet but I soon will.
Of course you will need to insert the actual owner of your webserver process (varies with operating systtem and/or linux distribution).
This can result from (and usually does) not having enough memory for PHP allotted under php.ini. Make sure that you allow at least 32 meg. The calendar sucks up a lot of memeory.
The same kind of issue occurs if your uploads are too large. There is also a maximum allowable packet size. On my system this came default at 1 meg. I increased mine to 2 meg.
If your’e up and runninf on MySQL5 and not seen any issues you are not likely to see any.
Yes, permissions and all other cases you mentioned are in place. This seems only to be an issue when using with PHP5. Have you got it up and running with PHP5 and the documents portion works without issue?
“””
Yes, permissions and all other cases you mentioned are in place. This seems only to be an issue when using with PHP5. Have you got it up and running with PHP5 and the documents portion works without issue?
“””
Well, The same thing is happening to me. When I try to bring up the dcoument handler I just get a white screen. This happening on my current Gentoo server that is running PHP5 and MySQL4. So this is a PHP5 issue and not a MySQL issue.
In all honsety, I hand’t noticed this problem before because I don’t store my documents this way.
This had been previously discussed in the developer forums about 1 ½ years ago.
The vote went for leaving the images on the hard-drive with just a pointer to the files. That is the reason the documents directory needs to be backed up separately.
I set up a PHP script that allows me to upload all my images as BLOBs in the database. This script has some limitations but is working very well under PHP5.
Andres, any thoughts on why the document handler is not working under PHP5?
I have been unable to help up until now because I did not have time to set up a php5, mysql5 system to test with. Last night, I set it up on my iBook, so I can try to help out. I’ll let you know if I find anything.
When you installed Ubuntu did you use the most recent version (Dapper Drake - 6.06 LTS) and did you do it with the LAMP option?
I’m using Ubuntu Dapper Drake and it’s working without issue.
When you installed Ubuntu did you use the most recent version (Dapper Drake - 6.06 LTS) and did you do it with the LAMP option?
I’m using Ubuntu Dapper Drake and it’s working without issue.
Yes, I installed with Dapper Drake 6.06.1.
No, I did not install with “LAMP option”.
So far I have tried Ubuntu and installed mysql5, mysqli, apache, and php5 using the Synaptic interface. Here the setup.php would not complete.
I have also installed with Gentoo using PHP5 and MySQL4. The same document error occurs.
I think we are not going to be able to ask all of our user base to install using Ubuntu with the LAMP module.