I see this referenced a lot: http://ajaxify.com/run/crossframe/
And I noticed now it's no longer working for the IFRAME (child) to change the parents hash.
I've been spending a few hours trying various things wondering why this isn't working anymore -- then I finally realized that the example I originally based it on was down too.
Can anybody confirm?
-
-
I need to use a cross domain iframe to take care of an order upload form that our shopping cart doesn't support, and I need the form to return an order ID to the parent, so that I can associate the data between the two servers.
Any recommendations or directions to head in would be appreciated.
I'm not looking for a shortcut or somebody to do my work. I've been reading all day... I just need a nudge in the right direction.
Thanks!
It is partly browser-specific. For instance, some browsers don't allow a nested child frame (iframe within an iframe) to change its parent's fragment. See this blog entry. But the basic functionality still works in recent browsers. This demo, which has an iframe change its parent, and vice versa (single level) works fine in Firefox 3.5.9 and Chrome 5.0.375.99.
The demo you gave also works both ways in that version of Firefox. It doesn't allow the child to change the parent in Chrome. The main difference seems to be that the working one uses parent.location, while the broken one uses parent.window.location.hash.
The best solution for recent browsers is postMessage. If necessary, you can also use a server proxy.
Related
I look for a tutorial, help or an example that tells me what I have to do to write a grid element like 2-colums in basic typo3 (v9) with fluid but no other extension like gridelements, DCE, Templa Voila, etc. I want the same gridelements can do but I dont want to be depended to this extention and move it in my own site extention.
I tried the same with normal content elements (CE) like here:
https://docs.typo3.org/c/typo3/cms-fluid-styled-content/9.5/en-us/AddingYourOwnContentElements/Index.html
But how can I nest a CE in a CE? And how can I do this by drag&drop in the backend?
You can't. The page module doesn't support nesting
You can't nest CEs in a CE. On database level this would mean that you have to make a tt_content record a subrecord of a parent tt_content record. You run into several problems, basically the multilanguage support will be broken and the shortcut element does not function as you will expect it to. That is why the extensions "gridelements" and "mask" exist.
I integrated the gridelements configuration into my sitepackage. So I do not need to bother anymore with it.
Just for your info:
There is now an initiative that works on integrating this functionality into the core (Structured Content Initiative, https://typo3.org/article/a-structured-content-initiative/). Stay tuned to it.
There is nothing special about providing Gridelements via external files, since it's based on TSconfig, TypoScript and Fluid. That's why there is not that much about it in the documentation, since it's the same thing you would do with any other kind of sitepackage. The TSconfig and TypoScript parameters are already explained there, while the Fluid would be up to you anyway.
To have a kind of kickstarter just take any extensions providing Gridelements layouts as an example. A very popular one would be bootstrap_grids, which can be found in the TER or here: https://github.com/laxap/bootstrap_grids
You don't necessarily need the flexform controller of that extension, but the Configuration and Resources folders, show you how to configure stuff and you can see how that is included via ext_localconf.php
There are even comments i.e. in the TSconfig files to explain what is possible there and how to handle i.e. mixed environments with record and file based setups. Although it would be recommended to go for files.
You would at least have to add the necessary backend rendering methods to a draw item hook, that will modify the preview of the container element.
So basically you would have to rewrite everything that DCE, Flux, Gridelements or other similar extensions already do.
Which brings us to the question, why you want to avoid those extensions, since especially those three are well known, widely spread, well supported and available for currently supported TYPO3 versions.
Xpage (listPostits.xsp) has a "View" container control, where one of the column is set "show values in this column as links".
Now, here comes "Strange behaviour".
When i work with this application on my own (developer) PC (Win XP, Chrome or IE), the Domino generate the link, which can't be really processed:
/servername/db/postit/postit.nsf/listPostits.xsp/onePostit.xsp?documentId=many_numbers&action=editDocument
Namely, the Bold-marked portion shouldn't be there ! This portion is the name of the XPage, where the View control is in.
When i work with the application from other PC (Mac, Firefox) then i get the correct link (the same as above but without the XPage name inbetween):
/servername/db/postit/postit.nsf/onePostit.xsp?documentId=many_numbers&action=editDocument
update: let us leave for the moment the differencies in generated links between two machines. The first question is - why the extra portion is inserted into automatically generated link?
After playing around i think i might have found the reason for this strange behaviour. Namely, the "Substitution" Rules on the server side. One of them is to substitute "*/postit/all" with "/db/postit/postit.nsf/listPostits.xsp"
If i switch it off, then the Links are generated properly. Still, it's pretty strange to me that these settings influence the way Domino generates the links. I thought it works on the fly with them and those settings have nothing to do with the way how Links are generated inside the application.
So, the help now is needed regarding Web Site Rule Topic, but for that, i guess, i have to create another topic. But in case somebody has some good Info on this, please share it with me. I'm a bit confused at the moment :)
Final Update: Spent some more hours of testing and the results confirmed the initial idea.
If i open the page with the standart URL, i.e.
http://servername/db/postit/postit.nsf/listPostits.xsp then everything is fine, links are generated properly. When i however open the same page with short URL http://servername/postit/all , then server adds the substitute URL (db/postit/postit.nsf/listPostits.xsp) to every single link he generates automatically to be used as the link to open/edit the underlying document.
Is it bug or feature ? Don't know.
As a workaround (because i want to keep simple URL's for the application) i have to manually generate links.
I'm inserting images to editor with id param. after that i'm trying to access it with Dom.get('id'), but it returns null.
I understand that it returns null because it works under parent window's scope. Is there any standard way to access it?
For specialized YUI-related questions, and especially if you don't get the answer you're looking for on StackOverflow, you may want to post to http://yuilibrary.com/forum -- the YUI devs and many YUI specialists spend time there, and that's typically the best place to get YUI-related help.
I wish to block ALL my content from any users using an ad-blocking browser extension (ie. Adblock Plus for Firefox, Adthwart for Chrome).
How can I acheive this? Is there a server-side solution? Client-side?
Edit 1
This question regards the detection of ad-blocking browser extensions:
Detecting AdBlocking software?
I'm concerned with post-detection action.
Edit 2
A duplicate question was asked after mine, so I thought I'd link to it here:
Prevent Adblock Users from Accessing Website?
To detect if the user is blocking ads, all you have to do is find a function in the ad javascript and try testing for it. It doesn't matter what method they're using to block the ad. Here's what it looks like for Google Adsense ads:
if(typeof(window.google_render_ad)=="undefined")
{
//They're blocking ads, do something else.
}
This method is outlined here: http://www.metamorphosite.com/detect-web-popup-blocker-software-adblock-spam
It's like trying to block users from reading your contents while standing rather then while sitting. It's silly, and it's likely to drive visitors off your site. The last time i saw a "you're using adblock, that hurt web developing bla bla" i jst blocked that div with the element hiding helper. It was fun i admit. Most sites are almost unreadable as now, with flashing ads and pale contents. A good quantity of ads are, also, malevolent, disguised as part of the site they're in takes the user to bad places.
That's why you should not. If you still want to, bad news, you can't. As long as i can write $('.ad').hide() in my console, nobody can stop me from adblocking something. I sometimes give up when ads divs have a very generic class, id, or they haven't any, so that it's difficult to target them with the adblock element hiding helper (of course if they are not in the lists, in that case i dont even know they exists). So the best you can do probably is give to ads a class of .content or something you use also in other parts of the site. It's not much, but it' all you can do. And just because you can, it does not mean you should. The web marketing model have to change, and it will.
That I know of this is not directly possible. Most add blockers work by locking at the URLs that are being "requested" and either blocking directly, or looking at the content/mime-type and blocking based on that.
You might be able to do something by looking for signs of the adblocker, but this will be difficult at best.
Although I love my adblocker, it's about answering questions. You could check if an url that would normally be blocked by an adblocker is reachable, and continue only if that image/bla in question is loaded. otherwise, you just don't.
I want to add a calendar control to a page that already includes Prototype and Scriptaculous. Not happy with any of the Prototype ones I could find, I'm considring using the YUI Calendar widget.
I this likely to cause any problems?
We have worked hard to make sure that YUI is safe to use with any other library. We namespace everything, as HermanD says, under only one required global (YAHOO) and one optional one (YAHOO_config). We don't modify native objects. And even though Protoype does modify native prototypes, we code defensively so that this doesn't break YUI functionality.
If you find any bugs in using the two together, please let us know.
Regards,
Eric
YUI Team
By default everything in YUI is within the YAHOO namespace, so as long as you sensibly apply namespaces to anything you use from YUI, I would have thought you should be ok.
See: http://developer.yahoo.com/yui/yahoo/
I successfully used the YUI tab control in an app I was already using Prototype and Scriptaculous in and had no problem. The weight of all that is a bit much though if you're looking at a publicly available app. I wouldn't care so much about an internal app, say for a company, but you might want to think about how much JavaScript you're making end users download and the number of separate files they're having to download for the page.