Установщик ModX при обновлении не видит соединение в режиме обычного обновления, но видит в режиме расширенного - но не хочет перезаписывать базу, говорит префикс уже такой имеется.

не 2.0 случаем ставите?

1.4.6 на 1.5 Beta

1.4.6 на 1.5 Beta

доступ в личку скиньте

1.5.0 не ставьте

1.4.6 последняя стабильная

1.5.0 не ставьте

Поставь в dev ветку 2.0, а в master 1.4.6

Поставь в dev ветку 2.0, а в master 1.4.6

Ок

Ох ты ж, два дня не заходил и больше тысячи сообщений... Что-то стряслось?

Ох ты ж, два дня не заходил и больше тысячи сообщений... Что-то стряслось?

Евгений объяснял как будет работать 2.0. (%

Вот самое полезное из 1000 сообщений

@webber_12 со стороны все эти претензии смотрятся неболее чем троллинг. Давай объективно, по принципу вопрос-ответ. - Что такое Evo 2.0? Этот все тот же MODX Evolution, вот только под капотом будет уже не просто набор каких-то функций объединенных в класс под названием DocumentParser, а целый ряд компонентов на базе которых собран фреймворк Laravel. Это позволит нам не писать кучу документации и примеров про кешер, события, логирование, файловую систему, кофиги, консоль, миграции, сиды, шаблонизатор Blade, модели Eloquent, Observers, ServiceProvider... - Почему именно Laravel? Обширная документация. Активная поддержка. Множество готовых пакетов, которые можно будет использовать и на Evolution 2.0 У нас было 2 пути: работать и дальше с устаревшим кодом Evolution, пока это пипл хавает, а сообщество не разбежалось. Либо же начать писать новый проект стараясь максимально сохранить старую парадигму разрабокти с деревом ресурсов, чанками, сниппетами, ТВ параметрами и т.д. Но мы нашли третий путь и пытаемся адаптировать устаревший код сохраняя обратную совместимость. - В ветке 2.0 я смогу работать по старому? Да, можешь. Старые конструкции будут и дальше работать, но всю гибкость нововведений врятли раскроют. Банальный переход от массива $modx->config к методу $modx->getConfig() уже позволит манипулировать ситемными настройками движка, которые берутся из базы. А совершить такой переход в сниппетах можно уже сейчас даже не дожидаясь релиза 2.0, т.к. метод getConfig() есть и в версии 1.4. Плагины на события можно вешать как раньше через админку, так и через файлы. Все это упрощает коммандную разработку, упрощает ведение проекта через git. Кто этого ждет - постепенно оценят. Для всех остальных изменения будут не значительными. - Под Evo очень мало готовых решений. Не лучше ли поратить время на разработку того же магазина? Разработчиков, которые способны написать более или мнее вменяемое дополнение не осталось. Многим просто надоело говнокодить и изобретать велосипеды. Даже если рассмаривать на примере файловой системы, то: нет возможности работать с файлами (копировать, перемещать, удалять) и все это рекурсивно с правильной расстановкой прав которые выставлены в настроках движка. При работе с базой мы вынуждены постоянно заботиться об sql-injection, т.к. зачастую работа происходит с сырыми данными. При работе с шаблонами мы вообще ничего не можем - даже стандартный метод parseChunk по умолчанию не понимает плейсхолдеров. Таким образом, вместо того, чтобы разработчик мог сосредоточиться на бизнес логке приложения, он тратит кучу времени на то, чтобы реализовать одни и те же вещи. А потом этот разработчик выпускает еще одно решение и там опять нужно сделать эти же вещи. Так появляется копипаст, который приодится к использованию однотипных классов/функций/методов в разных компонентах - яркий пример phx. В общем не для 2018 года такие методы разработки. Таким образом, в Evo просто нет тех людей, которые бы могли что-то написать и поделиться решением. Поэтому прежде чем писать какие-то компоненты, мы хотим решить все эти проблемы и дать больше свободы разработчикам.

По существу же, на версии 1.4 мы не можем установить целый сайт 1 кнопкой. Не можем работать в дев-прод версии адекватно, не можем, олноценно использовать шаблоны в файлах. Нет миграций и бла-бла. В версии 2.0 это все есть и есть этим не умеешь пользоваться, то имхо, проблема далеко не в движке

Это как переход от нативных sqlзапросов на модели.

Те, кто работает с моделями в разных фреймворках прекрасно понимают в чем преимущество. Те, кто не умеют работать - думают, что и SELECT/INSERT/UPDATE прям в базу норм

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

https://github.com/beyondcode/laravel-er-diagram-generator

Установка это composer require, создание файла провайдера из 1 строчки

Актуальные связи моделей в 2.0

Вот тебе пакеты готовые https://packalyst.com/

Ты воспринимаешь все слишком серьезно. - Парсер MODX это было хорошо, пока в него не напихали всякого бреда в виде <IF> и т.п. непонятных модификаторов - ТВ это хорошо для кастомизации шаблонов. Но это плохо для больших каталогов. - Сниппеты это всегда было круто. Но не нужно программировать вызовами сниппетов - лучше обернуть сниппет из которого выполнить runSnippet - Чанки это тоже удобно, но не нужно весь сай резать начанки и каждый шаблон при вызове сниппета тоже туда пихать. Иначе самому потом сложно найти где и что. Приходится разматываь всю цепочку: документ->шаблон->чанк->сниппет->чанк. В чанках движка должны лежать только обособелнные представления (письма пользователеям, независимые блкои без вложенных вызовов чанков и т.п.). В вызовах сниппетов лучше использовать @CODE. - PHX модификаторы тоже удобны. Но ими тоже нужно пользоваться с умом. Становится большой проблемой, когда стоит PHX плагин. А сниппет пытается использовать свой PHX класс. В конечном теряется всякая логика что за что отвечает. Естественно, после очередного обновления велика вероятность, что что-то пойдет не так. Я лично исползую PHX только для проверки notempty

Где бы времени взять на изучение всего(

Буду спамить каждый день) EVO 2.0 - Собираем донат :) http://modx.im/blog/news/5744.html У кого не открывается modx.im смотрим тут http://modx-gu.ru/ Уже собрано: 599$

Всем привет. Ни у кого, случаем, сегодня не было заражений сайтов? У меня на таймвебе все аккаунты полегли. Пока не знаю, на что грешить. Версия везде свежая, но сайтам там лет по 8, обновлялись. Возможно, старые бэкдоры оставались. На одном сервере, кроме прочего, в корне файлы http://take.ms/EruZh На другом сервере в в подпапках tinymce прячется скрытая папка .X1-unix с сотнями файлов. Вопрос только в том, у одного меня такое, или это массовое явление, и ждать выпуска заплатки.

такая же фигня. Поставил патч, пролечил, через 2 дня сайт стерли полностью. Достал из бекапа - там опять вирус нашел с папкой X1-unix. В логах было обращение к ajaxserarch_popup

вот кстати айболит еще ругается на phpmailer 6.03. Есть смысл его обновлять, или не критично?

Не критичео

Р.gg GVbb ioo

Прошу прощения)

такая же фигня. Поставил патч, пролечил, через 2 дня сайт стерли полностью. Достал из бекапа - там опять вирус нашел с папкой X1-unix. В логах было обращение к ajaxserarch_popup

А на index-ajax.php ставили или он так и стоит с версии 0.9?

А на index-ajax.php ставили или он так и стоит с версии 0.9?

index-ajax - это уже пройденные грабли в 2016 году, если не раньше)) Не было этого на том проекте

На синем скрине был, потому и спросил:)

Просто ajaxSearch через него вроде работал

Хотя в июле прошлого года как раз от него отказались и перенесли функционал в ajaxSearchPopup.php ) может и дырку какую с собой прихватили туда

Там же из поста только теги вырезают

Типа $config = getUserConfigName((strip_tags($_POST['ucfg'])));

Всем привет! Ребята, кто-нибудь делал два сайта, на одном домене?

поддомен сделай

за поддомен думал. только такое решение? просто заказачик хочет, чтобы 2 сайта с одним доменом были связаны.. экономия видимо😂😂😂

Мне интересней другое, а что будет решать какой сайт показывать?

Просто домен то один

заказчик же не хочет показывать, он хочет чтобы связано было

просто две записи в домене сделать и все

Ой я туплю

Я что-то подумал что 2 разных сайта, а домен один

просто две записи в домене сделать и все

+

точно

чпасибо

спасибо***

раз заказчик умный такой, так пусть сам и придумает как это должно работать

а то))

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

они же практически все умнее 😂😂😂 и знают как всё делать

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

я уверен, что и джумла справится

я уверен, что и джумла справится

в джумле нет технической поддержки, с которой можно поговорить как партнер

в джумле нет технической поддержки, с которой можно поговорить как партнер

Тогда укоз 😊

я уверен, что и джумла справится

тссс... ща Лёха опять этомит достанет))

можно как-нибудь натравить codemirror на любую тв-шку ?

на textarea например

можно как-нибудь натравить codemirror на любую тв-шку ?

http://docs.evo.im/04_extras/codemirror.html

http://modx.im/blog/fast-solution/5811.html

http://modx.im/blog/fast-solution/5811.html

+

Установщик ModX при обновлении не видит соединение в режиме обычного обновления, но видит в режиме расширенного - но не хочет перезаписывать базу, говорит префикс уже такой имеется.

Была такая хрень. Так и не понял что это быпо. Обновлял БД через PhpMyadmin вручную.

В итоге помогло временное удаление. htaccess и смена версии пхп с 7 на 5.6

Друзья, посоветуйте, как все же правильно хранение товаров задизайнить: есть товары, для каждого задано: производитель и тип товара (грубо: Asus -> Ноутбуки). Хочется где-то хранить товары, чтобы у товаров были свойства "производитель" и "тип товара", но чтобы со списком было удобно работать и чтобы заполнение свойств было из списка заранее заданных величин. Можно пойти по пути: создать папку "Товары", в ней по папке на каждого производителя, в них по папке на каждый актуальный для производителя тип товаров (скажем, "LG -> Телевизор" бывает, а "Asus -> Телевизор" - не бывает). И уже товары заводить в иерархии "Каталог -> Марка -> Тип -> Каждый товар". А можно хранить в одно папке все товары плоско (их не очень много, и вдиным списком с ними даже удобнее, но завести по TV типа drop-down list для марки и типа товара, и во время редактирования наполнять - получается, из дерева из предыдущего варианта? Как сделать правильнее и разумее? Что посоветуют лучшие модиксоводы?

мы еволюрыводы

Друзья, посоветуйте, как все же правильно хранение товаров задизайнить: есть товары, для каждого задано: производитель и тип товара (грубо: Asus -> Ноутбуки). Хочется где-то хранить товары, чтобы у товаров были свойства "производитель" и "тип товара", но чтобы со списком было удобно работать и чтобы заполнение свойств было из списка заранее заданных величин. Можно пойти по пути: создать папку "Товары", в ней по папке на каждого производителя, в них по папке на каждый актуальный для производителя тип товаров (скажем, "LG -> Телевизор" бывает, а "Asus -> Телевизор" - не бывает). И уже товары заводить в иерархии "Каталог -> Марка -> Тип -> Каждый товар". А можно хранить в одно папке все товары плоско (их не очень много, и вдиным списком с ними даже удобнее, но завести по TV типа drop-down list для марки и типа товара, и во время редактирования наполнять - получается, из дерева из предыдущего варианта? Как сделать правильнее и разумее? Что посоветуют лучшие модиксоводы?

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

Друзья, посоветуйте, как все же правильно хранение товаров задизайнить: есть товары, для каждого задано: производитель и тип товара (грубо: Asus -> Ноутбуки). Хочется где-то хранить товары, чтобы у товаров были свойства "производитель" и "тип товара", но чтобы со списком было удобно работать и чтобы заполнение свойств было из списка заранее заданных величин. Можно пойти по пути: создать папку "Товары", в ней по папке на каждого производителя, в них по папке на каждый актуальный для производителя тип товаров (скажем, "LG -> Телевизор" бывает, а "Asus -> Телевизор" - не бывает). И уже товары заводить в иерархии "Каталог -> Марка -> Тип -> Каждый товар". А можно хранить в одно папке все товары плоско (их не очень много, и вдиным списком с ними даже удобнее, но завести по TV типа drop-down list для марки и типа товара, и во время редактирования наполнять - получается, из дерева из предыдущего варианта? Как сделать правильнее и разумее? Что посоветуют лучшие модиксоводы?

обычно делают на некие категории а потом уже фильтрация по бренду, типу и т.д.

можно хранить не в одной папке, а типа каталог - телевизоры - каждый товар, а бренды хранить в отдельной папке (:

Друзья, посоветуйте, как все же правильно хранение товаров задизайнить: есть товары, для каждого задано: производитель и тип товара (грубо: Asus -> Ноутбуки). Хочется где-то хранить товары, чтобы у товаров были свойства "производитель" и "тип товара", но чтобы со списком было удобно работать и чтобы заполнение свойств было из списка заранее заданных величин. Можно пойти по пути: создать папку "Товары", в ней по папке на каждого производителя, в них по папке на каждый актуальный для производителя тип товаров (скажем, "LG -> Телевизор" бывает, а "Asus -> Телевизор" - не бывает). И уже товары заводить в иерархии "Каталог -> Марка -> Тип -> Каждый товар". А можно хранить в одно папке все товары плоско (их не очень много, и вдиным списком с ними даже удобнее, но завести по TV типа drop-down list для марки и типа товара, и во время редактирования наполнять - получается, из дерева из предыдущего варианта? Как сделать правильнее и разумее? Что посоветуют лучшие модиксоводы?

Как вариант - добавить поля для id бренда и т. д. в site_content. Бренды и остальное хранить в глобальных настройках (модуль ClientSettings, например)

Кто-нибудь может подсказать что случилось с плагином ElementsInTree?

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

Ошибку я исправил попутно переписав весь плагин сохраняя обратную совместимость. Теперь приходит вот эта ошибка https://github.com/evolution-cms/evolution/issues/887 ? У нас что, до релиза тоже сотрировались элементы по имени?

Ошибку я исправил попутно переписав весь плагин сохраняя обратную совместимость. Теперь приходит вот эта ошибка https://github.com/evolution-cms/evolution/issues/887 ? У нас что, до релиза тоже сотрировались элементы по имени?

Да, по категории и имени. Я так понимаю, там используются номера столбцов в запросе, и может структура таблиц поменялась или еще что-то

Да, по категории и имени. Я так понимаю, там используются номера столбцов в запросе, и может структура таблиц поменялась или еще что-то

Удивительно, но я ничего такого не менял. Просто переформатировал код и функции объединил в класс. Сами же запросы даже не пробовал трогать.

Структура базы тоже не менялась.

Но понял, поправлю раз было по другому

Единственное, все равно не поняно. Как код плагина попал в базу после обновления. Ведь до 1.4.6 его никто не трогал

Единственное, все равно не поняно. Как код плагина попал в базу после обновления. Ведь до 1.4.6 его никто не трогал

Где-то костыль, закладка сработала)

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

первая причина, это плагин FileSource, который включен по умолчанию. Возможно его не устанавливали ранее, а теперь пропустили и он установился включенным. Далее по привычке, люди вместо отмены (чтобы закрыть), нажимают сохранить, и тем самым загоняют плагины в базу (поскольку включен FileSource). Затем они отключают плагин FileSource, а коды плагинов то уже в базе, и пути в тех файлах указаны относительно себя, а не абсолютные. Вот и косяки отсюда и лезут.

первая причина, это плагин FileSource, который включен по умолчанию. Возможно его не устанавливали ранее, а теперь пропустили и он установился включенным. Далее по привычке, люди вместо отмены (чтобы закрыть), нажимают сохранить, и тем самым загоняют плагины в базу (поскольку включен FileSource). Затем они отключают плагин FileSource, а коды плагинов то уже в базе, и пути в тех файлах указаны относительно себя, а не абсолютные. Вот и косяки отсюда и лезут.

Я тоже по началу грешил на этот плагин. Но проверил у себя - код как лежал в файле, так и дальше лежит

@Agel_Nash, такой вопрос (Или это уже к Pathologic)? В DocLister не делали, часом, вывод количества результатов выборки типа [dl.count] и того что выводится последний элемент типа [dl.isLast]. Или может есть варианты реализации какие-нибудь?