Reports not generating correctly

meiert5798 wrote on Saturday, April 30, 2016:

After upgrading to OpenEMR 4.2.1, LBF reports with tables in NationNotes have not been generating correctly. There’s a few loose HTML tags that throw off the formatting. I reinstalled OpenEMR (redid the upgrade process save the database upgrade) and also tried replacing some of the PHP files I believed to be generating the reports with older versions (from 4.2.0), both of which did not help. I have attached an image of the generated form. I could post the generated HTML if need be, but I would have to scrub it.

I would imagine this is a problem with the LBF form (because it’s still broken after a “reinstall”). Has anybody else experienced this issue?

fsgl wrote on Saturday, April 30, 2016:

A screenshot of the layout would be helpful. Something like this:

.

Perhaps you will find something useful from this webpage.

In addition to layout_options, NationNotes will require the customlist & list_options tables.

A quick way to learn how to contruct a NationNote is to import the zipped files & play with the NT form.

If there had been no problems with the NationNote prior to the upgrade, try Section 12.2.

meiert5798 wrote on Saturday, April 30, 2016:

I roughly followed that webpage when initially creating the form. To clarify, all required tables are present. The form was working entirely as intended until the 4.2.1 update.

Is the botched HTML formatting because of something in the form is it possible that something is not functioning properly within OpenEMR?

There is nothing missing (buttons, fields, etc.) in the form; the issue is that the tables in the form are not aligned correctly.

fsgl wrote on Saturday, April 30, 2016:

I don’t understand the choice of NationNotes as the Data Type with Lists. Seems that Listbox with Lists is the easier route.

NationNotes are great because the WYSIWYG editor permits a selection of components from the left side bar to fit nicely into a paragraph format.
.

If you don’t want the components nor the editor, no reason (except to embed an image) to have a NationNote for text.

Is the misalignment, depicted above, that more than 1 field is appearing on 1 line? If that is the case, try 1,3 for the columns which will give 1 field per line.

I’m at a bit of a disadvantage because I did not upgrade my production copy to 4.2.1 & I don’t use the NT form (my touch typing is not that bad). I think Henry Alvarez uses the NT form, but he has not reported misalignment post-upgrade.

fsgl wrote on Sunday, May 01, 2016:

Henry Alvarez had this post.

I remember 3 years ago after a reinstall a misalignment problem.

I import the NT form into my test copy, which had been upgraded to 4.2.1, earlier this morning.

The NT form should look like attachment 1 with the layout, as depicted in attachment 2.

The NT form instead looked like attachment 3.

I changed the Size & Max Size of the first field, Time, see 4; which gave a nicer layout as depicted in attachment 5.

Changing the columns for the NationNotes made the boxes to the right of the name of each field served only to exacerabate the misalignment. The size of the NationNotes cannot be manipulated.

It’s not logical that a Textbox field (Time) should affect subsequent NationNotes, but it does.

Unfortunately users can expect to re-align their LBV forms after each upgrade/reinstall. As Henry Alvarez noted, if you have only NationNotes & you don’t care about the appearance of the form, the data entered in the WYSIWYG editor will look fine in the report.

meiert5798 wrote on Monday, May 02, 2016:

Although it is certainly nice to know more about this alignment issue (which I have experienced), it is still not the issue in question.

After some more experimenting, I have found that extraenous HTML tags are being added by the editor, but only if you insert a return anywhere in a table. These extraneous tags botch the alignment, engulf other parts of the form in the table, and generally make the report unreadable/unprintable.

Attached is an example of the tables working properly (no returns in the table), and an example of the problem (return used in table, table eats next section of report). The only difference between the two is a return after the “h” in the final cell of the first table.

I’ve even went as far as to replace the packaged CKeditor with the one from OpenEMR 4.2.0 and the latest version directly from the CKeditor site (4.5.8), neither of which helped.

cverk wrote on Monday, May 02, 2016:

I replaced the files in interface/forms/LBF with the files from the previous version and my layout based forms seemed to work again.

meiert5798 wrote on Monday, May 02, 2016:

This is exactly the fix I was looking for! Thank you very much.

I will continue to look in to this to find a cause/more appropriate fix, but this will get me going again.

sunsetsystems wrote on Monday, May 02, 2016:

See if undoing this change fixes it:

That is, change this line in interface/forms/LBF/report.php:

$arr[$field_id] = wordwrap($currvalue, 30, "\n", true);

to:

$arr[$field_id] = $currvalue;

Rod
http://www.sunsetsystems.com/