Fi1osof

Просто на заметку (из личного опыта):
этот пакет использует mPDF. В свое время выбирал между mPDF и DOMPDF. Остановился на последнем. Он более качественно поддерживал CSS и понимал разметку, в частности хорошо понимал colspan и width в таблицах (в ячейках), а так же «кушал» все стили сайта, включая бутстрап. mPDF на нем зубы обламывал, все ехало. Помимо всего прочего и колонтитулы нормально поддерживались. В итоге вот такое вот формировалось: joxi.ru/12M1KMNh44RL72 (и отправлялось на почту).
Если говорить о генерации всей страницы сайта, то скорее всего mPDF не подойдет. Да и DOMPDF не гарантирует 100%, хотя и более вероятен.

Я в этом вопросе не абсолютный спец, но скажу что знаю (хотя вполне меня могут поправить).
С pdf в общих чертах можно, это я делал, есть довольно продвинутые модули конвертации HTML в PDF (даже с довольно хорошей поддержкой CSS, включая ::before и т.п.). Но действительно хорошая поддержка возможна только с прорисовкой исходника в «виртуальном» браузере на стороне сервера.
В другие форматы не конвертировал, хотя опять-таки, скорее всего все это можно с помощью серверных конвертеров. То есть если вопрос выдернуть какую-то часть контента — это можно сделать с помощью того же DOMDocument.
В целом, опять-таки, не кажется мне этот компонент массовым. Несколько раз обращались на счет формирования PDF, и каждый раз слишком специфические требования были.

Я не обижаюсь. Я подхожу сухо к вопросу: если мы тратим свои калории на то, чтобы чем-то помочь, а в ответ я вижу, что помощь не нужна, значит я считаю не надо пытаться помогать.
То, что вы не видите ничего полезного в моем комментарии, тут все просто: каждый ученик из урока извлекает ровно столько, сколько он может извлечь © кто-то. Может со временем вы поймете.
Слова можете не забирать, что сказано, то сказано.

Страно мыслить такими критерями…

Был вопрос: «Как сделать Х»

И ответы:
~ Лев: «Х и У делается вот так»
~ Сергей: «Х делается вот так»
~~ Николай: «Эй, здесь не учли У»

Сорри, но на мой взгляд странно не мыслить такими критериями. Лично я всегда так и стараюсь мыслить, так как если не предусматривать заранее изменение и развитие системы, решение часто изначально не будет универсальным. А потом и получается, что добавили какую-то мелочь и сайт посыпался.
И может именно потому, что я так всегда смотрю на вещи, тот же shopModx, на основе которого создан не один десяток магазинов, практически не менялся с 2013-го года? joxi.ru/krDpeN0h00bb5r

Но, опять-таки, это мое ИМХО. Каждый пусть смотрит на вещи как ему больше нравится. Лично я больше постараюсь ни в чьи вопросы-топики не лезть. Пусть все со своими вопросами разбираются сами, если они итак все знают.

Вы приходите на форум с вопросами, и комментарии знающих людей для вас высеры? ОК. Постараюсь больше не засирать ваши темы с вопросами.

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

Я привык к тому, чтобы смотрели на технический момент, а не на эмоциональный. Потому особо не слежу за своим тоном.

Вот что может заставить написать такое

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

Что? Отсутствие ответа на вполне корректное замечание в течение 5-ти часов. joxi.ru/82QV3dNu115MJA
Лева правильно сказал — будет авторизован пользователь — будет видеть не то.

Где топикстартер написал, что у него пользователи авторизуются? Во втором предложении он даже написал:

Как получить поле с телефоном админа сайта на фронтэнде незарегистрированному пользователю?

Сегодня просто сайт и нет авторизованных, а завтра есть. Да и админ или манагер, на минуточку, тоже пользователь. Перешел во фронт и потом вопрос от него «А куда номер пропал?».
В общем, с технической стороны, твоя реализация рабочая, но имеет ряд минусов, о чем было сказано. Зачем делать такое, которое работать будет с кучей оговорок, когда есть не на много более сложное, но стабильное решение.

P.S. и не плачься ты уже за минуса, я тебе здесь ни одного минуса не поставил. joxi.ru/J2beE7ac44Knnm За других не скажу, и не интересно мне.

Лева, ты не был услышан :)
Ничего, когда авторизованные пользователи будут видеть свой телефон, может им понятней будет.

Пока еще не за что!

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

Это я помню и это правильно. Но стоит ли включать такую проблему?
И хорошо, давай не будем о том кто какой риск несет. Другой вопрос: ты усматриваешь возможность пофиксить это проблему?

Василий, я про это писал еще здесь.

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

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

Я вас услышал. Спасибо за комментарий! Есть соображения. И кажется я знаю, чем сегодня займусь :)

Что за коммент такой без ссылки на компонент?)))
Во, так лучше :)

Народ, вопрос: на сколько велика потребность в модуле «Заказать обратный звонок»? То есть просто чтобы на сайте появлялась кнопка «Заказать звонок», при клике всплывающее окно с полями нужными, пользователь заполняет форму и данные отправляются на емейл. Или уже есть такой модуль? Или это очень просто делается формитами, аджаксформами или типа того?

Сложно придумать универсальный модуль под такое. Условий переноса может быть очень много (в том числе наличие пользователя в других более старших группах). А так-то такие вещи довольно просто реализуются, достаточно основных методов modUser::joinGroup() и modUser::leaveGroup().

Поправил. Спасибо за подсказку! Заработался видимо)

За апдейт — не за что! Сейчас уже новый выйдет :) Этот уже должен быть совсем стабильный.

Кавычки при чем. Мы же все-таки на форуме программистов, и каждый символ имеет значение.
ОК, если у вас там нет ковычек, тогда уже вопрос к самому феному.

Кавычки судя по всему нужны все-таки, только тогда уж одинарные в таком виде "{$ts|date_format:'-1 day'}"

Ясно. ОК.

Прощения-то совсем не за что просить))

Для разлогинивания заблокированных пользователей использую вот такой код в том же плагине:

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

С обновлением групп симпатичненько :)

P.S. Вопрос: часто у тебя вижу подобное:

$ctxQuery->select($modx->getSelectColumns('modContext', '', '', array('key')));

Чем тебя смущает такая конструкция?

$ctxQuery->select(array('key'));

Одним методом меньше.