Самое время, похоже — все желающие уже сделали себе сайты, если не брать в расчет новый бизнес. Сейчас пора их обновлять, поскольку большинство сайтов компаний, далеких от IT и электронной коммерции, выглядят ужасно. Я как-то поискал в Google “road construcеion contractor” — с первой же страницы списка начинается уныние, а местами и ужас. Я не пробовал, но вполне уверен, что открывать такие сайты с iPad или iPhone не стоит. Анонс книги я не особо изучал, но глава об оптимизации сайтов под планшеты и смартфоны там обязана быть.

А сегодня Smashing Magazine прислал предложение запечатлеть свое имя в печатной версии книги. Сомневался я недолго.

Никакого смысла это предприятие не имело, поскольку я купил электронную версию книги — так дешевле, да и доставку ждать не надо. Короче, ни себе посмотреть, ни друзьям показать.

Parallels и тут все переделали на свой лад. Очевидно, с целью облегчить жизнь мэйнстриму. Попутно осложнив жизнь разным извращенцам.

В панели по пути Modules → Watchdog обнаруживается жестко заданный список сервисов, которые Plesk умеет мониторить. Добавить свой можно так.

1. Нужно добавить запись в таблицу MySQL psa.module_watchdog_service. Формат простой, нужно ввести название и описание, команду для запуска и остановки, путь к pid файлу. Там по аналогии разобраться несложно.

2. Далее, в папке /usr/local/psa/etc/modules/watchdog/service.tpl.d нужно создать файл с названием сервиса. Формат файла на примере nginx.

check process nginx
    with pidfile "/var/run/nginx.pid"
    start = "<nginx_start>"
    stop = "<nginx_stop>"
    if failed host <default_apache_ip> port 80 send "GET / HTTP/1.1\r\nHost: <default_apache_ip>\r\n\r\n" expect "HTTP/1\.[01x] [1-4][0-9]{2} .*\r\n"
    with timeout <nginx_connection_timeout> seconds then restart
    if <nginx_timeout_restarts> restarts within <nginx_timeout_cycles> cycles then timeout
    every <nginx_cycles> cycles
    mode <nginx_mode>

Кстати сказать, еще один шаблон мне тоже потребовалось поменять — после установки nginx и изменения порта для apache нужно скорректировать порт apache в файле /usr/local/psa/etc/modules/watchdog/monitrc.tpl. Из этого же файла я взял переменную <default_apache_ip> — в таблице она не хранится, где-то жестко зашита в Plesk.

Править нужно именно шаблоны, сразу складывать файлы в service.d и править monitrc не стоит — Plesk их перепишет.

3. Все, после перезапуска Watchdog Plesk создаст и обновит файлы и будет мониторить добавленные сервисы. Как из командной строки перезапустить Watchdog я не знаю, поэтому просто отключил/включил мониторинг в панели управления (Modules → Watchdog → Disable/Enable).

Забавно — моя лицензия на Plesk не позволяет управлять Tomcat, но я его поставил самостоятельно и использую чисто для себя. Так вот, штатный Watchdog не может мониторить Tomcat, соответствующая запись отключена, но добавленная по аналогии с nginx конфигурация по имени Tomcat5 вполне работает.

Необходимо и достаточно: Drupal 7, Views 3, модуль views data export, drush, пара часов времени.

1. Создаем представление (view) для вывода списка позиций (запчастей). Тип представления — data export, формат XML. Стандартный XML, который генерирует Viws Data Export не подходит под требования ИРР, надо переопределять шаблон представления. Используем drush views-data export view-name display-id adverts.xml для создания файла с предлложениями.

2. Копируем display, нам потребуется еще список картинок. Удаляем все поля, за исключением imagefield, формат вода меняем на txt, выводим результаты (имена файлов) в pictures.txt с помощью того же drush. Этот список будет использоваться для создания архива с картинками. Имеет смысл, если выгружаются не все объявления и, соответственно, не нужны все имеющиеся картинки.

3. Собираем shell скрипт, который будет запускать 2 выгрузки (views data export), собирать и складывать в архив картинки, загружать полученные файлы adverts.xml и pictures.zip по FTP на сервер ИРР.

TODO: В скрипте неплохо бы иметь проверки кодов завершения. Не помешает отправка уведомлений на email. В интерактивном режиме и так сойдет, но есть идея добавить cron job и забыть про него.

А еще у них появилась статистика в реальном времени — показывает кто откуда пришел, по какому поисковому запросу, где живет и что собственно, в данный момент просматривают.

Из ближайших бесплатных Open Source аналогов «для параноиков» могу назвать Piwik, его нужно устанавливать на свой сервер, тратить ресурсы, настраивать, обновлять. Зато его можно «заточить» под свои нужды, если они отличаются от типовых, охваченных Google Analytics.

А большинство клиентов все равно просят «влепить счетчик куда-нибудь снизу», им так проще. Мало кто готов анализировать статистику, точки входа, маршруты, сопоставлять с конверсией, делать выводы, оптимизировать сайт. Еще меньше желающих за это платить. Зато всем хочется «на первое место в Яндексе» по каким-нибудь надуманным запросам, которые проскакивают раз-другой в месяц, это в лучшем случае. И логотип побольше.

Что не радует — 4 из обладателей IE пользуются версией 6.0. Анафема!

Дано: Drupal 7.8, тип содержимого с единственной ссылкой (link field).

Задача: сделать так, чтобы ссылка отображалась в виде /node/*nid*/goto, а при нажатии перекидывала посетителя на адрес, фактически содержащийся в ссылке (link url).

Потребуются: модули redirect, custom formatters, rules.

Custom Formatters можно заменить на шаблон поля. Для примера field–field-url.tpl.php

<?php foreach ($items as $delta => $item) : ?&gt
<a rel="nofollow"
     title="<?php print $element['#object']->field_url['und'][0]['title']; ?>"
     href="/node/<?php print $element['#object']->nid;?>/goto">LINK TEXT</a>
<?php endforeach; ?>

Текст ссылки можно заменить на любое значение из $element['#object'], это все данные по текущему документу (node).
Custom formatter слегка удобнее использовать и оперативно редактировать. У меня получился такой код для link_field:

// Custom formatter for a link_field.
$node = $variables['#object'];
foreach (element_children($variables['#items']) as $delta) {
  $item = $variables['#items'][$delta];

  $source = "Перейти по ссылке";
  $destination = 'node/'.$node->nid.'/goto';

  return l($source, $destination, array('html' => false, 'attributes'=>array('rel'=>'nofollow', 'title'=>'Перейти в по ссылке '.$node->title, 'class'=>array('my-link-field'))));
}

Затем для нужного view mode меняем вывод нужной ссылки (Структура — Типы материалов — ВашТип — Управление отображением). Все, ссылку заготовили, но она пока ведет в никуда. Точнее, на ту же страницу, что и /node/*nid*, как любая ссылка на /node/*nid*/whatever.

Правило (Rule) настраиваем на событие “После редактирования существующего документа” и “После сохранения нового документа”, чтобы не пропустить возможные изменения ссылки. Отфильтровываем условиями тип материала, если необходимо. Действие будет типа PHP code (модуль PHP нужно заранее включить). Код примерно такой, взят почти полностью из тестов, идущих с модулем Redirect.

$redirect_defaults = array(
          'uid' => $node->uid,
          'status_code' => 302,
        );
    $redirect_path = $node->field_url['und'][0]['url']; // real URL to redirect to
    $source_path = 'node/'.$node->nid.'/goto'; // fake url (tweak to your link field custom formatter)
    redirect_delete_by_path($source_path); // delete existing redirects to avoid PDO errors
    $source_parsed = redirect_parse_url($source_path);
    $redirect['source'] = $source_parsed['url'];
    if (isset($source_parsed['query'])) {
      $redirect['source_options']['query'] = $source_parsed['query'];
    }

    $redirect_parsed = redirect_parse_url($redirect_path);
    $redirect['redirect'] = $redirect_parsed['url'];
    if (isset($redirect_parsed['query'])) {
      $redirect['redirect_options']['query'] = $redirect_parsed['query'];
    }
    if (isset($redirect_parsed['fragment'])) {
      $redirect['redirect_options']['fragment'] = $redirect_parsed['fragment'];
    }

    $redirect = (object) $redirect;
    redirect_object_prepare($redirect, $redirect_defaults);
    redirect_save($redirect);

Теперь после создания или изменения документа будет выполняться правило, которое создает перенаправление с локального адреса /node/NNN/goto на адрес, указанный в поле field_url документа с идентификатором NNN.

Если контент уже был, то нужно «передернуть» все материалы нужного типа — сфабриковать событие, по которому сработает правило. Я для этого использовал views bulk operations (VBO).

Вероятно, не самый простой и изящный способ, но вполне прозрачный и рабочий, по-моему.

Дано: CentOS 5 (64bit), Plesk 10.3, Apache 2.

Нужный результат: Nginx отсылает статику, Apache все остальное (php в основном).

1. Установка nginx на CentOS 5 (без фанатизма).

# rpm -ihv http://centos.alt.ru/repository/centos/5/x86_64/centalt-release-5-3.noarch.rpm
# yum install nginx
# chkconfig –level 35 nginx on

Меняем порт Apache по инструкции Parallels (Plesk 10.2, на 10.3 сработало)

# mysql -uadmin -p`cat /etc/psa/.psa.shadow` -D psa -e'replace into misc (param, val) values ("http_port", 8080)'
# mysql -uadmin -p`cat /etc/psa/.psa.shadow` -D psa -e'replace into misc (param, val) values ("https_port", 8080)'

Здесь 8080 — новый порт. Аналогичный указываем в /etc/httpd/conf/httpd.conf (Listen 80 → Listen 8080).
Ахтунг! В документации Plesk 10 есть тема про правку шаблона /usr/local/psa/admin/conf/templates/default/domain/domainVirtualHost.php и замену $VAR->server->webserver->httpPort на нужный порт — делать это не надо и очень вредно, Apache ругается: VirtualHost x.x.x.x:8080 overlaps with VirtualHost x.x.x.x:8080, the first has precedence, perhaps you need a NameVirtualHost directive).

# mysql -uadmin -p`cat /etc/psa/.psa.shadow` -D psa -e'replace into misc (param, val) values ("http_port", 8080)'
# mysql -uadmin -p`cat /etc/psa/.psa.shadow` -D psa -e'replace into misc (param, val) values ("https_port", 8080)'
# /usr/local/psa/admin/bin/httpdmng --reconfigure-all

У более ранних версий Plesk (до 9.5) была отдельная команда на этот случай (websrvmng –set-http-port –port=8080).

Дальше берем в этом малость устаревшем руководстве нужные файлы (тыц) и распаковываем куда-нибудь в рабочую папку. Копируем nginx.conf → /etc/nginx/nginx.conf и proxy.conf → /etc/nginx/proxy.conf — они подхачены для использования с Plesk.

UPDATE: По ссылке выше файлы не актуальны для Plesk 10 — там жестко зашито расположение корневых папок (document root) для доменов и поддоменов. В новом Плеске их можно произвольно переносить или переименовывать через панель управления, а сами данные хранятся в базе. Здесь исправленная версия generate_nginx_conf.sh для Plesk 10 и сопутствующие шаблоны, в которых тоже есть изменения. Не проверял и пока не менял ничего в настройке списков рассылки, webmail и sitebuilder.

Запускаем sh generate_nginx_conf.sh — скрипт выбирает из базы все домены и поддомены и создает в каждой папке /var/www/vhosts/*/conf/nginx.conf. Если порт для Апача выбран не 8080, то предварительно нужно поправить шаблоны template_dom.conf, template_subdom.conf (там порт жестко зашит).

Порт, на котором работает Apache (8080 или другой) нужно открыть в iptables. Делать это пришлось через панель управления, команда (iptables -A INPUT -p tcp –dport 8080 -j ACCEPT) не лечит.

Готово, вроде, перезапускаем httpd и nginx.

Проблемы по ходу дела — не запускался nginx, пришлось увеличивать server_names_hash_max_size 1024 (было 512) и server_names_hash_bucket_size 128 (было 64). Это /etc/nginx/nginx.conf.

TODO: После добавления домена в Plesk нужно создать конфиг для nginx. Скрипт generate_nginx_conf.sh каждый раз перезаписывает настройки виртуального хоста (/var/www/vhosts/*/nginx.conf) из шаблонов заново (нужно оставлять измененные).

UPDATE: Повесил скрипт создания/обновления nginx.conf на события в Plesk: Website created/updated/deleted (аналогично для Subdomain и Domain alias). Теперь конфигурация для nginx создается/обновляется автоматически.

Осталось одно желание — иметь возможность настраивать конфигурацию для каждого сайта отдельно. Сейчас все конфиги переписываются из шаблона и похожи как однояйцевые близнецы. Можно встроить проверку существования файла и не трогать его (только создавать новые), но это плохой выход, поскольку все поддомены/синонимы настраиваются в одном файле — после добавления алиаса или поддомена надо будет руками править nginx.conf.

Делать подключение еще одного файла на каждый домен/поддомен тоже бессмысленно — nginx не принимает переопределение, то есть 2 одинаковых директивы (location /, например) в «главном» и «подключаемом» конфигах сделать не получится, а без этого затея теряет смысл. Надо какой-то ум применить, пока не придумал ничего.

http://wiki.mediatemple.net/w/%28dv%29:Configure_nginx_as_reverse_proxy_web_server

http://www.grafxsoftware.com/faq.php/HOW-TO-configure-PLESK-with-NGinx-proxy-reverse/1/1/

http://kb.parallels.com/11232

http://www.x83.net/plesk-10-nginx-reverse-proxy-configuration-in-front-of-apache/

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

Структура сата (закладка 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 века.

Если коротко — 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 в том и состоит, что документации не очень много, примеры в основном примитивные, знающие люди неохотно делятся информацией (заняты они), а основной шум создают недоучки, вроде меня.

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

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

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

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