weranda

weranda

С нами с 25 июля 2015; Место в рейтинге пользователей: #300
weranda
05 сентября 2019, 13:50
0
Класс, спасибо за разъяснения.
Может быть у вас завалялась ссылочка на полезный материал по этим плейсхолдерам. Посмотрел информацию по ссылке, данной вами выше, — она скудна и без объяснений подобно вашим не разберешься.
weranda
05 сентября 2019, 13:39
0
Правильно ли я понял? — Сначала в шаблоне один раз перед нужными полями мы запускаем сниппет с именем Snippet, передаем в него нужные нам поля (content,description,tv.tvname). Затем сниппет запускается, включается прописанная в нем логика (делает замены) и закрепляет результат за некими переменными, именуемыми по именам переданных полей (content,description,tv.tvname). После этого в шаблоне становится доступными результаты работы сниппета, доступ к которым можно получить через общий префикс и имена, которые были заданы в сниппете.
Я просто никогда раньше с плейсхолдерами не сталкивался.
weranda
05 сентября 2019, 13:03
0
Возможно, именно этот момент мне и непонятен. Как получить нужные поля, обработать их — это понятно, а вот потом как вывести все обработанное в одном месте в разные поля — вот это вопрос.
weranda
05 сентября 2019, 12:42
0
Ладно, попробую еще раз объяснить.

Имеем три поля:
//Поле 1
зима, весна, лето, осень

//Поле 2
весна и лето — теплые времена года

//Поле 3
зима и осень — прохладные времена года. пьем кофе.

Имеем список замен (список будет исключительно в единичном экземпляре):
зима —> зима (холод)
весна —> весна (тепло)
лето —> лето (тепло)
осень —> осень (холод)
кофе —> кофе (горячий)

После преобразования должно получиться вот что:
//Поле 1 (4 совпадения, 4 замены)
зима (холод), весна (тепло), лето (тепло), осень (холод)

//Поле 2 (4 совпадения, 0 замен, так как замены уже были)
весна и лето — теплые времена года

//Поле 3 (1 совпадения, 1 замена)
зима и осень — прохладные времена года. пьем кофе (горячий).

Т. е. должна быть только одна замена из списка замен по всем полям, если их объединить.
weranda
05 сентября 2019, 11:57
0
Либо я не понимаю, либо плохо объяснил.
Давайте попробую еще раз. Для примера возьмем всего два поля и две замены. В первом и во втором полях встречаются по два искомых для замены слова. Используя первый вариант (через один и тот же модификатор для каждого поля), в каждом из двух полей мы получим по две замены. Этот вариант не подходит, так как в нем должно было бы замениться только два первых совпадения, а они встречаются в первом поле. Во втором же поле замен не должно было быть, так как по одной из них уже сделано было в первом поле.
Список замен один, общий для всех полей. Таким образом первый вариант не подходит из-за возможности повторения множественности замен, а второй — из-за того, что список замен общий для всех полей.
Третий предложенный вами вариант с обработкой всего кода страницы тоже не подход, так как нужна обработка данных именно в некоторых полях, а не во всех.
weranda
05 сентября 2019, 11:24
0
Малость не понял. Поясню что я имел в виду выше. Допустим, есть список замен из 100 слов. Мне без разницы где встретится слово — в первом поле, втором или третьем, но если оно есть на странице в любом из них, то должно быть заменено. Я так понял, что вы предлагаете каким-то образом разделить список замен так, чтобы для каждого из поля (content, dexctiption и пр.) не было пересечений в списках замен. Вы это предлагаете? Или же вы предлагаете добавлять дополнительную логику и в ней проверять были ли замены в предыдущем блоке для следующего?
weranda
05 сентября 2019, 11:06
0
Над этим вариантом размышлял. Если надо будет сделать только по одной замене слова на странице, то с прикреплением одного и того же модификатора к нескольким полям замены будут проведены минимум два раза на одной страницы при условии, что искомые для замены слова будут встречаться сразу в двух полях. Поэтому этот вариант не подходит.
weranda
13 июня 2019, 13:31
0
В общем, выше было три или четыре рабочих варианта. Если вы в них не увидели вам подходящего, пользуйтесь пятым/третьим вариантом Павла)
weranda
13 июня 2019, 12:56
0
Выше есть несколько конкретных решений. Специально для вас: два предельно ясных варианта, готовых, дал Павел Романов. Я же лишь привел ссылку тоже на готовое решение с примерами. Зачем их дублировать — я не понимаю.
weranda
13 июня 2019, 12:37
0
Потому что там все написано и расшифровано.
weranda
13 марта 2019, 08:27
0
Спавсибо за наводку.
weranda
12 марта 2019, 20:47
0
Уря, причину выяснили)
Осталось определить как настроить.
Посмотрел файлы кеша и нашел файлик auto_publish.cache.php. В нем, как я понял, сохранена дата публикации ближайшего по времени ресурса. После наступления этой даты в этот файл механизм MODX вписывает другую ближайшую дату публикации и при этом очичает весь кеш — правильно?
Полагаю, что можно удалить кеш из папки (программно), но тогда не создастся файл auto_publish.cache.php, придется также генерировать, но из-за незнания всех аспектов генерации такого файла, дело может и не выгореть — что-то может пойти не так.
Есть ли варианты обхода добавления ресурсов в БД без удаления уже существующего кеша?
weranda
14 февраля 2019, 10:17
0
Владимир, так про то и спрашиваю)
weranda
13 февраля 2019, 22:30
0
Вопрос в догонку: а не эффективнее ли написать свой сниппет? Насколько знаю, просто делается запрос в БД и выводится через шаблон, но как это правильно сделать — вопрос!
weranda
13 февраля 2019, 21:42
0
Павел, штука офигенная, но не получается вывести несколько разных ID. Если в поле пишу одно значение (1), то все выводится, а вот если пишу два через запятую (1,2), то ничего не выводится. Подскажите пожалуйста как выйти из этой ситуации!?
Пробовал в where прописать id вручную в JSON, но все равно не выводит:
&where=`{ "id":["1","2"] }`
weranda
23 ноября 2018, 19:49
0
Всем спасибо.
weranda
23 ноября 2018, 15:58
0
Я не знаю что произошло, но заработало. Странно.