Last modified: 2010-06-11 21:35:11 UTC
Currently the first section is opened by default, which is fine for readers, but not for editors. This is because on pl.wiki we've decided to use the first sections for readers and the second one for editors. Some solutions: 1. Make the last state permanent at least on one computer (e.g. with cookies that would be valid for a week). 2. Add some save-state button near the menu which would save that state to the database (to be permanent on other computers of the user). 3. List sections of the menu (as defined on the wiki) in one of the sections of preferences. On the list you could simply choose which sections should be opened.
(In reply to comment #0) > Currently the first section is opened by default, which is fine for readers, > but not for editors. This is because on pl.wiki we've decided to use the first > sections for readers and the second one for editors. > > Some solutions: > 1. Make the last state permanent at least on one computer (e.g. with cookies > that would be valid for a week). Already done. This feature was improved recently, with the cookies now valid for 30 days. > 2. Add some save-state button near the menu which would save that state to the > database (to be permanent on other computers of the user). Considered doing this earlier, not gonna do it. > 3. List sections of the menu (as defined on the wiki) in one of the sections of > preferences. On the list you could simply choose which sections should be > opened. This is not really very different from #2, and undesirable for many of the same reasons.
It could not only check the cookie, but also a javascript variable. Then it could be customized in the user vector.js, as well as per wiki.
I think #1 with long term cookies should work, but... Do you refresh the cookies validity? Let's say today is 2010-07-01 and let's say the default state is: Interaction - shown, Toolbox - shown, Print/export - shown, Languages - shown 1. @2010-07-01 user sets his favourite sidebar state as: Interaction - hidden, Toolbox - shown, Print/export - hidden, Languages - shown. 2. @2010-07-10 user decides he would like to have languages hidden. 3. @2010-08-02 user logs in and?... a) sees: Interaction - shown, Toolbox - shown, Print/export - shown, Languages - hidden b) sees: Interaction - hidden, Toolbox - shown, Print/export - hidden, Languages - hidden I would expect b), but if cookies are not refreshed a) will happen.
Clicking on one section doesn't touch the other cookies.
I think you've misunderstood my point. The point was to refresh cookies on each page load. Algorithm: var usabCookies = usab.getAllOurCookies(); foreach (usabCookies as cookie) { usab.addCookie(cookie.name, cookie.value, usab.defaultCookieDurtation); } And as seems it's not done like that, so that doesn't work for me/us (there are some concerns on our feedback page already).
(In reply to comment #5) > I think you've misunderstood my point. The point was to refresh cookies on each > page load. > > Algorithm: > var usabCookies = usab.getAllOurCookies(); > foreach (usabCookies as cookie) > { > usab.addCookie(cookie.name, cookie.value, usab.defaultCookieDurtation); > } > > And as seems it's not done like that, so that doesn't work for me/us (there are > some concerns on our feedback page already). Our code does do this. Whenever it processes a cookie to decide whether to show or hide a section, it renews it. This means cookies get refreshed on every page view where they're used (so viewing a page without a languages section will not renew the cookie for the languages section). Also, the cookies' expiry time is now 30 days. If you're having trouble with this, it's probably not due to expiring cookies as the code that makes these cookies expire after 30 days was deployed less than 30 days ago.
OK, sorry. Just tested this and it seems to work as expected. Thanks.
