Download Help PDF (29MB) | Search:
Once you've created your slideshow and made all desired customizations, the time will come when you're ready to put it live on the web. The process of uploading slideshows to a remote server is relatively simple, but you must follow the steps outlined below for the slideshows to appear properly.
First, it is important to note that there are no server-side requirements. You can deploy slideshows to any type of webserver.
When you insert a slideshow, several external files are referenced directly or indirectly by the slideshow HTML. Because paths to these files are constructed based on their location relative to the HTML page, it is important to have them in place before you insert the slideshow, and not modify the paths after you create the slideshow. The relevant files include:
It is important to understand that all of the dependent files are loaded externally at runtime; they are not embedded in the slideshow SWF file. This ensures the best user experience, reduces loading time and provides maximum flexibility for you, the developer. Because of this, all of the following dependent files must be uploaded in addition to your HTML page for a slideshow to appear properly when deployed:
If you receive a javascript alert message about the v4flashslideshow/slideshow.js file not being accessible, make sure that you uploaded all files in the v4flashslideshow/ supporting files directory. If the problem persists, make sure that this line in your slideshow HTML properly points to the slideshow.js file (e.g. its path is correct):
<!-- Do not remove the line below!!! It is required for the DWUser XML Flash Slideshow v4. -->
<script type="text/javascript" src="v4flashslideshow/slideshow.js"></script>
If a blank space appears when you try to view your slideshow on the remote site, right-click on the blank space. Usually, you will see a 'Movie Loading...' message. If this message remains for more than just a few seconds, the issue is that the SWF file (in the v4flashslideshow/ folder) was not properly uploaded. Try uploading it again. If you are using an external FTP program instead of Dreamweaver, make sure that you are uploading the SWF files in Binary mode, not ASCII mode.
If, in place of one or more images, you see a 'Loading Error - IO' message, this indicates that the images were unable to be loaded. Usually, this is because the image files must be uploaded. If the images still don't appear, there may be a path problem. You can check the image paths by doing this: 1 - Open the XML file in your browser. 2 - Copy and paste an image path (including the gallery's fullPathPrefix value if one exists) into your browser. It's important to construct the URL as if you were starting at the HTML page which holds the slideshow (NOT the XML file). 3 - Load this URL. If the image doesn't display properly (e.g. returns a 404 not found error), then double-check that your images have been uploaded and that the paths are correct. If the image displays properly, then there is some other problem.
If you are 100% sure that you have uploaded the images and the paths are correct, yet you still see a 'Loading Error - IO' message OR you see a solid red square in place of where the image(s) should be, this usually indicates that a permissions error is occuring behind the scenes, resulting in a 403 forbidden error when the images are requested. The 'solid red square' issue can also be caused by images which have been uploaded using an external FTP client using ASCII mode; Binary mode must be used to upload images. To address the permissions error, make sure that the file is accessible.
If you have an error like the previous two, but it only seems to affect a single browser, first try clearing your temporary internet cache. If the problem is still there, see if your webhost has a 'hotlink protection' setting. If so, try disabling it for the images in the affected slideshow. This setting can cause the server to misinterpret the image requests from the slideshow SWF based on the way certain browsers handle the HTTP request headers; the result is blocked images.
Loading any assets (XML, images, audio, video, etc) from a different domain (or a different server) can cause problems as well; see the Flash Player Security Restrictions section below.
General Tip: If you make changes but they don't seem to be rendered when you view the slideshow in your browser, you likely need to clear your temporary internet files. Old cached versions of various files can prevent new updates from showing.
If you are loading image files (or video or audio) or external image data from a server at a different domain, you will be affected by Flash Player Security Restrictions. In a nutshell: the Flash Player will not allow content to be loaded from a different domain than the residing SWF file sits on, unless the owner of that different domain specifically authorizes this loading.
First, it's important to explain what qualifies as a 'diffent domain'. Any difference in either a subdomain or root domain qualifies a URL as being an entirely different domain. The most common example might surprise you:
You have a slideshow on http://www.example.org/slideshow.html. You upload some images to your site, and add them to the slidehow with a URL 'http://example.org/images/image1.jpg'. When you view the slideshow, the image fails to load and you receive a security restriction error message. "Huh?" you say, "I'm loading from the same site!" The issue is that the Flash Player views example.org and www.example.org as two separate domains because their subdomains aren't identical.
More intuitive examples include a slideshow at http://www.example.org/ which loads data from http://api.flickr.com/bla . Because this is a different root domain, Flash Player security restrictions go into effect.
When you attempt to load assets (XML data, images, audio, or video files) from a different domain, the Flash Player checks to see if a crossdomain policy file has been placed on the remote server. This is a file which is named crossdomain.xml and sits at the root of the domain's server (e.g. http://data.example.org/crossdomain.xml or http://www.dataserver.com/crossdomain.xml). This file must either allow all domains (via the use of a wildcard) or specifically allow the domain on which your slideshow resides, or the loading will not be permitted.
To prevent loading errors (as evidenced by 'Image Failed - Security' messages and other loading errors, such as XML loading errors), you must either load from a server which specifically permits crossdomain loading (if you don't have control over the server), or place a crossdomain.xml file on the server. Here is a simple example file, which permits loading from across all subdomains on this domain:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="example.com"/>
<allow-access-from domain="*.example.com"/>
</cross-domain-policy>
Two live example files can be viewed at: http://search.yahooapis.com/crossdomain.xml (an open policy, with no restrictions) and http://www.amazon.com/crossdomain.xml (a more restricted policy). You can learn more about creating crossdomain.xml files (crossdomain security policy files) at Adobe's site: http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
Advanced users who are comfortable with server-side programming can also circumvent these restrictions through the use of a server-side proxy on the same server as hosts the slideshow. For an example, see this blog post: http://blog.nelsonsilva.eu/2008/02/27/apache-proxy-for-crossdomain-problems/ .
If a user doesn't meet the necessary requirements to view a slideshow (as detailed below; usually due to Javascript being disabled or an insufficient Flash Player version), the user will see the alternate HTML content. This is specified through the following code in the slideshow HTML code block:
<div class="dwuser_xfs_v4_holder" style="width: 600px; height: 400px;"> <strong><a href="http://www.adobe.com/go/getflashplayer/">You need to upgrade your Flash Player and enable Javascript to view this content »</a></strong> </div>
The default alternate content is a simple message which states "You need to upgrade your Flash Player and enable Javascript to view this content", and links to the Flash Player download page on Adobe.com. However, you can replace this default value with any desired HTML content, including images. Or, you could provide more content-specific information such as "Please enable javascript and upgrade your Flash Player to view the slideshow".
For more detailed information and examples, see this topic in the Developer Reference.
A special technique must be used when deploying slideshows to pages over which you don't have full control, such as a blog or CMS. To learn more about this situation, see Deploying to a Blog or CMS.
Many developers ask -- "What requirements are there for users to view slideshows I create?". The answer depends on what slideshow SWF type you've selected - Basic or Pro (available only in the Professional version of the software). If using the Basic version, the following requirements are in effect:
If using the Pro version, the following requirements are in effect:
In either case, if the user doesn't have the required Flash Player version but does have version 6.0.65 or higher installed, the Flash Player Express Install feature is automatically invoked. This will automatically upgrade the user's Flash Player and return them to your page. If they don't have this version of the Flash Player (a miniscule fraction of users) or if they have Javascript disabled, the alternate HTML content will be displayed. You can customize this alternate content as described in the Creating Custom Alternate Content section above.