Да уж какая тут может быть каша

tpl.mFilter2.price.number:

<label for="mse2_[[+table]][[+delimeter]][[+filter]]_[[+idx]]"><span>[[+title]]</span>
		<input type="text" name="[[+table]][[+delimeter]][[+filter]]" id="mse2_[[+table]][[+delimeter]][[+filter]]_[[+idx]]" value="[[+value]]"/> 
	</label>

tpl.mFilter2.price.slider:

<fieldset id="mse2_[[+table]][[+delimeter]][[+filter]]">
	<div class="filter-title">[[%mse2_filter_[[+table]]_[[+filter]]]]</div>
	<div class="mfilter-price dark">
		<p>
			[[+rows]]<span>Млн. руб.</span>
		</p>

<!--Дизайнерские красивости-->
		<div class="slider-bg">
		<span class="track-start">0</span><span class="track-middle">7</span><span class="track-finish">14</span>
			<div class="mse2_number_slider"></div>
		</div>
<!--Конец дизайнерским красивостям-->
	</div>
</fieldset>

Понятно, что чудес не бывает и мистики с магией. Бывает не хватка знаний или невнимательность.

Да, это стандартное поведение modx — обеспечение соответствия uri ресурсов псевдонимам и настройкам.

modx выполняет перегенерацию uri в 5 случаях:
1) При сохранении и копировании ресурсов (процессоры "resource/update", "resource/duplicate" и "resource/updatefromgrid")

2) Обновление сайта ("Сайт — Обновить", процессор "system/clearcache") — принудительно обновляет uri всех ресурсов. До версии modx 2.3.x перегенерацию URI при обновлении сайта не выполнял.

3) При изменении системных настроек типов контента (content type): процессоры "system/contenttype/update" и "system/contenttype/updatefromgrid"

4) При изменении системных настроек дружественных URL: процессор "system/settings/update"
5) При создании или изменении настроек дружественных URL для контекстов: процессоры "context/settings/create", "context/settings/update" и "context/settings/updatefromgrid"

Пытаюсь так:
Для buildNumberFilter

$min = round(array_shift($tmp),1);
$max = round(array_pop($tmp),1);

Для filterNumber:

$min = round(min($requested),1);
$max = round(max($requested),1);

Хочу добавить — спасибо всем за высказанные мнения.

Сейчас проверю конечно, но если всё вернуть как было. Т.е. без дробных чисел, т.е. как по умолчанию — всё работает аки швейцарские часы — бред начинается, когда я убираю округление в buildNumberFilter и NumberFilter floor у min и ceil у max. Именно с этого места.

Что-то мне кажется, что у тебя в чанках каша, раз меняются местами min и max.

Проверь-ка исходный код страницы, может там и вправду они поменяны?

Все комментарии про «незачем уводить дополнение от минимума, потому что его можно допилить» — считаю довольно странными. Зачем вам тогда готовое дополнение, если можно взять с нуля и допиливать, и допиливать, допиливать заново под каждый новый проект? Это просто мысли вслух — у каждого своя правда.

Для тех, кто радеет за минимализм и отсутствие «лишних таблиц» — вы и так подгружаете с тикетами все компоненты из пакета Тикетс, pdoTools, Jevix и Minifyx. Главное, обходиться без утрирования.

Что касается самих Тикетс в нынешнем виде, с кармой, комментариями и прочими фишками, — ребята, которые строят хорошие «юзер-френдли» ресурсы, — оценивают это дополнение, как одно из самых удобных, функциональных и быстрых на фоне аналогов в друпале и вордпресе.

В ручную разделитель в input не вводится. Попробовал добавить step:0.1, — пока двигаешь слайдер — всё вроде как нормально, хотя у max значение вида 2.900000 становится. Отпускается бегунок, max и min меняются местами. Ради смеха вернул всё как было везде и в default.js сменил range на false. Стало также кашей работать — менять min и max местами. Т.е. и в первом случае он ранжировал как-то по своему? Окончательно запутался.

Вот честно говоря, ни разу с таким поведением не сталкивался. И до этого подобных жалоб не было. Так что тут что-то уникальное исключительно для вашего сайта.
Логика отдачи заголовка проста как топор и нарушений в её работе добиться очень сложно. Может из-за nginx'а что-то.
Единственное, что могу посоветовать, — попробовать на другом хостинге протестировать (только аккуратно, чтобы поисковики не успели тестовый сайт проиндексировать), на каком-нибудь из рекомендуемых для modx. Если ошибка повторится, то дело в сайте, надо будет копать глубже.

А по поводу вылета из индекса…
С одной стороны не на столько это критичная ошибка и не на столько критичный фактор, чтобы весь сайт из индекса выкидывать.
С другой — этих роботов, порой, хер поймёшь. У АГС'а тоже есть статистический процент ошибок. Тут только ответа Платона ждать.
А в вебмастере смотрели? Там может быть что-то на эту тему, если есть проблемы с индексацией.

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

С тегами есть возможность реализации каких-нибудь подписок для пользователя или вывода лент. Исключение, например исключение тега 18+ для безопасной ленты. Тут наверное можно было бы подключить pdopage с переданными условиями.

Здравствуйте Алексей!
Осенью установил с Гитхаба Ваш пакет.
Зависит это от пакета или нет не знаю, но перед Новым годом сайт полностью вылетел из выдачи Яндекса (даже главная страница). Санкции поисковика маловероятны, так как сайт продвигается только «белыми» методами. Предположил, что дело в настройках сайта. Отписал Платону, но вероятно из-за праздников ответ задерживается.

Стал искать источник проблемы, выяснил, только то, что Last-Modified отдает с ошибкой (сервис last-modified.com/ru/):



Last-Modified выдает 15 октября, а 304 Not Modified не отреагировал.
Пакет инсталировал/деинсталировал, но результат не изменился.

Может подскажите в какую сторону копать?

Да, это справедливо. Помнится, Agel Nash даже выявлял довольно неприятные уязвимости tv-полей.

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

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

А что имелось ввиду под «исключением тега»?

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

По поводу все большей монструозности в тикетах, это имхо проблема нахождения баланса между универсальностью и модульностью дополнений. Если можно, то было бы логично делать в отдельном дополнении и ничего не вшивать, впрочем как и ТикетМета, да и ТикетКомментс, ничего плохого нет и в допиливании Таглистер, единственная проблема тут возможна будет с использованием библиотек Pdotools. Вообще грамотное ТЗ половина дела, тут думать надо.

А че там допиливать? сформировать строчку запроса where из гета (для запроса поиска реурсов по тегам)- дело не хитрое. Я ее в маленьком ленивом сниппете сделал и в pdoResource отправил. Делов-то. А то видишь ли качай ему getResource и getPage. Важный какой )
Но я вот о чем хочу сказать. Тиккеты подхватывают при установке пдо-тулз. Отдельный пакет. И как выше сказано, они обладают уже мощным функционалом. Вот допустим я хочу комментарии на сайте. Чеб мне не скачать только соответствующий сниппет тиккетов без расширенных ресурсов, например… Отдельным пакетом. Ну короче идея в том, чтобы при увеличении функционала в тиккетах он становился более модульным, чтобы можно было скачать то, что нужно и не качать остального. Но это так, размышления на тему.

Проверь работу php из консоли скриптом из моей заметки. Если будет больше 0.2-0.6 то пиши в поддержку Linode и жалуйся на тормоза.

Если в консоли скорость нормальная — то разбираться нужно с сайтом.

а как ускорить его работу?

Попробовал статичную и динамичную страницу с одинаковым контентом грузить. Статичная стабильно грузится с одним и тем же временем (~185ms), а динамическая скачет от 200ms до 4s.

TTFB — это время отдачи первого байта, то есть, скорость генерации страницы PHP.

Если TTFB высокий, значит PHP медленно работает. Для сравнения можно попробовать открыть статичную HTML страницу, а не PHP.

У меня жуткий костыль, код разбросан в 10 местах, суть такая:
1. В низу страницы есть код скрытой формы, эта форма отображается при помощи fancybox при загрузке картинки.
2. В форме есть input type=file, загрузка файлов идет по одному
3. Сама форма отправляется на сервер через ajax (jquery forms)
4. На севере висит php скрипт файл сохраняет и выдает в ответ сформированный html код со ссылкой на картинку и маленьким превью.

Так я и говорю, может просто его допилить до нужного состояния.

Могу ошибаться, но по-моему в нем где-то жестко использовался getResource в отображении, поэтому и написал свой модуль (повторяюсь, могу ошибаться — дело было давно) =)