bot_gzFlashEmbed 1.81 & 2.0 / bot_gzFlashEmbed.searchbot 1.5 & 2.0

Mambot/plugin solution to easily embed Flash clips into Joomla! 1.0.x / 1.5.x (- new! -) content (static/blog) with Flash text extraction and Joomla!-integrated search for Flash text

© Gero Zahn,

Table of Contents:

What's new?

1.6 (deprecated): Select if you want to use a HTML comment block to embed text or a <div style="display:none">...</div> tag - or both (default: both). (deprecated download)

1.7: CSS class for use in the <div...></div> tags implemented in V1.6 to prevent classification as SEO SPAM.

1.8: Third alternative: <noembed></noembed>.

1.81: Woops ... found and fixed a really stupid code-generation bug. Nothing serious, but it's highly advised to upgrade for better XHTML code.

2.0: Brand new version compatible with Joomla 1.5.x


Integrating Flash clips into web-pages isn't too much a deal if you're using a sophisticated software like Adobe GoLive, Macromedia DreamWeaver or whichever authoring tool you like best - even TinyMCE has a "Flash" button to embed Flash clips. - Though you still have to rely on your Flash IDE and its HTML export to extract the text from your Flash clip, to use it as invisible HTML comment: It's a tough job to keep this extracted text block current with your SWF, and otherwise you never know which search-engine will still ignore this HTML comment.

Featuring Flash clips inside a CMS should be made even easier for the editors, providing a very short and simple syntax that embeds the clips without any fuss, using reasonable default values for anything you didn't explicitely specify - yet giving you the chance to fine-tune the embedding with simple, error-tolerant pseudo-code that won't blow up from just one misplaced character.

On the other hand there should be a way to automate the text extraction from the embedded Flash clips, as well as providing them as usually invisible portions within the pages of your CMS to provide better search engine compatiblity. And last, but not least, the CMS-internal search engine should be able to find these text portions as well.

So - these are the core functions of my solution:

NOTE: The new version 2.0 for Joomla 1.5.x works exactly the same way like the version 1.0x/1.5+ works for Joomla 1.0.x. It is tagged "legacy" because it uses the legacy style of implementing plugins, which is very similar to implementing old-school mambots, although there's already a far more efficient API. Thus this old-style implementation will become deprecated and perhaps non-operational eventually. ... As for the time being a lot of Joomla 1.5's core plugins are implemented this way as well, I'll face this problem when it becomes unavoidable, but not earlier than that.

I have to admit that the general concept of creating a Flash embedder mambot / plugin is not new: At the beginning I was heavily inspired by Marc Hinse's mywflashbot (which, as Marc says, is itself based on mmsflashbot of ModernMediaSidon). But soon I realized that all other solutions could not match my personal needs, so I decided to start over from scratch and to redo the entire thing to gain much more flexibility at even simpler syntax.

bot_gzFlashEmbed / gzflashembed_legacy

First you have to download and install the bot_gzFlashEmbed mambot / pluging - see the download link below. The old version 1.0 should work in Mambo 4.5.x as well (I didn't test it), but I definitely expect that bot_gzFlashEmbed 1.5+ and bot_gzFlashEmbed.searchbot 1.5+ will not cooperate anymore. gzflashembed_legacy 2.0+ and gzflashembedsearch_legacy 2.0+ will work for Joomla 1.5.x

After installing you've got one more pseudo-tag at hand:


where "..." represents information about the Flash clip you actually want to embed. If you enter an empty pseudotag like this


or if your pseudocode makes no sense, you will the the following short information:

flashembed - you have to at least supply a Flash file name, height and width
You gave: 

swf = Flash file name - if necessary urlencode this
w = width - default undefined
h = height - default undefined
t = title - default undefined
v = version - default 6,0,0,0
wm = wmode - w=window, o=opaque, t=transparent - default opaque
p = play - 1=true, 0=false - default true
l = loop - 1=true, 0=false - default true
q = quality - l=low, m=medium, h=high, b=best, al=autolow, ah=autohigh - default high
s = scale - sa=showall, nb=noborder, ef=exactfit, ns=noscale - default showall
m = menu - 1=true, 0=false - default false
a = align - l=left, t=top, r=right, b=bottom, m=middle - default middle
sa = salign - lt / t / rt | l / "" / r | lb / b / rb - default = ""=middle
... You may also add additional parameters with yet unknown key names and parameter values.

... for a 100x100 version 7,0,0,0 / autoplay=false / wmode=transparent embedding

Basically, this says it all. :) But let's get a bit deeper into detail.

The basic embedding

The shortest possible Flash embedding states which .swf file you want to use and its dimensions, ie. width and height. It should look like this:


or (even shorter)


Note that "width=" and "w=" are synonymous, as well as "height=" and "h=".

The above embedding assumes a few reasonable default values: The embedding Flash will autoplay and loop in high quality, the requested version string is 6,0,0,0, it will not show the Flash menu on the right mouse button and a few other things you can find out yourself in the short information text shown above.

There are two ways to embed a .swf file:

  1. remote - in that case the file name has to start with "http://"
  2. local - then the file name is assumed to be relative to the root of your CMS. (The file name may or my not start with "/".)

If you get in trouble with blank or special characters in your file name, you may urlencode them. ... But as you all know: Better don't use blanks and other special characters in file names on web-servers at all.

Window mode - wmode

The window mode (or "wmode") is set to "opaque" by default. In this mode, DHTML flyouts (like menu bars, ad banners, whatever) can be placed on top of the Flash element. (The default wmode "window" does not support this and would the Flash clip place on top of the DHTML elements unasked.)

If you definitely wish to use regular "wmode=window" (which might play back your Flash clip slightly faster), use this:


Note that "wm=" is synonymous for "wmode=" and in this case "w" is synonymous for "window".

If you wish to have your clip's background color replaced by the HTML background the clip lies on, use window mode "transparent", or short:


This will result in a slower playback, but it looks great as you can place your Flash elements virtually over every (D)HTML background. - As of now (summer 2006), this should work for virtually any reasonably modern browser in Windows and MacOS (MSIE 5+, Mozilla 1+, of course all Firefox's, Opera 8+, as well as Safari). However I couldn't get transparent mode to work in any Linux browser (Mozilla, Firefox, Konqueror or Opera). And believe me, I've tried.

... Transparent mode requires Flash Player 6 or later. That's why gzFlashEmbed uses "6,0,0,0" as version string by default.

Requesting a certain Flash version

Let's say you want to embed a Flash MX-2004 clip, so the version string should be "7,0,0,0". That's easy:


Note that "v=" is synonymous to "version=" and in this case "7" is synonymous to "7,0,0,0". If you prefer e.G. to request Flash version "3,1,4,1" (though I'm not sure this one ever existed), try this:


Meaning: As long as you specify just a number like 1..99, the version will be added by ",0,0,0". If you want to specify a special version number, you have to state it completely.


This is a reminiscent to Marc's mywflashbot (see above) which I didn't thought to be necessary, but which I implemented back into my embedder anyway: The Flash clip will have a title tag and an alt tag. This could be useful for text browsers or browsers with Flash turned off. So use something like this:

{flashembed}swf=myflash.swf|w=100|h=50|t=My Flash Clip{/flashembed}

Note that "t=" and "title=" are synonymous.

The other stuff and future parameters

Now have a closer look at the short information text shown above. It describes all pre-defined parameters with their short synonyms, their default and possible values, mostly again short synonyms for usual parameters. Generally, the values for the boolean yes/no parameters like play, loop and menu can be abbreviated with "1" and "0" for "true" and "false" - and their first names by "p" (play), "l" (loop) and "m" (menu).

If some day an additional parameter will become necessary to control your Flash clip, it can be entered as well, though there won't be short synonyms for the paramter and its values. So let's assume, future Flash clips might need a parameter called "dontknowwhatfor" set to "thatsright". In that case this should work:


Expert stuff: Passing variables to your Flash clip

Let's say you want to pass a variable to your Flash clip - a database result, a cookie value or whatever else. (If you're an experienced PHP/Flash programmer, you'll find other examples this might be useful for.)

Usually trick can easily be done by adding it via "?" to the clip's name, so the resulting URL would contain the parameter that can be read-out from within the clip via ActionScript. So - the final URL might look like this:


You have to urlencode the clip's name like this:


Note that the blue "%3D" is the urlencoded representation of the former "=", seperating the parameter name from its value. When creating the .swf's URL, this is urldecoded automatically - the final URL will contain the correct parameter.

bot_gzFlashEmbed / gzflashembed_legacy and automatic on-the-fly Flash text extraction

I spared this issue up to this point - as it's not that easy to achieve: My text extraction from Flash files relies on a tool called swf2html that is copyrighted by Adobe/Macromedia and therefore is not GNU whatsoever. So I can't include it here as a download, neither can I use the inbound strurtural knowledge of SWF files without sacrificing the GNU license of bot_gzFlashEmbed.

However: Any interested Flash developer can participate in the Adobe/Macromedia Player licensing program for free and without obligations. After the registration process you can download the mentioned tool swf2html both precompiled for Windows and Linux, as well as in C++ source so you can compile it for virtually any server platform. The tool itself is tiny: The precompiled Windows .exe is 85 KB, the precompiled Linux ELF binary is 64 KB.

But getting hand on the swf2html tool is just the first half of the way. There are a few requirements:

Being through with that: Now go get swf2html at the above mentioned URL.

swf2html installation

Place the appropriate executable version of swf2html in the root folder of your Joomla! CMS and make sure your PHP can actually execute it.

If you're using a UNIX/Linux-based server, you might have to compile the tool - which basically costs you just one run of "make" and just a few seconds when GNU-C++ is installed. Afterwards move the binary to the CMS' root folder and check the file owner and permissions (usually 755).
If you're using a Windows-based server, you should be able to use the pre-compiled swf2html.exe from the archive you downloaded from Adobe/Macromedia. - Further configuration of this tiny program will not be necessary.

Note: Place just one executable in the Joomla CMS root, either the UNIX/Linux swf2html or the Windows swf2html.exe. bot_gzFlashEmbed checks which one is present and uses that one (thus detecting if it runs in a UNIX/Linux or in a Windows environment).
... The development took place on a Linux machine, but I also gave it a short check on a Windows 2000-based XAMPP-win32-1.5.3a on a fresh installation of Joomla! 1.0.10 - worked fine for me.

Functional test

If bot_gzFlashEmbed was able to find a working copy of swf2html, it should start using it right away. Open a page within your Joomla! website that contains a Flash clip embedded with with a content with a Flash content you've embedded with {flashembed}...{/flashembed} - of course it should be a Flash clip that actually contains readable text. Any static text block is suitable - but don't expect to be able to extract text that you've broken apart ie. converted to a vector graphic in your Flash IDE.

Now have a look at the page source. Right underneath the Flash <object ...>...</object> you should see an HTML comment block <!-- ... --> containing the text portions before trapped in the Flash clip. If you can see this, everything works fine.

bot_gzFlashEmbed afterwards stores the text elements in the database, thus significantly reducing the CPU overhead for swf2html. To do so bot_gzFlashEmbed creates a database table called jos_gzflashembed (or similar, if you have specified a prefix other than "jos_" while installing Joomla!).

Whenever a new Flash clip embedded with bot_gzFLashEmbed is displayed, the text is extracted and stored in the database. If you update that Flash element, the text will be re-extracted with the next page-impression (as long as the last-modified-date of the .swf file changes).

Note: swf2html can just extract text from Flash clips stored locally on your Joomla! CMS' file-system. bot_gzFlashEmbed can as well embed remote .swf files (see above), but it will not be able to extract text from them.

Types of the text embedding

gzFlashEmbed's default text embedding mimics the Flash IDE text output ie. it places the text portions within an HTML comment. As search engines usually ignore HTML comments completely while crawling websites, this is obviously rather useless.

One would assume that it might be a great idea to somehow create "invisible text" (like using the the background color as text color) so it wouldn't disturb regular page viewers but still keep the text on the page for the search-engines.
As this has often been abused for search engine spamming, you might face the consequence of being banned completely off many search-engines - so don't even think about doing this!

Creating invisible text through CSS and coding it like this

<div style="display:none">...</div>

is not far from the above color trick, so for this you might get banned by search-engines as well. (The deprecated version 1.6 of gzFlashEmbed created tags it like this, so it was permanently removed shortly after.)

But it is widely considered to be safe to use CSS like this:

<div class="swftext">...</div>

and to render swftext class text invisible like this by adding

div.swftext { display:none; }

to your CSS file - as the crawlers most likely won't evaluate the external CSS file at all. If you select "invisible DIV" in gzFlashEmbed 1.7 or later, <div>...</div>s like this will be created. Be sure to update your CSS file!

A third alternative which doesn't hover you entirely to the perfect side either is available since gzFlashEmbed 1.8: It is possible to place the text portions inside a <noembed>...</noembed> tag which should become visible only if the browser does not support embed tags or if plugin support is entirely disabled.
From my own experiments all Gecko based browsers (like Netscape 6.x or later, ie. of course all Mozilla or Firefox browsers - as well as IE5+ and Opera 7+) will not display text inside the <noembed>...</noembed>. As I checked Konqueror and Swift, I assume Safari on MacOS will do fine as well.

But note that there's one draw-back: noembed is not part of the W3C HTML standard, so strictly speaking you create incorrect HTML code by this. And again there have been rumors above search-engine bans because of the use of noembed to hide text - as it is easily detectable by robots.

My suggestion is: Use <div class="swftext">...</div>, but still be prepared to fight against the seach-engine editors that you use it just for useful text and not for spam.

bot_gzFlashEmbed.searchbot / gzflashembedsearch_legacy

Now having the Flash clips' text portions somehow inside in the HTML pages, this should greatly help the web-spiders of the search-engines as they can see the otherwie invisible text now where used to be just "silent" Flash elements.

But there's one more thing: The text portions should be searchable with the Joomla! internal search module. ... Which they are not right away as the content searchbot searches just the "raw" HTML content before any content mambot / plugin (like bot_gzFlashEmbed) can expand the content. So a regular search would not find your Flash text contents we just gained.

bot_gzFlashEmbed.searchbot closes this gap: Download it and install it (don't forget to publish it). Afterwards any search request will as well find those text portions that have been auto-extracted from your Flash clips via bot_gzFlashEmbed.

Note: bot_gzFlashEmbed.searchbot searches in jos_gzflashembed created by bot_gzFlashEmbed. Flash clips that have not been visible at least once before will not be found!
As well Flash clips stored on another webserver can not be searched/found as bot_gzFlashEmbed can not extract text from them.

Combining gzFlashEmbed / gzflashembed_legacy with gzNoClickToActivate(_legacy)

After Microsoft lost a lawsuit against Eolas, current internet browsers like MSIE 6+ and Opera 9+ have started to display a message "Click to activate" when you hover your mouse pointer over a Flash clip - as well when hovering over media clips or JAVA applets. This creates a terrible breach in web-wide usability as Flash based web applications may not work as expected anymore.

This can however be solved by a different, more complicated way to embed the Flash clips, applets other media clips into your HTML code. It was originally proposed by Microsoft and works fine for MSIE 6+ as well as for Opera 9+ and propably any future browser. I programmed another mambot / plugin to on-the-fly transform regular media embeddings, creating valid code working smoothly without clicking the content first. That mambot / plugin is called "gzNoClickToActivate" - click to find out more about it.

bot_gzNoClickToActivate and bot_gzFlashEmbed can be used together, you just have to make sure that bot_gzFlashEmbed has a higher priority (meaning: a smaller number in the mambot / plugin list) as gzNoClickToActivate has to parse and re-format the output of gzFlashEmbed. - Stated more simply: Move gzNoClickToActivate farther down in the list, at least below gzFlashEmbed - and you're fine.

You may wonder why I didn't integrate the no-click technology right into the Flash embedder. Simple: There may come the day when the no-click workaround might become obsolute (keep the faith!) - or the work-around might not work anymore some day (though this is pretty impropable as it doesn't touch the patent). Anyway: In that case the no-click work-around can be disabled or updated alone, without the need to get back into the Flash embedder's program.

On the other hand, the gzNoClickToActivate works for JAVA applets and any other (perhaps hand-coded) media embeddings as well, meaning: It covers much more than just Flash embeddings created with bot_gzFlashEmbed.


Version 2.0 - with Flash text extraction and Flash text search - meant for Joomla 1.5.x:

Version 1.5+ - with Flash text extraction and Flash text search - meant for Joomla 1.0.x:

Primary version 1.0 - without Flash text extraction (should run on Mambo 4.5.x as well).



Disclaimer: All quoted product or company names are or might be trademarks or registered trademarks owned by the correspondent companies. These names are used here solely for documentation purposes.
Any information on this page is given "as is". Though it is copyrighted by Gero Zahn,, the author refuses to take any responsibility for the described functions or side-effects using his software in unchanged or changed form.