Молчаливая ошибка в адм, if переименовать assets
modx revo 2.3.2, Ace 1.5.0
Заметил такой артефакт. Если переименовать папку assets, а в /core/config/config.inc.php оставить без изменений, то при загрузке админки (например, загрузка страницы для какого-нибудь сниппета) правая часть окна останется пустой. При этом:
а) никаких ошибок в логах php/apache (уровень логирования — максимальный)
б) никаких ошибок в логах modx (уровень логирования «warnings»)
в) ручная очистка кэша modx ничего не меняет
Понятно, что причина здесь в Ace (хотя, кто его знает, может, modx виноват). Но таких ситуаций в корректной программной системе быть не должно. Либо нужно отказываться от компонентов, приводящих к таким ситуациям, либо найти быстрый способ выявления причины без трассировки кода.
P.S. Почему-то заголовок темы сильно ограничен в длине. Всё время приходится ужиматься.
Заметил такой артефакт. Если переименовать папку assets, а в /core/config/config.inc.php оставить без изменений, то при загрузке админки (например, загрузка страницы для какого-нибудь сниппета) правая часть окна останется пустой. При этом:
а) никаких ошибок в логах php/apache (уровень логирования — максимальный)
б) никаких ошибок в логах modx (уровень логирования «warnings»)
в) ручная очистка кэша modx ничего не меняет
Понятно, что причина здесь в Ace (хотя, кто его знает, может, modx виноват). Но таких ситуаций в корректной программной системе быть не должно. Либо нужно отказываться от компонентов, приводящих к таким ситуациям, либо найти быстрый способ выявления причины без трассировки кода.
P.S. Почему-то заголовок темы сильно ограничен в длине. Всё время приходится ужиматься.
Комментарии: 22
Зачем это здесь? Нужно задавать вопросы MODX или автору дополнения Ace.
github.com/modxcms/revolution/issues/new
github.com/danyaPostfactum/modx-ace/issues/new
github.com/modxcms/revolution/issues/new
github.com/danyaPostfactum/modx-ace/issues/new
Прежде хочу убедиться, что данный артефакт наблюдается не только у меня.
В плагине MinifyX папка assets прописана железно (в 2 местах).
В остальных исходниках — всё нормально.
В остальных исходниках — всё нормально.
Не железно, а значением «по умолчанию», которое подставляется, если нужный системный параметр пуст или отсутствует.
Ну так как раз в качестве этого «умолчательного» значения
'/assets/components/minifyx/cache/'
(и в плагине, и в настройке «minifyx_cacheFolder» при установке компонента) корректнее брать $modx->getOption('assets_path').'components/minifyx/cache'
Ну так пришли pull-request в репозиторий.
Я не могу понять зачем это извращение с переименовыванием папки assets?
В целях безопасности. Так же, как и переименовывание папок core, manager, connectors, _build и setup.
В целях какой безопасности?
Директория assets раскрывается просмотром исходного HTML, в котором видно, откуда подключены скрипты и стили дополнений.
Директория assets раскрывается просмотром исходного HTML, в котором видно, откуда подключены скрипты и стили дополнений.
Поприветствуем Тайного Поклонника.
В целях какой безопасности?Как известно, папка «assets» является одним из способов идентификации используемой CMS. А когда известна используемая CMS, ломать сайты в разы проще. Иными словами, скрывая папку assets (при соблюдении прочих «маскировочных» мер), мы существенно снижаем риск взлома сайта.
Заодно скрой имена minishop2, tickets, minifyx и других дополнений, подключающих скрипты и стили из новой неизвестной папки.
Речь об именах папок дополнений внутри assets?
Этот вопрос полностью решается, например, заменой всех подключаемых в html файлов вызовом специального скрипта, которому в качестве параметра передаётся обратимый хэш с ключом от имени подключаемого файла. Делать это плагином в OnWebPagePrerender или OnWebPageComplete с помощью регулярки и только для неразработчиков.
А содержимое подключаемых скриптов и стилей (в том числе в составе html) можно обфусцировать так, чтобы имена переменных, констант и css-классов там тоже были минимизированы.
Этот вопрос полностью решается, например, заменой всех подключаемых в html файлов вызовом специального скрипта, которому в качестве параметра передаётся обратимый хэш с ключом от имени подключаемого файла. Делать это плагином в OnWebPagePrerender или OnWebPageComplete с помощью регулярки и только для неразработчиков.
А содержимое подключаемых скриптов и стилей (в том числе в составе html) можно обфусцировать так, чтобы имена переменных, констант и css-классов там тоже были минимизированы.
Не зря же в настройках config.core.php предусмотрели константы
MODX_ASSETS_PATH и MODX_ASSETS_URL
MODX_ASSETS_PATH и MODX_ASSETS_URL
Если переименовать папку assets, а в /core/config/config.inc.php оставить без измененийЕсли ты переименовываешь директорию и не меняешь конфиг — тебе ничего не поможет.
Не зря же в настройках config.core.php предусмотрели константыКоторые будут неверными, если ты не отредактировал config.inc.php.
В общем, с тобой как обычно — нашел «очередной фатальный недостаток» в системе и раздул из мухи слона.
Хоть я и зарекался с тобой вообще разговаривать, но опять не сдержался.
Либо нужно отказываться от компонентов, приводящих к таким ситуациям, либо найти быстрый способ выявления причины без трассировки кода.Либо подумать головой и понять, что в assets находятся скрипты, стили и коннекторы, к которым обращается UI.
Оттуда не подключаются php файлы, ядру MODX вообще не нужна эта директория для работы, поэтому на уровне php никаких ошибок нет и быть не должно.
Они все в консоли браузера:
Так это и есть:
Т.е. если папка не существует, то код элемента должен нормально отображаться в правой панели, но без Ace. Мне должная логика работы видится именно такой.
Сейчас же (при установленном Ace с корректным кодом) modx'у для реализации собственного базового функционала (отображение кода элемента) требуется папка assets.
либо найти быстрый способ выявления причины без трассировки кода.
ядру MODX вообще не нужна эта директория для работыОтображение правой панели (с кодом элемента/файла и пр.) — это базовый функционал modx, который не должен зависеть от дополнительно установленных компонентов (с корректным кодом) и наличия папки $modx->getOption('assets_path')
Т.е. если папка не существует, то код элемента должен нормально отображаться в правой панели, но без Ace. Мне должная логика работы видится именно такой.
Сейчас же (при установленном Ace с корректным кодом) modx'у для реализации собственного базового функционала (отображение кода элемента) требуется папка assets.
Еще раз, если не понятно. У MODX директория assets пуста по умолчанию. В репозитории её и вовсе нет.
В этой директории живут файлы дополнений, которые (о боже!) могут изменять внешний вид админки. Более того, они могут её даже сломать, если какой-то умник переименовал их директорию и не указал новый путь в конфиге.
И тогда дополнение пытается подключить свои файлы из несуществующей директории, и может сломать при этом админку.
Это не из-за MODX, это из-за тебя.
В этой директории живут файлы дополнений, которые (о боже!) могут изменять внешний вид админки. Более того, они могут её даже сломать, если какой-то умник переименовал их директорию и не указал новый путь в конфиге.
И тогда дополнение пытается подключить свои файлы из несуществующей директории, и может сломать при этом админку.
Это не из-за MODX, это из-за тебя.
Моё резюме по сабжу:
Риторический вопрос: позволяет ли текущая архитектура modx отобразить в админке содержимое элемента, если установлен Ace и папки assets не существует? Это я к тому, что текущее поведение modx не является единственно возможным и абсолютно верным. Технически возможна, например, более устойчивая реализация (дополнительные проверки существования файлов), когда при отсутствии папки assets modx нормально отобразит содержимое элемента при установленном Ace (или других плагинах), но без подсветки кода.
А текущее поведение modx следует принять как есть, не впадая в крайности типа "только так и должно быть" или "это фатальная проблема".
Риторический вопрос: позволяет ли текущая архитектура modx отобразить в админке содержимое элемента, если установлен Ace и папки assets не существует? Это я к тому, что текущее поведение modx не является единственно возможным и абсолютно верным. Технически возможна, например, более устойчивая реализация (дополнительные проверки существования файлов), когда при отсутствии папки assets modx нормально отобразит содержимое элемента при установленном Ace (или других плагинах), но без подсветки кода.
А текущее поведение modx следует принять как есть, не впадая в крайности типа "только так и должно быть" или "это фатальная проблема".
MODX запускает установленный плагин, тот подключает свои скрипты. MODX не может отвечать за то, как работает плагин и что он делает.
В этом и есть основной смысл плагинов и дополнений — изменить работу систему.
Расскажи, пожалуйста, как ты планируешь делать «более устойчивую реализацию» обработки такого плагина?
В этом и есть основной смысл плагинов и дополнений — изменить работу систему.
Технически возможна, например, более устойчивая реализация (дополнительные проверки существования файлов)Если я установлю плагин на событие OnManagerPageInit и напишу там
die();
админка сломается полностью, и починится только через удаление плагина из БД и кэша. Расскажи, пожалуйста, как ты планируешь делать «более устойчивую реализацию» обработки такого плагина?
— modx запускает плагин
— плагин проверяет существование нужных файлов (если их нет, выводит сообщение в логи и ничего фатального не делает)
— modx продолжает выполнение собственного кода (отображает код элемента)
— плагин проверяет существование нужных файлов (если их нет, выводит сообщение в логи и ничего фатального не делает)
— modx продолжает выполнение собственного кода (отображает код элемента)
— плагин проверяет существование нужных файлов (если их нет, выводит сообщение в логи и ничего фатального не делает)И причем здесь MODX? Он не может и не должен контролировать выполнение плагина.
Задавай вопрос автору Ace. Он у меня, кстати ничего не ломает.
У меня вся правая часть при отображении элемента пуста (и в Firefox, и в Chrome).
Firefox:
Ну да и ладно. Хрен с ним. Главное, причина локализована.
Firefox:
TypeError: b[e] is not a constructorChrome:
...,combineAndSend:function(){var a=this.callBuffer.length;if(a>0){this.doSend(a==1...ext-all.js (строка 21)
TypeError: MODx.ux is undefined
...ction() {MODx.ux.Ace.replaceComponent('modx-plugin-plugincode', 'application/x-p...index....e&id=40 (строка 41)
www.site.ru/manager/min/index.php?f=/assets/compon…l.plugin.js,/manager/assets/modext/sections/element/plugin/update.js Failed to load resource: the server responded with a status of 400 (Bad Request)
ext-all.js:21 Uncaught TypeError: undefined is not a function
index.php:41 Uncaught TypeError: Cannot read property 'Ace' of undefined
www.site.ru/manager/index.php?a=element/plugin/update&id=40 Failed to load resource: net::ERR_CACHE_MISS
Ну да и ладно. Хрен с ним. Главное, причина локализована.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.