I am using this
<audio src="audio.mp3" />
Now that file is big and system automatically downloads it when someone loads the page.
is there any way that when someone press play , only then system downlaods. Because that player is in my every page and it wastes the BW
You can use the preload='none' attribute. Documentation here
The "none" attribute:
Hints to the user agent that either the author does not expect the user to need the media resource, or that the server wants to minimise unnecessary traffic. This state does not provide a hint regarding how aggressively to actually download the media resource if buffering starts anyway (e.g. once the user hits "play").
Your HTML could look something like this:
<audio preload="none">
<source src="audio.mp3" type="audio/mpeg" />
Your browser does not support this audio type.
</audio>
Related
I'm implementing a slide-in-on-scroll newsletter signup form on our site, which is built as AMP-native.
I added a button that hides the div on tap using amp-bind, but I'm struggling to get my head around how to save the closed state with cookies/localStorage in AMP.
I've gone through the favorite button example code - https://ampbyexample.com/advanced/favorite_button/ (as recommended here on SE), but I don't see how it relates to this particular use-case, especially with the use of amp-list.
Based on what I've read and few examples I found the credentials="include" attribute is needed, as is a valid CORS json endpoint and an auto generated client id appended to the endpoint url using AMPs variable substitution, but I'm not sure how to put it all together.
I took a stab hacking something together using the favorite button example, but the tutorial doesn't say much about how to setup the CORS endpoint and that particular example is for storing multiple likes to a single endpoint, as apposed to storing a specific users viewing preferences.
Here is my rough (poking-around-in-the-dark) stab at the code:
<form method="post"
id="side-newsletter-wrap"
action-xhr="/prefs&clientId=CLIENT_ID(prefs)"
target="_top"
on="submit:AMP.setState({
showSideNewsletter: !showSideNewsletter
});
submit-error:AMP.setState({
showSideNewsletter: !showSideNewsletter
});">
<button on="tap:side-newsletter-wrap.hide" class="close-button"><i
class="fa fa-times"></i></button>
<amp-list width="320"
height="360"
credentials="include"
items="."
single-item
src="/prefs&clientId=CLIENT_ID(prefs)">
<template type="amp-mustache">
{{#.}}
<?php winefolly_load_fragment('newsletter-embed'); ?>
{{/.}}
{{^.}}{{/.}}
</template>
</amp-list>
</form>
For the prefs endpoint, I'm guessing I'd need to register a new endpoint in WordPress that outputs simple array with the preferences?
Something along the lines of:
{
showSideNewsletter: "true",
winesIndexView: "grid",
winesIndexSort: "title"
}
I also tried the amp-user-notification component (which has the closed state built in) but that felt a bit hacky and the newsletter embed code (via iframe) doesn't get loaded due to a known bug - https://github.com/ampproject/amphtml/issues/18995).
Any suggestions would be much appreciated.
Chris
You're right amp-user-notification is the correct approach. Is there a way to implement the newsletter form in AMP until the amp-iframe bug is fixed?
Another way is to use amp-access, which allows you to change the layout of the page on page load. You have to store the user preference server-side though using the READER_ID to identify the user. Storing this server-side is required as you might not be able to write cookies if the page is served from the AMP Cache due to ITP 2.0.
I have wordpress site with video player(JW player). I want to load test using jmeter. But i dont know how to do that?
JMeter doesn't act like a browser hence it won't "play" the video via JWPlayer. If you need to check whether your wordpress deployment will be able to serve video content and the video content itself is being hosted by you it is possible to simulate hundreds and thousands of users which are downloading videos.
If you look into wordpress page source you will see something like
<span class="jwvideo" id="hero-video_media" style="opacity: 1; visibility: visible;">
<video x-webkit-airplay="allow" webkit-playsinline="" src="https://content.jwplatform.com/videos/XjiIpRcb-1080.mp4"></video>
</span>
You're interested in https://content.jwplatform.com/videos/XjiIpRcb-1080.mp4 bit as this is the URL of the video file.
You can easily get the URL with the XPath Extractor using the following query:
//video/#src
And use simple HTTP Request sampler to simulate video download.
I just installed this and it seems to work like a charm except for one thing. When the page displays, the thumbnail is blank. Is there a way I can use the first video frame as the thumbnail display or something like that?
Thanks in advance for any help you can give me.
To have mediaelement.js load a thumbnail you need to ensure that preload is not set to none. For example:
<video src="myvideo.mp4" controls="controls" preload="metadata"></video>
Setting poster="poster.jpg" as per the example in the documentation won't necessarily work (unless you happen to have a file named poster.jpg). Though you can set the poster attribute to the location of an image to use as a thumbnail prior to loading the video, in the event you don't want the user agent to peek inside the media object.
See this answer for more information on the pre-load options - What are the options for the mediaelement player's "preload" setting?
I believe you need to put a poster="poster.jpg" attribute in the <video> tag.
We are handling PDF publishing by using a Dynamic Component Template associated with the PDF schema, then creating Binary Links where we need to link to the PDF.
We've found that un-publishing a PDF that is a component link inside a component used on a page is triggering the page to get unpublished.
I know we can control this behaviour by using a Custom Resolver, but is this the expected result?
Has this behaviour changed from Tridion 2009 to Tridion 2011?
BinaryLinks are meant to be used for "inline binary content", so typically things that are included by a src attribute.
<img src="..." />
<video width="320" height="240" controls="controls">
<source src="movie.mp4" type="video/mp4" />
<source src="movie.ogg" type="video/ogg" />
Your browser does not support the video tag.
</video>
For this inline binary content, the page will not display correctly without it. Knowing that, it is correct that the Page gets unpublished when you unpublish the MMC. So as far as I can tell this is indeed the expected behavior, which hasn't changed in a long time.
The mistake is in using an MMC for a PDF that you want to show as a hyperlink. For anything that you want to link to (so that turns into a <a href="...") you should be using a ComponentLink (or of course a PageLink of it is a Page).
The unpublishing of items that are used by a Binary Component was already there in 2009 (so much so, it's even one of the questions of the Tridion 2009 Business Analyst Exam).
I see a trend developing of people using Dynamic Component Presentations for their binaries, which bypasses all this side effect, but leaves you potentially with bad binary links on your pages.
If you go down the DCP route for binaries, make sure to use Dynamic Linking (pretty simple to create on the CM by using "tridion:type=binary" in your anchor markup).
I have a website that uses IFrame in a page that loads other pages based on server side logic. So, if I do a View source, I would see something like this:
<iframe src="DeterminedOnServerSide.aspx" id="myFrame">
</iframe>
My question is - Is there any way, an attacker can change the src attribute to point other users to a malicious website considering that the src is determined on the server side?
Yes or no. You have not specified how "DeterminedOnServerSide.aspx" is determined. If your code for this consists of DeterminedOnServerSide = Server.Request["frame"] then it can clearly be 'hacked'. If you use a method that ensures only valid urls are chosen, then it is not vulnerable.
No, not unless they've compromised your server and can access and modify those source files. And if that's the case, changing of the 'src' attribute in the iframe is the least of your worries.
Yes. A XSS attack has the capability of changing the src of an iFrame.
Check it out: http://research.zscaler.com/2009/12/xss-embedded-iframes.html
The page you "include" using the IFRAME can navigate to a new page, changing the source.
Any user of the site can change the src value of the IFrame, using Developer tools like Firebug and IE Developer Tools
Any sucsessful man in the middle attack can change all your html source including the src attribute. If the attacker is in control of a proxy or network between your customer and your server they can change any of your html including the src attribute.
Any sucsessful hack into your server can change all you sourcecode and change the attribute.
What Hacker are you thinking of? you should only iframe to people/sites you trust, as this is a common way for cross site scripting attacks.
The only ways to change the src attribute of your iframe (or anything in your website) are:
The webpage which load the iframe has an XSS vulnerability and the attacker use the DOM to change it.
He (or she) get access to your source code. Then the change of a iframe attribute is your less important concern ;-)