@sim3x на сколько мне помниться в nginx не применяется динамическая линковка, собственно именно поэтому при подключении нового модуля его приходится каждый раз перекомпилировать (в отличие от php). И Игорь даже в рассылке писал, что динамической не будет хотя запросы на такую фичу были.
@teet есть, но написаны они не для nginx, а для конкретного компилятора. Можно вообще скомпилить под конкретное системное окружение, но авторы пакета так гарантированно не делали.
@MasterF там одно ядро и часть модулей общая. У каждого сайта своя тема оформления которая по структуре одинакова, но на каждом сайте своя цветовая схема (к примеру, тут vladimir.arbitr.ru зеленая). Тексты, как и весь контент сайта у каждого свой. Т.е. хотя движок работает в мультисайтовом режиме каждый отдельный сайт автономен на столько, что может быть вынесен на отдельную инсталяцию drupal-а и там будет по прежнему без проблем работать.
@iwebber что бы восстановить NS нужно получить полное дерево из AL, рассчитать требуемые NSLeft и NSRight и сделать полный апдейт NS. Не вижу проблему кроме разве незнания матчасти, но необходимые ссылки я уже дал.
@inkvizitor68sl да и пусть кэша. Оно же максимально близко к клиенту. Хотя у того же MaxCDN я не нашел информацию о том, что у них есть хосты в России.
@GansikUA его можно скопировать и в фаербаге и вообще в любом адекватном инструменте. На практике устойчивых парсеров от этих готовых выражений толку мало, хотя на них можно бывает ориентироваться.
@GansikUA если нужно получить Standart, а его нет, то код упадет с ошибкой тут ->item(0). Решается if-ом и проверкой на length полученного набора узлов.
@GansikUA вообще для парсинга крайне рекомендую использовать XPath и только XPath. Он великолепен! Позволяет составлять очень навороченные правила (в духе, "найти соседа третьего потомка элемента в классе которого содержится подстрока item"), но которые писать очень просто и легко, при этом если правильно писать выражения, то парсер не развалиться даже если на странице изменится верстка.
@GansikUA в контексте XPath правильнее говорить о позиции в наборе узлов.
1) // (это сокращенный синтаксис, полностью ось записывается как descendant:: ) это "все потомки узла контекста", т.е. как прямые потомки, так и потомки потомков, поскольку узел текста не задан, то по умолчанию им становиться html.
2) table[@id="recommendation"] получить набор узлов связанных со всеми table, но выбрать только те, атрибут id которых равен recommendation, поскольку на странице может быть только один элемент с уникальным id, то получили набор узлов состоящий из одного узла, этот узел является контекстом для следующих шагов адресации.
3) //tr[5] (это сокращенный вид записи, полный такой descendant::tr[position=5] "среди всех потомков table найти узел элемента tr позиция которого в наборе равна 5-ти", на этом шаге адресации мы получили набор узлов состоящий из одного узла, этот узел связан с 5-ым элементом tr он и будет является контекстом для следующего шага адресации.
4) td[1] (child::td[position=1]) "среди всех непосредственных потомков узла контекста найти связанные с элементами td, оставить из этого набора первый".
Общая схема такая: оси задают где ищем (среди потомков, среди всех потомков, среди соседей и т.д.), условия задают что ищем (все узлы, узлы связанные с элементом с именем ХХ, предикаты задают условия фильтрации получившегося набора (их может быть несколько).
