Bugzilla – Bug 12477
Prefs / settings system can't handle quoted strings..
Last modified: 2009-06-22 10:42:03 UTC
When SqueezeCenter loads a stored prefs string into a field on plugin settings page, it truncates the string at the first double-quote. Example of a stored pref: szHibernate_cmd: This is not quoted. "But this IS a quoted string." And this is not. "Is." Is not. "Is." But this is what gets loaded into the edit box on the settings page: This is not quoted. The current settings / prefs system doesn't have a problem with correctly storing quoted strings from a settings page into a prefs file. Also, $prefs->get($prefname) doesn't have a problem with retrieving quoted strings from a prefs file. The only problem seems to be in loading quoted strings from the prefs file into edit boxes on settings pages. Thus, any quoted settings will get mangled anytime a user opens a settings page.
Thinking about this...this is really a WebUI issue, not a plugins issue, per se.
Take a look at the page's source. My guess is that the full string is there, but the unescaped double quotes cause the browser to end the form input field at the first one. All strings in text input boxes need to be 'HTML escaped'. Double quotes will end up as the entity "
So..are you saying that it's up to the plugin to catch prefs as they change and replace "'s with "'s? And when reading prefs, do the same translation? I can see how that might work. It just seems like a shame to have to massage the prefs data so much.
No, I couldn't say what's expected of a plugin developer. Sounds like bug in SC to me.
Did you take a look at the code as Jim suggested? Is the content there? If so, then try using the html_entity filter in your page template: http://template-toolkit.org/docs/manual/Filters.html#section_html_entity
Ah. You guys are right. Looking at the source of the rendered settings page: <input type="text" class="stdedit" name="pref_szNotIdleWatchdog_cmd" id="szNotIdleWatchdog_cmd" value="sudo /usr/bin/logger "SrvrPowerCtrl not idle"" size="80"><br> If I can figure out how to apply it, I'll try html_entity filters on all the edit boxes and see if that does the trick. I'll report back within a day so that this (apparently) non-bug can be closed. Thanks.
OK. That totally works. Thanks, you guys. In my basic.html template: [% WRAPPER setting title="PLUGIN_SRVRPOWERCTRL_NOTIDLE_WATCHDOG_ACTION_CMD" desc="PLUGIN_SRVRPOWERCTRL_NOTIDLE_WATCHDOG_ACTION_CMD_DESC" %] <input type="text" class="stdedit" name="pref_szNotIdleWatchdog_cmd" id="szNotIdleWatchdog_cmd" value="[% FILTER html_entity %][% prefs.pref_szNotIdleWatchdog_cmd %][% END %]" size="80"><br> [% END %] Adding this filter as Michael suggested causes the quotes to load, render and save. So...the bug was in my brain..not in the code.
> <input type="text" class="stdedit" name="pref_szNotIdleWatchdog_cmd" > id="szNotIdleWatchdog_cmd" value="[% FILTER html_entity %][% > prefs.pref_szNotIdleWatchdog_cmd %][% END %]" size="80"><br> If you only want to fix one single value, you can simplify this statement to [% prefs.pref_szNotIdleWatchdog_cmd | html_entity %] The pipe is the shortcut for FILTER.