Although this displays the word Ground as before with a bold style on a yellow background when created in a dashboard in emoncms v10.1.3 , I am unable to save any dashboard that contains this HTML code. Hitting the Changed, press to save button, generates a popup window saying:
ERROR: Could not save Dashboard. Error: Invalid dashboard content, content not saved
Could anyone with more familiarity with HTML code please explain what I am doing wrong or have there been changes to the way emoncms handles HTML code? Moreover, when this error message occurs is it possible to narrow down the exact item in the dashboard that is the cause.
I am running the latest OCT19 SD card image on a Pi v4 and am using a Safari browser in MacOS Mojave
After some experimentation, I have established the cause of the problem that I have experienced. The dashboard will not save text that contains some of the extended HTML special characters that exist, in particular, in my case, the non breaking space: . Although they display correctly on the dashboard when editing, they cannot be saved. A very simple example is:
<p>a) Item </p>
This issue is unrelated to the version of emoncms and arose by accident related to the order in which my desired end result was reached. The result that I was trying to achieve was a word on a coloured background whose colour extended a single space beyond the letters of the word itself. When I created my original text labels in v9.8.31 I did not have the spaces surrounding the text, the word Ground in this case. The dashboard would save. I subsequently added a space at either end of the word to extend the background colour and the dashboard again saved. However, when the spaces are included before the first attempt to save the dashboard, the error window appears.
To muddy the issue further, when a second attempt is made to configure the above simple example, the text no longer shows in the HTML field but the dashboard still refuses to save! An attempt to include the £ symbol in the text using the extended HTML special character: £ will save successfully so this issue does not apply to all of the special HTML characters. The only way that I have found to achieve the result that I desired was to use the <pre>& </pre>tags to preserve the formatting thus:
Thanks for your proposed fix to the problems that I encountered. The issue seems to be closely related to the href bug raised in Oct 2018 in that the code renders correctly in the dashboard editing window but will not save upon exit from this window. Then some of the HTML characters disappear from the text editing window when the dashboard is opened a 2nd time.
Unfortunately, I am unfamiliar with GitHub. A first impression of the subject just undertaken is of a confusing, impenetrable jungle of jargon that will take me some considerable time to grasp. I need to find a GitHub for Dummies before going further!
Your screen shots of the two HTML lines I used for illustration appear to have rendered and saved correctly but I have to leave it to others to try out this pull request to verify your fix.
I have come to a standstill having initialised a git repository in my pi/home area and have no desire to corrupt my working system by any making further stab-in-the-dark changes!
Hi @mhamer, apologies if this is repeating what you already know - also using this post to document the issue for others that might have this issue.
Yes @mhamer you are correct the main change here is to preserve the HTML entity from being decoded as a (space) and displaying errors when saved. This was the cause of the error you saw - the decoded and sanitized version of the value would not be valid as they don’t match the original (the entity was decoded as a ’ ')
The HTML entities are saved in the database as entered, however they are decoded in the textarea/input box as the intended character.
eg. £ would be shown as £, but still saved in the database as £
As HTML is allowed to be entered in here we must be careful not to allow malicious code that would run on other user’s machines as JavaScript. The above example shows that the is shown as the non-breaking space character. HTML characters should be rendered as appropriate glyph within the input box / textarea.
The library used replaces the code for it’s (space) character. This caused issues on this character only. All other Entitles should be successful checked without the need to manually replace them before the validation test.
Hi @emrys, I found your explanatory post very helpful being unaware of the behind-the-scenes validation that is required to mitigate against malicious code. Looking at your 2nd reply, I guess that the next stage is to gain approval to get the fix into the master branch of the emoncms code. Presumably it can then be rolled out at the next periodic update to emoncms on the Admin page. Hopefully there will be no more HTML extended characters that will require this type of manual intervention.
