Может возникнуть закономерный вопрос: зачем изобретать велосипед и почему бы не использовать обычный rsync для копирования данных напрямую в davfs2? Ответ простой: это… не работает как надо. Во всяком случае, с Яндекс.Диском, и если запускать процедуру на роутере под управлением OpenWrt.

То ли из-за особой неторопливости Яндекс.Диска, то ли из-за особенностей davfs2, но при попытке копирования большого количества файлов (а иногда такое случается и с единичными файлами!), большая их часть оказывалась в каталоге lost+found, служащем для локальных копий файлов, загрузка которых в WebDav провалилась. И всё это несмотря на достаточный объем выделенного кэша, стандартные настройки davfs2 для повторной загрузки файлов в случае ее неудачи, и довольно широкого канала связи.

Итак, для самописного и более надежного бэкапера в WebDav нам понадобятся:

1. davfs2 – стандартный пакет из репозитория OpenWrt;
2. cadaver – модифицированная версия утилиты для прямого копирования файлов в WebDav из нашего архива;
3. php-cli – стандартный интерпретатор PHP, при помощи которого мы сгенерируем набор команд для cadaver’а.

Добавленные в cadaver патчи позволяют при помощи нового ключа -F пропускать проверку подлинности сертификатов (а под OpenWrt у нас все используемые в WebDav SSL-сертификаты считаются подозрительными и требуют ручного подтверждения), а также указывать с помощью ключа -n нестандартный путь к хранилищу паролей для автоматической авторизации на WebDav-сервере. Внесенные изменения позволяют создать для cadaver файл с набором команд, которые будут выполняться автоматически без участия человека.

Теперь обратим внимание на скрипт phpsync.php.

У этого скрипта две задачи:
Во-первых, он отвечает за “обратную синхронизацию” – в скрипте производится проверка, все ли находящиеся в WebDav-хранилище файлы продолжают находиться на локальном диске. В случае обнаружения в удаленном хранилище файлов, которые были локально удалены, скрипт удалит их и из WebDav – обычным вызовом unlink() на смонтированном разделе davfs2.
Во-вторых, скрипт генерирует набор команд для cadaver‘а для загрузки локально измененных или отсутствующих в WebDav файлов в удаленное хранилище.
В скрипте есть ряд параметров, которые нужно настроить. Так, параметром $outfile определяется путь к файлу, в который будет записан сгенерированный набор команд, в параметре $remotebase необходимо указать точку монтирования davfs2. Также в нем указывается адрес WebDav сервера, к которому должен подключаться cadaver – по умолчанию это https://webdav.yandex.ru. Затем следует указать каталоги, которые требуется синхронизировать, например:

phpsync("/srv/content","/backup/content");
phpsync("/srv/otherdir","/backup/otherdir");

Так будут сгенерирован набор команд для отражения локальных каталогов /srv/content и /srv/otherdir в удаленные WebDav-каталоги /backup/content и /backup/otherdir соответственно. Обратите внимание – удаленные пути указываются относительно корня WebDav-диска, без привязки к локальной точке монтирования davfs2!

После этого следует создать парольный файл для cadaver. Это обычный текстовый документ, содержающий строку следующего вида:

machine webdav.yandex.ru login вашлогин password вашпароль

Наконец, создаем ash-скрипт, который мы будем вызывать через кронтаб:

#!/bin/ash
/usr/bin/php-cgi -f /srv/phpsync.php

if [ -e "/var/.phpsync.list" -a $(wc -l "/var/.phpsync.list" | awk '{print $1;}') -gt 2 ]
then
        /usr/bin/cadaver -F -r "/var/.phpsync.list" -n "/srv/auth.rc"
fi

Подставляем ваши значения:

• /srv/phpsync.php — путь к PHP-скрипту;
• /srv/auth.rc — путь к парольному файлу;
• /var/.phpsync.list — путь к файлу с набором команд для cadaver.

Не забываем сделать скрипт исполняемым, выполнив команду chmod +x на данном файле. Теперь мы можем проверить работоспособность копирования, запустив этот скрипт. В терминал при этом будет выведен результат работы PHP-генератора, а также будет показан процесс выполнения задания cadaver’ом.

Если все завершилось успешно – теперь можем добавить автоматический вызов данного скрипта через кронтаб в ночное время и более не беспокоиться о создании резервных копий.

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

• Энергетические решения для дома
  • Дизельные установки
  • Ветряные генераторы
  • Микроядерные установки
• Энергетические решения для офиса
  • Дизельные установки
  • Микроядерные установки
  • Термоядерные блоки

Причина проблемы состоит в том, что WordPress не допускает существование одинаковых ярлыков, даже если они находятся в разных ветвях иерархии. Поэтому, если при создании данной структуры не заполнять вручную ярлыки (“slugs”), автоматически получим такую структуру ярлыков:

• /категории/энергетические-решения-для-дома
  • /категории/энергетические-решения-для-дома/дизельные-установки
  • /категории/энергетические-решения-для-дома/ветряные-генераторы
  • /категории/энергетические-решения-для-дома/микроядерные-установки
• /категории/энергетические-решения-для-офиса
  • /категории/энергетические-решения-для-офиса/дизельные-установки-энергетические-решения-для-оф%0с
  • /категории/энергетические-решения-для-офиса/микроядерные-установки-энергетические-решения-дл%3bf~
  • /категории/энергетические-решения-для-офиса/термоядерные-блоки

Стандартный алгоритм пытается автозаполнить ярлыки категорий, исходя из их названий. Когда названия повторяются – WordPress пытается приписать к ярлыку название его родительской категории, создав тем самым более уникальное имя.

Почему сгенерированные названия получаются нерабочими? – Дело в том, что в базе данных на длину поля ярлыка выделено 200 символов. В принципе, это довольно большое число, которого должно было хватить с запасом в том числе и на имя родительской категории. Однако, как выяснилось, это верно лишь при использовании латинских символов. В базе данных ярлык хранится уже в URL-encoded форме, что при учете использования UTF-8 приводит к тому, что одна русская буква заменяется на последовательность из 6 символов. В результате, фактически в этом поле умещается название, в котором не более 33 русских букв. И, как выяснилось, никакой проверки этого факта в WordPress не предусмотрено: при записи слишком длинного ярлыка в базу просто пишется та его часть, которая уложилась в 200 символов. А при учете, что на одну русскую букву в кодированной форме приходится 6 символов, получаем, что одна из букв оказывается разорвана пополам. Как итог – битая нерабочая ссылка.

Для исправления этой ситуации можно пропатчить файл wp-includes/taxonomy.php:

--- a/taxonomy.php	2014-02-24 13:14:30.649795666 +0400
+++ b/taxonomy.php	2014-02-25 11:23:51.443231774 +0400
@@ -2436,6 +2436,15 @@
  * @param object $term The term object that the $slug will belong too
  * @return string Will return a true unique slug.
  */
+function truncate_slug_to_200_chars($slug, $limit = 200) {
+	while (strlen($slug) >= $limit)
+	{
+		$slug = rawurldecode($slug);
+		$slug = mb_substr($slug,0,-1);
+		$slug = rawurlencode($slug);
+	}
+	return $slug;
+}
 function wp_unique_term_slug($slug, $term) {
 	global $wpdb;
 
@@ -2451,6 +2460,10 @@
 			if ( is_wp_error($parent_term) || empty($parent_term) )
 				break;
 			$slug .= '-' . $parent_term->slug;
+			// [kreon] slugs are url-encoded and limited to 200 chars
+			// if this limit is exceeded then non-ascii urlencoded data will probably break
+			if ( strlen( $slug ) >= 200 )
+				$slug = truncate_slug_to_200_chars( $slug );
 			if ( ! term_exists( $slug ) )
 				return $slug;
 
@@ -2468,6 +2481,10 @@
 
 	if ( $wpdb->get_var( $query ) ) {
 		$num = 2;
+		// [kreon] same thing here. if result exceeds 200 chars, then things may break
+		// make sure we have free space for 3 additional chars to hold '-num' parameter
+		if ( strlen( $slug ) >= 197 )
+			$slug = truncate_slug_to_200_chars ( $slug, 197 );
 		do {
 			$alt_slug = $slug . "-$num";
 			$num++;

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

Патч не исправит уже имеющиеся поломанные ярлыки – их необходимо пересохранить повторно вручную.

$linecnt = exec("wc -l filename.txt");

А что делать, если PHP работает на компьютере под управлением Windows? В Windows-системах таковой утилиты напрочь нет. Рассмотрим возможные альтернативы:

1. Для небольших файлов, объем которых не превышает десятков килобайт, достаточно быстрым вариантом является загрузить все содержимое файла в память и посчитать количество получившихся строк:

$linecnt = count(file("filename.txt"));

Этот способ не подходит для больших файлов, т.к. таким образом можно легко зажевать всю доступную PHP память.

2. Для файлов чуть большего размера можно использовать циклический перебор строк и подсчитывать количество итераций до окончания файла:

$f = fopen("filename.txt",'r');
$linecnt = 0; while (fgets($f)) $linecnt++;
fclose($f);

Т.к. файл не загружается в память целиком, то расход памяти в данном подходе значительно меньше.

3. Для больших файлов можно использовать внешние средства. На просторах сети можно отыскать linux-утилиту wc, откомпилированную с Cygwin, и запустить ее в Windows. А можно обойтись и без установки стороннего софта – встречайте нецелевое использование стандартной утилиты find.exe (в сочетании с type.exe):

$linecnt = exec('type "filename.txt" | find /c /v ""');

При помощи type производится вывод на stdout содержимого файла, а find подсчитывает количество непустых строк. Необходимо обратить внимание, что утилита type вообще никаким образом не понимает относительных путей, поэтому для передачи пути к файлу не из текущего каталога необходимо воспользоваться функцией realpath().

Пример функции, позволяющий подсчитывать количество строк в крупных файлах как при запуске под Windows, так и под Linux:

function linecnt($path)
{
	if (strtoupper(substr(PHP_OS, 0, 3)) === 'WIN')
		return (int)exec('type "'.realpath($path).'" | find /c /v ""');
	else
		return (int)exec('wc -l '.$path);
}

PS: Интересная историческая справка о том, по какой причине find.exe может выискивать в файле непустые строки путем сравнения с “” (пустой строкой).

Простым решением подобной проблемы является возможность запросить XML-данные каким-либо другим средством, предусматривающим возможность настройки таймаутов, после чего передать полученную строку в simplexml_load_string().

Использование file_get_contents+simplexml_load_string

При использовании file_get_contents() для запроса удаленных данных имеется возможность указания ряда параметров при помощи т.н. контекста, создаваемого командой stream_context_create(). Например, указать предельное время ожидания HTTP-запроса можно следующим образом:

$opts = stream_context_create( array(
		'http' => array(
			'timeout' => 1
			)
		) );
$xmlstr = file_get_contents($url, false, $opts);
$xml = @simplexml_load_string($xmlstr);

Либо короче:

$xmlstr = file_get_contents($url, $false, stream_context_create(array('http' => array('timeout' => 1))));
$xml = @simplexml_load_string($xmlstr);

Этот способ работает хорошо до тех пор, пока мы не сталкиваемся с таймаутом при запросе доменного имени $url с DNS. В этом случае выставленный в контексте параметр ‘timeout’ в обработке не участвует и время ожидания по-прежнему может быть слишком высоко.

Использование cURL+simplexml_load_string

Применение библиотеки cURL хотя и требует фактического наличия означенной библиотеки и более громоздко при использовании, но представляет более широкие возможности по настройке параметров соединения:

$ch = curl_init($url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_TIMEOUT, 1);
$xmlstr = curl_exec($ch);
curl_close($ch);
$xml = @simplexml_load_string($xmlstr);

При этом параметром ‘CURLOPT_TIMEOUT’ определяется не только время выполнения запроса, но целиком время выполнения всех операций cURL, включая запросы к DNS. В PHP начиная с версии 5.2.3 поддерживается также параметр ‘CURLOPT_TIMEOUT_MS’, позволяющий указать длительность таймаута в миллисекундах.

Запуск под Windows?

В случае использования apache+php в системе под управлением MS Windows даже при использовании cURL мне не удалось найти никакой действительно работоспособной возможности для обхода длительного таймаута при сбое DNS на стороне локального сервера.

Интересно также, что в принципе запуск модуля cURL (php_curl.dll) в Windows-версии apache по умолчанию происходит с ошибкой, которая в error.log на стороне apache выглядит так:

PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\\php5\\ext\\php_curl.dll' - \xcd\xe5 \xed\xe0\xe9\xe4\xe5\xed \xf3\xea\xe0\xe7\xe0\xed\xed\xfb\xe9 \xec\xee\xe4\xf3\xeb\xfc.\r\n in Unknown on line 0

Либо, при переводе в человеческий вид, так:

PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\\php5\\ext\\php_curl.dll' - Не найден указанный модуль.\r\n in Unknown on line 0

Это, конечно, на редкость информативно и предоставляет возможности для полета фантазии на тему того, о каком именно модуле идет речь. Интересно отметить тот факт, что при запуске php -i модуль cURL загружается корректно, а проблема возникает только при запуске из-под apache.

В описываемом случае проблема отсутствующего модуля решилась путем копирования файлов ‘libeay32.dll’ и ‘ssleay32.dll’ из каталога C:/php5 в каталог C:/apache/bin.

Транслитерация

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

Реализация проста:

// массив замен
$converter = array('а' => 'a', 'б' => 'b', 'в' => 'v', ...);
// быстрая замена
$string = strtr($string, $converter);

Граничные эффекты

Если выбор названия веб-ссылки лежит на пользователе, то не стоит ожидать от него чудес разумности. Избавиться от пробелов, символов табуляции и прочих бессмысленных символов в начале и конце строки поможет обычная фунция trim:

$string = trim($string);

Уничтожение спецсимволов

В некоторых случаях при автоматическом составлении заголовков в них попадают различные знаки пунктуации, слэши и другие символы, которым нечего делать во фрагменте URL. Их необходимо вырезать или заменять на нейтральные символы. Также следует поступать и с символами пробела. Одним из вариантов может быть замена на дефисы любых символов, не являющихся цифрами или латинскими буквами. При этом в случае двух замен подряд заменяющие дефисы должны склеиваться.

Это реализуется одной строкой при помощи regex’а:

$string = preg_replace('/[^a-z0-9]+/', '-', strtolower($string));

Эта строка также переводит все символы в нижний регистр. Отметим, что после выполнения данной замены следует проверять, не схлопнулась ли вся исходная строка в один единственный дефис. Это означает, что все символы в исходной строке не были цифрами или латинскими буквами.

Подчеркивания или дефисы

Один из не самых однозначных вопросов заключается в том, какой символ использовать для разделения слов в URL – подчеркивание или тире (дефис). В целом, этот вопрос фактически относится лишь к тому, как поисковые системы станут интерпретировать используемые на вашем сайте ссылки. А вот интерпретируют данные поисковые системы эти разделители по-разному.

Так, например, для поисковика MS Bing дефисы и подчеркивания в качестве разделителей неразличимы. А вот поисковик Google, согласно заявлению его представителей, считает дефисы разделителями, а подчеркивания просто игнорирует. Так, выражение “erinome-lane” в адресной строке для Google преобразуются в “erinome lane”, а выражение “erinome_lane” будет восприниматься слитно – “erinomelane”.

Кратко: на настоящий момент в URL рекомендуется использовать тире вместо подчеркиваний.