ЗНАМЯ ЗАНАМИ

Случайно скачал Adobe Muse beta3. Muse — кодовое название инструмента для создания сайтов людьми. далекими от кода HTML, не говоря уж об более серьезных вещах. Работает это все на технологии Adome Air, то есть кроссплатформенность в Mu присутствует.

Работа начинается с создания нового сайта и назначения общих свойств. Ширина страницы (контентной части) задается в точках, без вариантов.

Структура сата (закладка Plan) представлена в виде многоуровневого «дерева», страницы добавляются слева-справа (братья и сестры) и снизу (отпрыски, то есть дети). Сначала будет полезно отредактировать стартовые шаблоны — вставить логотип, навигацию и прочие общие для всех страниц элементы.

Design — режим редактирования шаблонов и самих страниц. Полнейший WYSIWYG, все свойства объектов управляются выбором значений, пунктов, галочек, величин. Muse знает стандартный набор современных фишечек — скругленные углы, всплывающие состояния (rollover, mousedown etc.), модные градиенты и содержит набор готовых к использованию виджетов — галерея, слайдшоу, вкладки, динамически меняющиеся блоки с текстом и т.п.

С Preview все понятно — тут можно оценить свое творение с точки зрения браузера. Работает? Нормально выглядит? Едем дальше, к публикации.

Автоматически можно опубликовать получившийся сайт на хостинг Busyness Catalyst, пока так. Ничего хорошего о нем сказать не могу — по-моему дорого и глупо (от $19 в месяц). Гораздо разумнее экспортировать сайт в виде набора HTML файлов.

Файлы документов с русскими названиями Muse называет по-русски, равно как и соответствующие им css. В итоге в коде встречаются такие неудобочитаемые вещи: css/%d0%bd%d0%be%d0%b2%d0%be%d1%81%d1%82%d0%b8.css. Ну по идее никто из пользователей Muse кодом интересоваться не должен. Использование jQuery и «плужков» к нему тоже должно остаться незаметным.

Вердикт: отличный вариант для небольших организаций, для создания маленьких и простых сайтов. Эдакий Frontpage 21 века.

Категории: Журнал
Метки: muse, дизайн

За последние 3-4 недели успел поставить Drupal 7 и Drupal Commerce, поковырять его, отложить в сторону, поставить Ubercart 2 в лице адской сборки Openstore, поковыряться… и снова вернуться к Drupal Commerce. Возможно, это не последняя итерация.

Если коротко — Ubercart хорош для задач, которые он выполняет “из коробки”. Если эта коробка называется Openstore, то многим больше ничего не потребуется. Я с неделю занимался обратным процессом — выбрасывал из сборки ненужные мне модули. Закончилось тем, что оставшееся не выглядело сколько-нибудь лучше Drupal Commerce (для моей задачи).

Drupal Commerce — гол, как сокол. Я устанавливал сборку (профиль) Commerce Kickstart. Доставки нет, нужен отдельный модуль. Почти для всего нужен отдельный модуль, которого или вообще не существует, или он находится на dev, alpha, beta стадиях (вялой) разработки.

Ладно, перестаю ныть, начинаю похваляться делиться информацией. Задача была простая — добавить в Drupal Commerce два способа доставки — курьером (за фиксированную сумму) и “самовывоз”, который никакая не доставка, но выбор такой клиенту дать нужно. Пока пытаюсь сделать все правильно, используя модуль Commerce Shipping. Половину дела сделал легко — курьерскую доставку можно реализовать на основе модуля Flat Rate, простого и понятного — фиксированная цена доставки. Дальше начались трудности.

Модуль Commerce Shipping добавляет новый профиль (user profile) для пользователя и соответствующую панель (pane) на страницу расчета (checkout). Процедура оформления покупки в Drupal Commerce многостраничная, панели можно передвигать между страницами произвольно. По-умолчанию панель с адресом доставки (shipping profile) помещается на самую первую страницу. Для многих это логично — от адреса доставки могут зависеть доступные способы доставки или способы оплаты. У меня ситуация обратная — город известен заранее, стоимость доставки тоже. Остается реализовать “самовывоз”, то есть отключить панель адреса доставки (shipping profile) в случае выбора соответствующего способа доставки.

1. Помещаем панель shipping на первой странице (checkout), панель shipping profile переносим на вторую (review). Так мы принуждаем клиента выбрать способ доставки и меешм шанс не спрашивать адрес в случае самовывоза.

2. Создаем новый модуль (это за пределами заметки) и добавляем в него свой хук для переопределения панелей модуля commerce checkout.

/*
 * Hook hook_commerce_checkout_pane_info_alter($checkout_pane)
 */
function mymodule_commerce_checkout_pane_info_alter(&$checkout_pane) {
	global $user;
	// $checkout_pane на самом деле содержит массив из всех панелей...
	foreach($checkout_pane as $pane_name => &$pane_data) {
		// …нам нужна только она из них — панель с профилем доствки
		if($pane_name == 'customer_profile_shipping' && $pane_data['enabled']) {
			// загружаем текущий заказ
		    $order = commerce_cart_order_load($user->uid);
		    // $order->data был найден с помощью dsm()
		    // в нем не было ничего за исключением 'shipping_method' со строкой
		    // rules_pick_up это ID склонированного способа доставки flat rate
			if($order->data['shipping_method'] == 'flat_rate|rules_pick_up') {
				// панель была изначально включена в админке, отключаем ее
				$pane_data['enabled'] = 0;
			}
		}
	}
}

В итоге получается то, что задумывалось — если на первом этапе оформления выбран некий способ доставки (самовывоз), то на на следующем у клиента не попросят ввести адрес доставки.

У меня нет никакой уверенности, что это правильный и эффективный способ выполнить задуманное. Глядя на Drupal Commerce вообще, я был уверен, что найду способ сделать подобное с помощью Правил (Rules), но готовых “действий” не нашлось (панели не контролируются правилами), а приделать такое сбоку мне оказалось не по силам.

Если кто-то знает более изящные способы справиться с задачей — намекните. Проблема с Commerce в том и состоит, что документации не очень много, примеры в основном примитивные, знающие люди неохотно делятся информацией (заняты они), а основной шум создают недоучки, вроде меня.

Категории: Журнал
Метки: drupal, ecommerce

Проверьте свои Wordpress блоги — в платных и бесплатных темах оформления часто используется скрипт для генерации картинок timthumb.php, в котором обнаружили уязвимость — злоумышленник может загрузить на сайт с дырявым скриптом все, что ему заблагорассудится.

Измененный timthumb.php можно скачать тут.

Можно ничего не скачивать, просто открыть файл и удалить переменную $allowedSites. Разумеется, если вы не пользуетесь удаленной загрузкой, в которой вся проблема и кроется.

Суть «дырки» в том, что скрипт позволяет скачивать файлы с удаленных серверов, белый список настраивается в параметрах, но проверяется по ходу выполнения неверно — если разрешено загружать картинки с flickr.com, то и webshell с какого-нибудь flickr.com.hackersplace.com тоже можно загрузить.

Подробно об уязвимости timthumb.php пишет в своем блоге Mark Maunder фром хиз харт ин инглиш.

Категории: Журнал
Метки: wordpress, безопасность