Накидайте интересных тем для статей
Ребята, привет!
У меня есть желание написать несколько полезных статей для вас. Давайте вместе поучаствуем в этом! Вы напишите темы, которые вас интересуют, а я выберу самые интересные из них и напишу статьи/инструкции/кейсы.
Важно:
— чтобы тематика касалась MODX, хоть каким-то боком,
— не начального, а хотя бы, среднего уровня, чтобы писать было не скучно,
— сразу излагайте вопрос/тему подробнее, чтобы мне не пришлось тратить время на уточняющие детали.
Жду отклика в комментариях!
У меня есть желание написать несколько полезных статей для вас. Давайте вместе поучаствуем в этом! Вы напишите темы, которые вас интересуют, а я выберу самые интересные из них и напишу статьи/инструкции/кейсы.
Важно:
— чтобы тематика касалась MODX, хоть каким-то боком,
— не начального, а хотя бы, среднего уровня, чтобы писать было не скучно,
— сразу излагайте вопрос/тему подробнее, чтобы мне не пришлось тратить время на уточняющие детали.
Жду отклика в комментариях!
Поблагодарить автора
Отправить деньги
Комментарии: 36
Будем надеяться, что это кто-то заметит. :)
На деле уже мало кому интересно. Хорошие технические статьи никто не читает, сразу бегут в вопросы спрашивать, а как вот тут кнопку из синей красной сделать. Или вот украл пакет с modstore, помогите его настроить, а то доку читать влом, за поддержку платить жаба душит всю жизни и прочее подобное :)
Хотелось бы больше статей НЕ для интернет-коммерции. Например интересен следующий момент. Есть сайт, самый обычный — example.ru. Необходимо сейчас на поддомене сделать некую логику рынка, где люди будут выставлять на обмен предметы:
market.example.ru
При этом используется одна БД (родного сайта), одна регистрация и авторизация (родного сайта), одна админка и т.д. Я не уверен какой это уровень, но я пока немного торможу с реализацией этого функционала. Будут ли конфликты при работе двух сайтов с одной БД? Какие подводные камни есть и т.д…
market.example.ru
При этом используется одна БД (родного сайта), одна регистрация и авторизация (родного сайта), одна админка и т.д. Я не уверен какой это уровень, но я пока немного торможу с реализацией этого функционала. Будут ли конфликты при работе двух сайтов с одной БД? Какие подводные камни есть и т.д…
Для этого достаточно использовать контексты, когда то они создавались именно для такого функционала и это было главной фишкой modx revo. Соответственно статей описывающих мультисайтовость на modx тьма
Про безопасный доступ для менеджера.
Из идей:
— если пользователь авторизовался и попытался стать sudo то проверять его по доверенным IP, и если он не окажется в этом списке то не давать ему доступа.
— запрет запуска сниппетов в поле content для менеджеров(хотя наверное даже для всех)
ну и другие пути решения для этого.
Из идей:
— если пользователь авторизовался и попытался стать sudo то проверять его по доверенным IP, и если он не окажется в этом списке то не давать ему доступа.
— запрет запуска сниппетов в поле content для менеджеров(хотя наверное даже для всех)
ну и другие пути решения для этого.
Павел, я с большим удовольствием почитал бы про работу самого MODX, в частности, мне не совсем понятно, зачем в базе данных хранятся сниппеты и чанки, почему нельзя выполнять их во внешних файлах? Полагаю, что это логика работы самого MODX, тогда хотелось бы знать почему именно был выбран этот вариант?
Раньше я работал на других платформах и не припомню, чтобы что-то подобное хранилось в базе, могу конечно ошибиться, если это так, то поправьте меня.
P.S. Может кому-то мой вопрос покажется глупым, поэтому сразу прошу не кидать в меня камнями :)))
Раньше я работал на других платформах и не припомню, чтобы что-то подобное хранилось в базе, могу конечно ошибиться, если это так, то поправьте меня.
P.S. Может кому-то мой вопрос покажется глупым, поэтому сразу прошу не кидать в меня камнями :)))
Чтобы хранить чанки и сниппеты в файлах достаточно использовать феном. А так, насколько я знаю — данный выбор был сделан потому, что хранить в базе раньше было быстрее чем в файловой системе
Не быстрее, а проще. В том плане, что все элементы, включая куски кода, были реализованы через xPDO, где элементы пол умолчанию хранятся в БД. Удобство было в том, что рядом с кодом можно было хранить и все его метаданные, т.е. название, описание, всякие связанные property sets и прочее. В том же October это вынесли в мета-заголовки в сами файлы, что выглядит просто ужасно, когда в одном файле мешанина из yaml, html и php.
Вау! Оперативно. Пока писал комментарий, Вы уже успели ответить :)
Павел, огромное Вам спасибо, что откликнулись на мой вопрос.
Если я Вас правильно понял, при использовании Fenom, чанки и сниппеты теперь дергаются из файлов, а не из базы? Если это так, то может отказаться от их хранения в базе, для чего они теперь там нужны, мне это не понятно? И еще я не совсем понял, что значит «хранить в базе раньше было быстрее чем в файловой системе»?
Если я Вас правильно понял, при использовании Fenom, чанки и сниппеты теперь дергаются из файлов, а не из базы? Если это так, то может отказаться от их хранения в базе, для чего они теперь там нужны, мне это не понятно? И еще я не совсем понял, что значит «хранить в базе раньше было быстрее чем в файловой системе»?
Ну я отказался. У меня все в файлах
Михаил, а можно чуть поподробнее, хотел тоже все подгружать из файлов, но пока отказался от этого. Хотелось бы у Вас узнать, чанки в итоге остались в базе?
нет, зачем. pdoTools + файловые элементы и все
Михаил, вот это уже круто! Спасибо Вам огромное за столь полезную информацию, не думал, что кто-то уже так работает, еще взвешу все за и против (почитаю комментарии) и потом приму окончательное решение, но чаша весов уже перевешивает в сторону использования файловых элементов в связке с pdoTools и удаления всего лишнего из базы.
В случае с феномом запускать сниппеты можно так:
А чанки вот так:
{'@FILE snippets/snippet.php' | snippet}
где «snippets/snippet.php» путь до файла относительно корневой папки pdoToolsА чанки вот так:
{include 'file:chunks/chunk.tpl'}
Если это так, то может отказаться от их хранения в базе, для чего они теперь там нужны, мне это не понятноЯ предпочту вариативность его отсутствию например
Ещё вариант — добавить свои собственные теги
{snippetFile 'snippet'}
{chunkFile 'chunk'}
В которых прописать и путь и всю логику. Я писал как это легко сделать.
Павел, спасибо Вам за такие подробные разъяснения, долго думал переходить на Fenom или нет, в итоге решился использовать его видимые преимущества. Но одно меня все же не устраивает — это хранение в базе чанков, просто я не вижу необходимости там их хранить при использовании полного функционала Fenom, Вы только не подумайте, что я против вариативности, нет, я обеими руками за, но по-моему (мое сугубо личное мнение), было бы не плохо предусмотреть, если я использую статичные файлы, то из базы они удаляются, ну и для удобства, которое все так любят, можно предусмотреть загрузку этих файлов в админку — для редактирования, и наоборот, не хочешь использовать статичные файлы — ради Бога, используй как есть. Вообщем мое видение данного вопроса я озвучил. Критика приветствуется :))) Ибо из таких разных и новых идей рождается, что-то новое.
, было бы не плохо предусмотреть, если я использую статичные файлы, то из базы они удаляютсяВ случае с феномом статичные файлы туда и не добавляются, чтобы удалятся
Прочитал снова свой комментарий и понял, что мысль сформулирована не понятно. Я имел ввиду следующее, вот смотрите, например, какой-то чанк, некоторого сниппета по умолчанию хранится в базе данных, когда я ставлю чекбокс «Статичный», то чанк теперь хранится во внешнем файле, но и в базе данных запись об этом чанке остается, хотя логичнее было бы эту запись от туда удалить (зачем в базе хранить лишние данные?) и работать уже только со статичным файлом. Кстати, только что, нашел статью Сергея — «Fenom. Загрузка чанков и сниппетов из файлов». Сейчас изучу, потестирую, и если все понравится, то реализую на своем проекте.
Статья устарела. Всё описанное работает из коробки.
Да, я это уже понял, но все равно интересно почитать, оказывается что Вы уже над этим давно задумались, а я только-только до этого дошел, не задумывался раньше об этом, делал по старинке. Если честно признаться, не особо следил за нововведениями, теперь исправлюсь, так как новые наработки не так уж и плохи, и было бы большой ошибкой их не использовать.
Пошел дальше изучать.
Пошел дальше изучать.
И еще я не совсем понял, что значит «хранить в базе раньше было быстрее чем в файловой системе»?Не быстрее конечно. Просто удобнее для реализации концепции параметров у сниппетов и чанков. Кстати очень удачная вещь получилась.Для плагинов — это события.Тоже очень удобная реализация интерфейса.
А лично меня полностью устраивает возможность хранить чанки и сниппеты в базе, и править всё это в админке, разбивать по категориям с несколькими уровнями вложенности. Разницу в скорости по сравнению с файлами почувствовать сложно, зато удобство очевидно. По крайней мере лично для меня) Попадались сайты, которые были сделаны на файлах. По мне так треш полный. Куча чанков и сниппетов разбиты по папкам, замотаешься искать, что куда вложено, от чего зависит. А некоторые программисты слишком ответственно подходят к этому делу. Как разобьют всё на чанки, так потом приходится 20 окон открыть, чтобы какую-нибудь небольшую штуку добавить. Отрыл шаблон — там ссылка на другой шаблон — там ссылки на чанки, в чанках на другие чанки, а там в каждом ещё по пять ссылок… И всё это в отдельных файлах, разбитых по куче папок. Думаешь, нафик эти извращения))
В связи с этим хотелось бы узнать опыт грамотных программистов. Лично я стараюсь как можно меньше плодить чанков и шаблонов. В идеале, 2-3 шаблона, и штук 5-7 чанков касающихся вёрстки. Не считая чанков разных дополнений.
В связи с этим хотелось бы узнать опыт грамотных программистов. Лично я стараюсь как можно меньше плодить чанков и шаблонов. В идеале, 2-3 шаблона, и штук 5-7 чанков касающихся вёрстки. Не считая чанков разных дополнений.
Да, также работаю. Благо fenom позволяет минимизировать количество чанков и шаблонов.
Николай, я тоже не вижу необходимости городить огород, использую шаблоны и чанки по минимуму.
Павел, класс!
Было бы классно про создание CMP и сборку пакетов. Я знаю, что есть примеры Василия Наумкина и Боба Рея, на классно было бы альтернативу изучить.
Особенно волнуют вопросы добавления сложных кастомных полей (как товаров, так и ресурсов). Например добавление поля ресурса с типом «автотег» (как tvSuperSelect, но без ТВ). Или добавление полей изображений.
Очень интересно, как подключать дополнительные JS-модули и использовать их функционал – например, сделать поле ресурса с рендером картинки, которую можно «кропнуть» кастомным кроппером и сохранить в файл.
Также интересно почитать про методы оптимизации скорости загрузки сайта на fenom.
Я пользуюсь нормальным shared-хостингом, но интересно почитать про настройку MODX на выделенном серевере.
Было бы классно про создание CMP и сборку пакетов. Я знаю, что есть примеры Василия Наумкина и Боба Рея, на классно было бы альтернативу изучить.
Особенно волнуют вопросы добавления сложных кастомных полей (как товаров, так и ресурсов). Например добавление поля ресурса с типом «автотег» (как tvSuperSelect, но без ТВ). Или добавление полей изображений.
Очень интересно, как подключать дополнительные JS-модули и использовать их функционал – например, сделать поле ресурса с рендером картинки, которую можно «кропнуть» кастомным кроппером и сохранить в файл.
Также интересно почитать про методы оптимизации скорости загрузки сайта на fenom.
Я пользуюсь нормальным shared-хостингом, но интересно почитать про настройку MODX на выделенном серевере.
Было бы интересно если бы появился хороший рассказ, возможно с небольшими примерами про modRestCotroller там кстати несколько классов. Причем я уверен что это интересно было бы далеко не только мне.
Было бы также не плохо там затронуть момент регистрации и авторизации в modx.
Было бы также не плохо там затронуть момент регистрации и авторизации в modx.
Да, по авторизации – плюсую! И классно было бы узнать больше про создание страниц для авторизованных пользователей на сайте. Например, личный кабинет клиента.
А официальная документация не устраивает?
Ну нет, она ни какая. Вот именно по ресту. И судя по кол-ву вопросов про него по всему интернету, видимо не только меня не устраивает ее скудность.
Ну не знаю. Мне кажется, что у человека, столько лет работающего с MODX, вопросов быть не должно.На любой вопрос можно найти ответ в исходниках.
Ещё было бы классно узнать про работу с контекстами. Например, есть несколько сайтов региональных на поддоменах. Задача создавать ресурсы в одном контексте, а в других – выводить те же ресурсы, но со своими переменными (город, телефон) и своими чанками (например, отзывы, карта офиса).
В то же время оставлять возможность создавать ресурсы, которые видны только в определённом контексте.
В то же время оставлять возможность создавать ресурсы, которые видны только в определённом контексте.
посмотрите возможности компонента cityFields
Интересует REST API для создания, обновления, удаления ресурсов, товаров, категорий, изображений в галерее. Реализация для MODX2 (мб компонент), а также для MODX3
А авторизация запросов к апи вам при этом разве не интересна?
Да, конечно
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.