fearless359 / simpleinvoices

Fearless359 SimpleInvoices beyond great beginnings
https://simpleinvoices.group
GNU General Public License v3.0
28 stars 7 forks source link

Fix minor PHP errors. Ensure valid UTF-8 encoded text for products table output. #89

Closed redcuillin closed 2 years ago

redcuillin commented 2 years ago

A pull request not including unwanted changes, but some minor unset variable fixes and errors seen when error_reporting set to E_ALL.

redcuillin commented 2 years ago

Revision [3cb7685] contains a fix to a repeated problem I had encountered. Product data stored in database appeared to contain invalid UTF-8, so json_encode() would fail, and further did not throw any error. The data.json file would be empty. Have edited manage.php so that the results from Product::manageTableInfo() is run through mb_convert_encoding() to ensure valid UTF-8 characters. Have further added a try...catch block to log any errors when generating json for output to datatables.

fearless359 commented 2 years ago

The change for encoding looks fine. The try/catch isn't valid as their is no error thrown by json_encode. A test for "=== false" would be valid. Can you give me sample data that will replicate the error? I'd like to see why this happens for you and not others. Possibly a series of combinations that you have that other don't. But need something to test it against. Finally, if a fix is added (which seems likely), I'd like to make it across the board for all the json_encode's from database info. The best way is to not merge your changes and do them all in a push from my end (with appropriate attribution).

redcuillin commented 2 years ago

Great ... I'll take a look and provide the example text that caused problems for me. The database product strings cause issues on an AWS RDS MySQL instance, but not on a vanilla Linux server ... I suspect there's something weird happening that's unique to the AWS version of MySQL, which is a MySQL compatible Aurora database, and not 'real' MySQL. Usually "SET NAMES = UTF-8" takes care of encoding problems in regular MySQL in my experience. However an AWS Aurora database oddity could well crop up with other users in the future.

redcuillin commented 2 years ago

I identified the database entry with the encoding problem ... a long defunct product that will have been entered in the database maybe 6 or 7 years ago. I'm pasting it here, although Github may well sanitize the string...

<a class='[index_table]()' title='[View Wordpress Website support services � Monthly [Old System/HCA]]()' href='[index.php?module=products&amp;view=view&amp;id=17](view-source:https://si.trwa.ca/index.php?module=products&view=view&id=17)'><img src='[images/view.png](view-source:https://si.trwa.ca/images/view.png)' class='[action]()' alt='[View Wordpress Website support services � Monthly [Old System/HCA]]()' /></a>&nbsp;&nbsp;<a class='[index_table]()' title='[Edit Wordpress Website support services � Monthly [Old System/HCA]]()' href='[index.php?module=products&amp;view=edit&amp;id=17](view-source:https://si.trwa.ca/index.php?module=products&view=edit&id=17)'><img src='[images/edit.png](view-source:https://si.trwa.ca/images/edit.png)' class='[action]()' alt='[Edit Wordpress Website support services � Monthly [Old System/HCA]]()' /></a><br>products[131][description]: FALSEWordpress Website support services � Monthly [Old System/HCA]<br><script>

redcuillin commented 2 years ago

See new pull request. I've updated and replaced the code in the original pull requesrt.