пока ни в чем, приобрел вон курс Васин, дома не завелось, хочу на работе проверить, чтобы не пытать зря автора

У тебя же мак. Там все просто ставится

Можно ли в принципе вывести графики на сайте по созданным ресурсам ?

К примеру есть у ресурса TV поле "статус" и можно ли вывести по дням, когда какой статус был у ресурса ?

К примеру есть у ресурса TV поле "статус" и можно ли вывести по дням, когда какой статус был у ресурса ?

Понял, тоесть при изменении статуса нужно, чтобы он в бд сохранял статус и его дату

Понял, тоесть при изменении статуса нужно, чтобы он в бд сохранял статус и его дату

Почему большинство разрабатывает и фронт и бэк на пк а не на хостинге?

ставите ноду, пакеты?

Ну тут этим 95 процентов не пользуется вообще

Стили, хтмл и яваскрипт)

подскажите, если ресурс опубликован, но у него снята галочка "доступен для поиска", он будет индексироваться роботами?

у Вани еще и pug

И всех призываю попробовать)

Причем тут питон и вёрстка?

Подозреваю что они как бекенд шаблонизатор pug используют, в го, кстати, тоже сильно популярен pug для бекенд шаблонизации Кстати, а причем тут верстка и pug?) Это же исконно нодовский шаблонизатор

добрый день, подскажите в чем проблема, при переходе внутри каталога на карточку (не минишоп), формируется дублируемый url (например: .../catalog/catalog/...)

Просто какие то ушлые ребята его зачем то стали использовать чтобы генерировать из него html

удобно

а открывается или 404?

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

подскажите что можно с этим сделать, чтобы не ковырять весь сайт и robots.txt?

Почему большинство разрабатывает и фронт и бэк на пк а не на хостинге?

Причем тут питон и вёрстка?

Ivan Bochkarev :modx: 16:54 Hi all! Why not take as a basis zoomx or pdootools Mark Hamstra :без_рта: 16:55 I've not personally worked with zoomx so not too familiar with how it works 16:56 But yeah that does seem closely related to several of the topics

Ну хотя бы за иниересовались

По поводу #ZoomX, вот лично я несколько раз пытался понять, зачем мне его пробовать (ну типа, надо же чтобы была какая-то нерешенная проблема, какая-то боль, которую исправит новое решение, относительно того, которое сейчас) и честно, после всех статей, после уточнений в комментариях на modx.pro — я сделал вывод что для сборки веб-сайтов (не сервисов и порталов конечно), если не использовать SPA с фронтенд-шаблонизацией, для которого нужен развитый бекенд-апи (а для веб-сайтов оно нафиг не нужно), всё же нет у него преимуществ перед modx/pdo-parser+fenom. Судя по шумихе вокруг него, похоже, это решение офигенно заходит тем, кто переходит на MODX с других фреймворков, какой-то парадигмой, применяемой в других системах, но всё что например я видел вне MODX - было намного страшнее чем modx-парсер и fenom. Хоть синтаксис у fenom и ужасный по сравнению в modx-тегами)) Ну так в smarty как я понял, он такой же...

Сейчас наблюдаю беду с документацией по компонентам, и наличию компонентов, очень много неактульного, многие пакеты вообще пропали с modstore

По поводу #ZoomX, вот лично я несколько раз пытался понять, зачем мне его пробовать (ну типа, надо же чтобы была какая-то нерешенная проблема, какая-то боль, которую исправит новое решение, относительно того, которое сейчас) и честно, после всех статей, после уточнений в комментариях на modx.pro — я сделал вывод что для сборки веб-сайтов (не сервисов и порталов конечно), если не использовать SPA с фронтенд-шаблонизацией, для которого нужен развитый бекенд-апи (а для веб-сайтов оно нафиг не нужно), всё же нет у него преимуществ перед modx/pdo-parser+fenom. Судя по шумихе вокруг него, похоже, это решение офигенно заходит тем, кто переходит на MODX с других фреймворков, какой-то парадигмой, применяемой в других системах, но всё что например я видел вне MODX - было намного страшнее чем modx-парсер и fenom. Хоть синтаксис у fenom и ужасный по сравнению в modx-тегами)) Ну так в smarty как я понял, он такой же...

По поводу #ZoomX, вот лично я несколько раз пытался понять, зачем мне его пробовать (ну типа, надо же чтобы была какая-то нерешенная проблема, какая-то боль, которую исправит новое решение, относительно того, которое сейчас) и честно, после всех статей, после уточнений в комментариях на modx.pro — я сделал вывод что для сборки веб-сайтов (не сервисов и порталов конечно), если не использовать SPA с фронтенд-шаблонизацией, для которого нужен развитый бекенд-апи (а для веб-сайтов оно нафиг не нужно), всё же нет у него преимуществ перед modx/pdo-parser+fenom. Судя по шумихе вокруг него, похоже, это решение офигенно заходит тем, кто переходит на MODX с других фреймворков, какой-то парадигмой, применяемой в других системах, но всё что например я видел вне MODX - было намного страшнее чем modx-парсер и fenom. Хоть синтаксис у fenom и ужасный по сравнению в modx-тегами)) Ну так в smarty как я понял, он такой же...

Можешь набросать какую то расширенную аналитику? Будет понятнее с чем работать, на что силы привлекать

Ну вот тебе на вскидку несколько вещей которые для меня решил ZommX: 1)Циклический парсинг шаблонов, чанков - даже fenom всё равно это делает, а это всё во вред времени ответа, ZoomX делает это всё за один проход, результат не то, чтобы прямо громадный, но он есть. 2)Все строительные элементы сайта, кроме тв-полей, хранятся исключительно в файлах, а это версионный контроль, да и возможностей там чуток больше. 3)Возможность завести API, не всегда нужно, но когда есть возможность это уже +

На правах здоровой дискуссии, не умаляя пользы и описанных преимуществ всё же отвечу по каждому пункту: 1) Да, за 1 проход быстрее, но и сейчас оно не работает медленно. Конечно, в каждом проекте своя «планка качества», но вот пара кейсов: я думаю тут многие заметили что я заморачиваюсь по скорости, так вот, в среднем бекенд на более-менее сложной странице сайта отрабатывает где-то за 250мс, сейчас ещё раз проверил 3 проекта. На простой странице - около 100мс. Если фронтенд очень хорошо оптимизирован (скажем 90+ баллов #pagespeed на мобиле, и 98+ на ПК) бекенд занимает от четверти до половины всего времени ожидания загрузки страницы! Плюс к этому, если использовать service worker или prefetch запросы на фронтенде, можно и эти 100-250мс пользователя не заставлять ждать. У меня есть проекты где от клика до события load проходит менее 100мс суммарно на всё. То есть для меня нет проблемы медленного бекенда на pdoTools. Можно ещё быстрее? Можно! Надо? Ну в мире ИТ почти всегда можно где-то что-то улучшить. Вплоть до подсчета MHz на хостинге (у меня 3.8 к стати). По заверению автора ZoomX, прироста даже в 2 раза с ним точно не будет. В не-синтетических условиях. Мы сейчас не рассматриваем страницы, где какой-нибудь долгий запрос в БД всё затормозит, это с любым шаблонизатором одинаково. 2) Я уже с ~2014 года все элементы храню в гите, MODX увидел с версии 2.0.4 (вроде, рево был молод) и вроде там уже была галка "статичный" у любых элементов, ну если её ктото не нажимает, то я не в курсе почему. Возможность писать код в браузере меня вааащще не впечатлила и я её пользовался за прошедшие ~10 лет для "тушения пожара" ну может не более 5 раз в год. Вообще не понимаю эти разговоры про статичные элементы, и pdoTools это анонсировал как фичу (ну там хоть без создания в админке, хотя мне не сложно кликнуть 2 раза в ней, и StaticSaver юзаю давно, а теперь новый StaticElementsLive ) 3) Возможность сделать api по-лайту у меня и так есть (тип ресурса - xml/json и свой сниппет), а по харду... ну как я и сказал сразу, для веб-сайтов без SPA это не нужно, ну плюс да, однако не болит, проблемы не ощущается без это фичи на modx+fenom

А ну да и совсем забыл, адекватный кэш, к нему ещё допились хороший кэш-менеджер на замену стандартному, чтобы не всё сносить при любом чихе, а точечно, только то, что нужно и будет вообще конфетка

На правах здоровой дискуссии, не умаляя пользы и описанных преимуществ всё же отвечу по каждому пункту: 1) Да, за 1 проход быстрее, но и сейчас оно не работает медленно. Конечно, в каждом проекте своя «планка качества», но вот пара кейсов: я думаю тут многие заметили что я заморачиваюсь по скорости, так вот, в среднем бекенд на более-менее сложной странице сайта отрабатывает где-то за 250мс, сейчас ещё раз проверил 3 проекта. На простой странице - около 100мс. Если фронтенд очень хорошо оптимизирован (скажем 90+ баллов #pagespeed на мобиле, и 98+ на ПК) бекенд занимает от четверти до половины всего времени ожидания загрузки страницы! Плюс к этому, если использовать service worker или prefetch запросы на фронтенде, можно и эти 100-250мс пользователя не заставлять ждать. У меня есть проекты где от клика до события load проходит менее 100мс суммарно на всё. То есть для меня нет проблемы медленного бекенда на pdoTools. Можно ещё быстрее? Можно! Надо? Ну в мире ИТ почти всегда можно где-то что-то улучшить. Вплоть до подсчета MHz на хостинге (у меня 3.8 к стати). По заверению автора ZoomX, прироста даже в 2 раза с ним точно не будет. В не-синтетических условиях. Мы сейчас не рассматриваем страницы, где какой-нибудь долгий запрос в БД всё затормозит, это с любым шаблонизатором одинаково. 2) Я уже с ~2014 года все элементы храню в гите, MODX увидел с версии 2.0.4 (вроде, рево был молод) и вроде там уже была галка "статичный" у любых элементов, ну если её ктото не нажимает, то я не в курсе почему. Возможность писать код в браузере меня вааащще не впечатлила и я её пользовался за прошедшие ~10 лет для "тушения пожара" ну может не более 5 раз в год. Вообще не понимаю эти разговоры про статичные элементы, и pdoTools это анонсировал как фичу (ну там хоть без создания в админке, хотя мне не сложно кликнуть 2 раза в ней, и StaticSaver юзаю давно, а теперь новый StaticElementsLive ) 3) Возможность сделать api по-лайту у меня и так есть (тип ресурса - xml/json и свой сниппет), а по харду... ну как я и сказал сразу, для веб-сайтов без SPA это не нужно, ну плюс да, однако не болит, проблемы не ощущается без это фичи на modx+fenom

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

Я понимаю, запросов много в базу, чем больше, тем хуже, но ты же прочитал мой пункт 1? Если скорость в 100-250мс с учетом всего что там происходит, вполне подходит и тенденция к тому что её перестанет хватать, особо не прослеживается, зачем использовать что-то другое?

Ну ты же сам написал, есть всегда что-то улучшить, вот я и улучшаю)

Тут главное баланс соблюдать🤪 К сожалению на практике тюнить бекенд, где ты можешь отыграть 100-200мс адскими усилиями, при том, что на фронте 3000мс++ затупы, довольно нерационально 😄 Ну нет проблемы тормозного бекенда в MODX. Отсутствует она! Только если захотеть специально сделать, или прям совсем в лоб что-то писать, не используя возможностей системы по оптимизации...

Я бы ещё проще описал, почему мне лично с ZoomX работается легче, собственно эту идею Сергей-автор компонента и продвигал, это когда переключаешься с проекта на фреймфорке на MODX и не чувствуешь дискомфорта, на самом деле, чувствуешь, но когда там ZoomX, не такой сильный)

Если мы продолжаем про ZoomX - то это скорее не про скорость, а про удобство, а я очень люблю комфорт в разработке