Василий Наумкин

Полагаю, Instagram просто не отдаёт эти данные совсем.

Документация, параметр &tplWrapper — там нужно убрать плейсхолдер [[+top]].

Минус от меня, за то что тебе лень использовать тег code, создавая тем самым битые ссылки на modx.pro. А мне потом приходится редактировать это дело.

На будущее — желательно нажимать ссылку «ответить» под комментарием, чтобы на него ответить. Тогда автору комментария придёт об этом уведомление.

А ты пуляешь все комментарии в корень ветки. Это и выглядит не очень, и я никаких уведомлений о твоём вопросе не получал.

P.S. Всё твои ответы перенёс повыше.

[[!*createdby]]

Это создатель текущей страницы и не факт, что он заходил через соцсети.

Если нужен определённый юзер, то нужно указать его id, числом. А если нужен текущий юзер, авторизованный в системе, то нужно использовать вот такой плейсхолдер:

&where=`{"internalKey": [[!+modx.user.id]]}`

Ну а для оформления кода у нас на сайте нужно использовать тег code:

<code></code>

Ajax или обычный запрос на свой сайт, а там сниппет, который сделает запрос через cURL на сторонний API.

Я бы написал плагин на событие сохранения комментария:

if ($modx->event->name == 'OnBeforeCommentSave') {
	if (stripos($_POST['text'], 'b-nosov.blogspot') !== false) {
		$modx->event->output('Хватит спамить!');
	}
}

Email очень просто изменить, поэтому лучше проверять текст комментария на спамерскую ссылку.

Сомневаюсь.

Отличный анализ, спасибо!

Думаю, ничего страшного не случится, если я пока оставлю всё как есть.

На мой взгляд, если приходится много чего-то копировать, то лучше наследовать и расширять.

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

Но это моё сугубо личное мнение, никому не навязываю.

Насколько я вижу, половина логики Twiggy скопирована из pdoTools, поэтому и отвечаю на твои вопросы =)

Тут ответ однозначный: где-то неверная последовательность вызова/вывода.

Может быть.

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

Вот тестовый сайт:
чанк с кэшированным вызовом MinifyX
класс pdoParser с закоментированным добавлением скриптов и стилей после обработки тегов Fenom

Логин s3914
Пароль UAChpcjgpO9r

Ты чего меня на вы-то? Вроде уже лично познакомились.

А вообще, тут всё просто. Без этой правки скрипты и стили из кэшируемых сниппетов, вызванных через Fenom, не добавлялись на страницу. А с ней — добавляются.

Сделать так мне показалось просто и логично, но если ты считаешь, что MODX нужно делать дополнительный вызов плагина для этой операции — шли PR на GitHub, добавим.

Следите за руками:

[[!pdoResources?
	&class=`haUserService`
	&sortby=`id`
	&tpl=`@INLINE <p>{{+provider}} - {{+profileurl}}</p>`
	&where=`{"internalKey": [[!*createdby]]}`
	&showLog=`1`
]]

Чанк можно усложнить — вынести отдельно и расписать любые условия через Fenom.

Затем же, зачем оно же и в pdoTools, у которого обработка тегов Fenom запускается после process() самого документа.

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

В смысле «куда-то»? Все ресурсы кэшируются в /core/cache/resource/контекст/resources/айди.cache.php. Если открыть этот файл, то там все параметры ресурса, именно они и выводятся при modX::getObject().

Для этого и придуман параметр cacheable — сохранять данные в кэш, или нет. Многие думают, что там только кэшированные сниппеты или шаблон страницы, но нет — там все свойства объекта.

И да, кэш ресурсов очищается при их сохранении в админке, может поэтому у тебя там иногда обновляются данные.

Лично я всё это заметил, когда пытался сохранять просмотры в ресурс для Tickets. Поэтому там сейчас отдельная таблица просмотров и никаких проблем нет.

А теперь вызови этот же сниппет без Fenom и убедись, что он работает точно также. Стоит подумать над тем, откуда берётся description для прибавления, если документ кэшируется — а вдруг из кэша?!

А как например мне вызвать аналог [[!*pagetitle]] т.е. не сниппет, а тег некешированным вызвать?

Теги не кэшируются вообще, а напрямую выводятся данные из $modx->resource. Документация.

Очень похоже на включенный register_globals.

Проверяй, отключай и извиняйся.

Странно, должно и так работать. Вот код процессора, $object там жёстко прописан.

Возможно, у тебя старая версия MODX.

Еще раз, речь про циферки. Не 1,2,3,4,5, а 5,4,3,2,1.

Типа зашел сегодня и увидел страницу 5, зашел завтра — уже 6. И с неё стартуешь, отматывая к 1. Если остановился на 3, то там и продолжишь потом читать, ничего не изменится, просто добавятся страницы 7 и 8 через пару дней.

В теории, вроде бы, всё хорошо. Однако неясно, почему так никто не делает.

Ничего, тут речь именно про циферки.

Идею я, вроде бы, понял. Но не уверен, что она приживётся и будет понятна людям. А времени делать «чтобы было» сейчас нет.

Поэтому, отложим пока эту мысль в сторонку и понаблюдаем за спросом.