Recently, I was tasked with developing a website on
Drupal using powerful Flash, proprietary fonts, and PNG graphics so that it would all be equally displayed in office IE6 and other more popular browsers. With all the technologies, I worked for a long time, but I could not even imagine that all together would be one big headache. But a million different private solutions did lead me to a general solution of this long equation. About what I am going to tell in this article.
Task
Drupal product catalog with flash-magazine as a “highlight” and replacement of standard fonts in menus and headers.
Go!
Usually, when developing the design layout of a future
Drupal site to shorten development time, I used the
Framework theme, which was crafted for myself. And this time, acted like the previous one. The overall structure was developed, it was necessary to fasten a flash to it.
')
The first dead end. Flash in Drupal theme
Since the future site of the customer was located on my hosting without access rights to the source code, but with Drupal Administrator rights, it was necessary to prohibit the change of the inserted flash-element. From the usual
swftools had to be abandoned.
After a long search for a solution (since the usual insertion of flash in HTML, the Drupal theme did not produce results), the flash object was inserted using the following code:
<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0" width="880" height="440" align="middle" class="header2"> <param name="allowScriptAccess" value="sameDomain" /> <param name="allowFullScreen" value="false" /> <param name="movie" value="/FLASH.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFF" /> <param name="SCALE" value="noborder" /> <param name="wmode" value="transparent" /> <embed src="/FLASH.swf" width="880" height="440" align="middle" quality="high" bgcolor="#FFF" wmode="transparent" allowscriptaccess="sameDomain" allowfullscreen="false" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" scale="noborder" /> </object>
<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0" width="880" height="440" align="middle" class="header2"> <param name="allowScriptAccess" value="sameDomain" /> <param name="allowFullScreen" value="false" /> <param name="movie" value="/FLASH.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFF" /> <param name="SCALE" value="noborder" /> <param name="wmode" value="transparent" /> <embed src="/FLASH.swf" width="880" height="440" align="middle" quality="high" bgcolor="#FFF" wmode="transparent" allowscriptaccess="sameDomain" allowfullscreen="false" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" scale="noborder" /> </object>
- The code, of course, is as old as the World and, perhaps, is not properly built, but it all worked! And this is the main thing. But, since the inserted element took up quite a lot of space relative to the main content of the page and did not plan to change, I assumed that after a one-time familiarization with this flash-movie, the user would not want to see it in the future. In order not to distract the visitor, it was necessary to give the opportunity to “hide” the element, but at the same time, give the opportunity to look at it again. Ideally, without reloading the page.
The decision came quickly. Using simple jQueery and a simple additional js file in the subject:
- Install jQuery Update and jQuery UI modules in Drupal
- In the Drupal theme, we add the necessary CSS (for the blocks that we want to hide or show)
- Add a JS file to the topic that hides / shows these elements.
- Create a button, when clicked, that action will be performed
To my surprise, everything worked and there were no conflicts. But the effect was not, in fact, achieved. After moving to another page, everything was repeated from the beginning.
The second dead end. Ajax and drupal
After painful deliberation, weighing all the pros and cons, I still decided to use ajax-loading content so that the hiding blocks with flash are not updated along with the rest of the content.
After some searches, I found several solutions on the network. I chose the first one and started to turn it to the created site. The so-called “solution” is Page renderer + Asynchronous modules and the corresponding theme from the same manufacturer. For some reason, they are now unavailable at drupal.org. Apparently, because I was far from the only one who ran into the problems of this “solution”. At first glance, everything was great! I screwed the topic, installed modules, configured. It all worked! And what's more, it worked very nicely: when you clicked on one or another internal link, a customizable CSS div appeared, announcing the download being made. I modified some details of the topic and already when everything was ready, I started filling the site with the most information (text, photos, etc.), but then the most sad thing happened: any Wysiwyg editors and some of the modules that were important to me also refused to work . They were not there. Having spent several sleepless nights behind the laptop, smoked more cigarettes and drank more than a dozen liters of coffee in search of and resolving the conflict, I was forced to abandon all this “beauty” and start looking for another solution. And it was found:
- Install (in addition to the jQuery Update and jQuery UI already installed) the AjaxIT module, not forgetting to update / install the necessary libraries
- Customize it according to the theme of the site (everything is very simple)
And "Oh, God!" - works! True, a beautiful boot element does not appear. But this, I think, to whom it is important, is not difficult to screw on your own. When everything worked, it seemed to me that I could only dance for joy, but it was not there. I forgot about replacing standard fonts with my own.
The third impasse. Drupal + AjaxIT + Cufon = Conflict
I used to use the
Cufon module and
font converter in JS for it. But this time, having performed all the usual actions, I did not get any result. At first, I thought that the problem was in the font, but by applying another one, already tested, I did not get anything again. Then the @ font-face property came to my mind.
The fourth dead end. @ font-face and Opera
Not long digging into the wilds of the world wide web, I found a
font-face generator , the work with which seemed to me extremely simple, which alerted me. But vigilance with simplicity seemed to find no justification after the site test for cross-browser compatibility in
Adobe BrowserLab - even the world’s “favorite” donkey worked like a clock. But when I called my friend with the joyful news and the desire to boast of the work done with a request to test the site and throw off my screen, I was stunned to receive a letter from her - the Opera she used (10.50) did not display the fonts I so carefully screwed.
After some thought and attempts to find a suitable solution by applying the code:
@font-face {
font-family: '';
src: url('_normal-webfont.eot');
src: local(''), local('-Normal'), url('_normal-webfont.woff') format('woff'), url('_normal-webfont.ttf') format('truetype'), url('_normal-webfont.svg#') format('svg');
}
- came to the desired result. All browsers of interest to me (including Opera, which more than thirty percent of Russian users of my projects prefer) displayed fonts and all other content as I wanted.
It remained only to display PNG in IE6, for which I used the module for Drupal -
PNG behave . And he performed his work with dignity.
If there are questions, I can tell you in detail about each of the “dead ends” that this or that technology drove me into when creating this project and provide a link to the result.