I'm planning on trying to see if it's possible to make a website in Godot(Yes, I know I shouldn't I just want to try just to try). I thinking about and looking over the features I need and I have one problem.
I just need a way for a person to press a button and get redirected to my itch games. I don't care if it creates a new tab or changes the current tab. Thank you for any help.
If you dont export to web you can call
OS.shell_open("url")
Sadly this does not work in an html export. A solution I found for myself is the JavaScript Interface. As the name suggested it allows you to execute Javascript.
So to open a URL you could connect the pressed signal of a button to something like this:
if OS.has_feature('JavaScript'):
JavaScript.eval("""
window.open('https://google.com', '_blank').focus();
""")
This will open a new tab in the active browser.
I also found an article on the godot site, basically asking the same question (https://godotengine.org/qa/46978/how-do-i-open-richtextlabel-bbcode-links-in-an-html5-export). Here they tried to use an RichTextLabel with BBCode.
The solution did not work for me, when I tested it, though.
As pointed in the comments you can try OS.shell_open, for example:
OS.shell_open("https://example.com")
That only works if it is not an HTML export.
Your other alternative is to eval JavaScript, for example this navigates the current tab:
JavaScript.eval("window.location.href='https://example.com'")
Which only works if it is an HTML export.
Since that only works for an HTML export and the other does not work on an HTML export... If you need both you can do this:
if OS.get_name() == "HTML5":
JavaScript.eval("window.location.href='https://example.com'")
else:
OS.shell_open("https://example.com")
See also Close a game in Godot.
I'm trying to send an automatic email receipt for items that have been created on a sharepoint list.
Conditions
I cannot use workflows - they are disabled
I cannot use webparts - they are disabled
I cannot use sharepoint designer etc etc etc - they are all disabled
The function needs to be OOTB
The only option I have is using javascript in calculated columns. I am aware of the use of the HTML:mailto tag - but this opens Microsoft outlook, and is not automatic.
Came across this link:
http://geekswithblogs.net/ThorvaldBoe/archive/2014/07/03/sending-email-with-sharepoint-and-jquery.aspx
So, here is the calculated column attempt:
="<button onclick=""{function SendEMail(from, to, body, subject){"
&"var siteurl = _spPageContextInfo.webServerRelativeUrl;"
&"var urlTemplate = siteurl + '/_api/SP.Utilities.Utility.SendEmail';"
&"$.ajax({"
&"contentType: 'application/json',"
&"url: urlTemplate,"
&" type: 'POST',"
&"data: JSON.stringify({"
&"'properties': {"
&"'__metadata': { 'type': 'SP.Utilities.EmailProperties' },"
&"'From': from,"
&"'To': { 'results': [to] },"
&"'Body': body,"
&"'Subject': subject"
&"}}),"
&"headers: {"
&"'Accept': 'application/json;odata=verbose',"
&"'content-type': 'application/json;odata=verbose',"
&"'X-RequestDigest': $('#__REQUESTDIGEST').val()"
&"},success: function (data) {"
&"alert('Eposten ble sendt');"
&"},error: function (err) {"
&" alert(err.responseText);"
&" debugger;}});}"
&"SendEMail('user#whatever.com','user#whatever.com','Test1','Test2');}"">"&"Send</button>"
When running the code, the Console shows the following error: '$' is undefined
Any suggestions on how to overcome this?
Thanks
You keep raising the bar, Steve!
You're really making it difficult for yourself this way
I suggest the next learning steps first:
Learn all about Chrome Snippets
this will help you develop/execute code directly on the View page without the need for stuffing it in a Calculated Column or any script in SharePoint
Learn jQuery (by using Snippets)
check out jQuerify it will inject jQuery where it is not available
[optional] Learn Tampermonkey
this will help in immediatly executing your scripts on a SharePoint page (without the need for including the script in SharePoint
Learn JSOM Ajax calls and REST Ajax calls (REST is halfbaked implemented in 2010)
again; do them in Snippets first
When that all works you're halfway done and you can wrap it all in the Calculated Column (again, this is all undocumented hacking away at Microsoft technology, if they decide to make changes in an Update you're cooked... e.g they disabled the use of the SCRIPT tag in summer 2013; that's why you now have to use the blank IMG onload trick
Note: I have updated my CalcMaster BookMarklet on GitHub. Once you have your Snippet working you can paste it in an existing Calculated Column Formula and wrap it in IMG onload and &".." notation with one click
If you get that sending email working let us know; I have never done it... I stay away from projects where SharePoint Designer can not be used.
Once you have mastered all the above you will have learned so much Front-End development I suggest you go look for another job.
I need to embed PDF files in an xpage application. We are using IE11 x64 and this cannot be changed. Eventually, I'll also need to embed MS Office files (Word, Excel, Power Point).
I have looked at a lot of pages and couldn't get a working solution for this... I have some code that works if I force IE11 in IE10 mode, but then Dojo starts acting weird (cannot close dialog boxes, ...).
The code I have right now in my computed field looks like this:
var id:string = pageDocument.getDocument().getUniversalID();
var attNames = #AttachmentNames();
var url = getAttachmentURL(id,attNames);
'<object data="' + url + '#view=Fit&pagemode=none&statusbar=0&messages=0"' +
'type="application/pdf" width="100%" height="100%" > ' +
'<p>It appears your Web browser is not configured to display PDF files. ' +
'No worries, just click here to download the file.</p>'+
'</object>'
I need a free solution.
IBM, This should be made easy if we want to compete with SharePoint, no???
Short answer: don't bother.
Long answer: While you might get it to work for PDF in IE11, your boss won't be happy, because it will not show on her iPad, so you need to have a plan B.... and there is another gotcha down the road (read below). This is what I would do:
Use Apache PDFBbox to extract text from the PDF and show that in the XPage.
Add a link to the page to open the whole PDF
Do the same thing for office documents using Apache POI eventually using OpenNTF POI4XPages
The download link should make use of WebDAV for Domino to allow round-trip editing
Why all this fuzz:
Your users will use mobile at some point of time and NO mobile browser does support embedding (nor do any browsers on a Mac)
Even if you successfully get embedding working, users will start to edit the embedded document and get really really upset since you don't save back the changes
On a side note: asking IBM to support a technology that is vendor proprietary working in one browser (that has been EOL for future updates - see project Spartan) - ain't going to happen.
I got this working nicely in IE11 for PDF files with this very simple line:
<embed src="MyPDFFile.pdf" width="640px" height="755px" alt="pdf" />
I'll go along with Stephen's answer: I won't bothe rtrying to mak ethis work with Office files. It will give our "Notes is bad" users some munitions to move to SharePoint, but we do have other advantages!
I tried using Bumpbox, and pdf.js and while I could get them working, iframes seemed to work best for me with using normal Domino attachment urls in xpages
I am not sure if this solution is right or not, but it works well for an app I have that only has PDFs. It does work on mobile too, at least on iOS.
<iframe
src="#{javascript:
var url = 'https://app.nsf/';
var doc = sessionScope.docID;
var atname = #RightBack(sessionScope.aname,'Body');
var end = '/$file'+atname;
return url+doc+end}"
width="800" height="1000">
</iframe>
Probably the best approach is to use a pure HTML5/JavaScript renderer
for PDF documents without any third-party plugins (e.g. PDF.js)
For further discussion take a look at the following stackoverflow
entry recommended way to embed pdf in html
In my opinion, it's the best way to use a commercial product (e.g. crocodoc) for other documents like MS Office (Word, Excel, etc.).
I am currently developing a site which is not supposed to expose its developer magento platform(Sorry about that ).
I thought the wappalyzer(Mozila addon),GTmetrix site is finding the cms names by its html format but when i saw a empty white page with that tools it still shows me like am using Magento(there is nothing in the source view - its white page), so now how they are finding that am using magento. Any idea about hw they are working? I checked headers but there nothing specially mentioned as magento. Same goes with wordpress/joomla - simply wappalyzer(Mozila addon),GTmetrix finds the site platform even there is no html source.
So I guess something with in header(i might missing something) or what it can be? please advice. Attached screenshot of it.
Thanks in advance
You can view Wappalyzer's source code: (Ctrl+F Magento):
https://github.com/ElbertF/Wappalyzer/blob/master/share/js/apps.js
Most likely Wappalyzer picked up on the "Mage" JavaScript variable. You can see this by clicking the DOM tab in Firebug.
They are finding it using the words like mage,varien,magento. If it finds any of these words inside css/js file class,#id,inside comment then it found it as magento.
Also gtmetrix does one more step , like it is checking the css/js url path - if it fins the url like skin/frontend then it says it as magento.
Dont forget cookies...
I use FireBugs. Go to main menu -> Cookies
There is frontend in cookies.
How do you prevent Firefox and Safari from caching iframe content?
I have a simple webpage with an iframe to a page on a different site. Both the outer page and the inner page have HTTP response headers to prevent caching. When I click the "back" button in the browser, the outer page works properly, but no matter what, the browser always retrieves a cache of the iframed page. IE works just fine, but Firefox and Safari are giving me trouble.
My webpage looks something like this:
<html>
<head><!-- stuff --></head>
<body>
<!-- stuff -->
<iframe src="webpage2.html?var=xxx" />
<!-- stuff -->
</body>
</html>
The var variable always changes. Although the URL of the iframe has changed (and thus, the browser should be making a new request to that page), the browser just fetches the cached content.
I've examined the HTTP requests and responses going back and forth, and I noticed that even if the outer page contains <iframe src="webpage2.html?var=222" />, the browser will still fetch webpage2.html?var=111.
Here's what I've tried so far:
Changing iframe URL with random var value
Adding Expires, Cache-Control, and Pragma headers to outer webpage
Adding Expires, Cache-Control, and Pragma headers to inner webpage
I'm unable to do any JavaScript tricks because I'm blocked by the same-origin policy.
I'm running out of ideas. Does anyone know how to stop the browser from caching the iframed content?
Update
I installed Fiddler2 as Daniel suggested to perform another test, and unfortunately, I am still getting the same results.
This is the test I performed:
Outer page generates random number using Math.random() in JSP.
Outer page displays a random number on the webpage.
Outer page calls iframe, passing in a random number.
Inner page displays a random number.
With this test, I'm able to see exactly which pages are updating, and which pages are cached.
Visual Test
For a quick test, I load the page, navigate to another page, and then press "back." Here are the results:
Original Page:
Outer Page: 0.21300034290246206
Inner Page: 0.21300034290246206
Leaving page, then hitting back:
Outer page: 0.4470929019483644
Inner page: 0.21300034290246206
This shows that the inner page is being cached, even though the outer page is calling it with a different GET parameter in the URL. For some reason, the browser is ignoring the fact that the iframe is requesting a new URL; it simply loads the old one.
Fiddler Test
Sure enough, Fiddler confirms the same thing.
(I load the page.)
Outer page is called. HTML:
0.21300034290246206
<iframe src="http://ipv4.fiddler:1416/page1.aspx?var=0.21300034290246206" />
http://ipv4.fiddler:1416/page1.aspx?var=0.21300034290246206 is called.
(I navigate away from the page and then hit back.)
Outer page is called. HTML:
0.4470929019483644
<iframe src="http://ipv4.fiddler:1416/page1.aspx?var=0.4470929019483644" />
http://ipv4.fiddler:1416/page1.aspx?var=0.21300034290246206 is called.
Well, from this test, it looks as though the web browser isn't caching the page, but it's caching the URL of the iframe and then making a new request on that cached URL. However, I'm still stumped as to how to solve this issue.
Does anyone have any ideas on how to stop the web browser from caching iframe URLs?
This is a bug in Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=356558
Try this workaround:
<iframe src="webpage2.html?var=xxx" id="theframe"></iframe>
<script>
var _theframe = document.getElementById("theframe");
_theframe.contentWindow.location.href = _theframe.src;
</script>
I have been able to work around this bug by setting a unique name attribute on the iframe - for whatever reason, this seems to bust the cache. You can use whatever dynamic data you have as the name attribute - or simply the current ms or ns time in whatever templating language you're using. This is a nicer solution than those above because it does not directly require JS.
In my particular case, the iframe is being built via JS (but you could do the same via PHP, Ruby, whatever), so I simply use Date.now():
return '<iframe src="' + src + '" name="' + Date.now() + '" />';
This fixes the bug in my testing; probably because the window.name in the inner window changes.
As you said, the issue here is not iframe content caching, but iframe url caching.
As of September 2018, it seems the issue still occurs in Chrome but not in Firefox.
I've tried many things (adding a changing GET parameter, clearing the iframe url in onbeforeunload, detecting a "reload from cache" using a cookie, setting up various response headers) and here are the only two solutions that worked from me:
1- Easy way: create your iframe dynamically from javascript
For example:
const iframe = document.createElement('iframe')
iframe.id = ...
...
iframe.src = myIFrameUrl
document.body.appendChild(iframe)
2- Convoluted way
Server-side, as explained here, disable content caching for the content you serve for the iframe OR for the parent page (either will do).
AND
Set the iframe url from javascript with an additional changing search param, like this:
const url = myIFrameUrl + '?timestamp=' + new Date().getTime()
document.getElementById('my-iframe-id').src = url
(simplified version, beware of other search params)
After trying everything else (except using a proxy for the iframe content), I found a way to prevent iframe content caching, from the same domain:
Use .htaccess and a rewrite rule and change the iframe src attribute.
RewriteRule test/([0-9]+)/([a-zA-Z0-9]+).html$ /test/index.php?idEntity=$1&token=$2 [QSA]
The way I use this is that the iframe's URL end up looking this way: example.com/test/54/e3116491e90e05700880bf8b269a8cc7.html
Where [token] is a randomly generated value. This URL prevents iframe caching since the token is never the same, and the iframe thinks it's a totally different webpage since a single refresh loads a totally different URL :
example.com/test/54/e3116491e90e05700880bf8b269a8cc7.html
example.com/test/54/d2cc21be7cdcb5a1f989272706de1913.html
both lead to the same page.
You can access your hidden url parameters with $_SERVER["QUERY_STRING"]
To get the iframe to always load fresh content, add the current Unix timestamp to the end of the GET parameters. The browser then sees it as a 'different' request and will seek new content.
In Javascript, it might look like:
frames['my_iframe'].location.href='load_iframe_content.php?group_ID=' + group_ID + '×tamp=' + timestamp;
I found this problem in the latest Chrome as well as the latest Safari on the Mac OS X as of Mar 17, 2016. None of the fixes above worked for me, including assigning src to empty and then back to some site, or adding in some randomly-named "name" parameter, or adding in a random number on the end of the URL after the hash, or assigning the content window href to the src after assigning the src.
In my case, it was because I was using Javascript to update the IFRAME, and only switching the hash in the URL.
The workaround in my case was that I created an interim URL that had a 0 second meta redirect to that other page. It happens so fast that I hardly notice the screen flash. Plus, I made the background color of the interim page the same as the other page, and so you notice it even less.
It is a bug in Firefox 3.5.
Have a look..
https://bugzilla.mozilla.org/show_bug.cgi?id=279048
I set iframe src attribute later in my app. To get rid of the cached content inside iframe at the start of the application I simply do:
myIframe.src = "";
... somewhere in the beginning of js code (for instance in jquery $() handler)
Thanks to
http://www.freshsupercool.com/2008/07/10/firefox-caching-iframe-data/
I also had this problem in 2016 with iOS Safari. What seemed to work for me was
giving a GET-parameter to the iframe src and a value for it like this
<iframe width="60%" src="../other/url?cachebust=1" allowfullscreen></iframe>
I also met this issue, after trying different browsers, and a ton of trial and error, I came up with this solution, which works well in my case:
import { defineComponent } from 'vue'
import { v4 as uuid } from 'uuid'
export default defineComponent({
setup() {
return () => (
// append a uuid after `?` to prevent browsers from caching it
<iframe src={`https://www.example.com?${uuid()}`} frameborder='0' />
)
},
})
If you want to get really crazy you could implement the page name as a dynamic url that always resolves to the same page, rather than the querystring option?
Assuming you're in an office, check whether there's any caching going on at a network level. Believe me, it's a possibility. Your IT folks will be able to tell you if there's any network infrastructure around HTTP caching, although since this only happens for the iframe it's unlikely.
Have you installed Fiddler2?
It will let you see exactly what is being requested, what is being sent back, etc. It doesn't sound plausible that the browser would really hit its cache for different URLs.
Make the URL of the iframe point to a page on your site which acts as a proxy to retrieve and return the actual contents of the iframe. Now you are no longer bound by the same-origin policy (EDIT: does not prevent the iframe caching issue).