Недавно, передо мной была поставлена задача разработать сайт на Drupal с использованием весомого Flash, фирменных шрифтов и PNG-графики так, чтобы всё это одинаково отображалось в офисных IE6 и других более популярных браузерах. Со всеми технологиями, я работал давно, но и предположить не мог, что всё вместе окажется одной большой головной болью. Но миллион разных частных решений таки привёл меня к общему решению этого длинного уравнения. О чем и собираюсь рассказать в сей статье.
Каталог продукции на Drupal с flash-журналом в качестве «изюминки» и заменой стандартных шрифтов в меню и заголовках.
Обычно, при разработке дизайн-макета будущего сайта на Drupal для сокращения времени разработки, я использовал перелопаченную под себя тему Framework. И в этот раз, поступил аналогично предыдущим. Общая структура была разработана, нужно было прикрутить к ней flash.
Так как будущий сайт заказчика был расположен на моём хостинге без прав доступа к исходному коду, но с предоставлением прав Администратора Drupal, нужно было запретить изменение вставляемого flash-элемента. От привычного swftools пришлось отказаться.
После долгих поисков решения (так как привычная вставка flash в HTML, в теме Drupal не дала результатов), flash-объект был вставлен с помощью следующего кода:
— Код, конечно, стар как Мир и, возможно, не правильно построен, но всё заработало! А это главное. Но, так как вставленный элемент занимал достаточно много места относительно основного содержимого страницы и не планировал меняться, я предположил, что пользователю, после однократного ознакомления с данным flash-роликом, не захочется видеть его в дальнейшем. Чтобы не отвлекать посетителя, нужно было дать возможность «спрятать» элемент, но при этом, дать возможность вновь его посмотреть. В идеале, без перезагрузки страницы.
Решение пришло быстро. Применение простого JQueery и не сложного дополнительного JS-файла в теме:
На моё удивление, всё заработало и конфликтов не возникло. Но эффект не был, собственно говоря, достигнут. После перехода на другую страницу, всё повторялось с начала.
После мучительных раздумий, взвешивания все «за» и «против», я всё же принял решение о применении ajax-подгрузки содержимого, чтобы прячущиеся блоки с flash не обновлялись вместе с остальным содержимым.
После некоторых поисков, в сети мной было обнаружено несколько решений. Выбрал первое и начал крутить его к создаваемому сайту. Так называемое «решение» — модули Page renderer + Asynchronous и соответствующая тема от того же производителя. Почему-то, сейчас они недоступны на drupal.org. Видимо, потому, что я был далеко не единственным, кто столкнулся с проблемами этого «решения». На первый взгляд, всё было здорово! Тему я прикрутил, модули установил, настроил. Всё заработало! И более того, заработало очень симпатично: при клике на ту или иную внутреннюю ссылку, появлялся легко настраиваемый по средствам CSS div, оповещающий о производимой загрузке. Я дорабатывал некоторые детали темы и уже когда всё было готово, принялся за наполнение сайта самой информацией (текст, фото и т.д.), но тут случилось самое печальное: отказались работать любые Wysiwyg-редакторы и некоторые, тоже важные для меня, модули. Их как-будто не было. Я, проведя за лэптопом несколько бессонных ночей, выкурив больше блока сигарет и выпив не один десяток литров кофе в поисках и устранении конфликта, был вынужден отказаться от всей этой «красоты» и приступить к поиску иного решения. И оно было найдено:
И «О, Боже!» — работает! Правда, красивый загрузочный элемент не появляется. Но это, думаю, тем кому важно, не сложно докрутить самостоятельно. Когда всё заработало, мне, казалось, остаётся только плясать от радости, но не тут-то было. Я забыл о замене стандартных шрифтов своими.
Я привык пользоваться модулем Cufon и преобразователем шрифтов в JS для него. Но в сей раз, выполнив все уже привычные действия, не получил никакого результата. Сначала, думал, что проблема в шрифте, но применив другой, уже протестированный, снова ничего не получил. Тогда в моей голове всплыло свойство @font-face.
Не долго копаясь в дебрях всемирной паутины, я нашел font-face генератор, работа с которым показалась мне крайне простой, что и насторожило. Но настороженность простотой, казалось, не нашла оправдание после теста сайта на кроссбраузерность в Adobe BrowserLab — даже всемирно «любимый» ослик работал как часы. Но, позвонив подруге с радостным известием и желанием похвастаться проделанной работой с просьбой протестировать сайт и скинуть мне скрин, был ошарашен, получив от неё письмо — в Опере, которой она пользовалась (10.50), не отображались шрифты, которые я так старательно прикручивал.
После некоторых раздумий и попыток найти подходящее решение, применив код:
— пришел к желаемому результату. Все, интересующие меня браузеры (в том числе и Opera, которой более тридцати процентов Российских пользователей моих проектов отдают предпочтение) отображали шрифты и весь другой контент так, как мне того хотелось.
Оставалось только отобразить PNG в IE6, для чего я воспользовался модулем для Drupal — PNG behave. И он выполнил свою работу достойно.
Если есть вопросы, могу детально рассказать о каждом из «тупиков» в которые меня загоняла та или иная технология, при создании сего проекта и предоставить ссылку на результат.
Задача
Каталог продукции на Drupal с flash-журналом в качестве «изюминки» и заменой стандартных шрифтов в меню и заголовках.
Поехали!
Обычно, при разработке дизайн-макета будущего сайта на Drupal для сокращения времени разработки, я использовал перелопаченную под себя тему Framework. И в этот раз, поступил аналогично предыдущим. Общая структура была разработана, нужно было прикрутить к ней flash.
Первый тупик. Flash в теме Drupal
Так как будущий сайт заказчика был расположен на моём хостинге без прав доступа к исходному коду, но с предоставлением прав Администратора Drupal, нужно было запретить изменение вставляемого flash-элемента. От привычного swftools пришлось отказаться.
После долгих поисков решения (так как привычная вставка flash в HTML, в теме Drupal не дала результатов), flash-объект был вставлен с помощью следующего кода:
<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>
— Код, конечно, стар как Мир и, возможно, не правильно построен, но всё заработало! А это главное. Но, так как вставленный элемент занимал достаточно много места относительно основного содержимого страницы и не планировал меняться, я предположил, что пользователю, после однократного ознакомления с данным flash-роликом, не захочется видеть его в дальнейшем. Чтобы не отвлекать посетителя, нужно было дать возможность «спрятать» элемент, но при этом, дать возможность вновь его посмотреть. В идеале, без перезагрузки страницы.
Решение пришло быстро. Применение простого JQueery и не сложного дополнительного JS-файла в теме:
- Устанавливаем в Drupal модули jQuery Update и jQuery UI
- В теме Drupal дописываем необходимые CSS (для блоков, которые мы хотим спрятать или показать)
- Добавляем в тему JS-файл, прячущий/показывающий эти элементы
- Создаём кнопочку, при нажатии на которую, будет выполняться то самое действие
На моё удивление, всё заработало и конфликтов не возникло. Но эффект не был, собственно говоря, достигнут. После перехода на другую страницу, всё повторялось с начала.
Второй тупик. Ajax и Drupal
После мучительных раздумий, взвешивания все «за» и «против», я всё же принял решение о применении ajax-подгрузки содержимого, чтобы прячущиеся блоки с flash не обновлялись вместе с остальным содержимым.
После некоторых поисков, в сети мной было обнаружено несколько решений. Выбрал первое и начал крутить его к создаваемому сайту. Так называемое «решение» — модули Page renderer + Asynchronous и соответствующая тема от того же производителя. Почему-то, сейчас они недоступны на drupal.org. Видимо, потому, что я был далеко не единственным, кто столкнулся с проблемами этого «решения». На первый взгляд, всё было здорово! Тему я прикрутил, модули установил, настроил. Всё заработало! И более того, заработало очень симпатично: при клике на ту или иную внутреннюю ссылку, появлялся легко настраиваемый по средствам CSS div, оповещающий о производимой загрузке. Я дорабатывал некоторые детали темы и уже когда всё было готово, принялся за наполнение сайта самой информацией (текст, фото и т.д.), но тут случилось самое печальное: отказались работать любые Wysiwyg-редакторы и некоторые, тоже важные для меня, модули. Их как-будто не было. Я, проведя за лэптопом несколько бессонных ночей, выкурив больше блока сигарет и выпив не один десяток литров кофе в поисках и устранении конфликта, был вынужден отказаться от всей этой «красоты» и приступить к поиску иного решения. И оно было найдено:
- Устанавливаем (в добавок к уже установленным jQuery Update и jQuery UI) модуль AjaxIT, не забывая обновить/установить необходимые библиотеки
- Настраиваем его соответственно темы сайта (там всё очень просто)
И «О, Боже!» — работает! Правда, красивый загрузочный элемент не появляется. Но это, думаю, тем кому важно, не сложно докрутить самостоятельно. Когда всё заработало, мне, казалось, остаётся только плясать от радости, но не тут-то было. Я забыл о замене стандартных шрифтов своими.
Третий тупик. Drupal + AjaxIT + Cufon = конфликт
Я привык пользоваться модулем Cufon и преобразователем шрифтов в JS для него. Но в сей раз, выполнив все уже привычные действия, не получил никакого результата. Сначала, думал, что проблема в шрифте, но применив другой, уже протестированный, снова ничего не получил. Тогда в моей голове всплыло свойство @font-face.
Четвертый тупик. @font-face и Opera
Не долго копаясь в дебрях всемирной паутины, я нашел font-face генератор, работа с которым показалась мне крайне простой, что и насторожило. Но настороженность простотой, казалось, не нашла оправдание после теста сайта на кроссбраузерность в Adobe BrowserLab — даже всемирно «любимый» ослик работал как часы. Но, позвонив подруге с радостным известием и желанием похвастаться проделанной работой с просьбой протестировать сайт и скинуть мне скрин, был ошарашен, получив от неё письмо — в Опере, которой она пользовалась (10.50), не отображались шрифты, которые я так старательно прикручивал.
После некоторых раздумий и попыток найти подходящее решение, применив код:
@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');
}
— пришел к желаемому результату. Все, интересующие меня браузеры (в том числе и Opera, которой более тридцати процентов Российских пользователей моих проектов отдают предпочтение) отображали шрифты и весь другой контент так, как мне того хотелось.
Оставалось только отобразить PNG в IE6, для чего я воспользовался модулем для Drupal — PNG behave. И он выполнил свою работу достойно.
Если есть вопросы, могу детально рассказать о каждом из «тупиков» в которые меня загоняла та или иная технология, при создании сего проекта и предоставить ссылку на результат.
