Thanks a lot to everyone who replied! Problem solved! I had tried using the CookieManager plugin, but it didn't completely prevent cookie creation.
I didn't really have to hijack the function to get what I wanted, but just looking at the code at the site Yakov mentioned gave me a fix. The only JavaScript I know I've picked up while tinkering with TiddlyWiki, so I don't //fully// understand why what I have now works and what I had before didn't, but here's the code that will completely kill cookies: //{{{ window.saveCookie = function(name) { } //}}} Does it have something to do with the core TiddlyWiki code running at a level where all the declared functions are being assigned to window? Anyway, Thanks again! That solved a major hassle! Scott On Jun 28, 1:12 am, perlguy <perl...@gmail.com> wrote: > 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); > }} > > functionsaveCookie(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 thesaveCookiefunction: > > > functionsaveCookie(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: > > //{{{ > > functionsaveCookie(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- Hide quoted text - > > - Show quoted text - -- 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.