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

Всё возможно, только нужно указать им разный &pageVarKey.

Правильно.

Страница, на которой указан неверный параметр для сниппета, не перестаёт существовать.

Подумать совсем лень?

[[!pdoPage?
	&parents=`0`
	&sortby=`[[!#get.sort:default=`id`]]`
	&sortdir=`[[!#get.dir:default=`asc`]]`
	&showLog=`1`
]]

Активационную ссылку просто так не создать. Для этого нужно как бы сбросить пароль заново, сохранить его еще на 3 часа и отправить уже ссылку, по которой он будет активирован.

Компонент Office делает так из коробки. Если пытается войти неактивированный юзер — он получает новое письмо со ссылкой на активацию.

По идее, просто [[+comment]].

Конечно.

А у меня путь указать, который кстати, можно и не указывать, это невероятно сложно. Улыбнуло.

И у меня можно путь не указывать, тоже есть директория по умолчанию. Но лично я этим сам не пользуюсь — или @INLINE чанки, или обычные. Файловые не прижились, почему-то.

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

Но почему-то не сделано. Почему, интересно? Наверное потому, что я по-прежнему не вижу никакой выгоды это делать.

Если только «чтобы было».

[[!любойсниппетсpdotools?
	&tpl=`@FILE имяфайла.tpl`
	&tplPath=`путь\к\директории\с\шаблонами`
]]

Если нужно без pdoTools, то просто еще один сниппет loadChunk:

<?php
return file_get_contents($path_to_file);

Пока я вижу только усложнение работы без явной выгоды. Указывать пути, отказываться от наборов параметеров, echo вместо return — зачем это всё?

Проблему деплоя это не решает, потому что вызовы сниппетов и чанков кто-то еще должен прописать в шаблонах или ресурсах — а их как делать статическими? Всё равно нужен какой-то скрипт распаковки, или установочный пакет.

А если у нас должен быть установочный пакет, то он и так всё может собрать — и сниппеты и чанки, и наборы параметров, и шаблоны, и ресурсы. Собственно, Theme.Bootstrap является простейшим примером такой установки.

Лично я так же пакетами разворачиваю изменения на modstore.pro и на modhost.pro — проблем пока не было.

Чанки уже давным-давно можно вызывать из файлов через @FILE, так что о них смысла спорить нет.

А какой профит будет от вызова сниппетов? Их что, 50 штук на странице вызывается, чтобы только от способа вызова оно тормозило? Сомневаюсь. Евгений свои исследования давно делал, с тех пор много версий MODX сменилось — нужно перепроверять.

И если очень хочется сниппеты из файлов, в любом месте, смотри как это просто:

<?php

return include $path_to_file;

Сниппет loadSnippet, который грузит любой код из файлов. Кажется, я это даже где-то уже видел на продакшене.

В общем, еще раз, нужны тесты производительности.

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

С этого нужно было начинать. Без серьёзного улучшения производительности говорить не о чем.

На мой взгляд вряд ли сниппеты станут работать быстрее, ибо они и сейчас все кэшируются в /core/cache/includes/elements/, а потом подключаются как файлы.

В общем жду экспертную оценку моего творчества. Какие подводные камни могут быть? Нужно ли включать такой функционал в pdoTools?

Я считаю, что нет, не нужно.

Со времен Evolution в любом сниппете можно сделать

include 'file.php';

и работать с файлами. Есть статические элементы, есть Gitify, есть установочные пакеты (лично я переношу изменения через них).

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

Нет, ничего такого нет.

Можно только сохранить комментарий в заказ и всё, никаких писем при этом не придёт.

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

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

Советую просто отключить виджет, потому что исправлять это, похоже, никто не планирует.

Конечно!

В основном классе для этого есть специальные методы.

Исходники Office открыты, можно посмотреть.

Речь о том, что сейчас в modExtra есть таблица в БД, для которой есть интерфейс внутри админки, и снаружи сайта.

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

Мне это давно надоело и тогда я придумал написать Office, который позволяет работать с юзером на фронтенде и не забивать себе голову сложностями. Пишешь контроллер, кладёшь его куда надо, забиваешь в нём методы и можешь обращаться к ним как

[[!Office?
	&action=`ИмяКонтроллера\ИмяМетода`
]]

Таким же способом ты можешь обращаться и к другим методам через Ajax, просто отправляя нужный action на /assets/components/office/action.php.

Заодно добавил всякие вещи, чтобы было просто на фронтенде использовать Ext JS для крутого функционала. Именно этот пример теперь можно увидеть в modExtra.

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

Например я уже делаю кое-что новое для modstore.pro.

Если показывается главная страница вместо нужно — дело явно в правах доступа.

Я даже зарегистрироваться не могу — сервер не отвечает. Видимо, отправка почты не работает.

Пришло письмо, щас гляну.

Глянул, с авторизацией всё ок, дальше снаружи ничего не понятно. Если компоненты куплены — задавай вопросы в поддержке магазина и пиши сразу доступ к админке.

Доступна новая версия, в которой загрузка файлов выглядит вот так:

Окошко и таблицу выкинул совсем, всё стало гораздо быстрее и удобнее.

Я его даже начал делать (officeModExtra) и на середине понял, что дублирую практически всё от modExtra.

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

1% больше чем 0%.

Для меня достаточная причина, что я сам этим воспользуюсь и не один раз =)