There is no doubt that what breaks the cookie implementation is FW6’s way of generating code.
… or even the way you make FW6 generating the code!
All I can see is style hodgepodge of “extended” and “internal”, no class .hidecookie applied to the DIV #legaleze and no class-style .hidecookie created.
##STEP 1
Could you please do me a favor and tell me what you’ve got applied to the extended “DIV” dialogue Tab when selecting the item “#legaleze”? I suppose some css properties applied to (left, top and z-index)?
All that I did is written earlier in this thread. But to specifically answer your question…
When I select the HTML box “legaleze” and choose “Item>Extended…”, within
is: Name = display, Value = none
Again, if you look back in this thread for those keywords, you will see where Walter Davis guided me to add that (on 28 Sep 2012, 11:11 pm). And like I said, it works fine when FW5.6.5 generates the page. But when I open the same site in FW6, FW6 generates the page HTML a tad differently, and that differences breaks the cookie.
FW6 is a cookie cutter! Great for the kitchen, but not for my web pages! Ack!
James - not “DIV-Style” Tab but “DIV” Tab I’m interested.
The “DIV-Style” can be deleted anyway (cause you force your DIV not be displayed at all). This is task of the script and the additional class style we create in Step 3.
As far as the following two example pages are concerned, there is nothing at all within the
tab:
Again, I am using Walter’s suggested cookie implementation, as discussed earlier in this thread. I am not using DeltaDave’s implementation on those two pages (which calls for use of the
tab instead of the
tab).
If you’re still not understanding what I mean, please read through this thread, starting at the beginning:
OK - understood James - I was indeed on the DD trip (cause of the URL deltadave sub-folder).
The point is, that FW6 is externalizing code while FW5 is keeping it internal. FW6 is doing an excellent job in this and I’m still convinced of the ‘rat’ in there.
But from what I can see is, that there are two #legaleze styles, one style-property is served by FW itself (and therefor part of the default css) and the other is part of the before end head tag.
Probably this is a too strong argument, which causes the failure of the script.
What you could try is to remove it from the item directly (DIV-Style and go to the before end head tag and add the property display: none there (just a guess).
I just went through this with another user off-list. The issue here is that adding display:none in the usual manner breaks in Freeway 6, because the style is no longer added to the element directly, but rather coalesced into the styles applied to the element’s ID in the stylesheet (either in the head of the page or the external sheet – it makes no difference).
Where this breaks the effect is as follows:
Prototype requires that any display:none that you plan to later modify using the show() or hide() methods must be declared inline, within the element itself.
Freeway doesn’t place the pre-hidden attribute in that location.
Prototype attempts to change the visibility by removing display:none from the element, not by adding display:block to the element (which would work) because block is not guaranteed to be the correct value for that element (there’s no way to know what the correct value should be – it can’t even be ‘auto’, because there may be an override elsewhere that forces that element to be displayed in a manner inconsistent with its standard representation, like a div set to display:inline-block).
The show() method (or toggle()) cannot ever make the element appear, because the stylesheet (not the inline style attribute) is set to display:none.
Here’s how to fix this in Freeway 6:
Locate the element that you set to be initially hidden using the Extended style attribute. Locate that declaration in the
tab, and delete it. Switch over to the tab of the Extended dialog, and add a new attribute named style. In the value of that attribute, put the entire display:none declaration. This new style attribute will be written into the inline tag declaration, and not coalesced into the item’s style, so Prototype can fiddle with it.
Walter
On Jul 29, 2014, at 4:50 AM, JDW wrote:
Thomas,
All that I did is written earlier in this thread. But to specifically answer your question…
When I select the HTML box “legaleze” and choose “Item>Extended…”, within
is: Name = display, Value = none
Again, if you look back in this thread for those keywords, you will see where Walter Davis guided me to add that (on 28 Sep 2012, 11:11 pm). And like I said, it works fine when FW5.6.5 generates the page. But when I open the same site in FW6, FW6 generates the page HTML a tad differently, and that differences breaks the cookie.
FW6 is a cookie cutter! Great for the kitchen, but not for my web pages! Ack!
This is really odd. I deleted the cookie from your server, and I can’t make the message re-appear in either one of these now. I will have to wait a couple of hours and see if it returns.
Walter, after waiting several hours, what happened?
I moved on to other things, and promptly forgot to go back to that tab. I believe I have figured out the issue, though.
There is no doubt that what breaks the cookie implementation is FW6’s way of generating code. It works in FW5. It doesn’t work in FW6. I just don’t know WHY this is so. Since we cannot change FW6’s HTML generation, the only way to fix the problem is to alter the cookie implementation to be compatible with FW6. But I don’t understand the ROOT PROBLEM well enough to do that. Do you? Is that why you deleted the cookie?
I deleted the cookie to see if I could make the effect run again – as I said, the message overlay never returned for me. This may be related to CloudFlare, which does very aggressive caching to speed up your site. But it may be because there have been a number of attempts on our parts to make this effect work, and there may be conflicting code left in place that keeps it from working (even though no errors are thrown). There was nothing wrong with the cookie code, the only thing I did see was that clicking the message did not appear to have any sort of “hide” behavior applied to it, but to be honest, I didn’t trace through every line of script in that page to see if I could find one. Clicking the message did not produce any error, but it also did not hide the message when I initially saw it (when this testing process began). That particular issue could be related to the fact that the display directive was not in the
tag where Prototype could mess with it.
If the other solution does not sort this out for you, could you please make a cut-down example page with nothing at all on it except the overlay, a filled rectangle below it to show that there’s something there on the page, and only the scripts related to the cookie show/hide. Post that, in its FW6 incarnation. There are two reasons for doing this. First and most important is that doing so will require you to strip out all of the other things that may be confusing you. You may find that you cannot make a page that doesn’t work when you start from scratch. If that’s the case, then your solution on your current page will be to go through it, deleting things that are overlapping efforts to do the same thing, until it starts to work.
Note that my version is FW6 and instead of adding display:none to the Div I added the class of hidecookie using the Extended attribute and then declared hidecookie as display:none in Page>Html Markup
In the Dom loaded code the class ‘hidecookie’ is Removed/Added depending on the circumstances.
Thanks for the tip and detailed explanation. I moved the
tab content to the
tab. When I first bring up the page in browser, the overlay appears and I can click anywhere to close it. Great! BUT… If I then reload the page, the overlay appears! BAD! And even worse, I cannot click to clear it off! It’s almost as if the cookie is dead.
Have a look:
That remains true whether I use either of the following inside “CDN URI” of Protaculous2:
Alas, I am once again humbled by my own foolishness and your genius, Walter. Thank you. The problem is now fixed, as shown here:
And for those of you who are following this entire thread from the beginning, please note that the only 2 changes I made to Walter’s original cookie implementation are as follows:
In the
tab of Item/Extended, I added this: •Name: style • Value: display: none
I confirmed the above 2 changes work in both FW5 and FW6.
NOTE: When testing in Chrome, test from your server to see the cookie work. If you test locally in Chrome, the overlay will appear and disappear with your click, but the overlay will reappear each time you reload the page. It works as expected when you load from a server, however.
Best wishes to all who contributed to this thread.
You have two different CSS declarations for #legaleze – one may be hand-coided somewhere. The first does indeed set it to position:fixed, but the second sets it to position:absolute. The first is at line 73 of the page, and the second is at line 2.
Walter
On Aug 5, 2014, at 3:32 AM, JDW wrote:
Walter,
Everything works now, except that when I scroll down, the white overlay does not appear in the bottom portion of the page I scroll down to view.
Ages ago in this thread, you gave me the following solution for that:
If you set the overlay to position:fixed in the Inspector
> (Fixed in Window) you won’t have this problem any more,
> and you can go back to 100% height.
My “legaleze” (overlay, HTML box) is definitely set to “Fixed in Window” in the Inspector, and yet the problem remains. Would you know why?
Today, I added popover content to mimic what I have on my top page, controlling the display via cookiejar, so my popover content only displays once per session. When I first launch the browser to display my new page, the popover content displays fine, and if I then go to my top page, its popover content displays fine. Reloading those pages won’t display the popover content, which is correct behavior. But if I relaunch the browser and go to my top page first, its popover content displays, but if I then go to my new page, its popover content won’t display. That is the problem.
In other words, depending on the point of entry, my new page’s popover content may or may not display. But my top page’s popover content always displays (on the 1st launch of the browser). How do I resolve this?
Thanks,
James W.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
On my top page, within the DOM Loaded Observer button of Protaculous 2, I am using the following code:
var message_box = $('legaleze').setStyle('z-index: 1000');
$$('body').first().insert(message_box.remove());
var jar = new CookieJar({expires: ''});
//you can also set expires to any number of seconds
if(!jar.get('hide_message')){
message_box.show().observe(
'click',
function(evt){
jar.put('hide_message',true);
this.hide();
}
);
};
I tried using the same code on my new page, but again, if I go to my top page FIRST and then to my new page, the popover content of my top page displays, but the popover content of my new page won’t display. And like I said before, if I relaunch the browser and go directly to my new page, it’s popover content displays fine. And if I then go to my top page, it’s popover content displays fine. Why in the world is it that when I go to my top page FIRST, then my new page won’t display it’s popover content?
I tried changing the var name but that didn’t do anything. I tried changing CookieJar to CookieJar2, but that didn’t do anything. I renamed my popover content from “legaleze” to “ttt” and then updated the code accordingly, but that didn’t fix the problem either.
Again, I want independent control over the popover content on my TOP page and my NEW page. It shouldn’t matter which page I display first. Whatever page I choose should show its popover content ONCE PER SESSION, which usually means I need to relaunch the browser to see it display again. Displaying one page’s popover content should never prevent another page’s popover content from displaying.
Your thoughts?
–James W.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
After I click to hide the popover content, I see a cookie appear with the following name:
__CJ_hide_message
And of course, when I relaunch the browser, that name is gone, which is correct.
If I launch the browser and then open my NEW page, it creates a cookie name “__CJ_hide_message” and if I then open my TOP page and click-to-hide the popover content, it creates a second cookie named “__CJ_hide_message”. But if I relaunch the browser and open to my TOP page, it creates “__CJ_hide_message” and if I then open my NEW page, it won’t create a cookie.
I am thoroughly confused as to what is going on here.
–James W.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
I changed the code on my NEW page to the following:
var message_box = $('tmy').setStyle('z-index: 1000');
$$('body').first().insert(message_box.remove());
var jarz = new CookieJar({expires: ''});
//you can also set expires to any number of seconds
if(!jarz.get('hide_msg2')){
message_box.show().observe(
'click',
function(evt){
jarz.put('hide_msg2',true);
this.hide();
}
);
};
I changed “hide_message” to become “hide_msg2”. That improved the situation in that, regardless of entry point, I see popover content on my TOP page and my NEW page. HOWEVER, if I open my NEW page then the HOME page and then return to the NEW page, the popover content on my NEW page displays twice. It’s only twice and no more (per session), but its strange. Why twice?
Observing the browser cookies, I see that 2 cookies named “__CJ_hide_msg2” are being created (for my NEW page). But why?
I want to display the popover content ONCE and only ONCE per page, per session.
Thanks,
James W.
freewaytalk mailing list
email@hidden
Update your subscriptions at: