Alex Pts

Через mac port ставил просто sudo port install php-mcrypt

Если версия mysql позволяет, то можно использовать виртуальные колонки.
Как вариант сумму в приложении получать и не хранить сумму в БД.

Скорее всего дело в настройках хоста nginx, document_root указывает на папку с корнем сайта.

Правильно так

mapOpen = $('button.map-open');
mapOpen.click(function() {
			$('#map').fadeIn('400');
			$('body, html').animate({'scrollTop':5000},600);
			mapOpen.text('закрыть схему проезда');
			mapOpen.addClass('map-close').removeClass('map-open');
		});

mapClose = $('button.map-close');
 mapClose.click(function() {
				$('#map').fadeOut('400');
				mapClose.text('открыть схему проезда');
				mapClose.addClass('map-open').removeClass('map-close');
			});

У вас обработчик закрытия каждый раз устанавливался при клике открыть

https://developer.mozilla.org/en-US/docs/Web/Guide...

$('img').click(function(){
    $('audio')[0].play(); //  выборка нужного тега audio и запуск метода play()
});

query_posts() и get_posts() внутри работают с WP_query объектом. В этом году про некоторые тонкости выборки и отличия был доклад на wordCamp 2014. В сети доступно видео, можно найти.

По поводу скорости, то тут нужно посмотреть SQL запрос итоговый и посмотреть попадают ли искомые поля в индексы таблиц, которые будут в запросе использоваться. Ну и explain на запрос можно прямо выполнить, чтобы об эффективности говорить. На небольших таблицах это будет однозначно работать быстро.

Можно с помощью canvas

Ну и set_exception_handler по аналогии

monolog

Спасибо, еще бы IDE заставить не матерится на такой синтаксис

Столкнулся с этой же проблемой, но иногда не файл обрезается, в в конец вставляются символы знаков вопроса. Стоит fedora под VB, после обновления до 20 версии с 19 такая проблема начала проявлятся

А каков сакральный смысл отлова события на document в данном случае?

Да, вы правы, у нас получается по сути тоже самое, что мы просто на объект навесим обработчик по сути.
Хотя если проверить элемент на котором произошло событие не только по селектору, а по набору элементов, то слушатель то у нас один все равно, просто он проверят наличие в некотором множестве. Думаю, что смысл делегирования все равно имеет место быть с точки зрения как производительности, так и работы с динамической моделью DOM.

$(document).on('change', '[data-my-plugin]', someHandler)

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

В вашем примере, я так понимаю, нельзя будет назначить разные обработчики, если мы вызовем свой метод myPlugin() на 2 разных наборах. Чтобы первый вызов один обработчик имел, а второй свой. Тогда для них придется selector уникальный составлять на каждый вызов. Это не гибко.

Возможно есть простой вариант не с использованием jQuery, это не принципиально.

Хостеры как-то на уровне htaccess закрыли доступ к /wp-admin/ и /wp-login.php из-за актиновго брутфорса, который видимо нагрузку на хостинг создавал. Разрешив доступ только по указанным явнов .htaccess IP. Если IP у вас белый, то можно вполне тоже самое самому себе сделать.

По поводу механики на клиенте Serkaz все верно написал.

Если опустить время на запросы, то через setInterval() можно равномерно эту функцию вызывать.

А проблема была в
complete:getmess

На событие comolete запроса вы следом же снова эту функцию вызывали. Отсюда и интервал 0,1 сек был

Браузер однозначно что-то оптимизирует при выходе элементов за viewport, но на это сильно расчитывать не стоит.

а) Делал горизонтальную прокрутку viewport`а, анимация идет намного плавнее, если по бокам элементов намного меньше и те что не в области видимости прятать через display:none; Визуально разницу можно наблюдать. Можно проверить.

б) Делал бесконечную вертикальную прокрутку вниз, подобие стены в соцсети, где доходя до низа приходит новая пачка с медиа контнетном. В js все обработчики отвязывались своевременно, профайлил все долго и упорно, пытаясь ускорить сей процесс. Но после 1000-2000 элементов контента на странице, браузер начинал на ПК тупить и кушал все больше памяти. Хотя оптимизация самими браузером определенно есть. Но удалять элементы из DOM оказалось намного эффективнее.
2) Тут вопрос не в прокрутке, а в том, что когда ты удалишь вышерасположенные элементы, то представление схлопнется, элементы перепозиционируются. Вставлять пустую элементы такой же высоты вместо прежних это костыльно.

Посмотреть можно примеры отсюда - http://masonry.desandro.com/
Уверен что кто-то выгружает тоже элементы, чтобы GUI был более отзывчивым.