I wanted to use the progressive player that Dreamweaver provides, so I generated the code, pulled out the flashvars and parameters and inserted them into the SWFObject code like so:

(Line wraps marked »)

<script type="text/javascript">
    var flashvars = {
        skinName: "video/Clear_Skin_3",
        streamName: "MyVideoTitle",
	autoPlay: true,
	autoRewind: false
    };
    var params = {
        movie: "video/FLVPlayer_Progressive.swf",
	salign: "tl",
	quality: "high",
	scale: "noscale"
    };
    var attributes = {};

    swfobject.embedSWF("video/FLVPlayer_Progressive.swf", "FLVPlayer", »
    "800", "600", "9.0.0","video/expressInstall.swf", flashvars, params, »
    attributes);
</script>

The important thing here being, that the path to the video file is relative to the player SWF (in this case ‘FLVPlayer_Progressive.swf) NOT the page calling it – Nice!

Fancybox is a really nice jQuery plugin that gives you some handsome options for the div overlay.  We are using it in a new project, but needed to call it from Flash, and there was really no documentation for how to do this.  Hopefully our solution will help someone else.

Here’s the really simple javascript function we added onto our page:

<script type="text/javascript" >
function callFancy(my_href) {
var j1 = document.getElementById("hiddenclicker");
j1.href = my_href;
$('#hiddenclicker').trigger('click');
}
</script>

Now somewhere on the page we had to add a “hidden” <a> tag that we could manipulate with javascript like this:

<div id="hidden_clicker" style="display:none;">
<a class="overlay-flash" id="hiddenclicker" href="#" >Hidden Clicker</a>
</div>

The tag is wrapped in a div tag that has a display:none set so it doesn’t show in the browser.

Next part is the ActionScript. We embedded the SWF using SWFObject and can call the javascript function just like this:

getURL("javascript:callFancy('/linktopage.html');");

That’s it. Hope it helps someone out there.

UPDATE 8/18/09:  I neglected to point out that the A class assigned to our “hiddenclicker” div is a custom javascript implementation to launch a certain window.  Here is the code we added to an included .js file:

$(document).ready(function() {
 $("a.overlay-flash").fancybox({
 'padding'                : 0,
 'zoomOpacity'            : true,
 'zoomSpeedIn'            : 500,
 'zoomSpeedOut'            : 500,
 'overlayOpacity'        : 0.75,
 'frameWidth'            : 530,
 'frameHeight'            : 400,
 'hideOnContentClick'    : false
 });
});

Sorry for the omission…

But if I’ve been having this problem this long I have to believe there are others.  For the last two months, I’ve been completely unable to browse the magentocommerce.com website in Firefox – major pain, considering I’ve been working on two magento projects.  Every time I visited I would get a “400 Bad Request” error.

I tried turning off all my Firefox add-ons – to no avail.  Finally figured it out.  It was a bad cookie that somehow the site had stored on my machine.

I used the Web Developer Toolbar to clear out all the site cookies for magentocommerce.com and that did the trick.  Hope this helps someone else from pulling all their hair out.

We’ve also taken to a new approach for updating our WordPress sites. Since we’ve had a love affair recently with SVN for version control, I decided it made a lot more sense to use direct SVN checkouts of the tagged releases in the WordPress SVN, rather than FTP’ing the entire WordPress directory every time we get a minor release. So… here’s how we’ve got it set up:

1. First, we run an SVN checkout to get the tagged release. This gives us all the core WordPress files.
2. Next, we upload via FTP all the files that don’t belong to the core WordPress file structure. These files are:
3. wp-config.php
4. .htaccess
5. our custom theme
6. our plugins (besides akismet and hello)
7. the wp-content/uploads folder
8. Then we make sure that uploads folder is writeable by the server, and all should be well.

So with this setup, the next time that we need to upgrade the WordPress release, we can simply SSH into the server and run an svn switch command to the newest tagged release and it will update the changed files. Then we run the upgrade script and we’re there. Much easier when you have to update a dozen WordPress sites at once.

So. Anyone see any gotchas in this approach?

By default, Blueprint has a stylesheet for IE that adds a position: relative declaration to certain classes. Took me a little while to track this down and the solution is pretty simple: add a z-index property to the nearest positioned ancestor of the dropdown navigation, and set the value to something greater than the z-index of the content (e.g. 100). Voilà! You’re back up and running.

In short, I changed the first line of this:

<div class="column span-42 pull-10 last">
  <ul id="nav">
    <li><a href="#">COMPANY</a>
      <ul>
        <li><a href="/ourstory">OUR STORY</a></li>
        <li><a href="/executivemanagement">EXECUTIVE MANAGEMENT</a></li>
        <li><a href="/news">LATEST NEWS</a></li>
      </ul>
    </li>
  </ul><!-- end #nav -->
</div>

to this:

<div class="column span-42 pull-10 last" style="z-index: 100;">

Oh yeah, and to keep the Suckerfish dropdown menus from appearing behind Flash pieces, make sure that you set the Flash parameter ‘WMODE’ to ‘transparent’

If you’re using SWFObject to display your Flash pieces, you would add the line:

so.addParam("wmode", "transparent");

Those of us who appreciate the WYSIWYG will be able to view their flash files again.

CSS Organization