Изменения в jquery связанные с селекторами Xpath и History/Remote plugin

В одном моем проекте используется куча разных jquery плагинов, что сделало процесс обновления самого jquery довольно трудным, ибо везде что-то отваливается, какие-то из них не обновляются с выходом новых версий самого jQuery и т.п. Но вчера я всетаки решил обновиться, и одним из плагинов который пришлось допиливать самому оказался History/Remote плагин. Перестал он работать, как оказалось, из-за того что селекторы Xpath вида [@attribute] были какое-то время deprecated, а теперь и вовосе перестали работать. Вместо них нужно юзать [attribute], т.е. просто убираем знак “@”. В частности в указанном выше плагине, код

$('a[@href$="' + iframeHash + '"]').click();

поменялся на

$('a[href$="' + iframeHash + '"]').click();

, и все прекрасно заработало.

Мелочь когда знаешь куда смотреть, но проблема когда в интернетах этого не пишут ) Так что хозяйке на заметку )))

PHP+Oracle Faq

http://download-west.oracle.com/otndocs/tech/ias/portal/files/RG/completewebsitephpfaq2.htm Полезнейший FAQ от ораклов, о том как их чудо-продукт всетаки заставить работать с похапе.

На заметку.

Хозяйке на заметку, или кратко об очевидном, кажущимся неочевидным

Отсутствующие локали

При отсутствии на сервере нужной локали, например ru_RU.CP1251, можно легко её добавить:

localedef ru_RU.CP1251 -i ru_RU -f CP1251

после этого проверяем, появилась ли она, командой

locale -a | grep ru

Переменные окружения

Как известно, большая часть неочевидных проблем в линуксе связана с переменными окружения. Чтобы понять, как так случилось что из консоли ваш демон запускается и работает правильно, а при запуске из init.d что-то не так (например у меня переставал коннектиться к Ораклу, или слетала локаль), достаточно сделать тестовый вывод переменных среды окружения в инит скрипте.

На примере стартового скрипта php-fpm, добавляем в него после #/bin/bash следующую строку:

export > /tmp/envvars

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

Rewrite Rule для CodeIgniter и nginx

В интернетах куча вариантов этих rewrite-rule’ов, у меня же заработал такой вариант (полный конфиг vhost’а):

server {
   listen 80;
   server_name yourhost.com;
   index index.php;
   root /www/yourhost.com/htdocs;
   access_log  logs/yourhost.com_access.log;

   location / {
      #error_page 404 = 404.html;

        if (-f $request_filename) {
            expires max;
            break;
        }

        if ($request_filename !~ (js|css|images|robots\.txt|index\.php.*) ) {
            rewrite ^/(.*)$ /index.php/$1 last;
        }
   }

   location ~ .php$ {
      fastcgi_pass 127.0.0.1:9000;
      fastcgi_index index.php;
      include /usr/local/nginx/conf/fastcgi_params;
   }

  location ~ /index.php/
  {
    include /usr/local/nginx/conf/fastcgi_params;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /www/yourhost.com/htdocs/index.php;
    fastcgi_param  REQUEST_URI      $request_uri;
    fastcgi_param  QUERY_STRING     $query_string;
    fastcgi_param  REQUEST_METHOD   $request_method;
    fastcgi_param  CONTENT_TYPE     $content_type;
    fastcgi_param  CONTENT_LENGTH   $content_length;
    fastcgi_param  HTTP_REFERER     $http_referer;
    fastcgi_pass   127.0.0.1:9000;
  }

}

Ну и в конфиге самого CodeIgniter’a нужно указать что

$config['uri_protocol'] = "REQUEST_URI";

Колхозники и apache make_sock :)

Starting httpd: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down
Unable to open logs!

при возникновении такой ошибки на боевом сервере, обычно после apachectl stop, меня охватывала паника, и все на что хватало воспаленного мозга - reboot в консоли. Учитывая что процессов апача запущено не было, а на 80м порту висела пара FIN_WAIT’ов, выбора казалось бы нет ))) И так было не раз.

Стоило чуть задуматься немного погуглить, и нашелся простейший ответ:

netstat -lnp | grep ':80'

в моем случае подсказало мне, что 80й порт каким-то чудом умудряется занять memcached, за что он моментально наказывается

killall -9 memcached

:))

Вот такие дела. Воистину, reboot - крайняя мера в линухах ))