As mentioned... hijacking the internal functions is probably the way
to go... but - in 2.6.2 (and probably earlier versions too), there's
an alias as well. Here's what I use, to force most options to be
saved as settings, not cookies (in SystemConfig tiddler). I did have
to prime SystemConfig initially - I didn't want to flush my cached
cookies, and was too lazy to delete the tiddler specific cookie(s). If
I had thought about putting this as a first load tiddler, instead of
last load, and overridden the function that reads cookie settngs, that
would have been cleaner/more portable. But once I got it working, I
didn't think of that - until your problem was presented. Notice the
saveOption AND saveOptionCookie overrides at the end.
//# ensure that the plugin is only installed once
if(!version.extensions.ForceSettingsPlugin) {
version.extensions.ForceSettingsPlugin = { installed: true };
config.extensions.ForceSettingsPlugin = {
oldSaveOption: saveOption,
newSaveOption: function(name) {
if (name.match(/txt.*Tab$|chkSlider|chkBackstage/)) { return };
config.optionsSource[name] = 'setting';
config.extensions.ForceSettingsPlugin.oldSaveOption(name);
}
}
function saveCookie(name){ return }
saveOption = config.extensions.ForceSettingsPlugin.newSaveOption;
saveOptionCookie = saveOption;
}
//# end of "install only once"
Also, this is what I used to convert all my options from cookies to
settings, in the first place:
/*
// convert cookies to settings - needed once to mass convert
for(var key in config.options) {
config.optionsSource[key] = 'setting';
}
*/
On Jun 27, 6:58 am, Scott Steele <scottlste...@gmail.com> wrote:
> I really need help on this. I'm developing a TiddlyWiki to act as my
> organization's navigation tool for finding files on our extremely slow
> and cumbersome internal website/server.
>
> Problem: Some of the options TiddlyWiki saves to a cookie apparently
> conflict with the internal website's own cookie options. The
> TiddlyWiki has to be hosted on / loaded from the internal website and
> so its cookie has the same url/name as the internal website. Various
> useful TiddlyWiki plugins leave cookies that either stop one from
> being able to upload anything to the internal website or even prevent
> it from opening at all.
>
> Telling every user of this site to delete their cookies after viewing
> the website is not an option.
>
> I can't get access to the contents of the cookie because our
> information management permissions process is slow, complicated, and
> doesn't even understand my problem.
>
> I've done many things to try to solve this:
>
> I used the CookieManager plugin and set it to disallow any cookies,
> but a cookie was still being dropped.
>
> I tried disabling plugins, re-uploading, and testing. After getting
> rid of several useful plugins, I was at least able to still access the
> internal website. However, I would have to disable the advanced search
> plugin in order to fix the issue with not being able to upload to the
> internal site. I really need advanced search since it both provides
> some of the visitor/editor segregation and also is one of the main
> selling features of using TiddlyWiki for my organization.
>
> I tried renaming the options in the advanced search plugin (in
> particular) to names that would probably not be used as cookie options
> by our internal site. This didn't seem to work.
>
> What DOES work is it manually edit the TiddlyWiki source code to
> comment-out the innards of the saveCookie function:
>
> function saveCookie(name)
> {
> // var cookies = {};
> // for(var key in config.options) {
> // var value = getOption(key);
> // value = value == null ? 'false' : value;
> // cookies[key] = value;
> // }
> // document.cookie = 'TiddlyWiki=' + String.encodeHashMap(cookies) +
> '; expires=Fri, 1 Jan 2038 12:00:00 UTC; path=/';
> // cookies = getCookies();
> // for(var c in cookies) {
> // var optType = c.substr(0,3);
> // if(config.optionHandlers[optType])
> // removeCookie(c);
> // }
>
> }
>
> My problem, though, is that this has to be done after every upgrade of
> the TiddlyWiki template, which I sometimes need to do after going
> through the copy/paste/file-rename steps necessary for Windows to
> allow TiddlyWiki to save. (These steps often screw up the TiddlyWiki
> template so that it doesn't think the TiddlyWiki file is valid. It
> will then refuse to save changes until I upgrade.)
>
> I don't mind doing this manually so much. It's a hassle, but it
> doesn't take very long. I can't expect any of the other members of our
> website team to do it, though, and I need to have our TiddlyWiki in a
> state that it can be maintained/updated without me.
>
> I tried making systemConfig file like this:
> //{{{
> function saveCookie(name) { }
> //}}}
>
> I thought/hoped it would overwrite the function even when it's intact
> in the original source code. If it does, it doesn't do it before the
> TiddlyWiki drops a cookie that screws up [the ability to access] our
> internal website.
>
> I really need help on this since I don't know what else to do, and
> this is an issue that could possibly jeopard the use of TiddlyWiki by
> my organization.
>
> Thanks,
>
> Scott
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/tiddlywiki?hl=en.
