Bugzilla – Bug 1211
new formatting in 2 steps works - not in 1.
Last modified: 2008-08-18 10:54:16 UTC
When adding a new formatting and mark the new formatting as the one I want I got an errormessage and the new formatting is added but the old one is used. It I then klick on the new formatting again - the new one is used. Of course this is because os the order the tho thins is donw in the server. And this isn�t done so many times so its a minor thing. Nalle
Nalle: Can you please add specific steps to reproduce the problem? We don't understand.
Start WebbGUI, http://localhost:9000 (Log in) Click Server Settings Click Formatting Scroll down to Title Format Click in the RadioButton after the last one in use Enter "File: FILE.EXT" as an example in the textfield to the right of the radiobutton. Click Changebutton My result this time was: Title format 12: File: FILE.EXT Format will be changed for any clients using this settings New value for Current web title format rejected: Invalid value specified: 12 The new value "File: FILE.EXT" is in the list if you scroll down but the radiobutton has not changed It is still on the old value. If I click in the right radiobutton agan and change - everything is fine.
I get it. I'm not sure how this can be fixed, tho. The validation for the radio buttons is built as the page is created. When you add a new format, the old validation wont see it the first time. However, a bit of time pondering may find a way to allow the 'extra' value.
that needs to happen, is a way to force titleFormat to be processed fully BEFORE titleFormatWeb is validated so that we can validate titleFormatWeb based on the new titleFormats. cc'ing moser, got any tips?
I guess using validateInHash isn't the best choice for the titleformatWeb preference. It should probably be changed to validateInteger(0,$arrayMax + $arrayAddExtra,1,1) with a bit in onChange to drop it down to the $arrayMax if it is greater than that. I can make the appropriate changes tomorrow, plus check to make sure there aren't other prefs in a similar situation.
Change 3132 for the fix.
This bug was marked resolved in Slimserver 6.1, which is several versions ago. If you're still seeing this bug, please re-open it. Thanks!