hey,
We’ve uncovered a UTF8 bug that only happens in Windows. It is only cosmetic (doesn’t affect the database), but is very annoying. The calendars can’t display patient names if in UTF-8 characters (such as Greece or Chinese). This is secondary to the following code found in the 10 of the calendar files (listed all files at end of message):
$lname = addslashes(ucfirst(strtolower(substr($event[‘patient_name’], 0, $commapos))));
$fname = addslashes(ucfirst(strtolower(substr($event[‘patient_name’], $commapos + 2))));
Luckily, this doesn’t pose problems on the linux boxes, but we need to stay away from any heavy string manipulations now that were supporting UTF-8 character. The following will fix the bug:
$lname = addslashes(substr($event[‘patient_name’], 0, $commapos));
$fname = addslashes(substr($event[‘patient_name’], $commapos + 2));
If nobody has any issues I will commit these changes to CVS (both 3.2.x and 3.1.x), and post a "patch" for this in the tracker (the patch will simply be a zipped file of the 10 fixed files). Also will open a bug in tracker to refer windows users to the patch if they have this problem.
If anybody has problems with above code changes let me know, otherwise will commit changes tomorrow.
-brady
as promised here are the list of problem files:
openemr/interface/main/calendar/modules/PostCalendar/pntemplates/default/views/day/orig_default.html
openemr/interface/main/calendar/modules/PostCalendar/pntemplates/default/views/day/ajax_template.html
openemr/interface/main/calendar/modules/PostCalendar/pntemplates/default/views/day_print/outlook_ajax_template.html
openemr/interface/main/calendar/modules/PostCalendar/pntemplates/default/views/day_print/ajax_template.html
openemr/interface/main/calendar/modules/PostCalendar/pntemplates/default/views/week/ajax_template.html
openemr/interface/main/calendar/modules/PostCalendar/pntemplates/default/views/week_print/ajax_template.html
openemr/interface/main/calendar/modules/PostCalendar/pntemplates/default/views/week_print/outlook_ajax_template.html
openemr/interface/main/calendar/modules/PostCalendar/pntemplates/default/views/month/ajax_template.html
openemr/interface/main/calendar/modules/PostCalendar/pntemplates/default/views/month_print/ajax_template.html
openemr/interface/main/calendar/modules/PostCalendar/pntemplates/default/views/month_print/outlook_ajax_template.html
Another question. Why are we adding slashes? These variables don’t seem to be sent to the database, just the screen.
So, new proposed changes are:
$lname = substr($event[‘patient_name’], 0, $commapos);
$fname = substr($event[‘patient_name’], $commapos + 2);
Might be to deal with names that include apostrophes. I recently had to change it from addslashes() to htmlspecialchars() on our end.
Names were being stored in the db correctly and displayed as O’Malley, but in the browser the single quote was going on to mess things up elsewhere, like in the add_edit_event popup.
Some developers add slashes and some don’t. Some insist on turning Magic Quotes “on” and some insist turn “Magic Quotes off”. We have ended up with a hodge-podge of some of the code works with Magic Quotes “on” and some work “Magic Quotes off”.
Personally, I think Rod Roark is correct in that we should be handling this type of problem through the database connector class. The code should detect the system value of Magic Quotes status and then "do the right thing".
Bill,
Sounds like this would be better then:
$lname = htmlspecialchars(substr($event[‘patient_name’], 0, $commapos));
$fname = htmlspecialchars(substr($event[‘patient_name’], $commapos + 2));
I’ll test that.
Where else have you made these changes besides the files I mentioned above. May be a good idea to consider changing those in the current development tip.
Sam,
The thing that is odd here is that these variables aren’t going to the database, just the screen. So no need for magic quotes or addslashes. Agree that that issues needs to be standardized especially considering php6 will not allow magic quotes anymore.
-brady
I agree with Sam that this is a problem. And has been throughout. If it is possible to have all data verified to accept anything the person enters in the data box, then that should be done. Note that I personally do not know how, but you developers do. Time to remove the we-they and fix this with the next release.
I forgot to note that I do not use any non-english characters, so I cannot help in testing the problem and fix for the UTF8 issue. But if it will be part of the release distribution when the Xampp-3.1.0 Windows version comes out, a patch for ANY such changes, usable in the other distributions, should be either provided at the same downloads page, or at least a recommendation that users apply the patch or re-load the updated version. It is way too easy to overlook such things six months from now as we try to solve some other issue. Thanks.
As part of the zip file, since this affects Windows users, would it not be ideal to include a BATCH file which explicitly takes the files from wherever the extract is done and places them? I might suggest to use the default xampp-windows location structure, but include in the instructions posted that users can change that to their individual locations with a common Edit function on that batch file. That way, most Windows users (I presume) would simply run the batch after extract, and all would be hunky-dory
Bill,
The htmlspecialchars stuff works great, but instead needed to be more granular. For example when posting to screen (so not within quotes) used htmlspecialchars(), however when within title of click (in lots of jason’s outlook stuff) used htmlspecialchars(,ENT_QUOTES)
-brady
This was not a very joyous task. Fixed all the files in the 3.1.x and 3.2.x branch. Also posted a bug(ID:2852519 ) and a patch(ID:2852515) in the trackers.
Not a horrible bug, the users that need to fix this should be able to copy files in MS Windows (I hope…) We’ll use this patch for the soon to be released openemr-xampp package. If need be, could always develop a automated patch method, but I truly have no motivation to work on something like that.
The addslashes was certainly a hold over from ancient code.
But here is something else to consider… and I think Brady found it already.
The patient’s lname and fname are used in the title attribute of the DIV tag in the AJAX calendar. When a patient has an apostrophe in their name, such as O’Brien, the title tag is screwed. Here is an example of what I’m talking about.
Look at the part around [Office Visit] and you’ll see the added slash. However, because the title attribute is bounded by single quotes it is accidentally terminated after the added slash.
This leads to broken and invalid HTML code in certain situations.
I get the feeling that Brady already found and corrected this oversight.
I will be happy to build a zipped batch file which will autoload for any existing 3.1.0 setup. I will need the list of all affected files and where I can find the fixed ones to download, and then to whom I send the zip file for posting on the appropriate site (I would suggest the downloads location for 3.1.0) and a simple instruction set for its use, along with how to revise if their directory location is NOT that of the default xampp-windows install. Please let me know at
I downloaded from the tracker and looked at the 10 files package, and it needs no batch file. Windows includes an "Extract" function available with a right-click on the zip file in Windows Explorer (NOT IE) which allows simply designating the "extract to" directory to be the main openemr directory (beneath htdocs in the xampp setup). It will prompt that files exist and will be replaced, but it only replaces the final level files in the tree structured directory, leaving all the others in the various locations as they were. So the windows instruction should simply be to "Extract the zip file to the base …/openemr directory and accept the overwrites".
Please note too; I could not test with chinese characters, etc, but have no doubt that your testing verified that as OK in the Calendar Views. But I did verify that names with apostrophes (like O’Brien) would display (they must have the php.ini file "magic_quotes_gpc" set to On or an error will occur on trying to save the demographics. I did this by changing the name as already entered for an appointment, by clicking on the name in the appointment and editing the demographics. However, other problems with display occur in the "Add" function for the calendar, where the "Patient:" search field will balk at any name which contains an apostrophe, even if the last name, which is entered in the seach box, does not contain the apostrophe. The resultant selection list will show the name like "Test, Sys’tem", but clicking on it does nothing. Removing the apostrophe allows it to work fine. So the problem will remain I am pretty sure if the user has entered UTF8 character sets in the Lname or Fname fields as well, or at least if a name like O’Brien is entered. It will not allow the "Add" function in the Calendar as-is.
So I think the problem is not quite completely fixed with the 10 file set. Sorry.
There were two unrelated issues in calendar:
-UTF8 characters (primary goal to fix)
-apostrophes (happened to be on same source code line as above fix, so fixed some of this as well)
The display of UTF-8 characters is fixed.
The apostrophes issues are only fixed in the calendar display. There are likely more bugs to unravel with apostrophes, and the add appt page would be next place to start. Would be great if you could open a bug in the tracker with your findings to remind us to begin fixing the apostrophe errors within openemr when have time.
