Testing on a Local PC
Wimpy was designed FOR THE WEB. Attempting to test Wimpy on pages loaded off of your local PC will probably not work because:
- Browser's have built-in security measures to prevent access to local files.
- It is a "web app" (server based) not a traditional local-based app.
- It doesn't have permission to interact with local files.
- It requires special server-side functionality (PHP), which local PC's don't have.
Wimpy leverages a number of technologies, each have there own idiosyncrasies. Plus, browsers and systems (Mac, Linux, Windows) have their own set of "issues". Hence, the best way to be sure things are working is to TEST ON A LIVE WEB SERVER.
Your working on a page on your local PC, and you've incorporated Wimpy into the page. And to make sure everything works, you decide to test the page before uploading it.
When you double click the file, your browser opens and any one of these thing happen:
- Wimpy doesn't appear.
- An Adobe Flash prompt opens with a security alert.
- Wimpy appears but doesn't play anything.
- Nothing appears in the playlist.
- Nothing happens, period.
Any one of these things can happen!
Browsers are designed to prevent stuff from the web from affecting anything on your local PC. Some browsers are extremely strict, and othesrs, not so much. Here's a little more information onwhy these things may happen:
Skin files, media files and playlists can be located in various places throughout your overall website. Each file has a unique URL. These URL's may only make sense when the host HTML file is situated on a web server.
When running an HTML page on a local PC, browsers only allow files to load that are within the same folder as the host HTML file. When a browser prevents a file from loading, well, Wimpy can't do anything to over-ride the browser, and so Wimpy will not load properly.
In order for Wimpy to "know" where files are, or to automatically list files in a playlist, Wimpy uses special server-based functionality (PHP). PHP is a scripting language that most web servers have and is not available on local PCs. So when Wimpy makes a request to a PHP script file, a local PC will not interpret the script. Only web-servers know what to do with PHP files.
While Wimpy is not completely dependant on PHP to operate, if you're using "automatic playlist" (via wimpy.php) -- or using the Customizer Tool, things will not work as expected.
Cross Site Scripting
One main concern for browser developers is a thing called "cross site scripting" (aka XSS). In order to mitigate XSS, some browsers only allow files to be loaded from the same domain.
Some browsers even go to the extreme of only allowing files to be loaded from the same sub.domain. This security measure reduces the probablity that a remote site will be able to "take over" your site through scripting vulnerabilities.
XSS could potentially be disaterous if browsers allowed a remote site to fiddle with files on your local PC. So you can see how preventing cross domain stuff from happening is a good thing!
Your local PC is sorta-kinda considered a domain unto itself. Hence, even if you're using full URLs, Wimpy may not be allowed to load them because doing so would mean files are loading "across domains".
Why is Flash loading?
Wimpy always conducts tests to see what technologies are available. One of the tests is to check for the existance of Adobe Flash. Adobe Flash is very strict about running SWF files directly off of a local PC.
The reason we test for Flash is because not all browsers have the capability to play media natively. Or, the browser may not be able to handle MP3 or H.264 encoding. Under these circumstances, Wimpy may use Adobe Flash to playback media.
There are many more reasons why Wimpy may not work on a local PC, some of them are voodoo, or too boring to get into...
Test things on a live web server!