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

Просто сделать такой интерфейс универсальным несколько сложнее. Из коробки будет заточенность только под бутстрап.

Сорри, что вмешиваюсь в разговор :-) С Наступившим!
А данная заметка в настоящее время актуальна?

Еще раз, Максим, хочу подвести к тому, что большинству нужно решение из коробки. Программистам оно не нужно и с этим я согласен.

Про большой ум и битрикс — я рад за тех, кто все это может. Допиливать, переделывать и прочее. Я не могу. Мне нужно готовое дополнение. И мне нужно мнение, которое поможет сделать его удобным. Вопрос целесообразности для меня не стоит.

Было бы здорово, чтобы годные программисты писали и допиливали для себя.

Ну, на мой взгляд, годные программисты и так стараются писать все дополнения под себя, за исключением pdotools, tickets и аналогичных, которые написаны слишком уж хорошо +на реализацию которых самим просто нет возможностей/времени.

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

— к чему это сказано? С тем же успехом можно было сказать что-то в духе: «ребята, которые работают на битриксе, оценивают битрикс как один из самых удобных и быстрых функционалов», но вряд ли от их мнения он таким становится.

Ну и да, к слову: большого ума, как по мне, чтобы реализовать более быстрый аналог друпалу и вордпрессу в текущей их ипостасти и не требуется. Ровно до тех пор, пока легкие дополнения Modx'a не стали «универсальным решением на все случаи жизни из коробки для ленивых»

Что же до подгружаемых элементов с пакетами tickets — повторюсь, вопрос в востребованности и максимальной необходимости для большинства. И теги ими, на мой взгляд, не являются.

не совсем. Если честно признаться, то я не совсем понял в какой консоли и как его запускать, поэтому просто создал в корне сайта файл 123.php и запустил его в браузере.

Сам файл выполняется быстро (Результат: 0.087812900543213). Но, я смотрю время загрузки его в браузере (F12, вкладка Network, и несколько раз F5). И вижу там, что TTFB колеблется от 200ms до 2s. Два раза нормально, на третий долго. Потом опять.

Василий?

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

То есть, скрипт из консоли сервера выполняется быстро, а через браузер до 2х секунд?

Я правильно понял?

Вывод тега в урл с транслитом букв или нумеровать.

Написал в поддержку. :)

положил файл со скриптом в корень сайта

<?php
$time = microtime(true);
for ($i = 1; $i <= 1000000; $i++) {
    $x = rand();
}
echo microtime(true) - $time;

запускаю. Результат: 0.087812900543213
А время TTFB колеблется от 200ms до 2s. Два раза нормально, на третий долго. Потом опять.

Я так понимаю, что в Linode жаловаться смысла нет (скрипт же быстро выполняется), и сайт тоже вроде как не причем, т.к. я же просто файл запускаю, минуя всю начинку MODx. Остаются настройки PHP и NGINX, а их я брал из инструкции Василия по настройке сервера.

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

В этом и вся фишка — в этом алгоритме твшки в выборках практически не учавствуют.
Единственное место, где они будут нужны — это вывод списка тегов на странице. И здесь вопрос решается очень и очень просто — pdoResource.
В pdoTools'е всё уже предусмотрено. Так что скорости будут максимальными

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

Плюс проверка слова, для предотвращения повторения одних и тех же слов с разными окончаниями (машина, машину, машины) и подставление уже имеющихся.

Зато теперь возникает проблема реализации собственного генератора URL.
Возможны 3 варианта:

1.Замена стандартного генератора uri собственным. Реализуется перегрузкой одного из методов: modx::refreshURIs() либо modResource::getAliasPath(). При каждом вызове стандартного генератора фактически будет вызываться наш собственный генератор

Плюсы:
1) Не придётся отслеживать моменты, когда и для каких ресурсов нужно выполнить перегенерацию URI — этим будет заниматься modx
2) Внутри собственного генератора URI можно легко отслеживать изменение URI и вызывать соответствующие методы Редиректора

Минусы:
1) Перегрузка классов modx или modResource реализуется не совсем чисто и не надёжно (нужно решать проблему «подсовывания» своих классов в нужных местах и в нужные моменты времени). Если для перегрузки класса modx достаточно ручной корректировки одной строки кода в 4 файлах при каждой установке и обновлении modx, то подсовывание своего класса modResource остаётся проблемой.
2) Поскольку необходимость перегенерации URI определяет modx, то при изменении тех данных, которые используются собственным генератором uri, но не используются стандартным, — при изменении этих данных собственный генератор вызываться не будет

2.Собственный генератор URI наряду со стандартным (без использования заморозки). Собственный автоматический генератор замороженные uri не трогает (так же, как и стандартный)

Плюсы:
1) Не нужно ничего перегружать
2) Сохраняется стандартная логика modx: если uri заморожен, то автоматическая генерация его затронуть не должна. Заморозка предоставляет возможность некоторым ресурсам задавать uri вручную (отлично от тех, что генерируются автоматически) и быть уверенным, что никакая «автоматка» эти uri не тронет

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

Но в автоматическом режиме задача нерешаема по следующим причинам:
а) события на генерацию URI нет
б) метод modResource::save() не генерирует никаких событий.
(Для сравнения: у элементов (плагинов, сниппетов, чанков, шаблонов, tv) при выполнении метода {ELEMENT}::save() генерируются события OnBefore{ELEMENT}Save и On{ELEMENT}Save)
в) при изменении системных настроек, настроек контекста и типов контента тоже не генерируется никаких событий

Т.е. возможно отследить только обновление сайта (событие OnSiteRefresh) и изменение/сохранение ресурса (события OnBeforeDocFormSave и OnDocFormSave)

3.Собственный генератор URI наряду со стандартным (с использованием заморозки). Собственный автоматический генератор при генерации uri их замораживает.

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

Минусы:
1) Нарушается стандартная логика modx: если uri заморожен, то собственная автоматическая генерация его затронет (например, при сохранении ресурса). Т.е. для ресурсов не будет возможности задавать uri вручную.
2) Придётся самостоятельно отслеживать изменение тех данных, которые учитываются при работе собственного генератора.
Если собственный генератор учитывает системные настройки, настройки контекстов или настройки типов контента (последнее — уж обязательно), то эта задача опять-таки в автоматическом режиме нерешаема, т.к. нет событий, наступающих при изменении этих настроек.

==========================================================================
Мой выбор — вариант №2. Сохраняющий стандартную (корректную) логику работы с замороженными url
Только как автоматически и универсально отслеживать изменение url стандартным генератором?

Ты не уловил посыл)
Главное не «тегирование из коробки», а «правильное тегирование». Правильное в коробку завернуть как раз не проблема, было бы оно правильным :-)

Может быть на следующей неделе соберу. Хз когда выздоровлю.

Смысл в том, чтобы собрать пакет, который дает «тегирование» из коробки. То, как это делать, в теории, я и сам могу написать :) Спасибо и добра тебе :)

На другом хостинге попробую.

В вебмастере пишет «Страниц в поиске» — 0
«Последнее посещение роботом» — 04.01.2015

Плагин отключил.

Сайт всегда индексировался отлично — страницы влетали в поиск в течение нескольких минут.

Если проблема прояснится отпишусь…

Я тут долго расписывал чем вредны теги, но надоело, если честно, и я забил)
Поэтому просто расскажу, как _надо_ делать тегирование.

Нужны:
1. Тикетс;
2. 2 tv;
3. 1 плагин;
4. 1 таблица.

Создаём раздел с тикетами. Называем его, к примеру «Теги» :-)
Создаём tv. В него будем записывать теги для страницы.
На сохранение ресурса (у которого д.б. теги), в плагине, смотрим в этот tv, разбираем теги и на каждый создаём тикет в нашем разделе «Теги». У этих тикетов-тэгов д.б. tv-шка, в которую мы в исходном виде записываем текст тега.
Потом записываем в нашу таблицу id ресурса и id тикета-тега (сколько тегов, столько и записей в таблице), не забывая перед этим очистить все прошлые записи для этого ресурса (ну вдруг мы отредактировали ресурс и какой-то тег удалили. Чтобы не заморачиваться с логикой — просто удаляем все записи для этого ресурса, а потом сохраняем текущие).
Выборку статей с данным тегом делать pdoResource'ом.

Собственно всё.
Я бы собрал пакетик на днях, да только болею я.

В общем, в чём профит.
На каждый тег будет отдельный ресурс. Да, если тегов 1000, то и ресурсов будет 1000. Если кого-то такой вариант не устраивает, то… не мои это проблемы)
Смысл в том, что у каждой страницы-тега можно редактировать урлы, контент, тайтлы, дескрипшены, да и вообще что душа пожелает — это же обычный ресурс. Это просто рай для любого более-менее грамотного сеошника. Вы в своих интернет-магазинах (и не только) сможете просто нереально расширить семантику, поднять траффика и позиции по куче низкочастотников. Достаточно небольшого уникального текста символов на 300, уникального тайтла и дескрипшена на каждой легированной странице. Вот и всё.
Все остальные варианты тегирования, в большинстве случаев, будут только во вред.

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

Всем добра :-)

Исходный код страницы — это не исходный код чанка.

В странице должно быть что-то вроде такого:

<h4>Цена</h4>
<div class="mse2_number_slider"></div>
<div class="mse2_number_inputs">
	<div class="form-group col-md-6">
	<label for="mse2_ms|price_0">От
		<input type="input" name="ms|price" id="mse2_ms|price_0" value="0" class="form-control input-sm" />
	</label>
</div><div class="form-group col-md-6">
	<label for="mse2_ms|price_1">До
		<input type="input" name="ms|price" id="mse2_ms|price_1" value="3999" class="form-control input-sm" />
	</label>
</div>

price_0 — меньшее число, price_1 — большее. Вот это и нужно проверить.

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