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.

Reply via email to