Cyrax_02
С нами с 04 августа 2013; Место в рейтинге пользователей: #2504 часа назад
не помогло к сожалению, подскажите пожалуйста, в каком направлении вы бы продолжили искать?
msOneClick. Ошибка, не появляется модальное окно 2
Вчера в 15:29
Разобрался!
Использую редактор Tinymcerte
В системных настройках нужно отключить Относительные URL!
Теперь обычные внутренние ссылки корректные...
Jevix чудит 8
Вчера в 14:35
Николай, низкий поклон за время и труд, тебе и всем ребятам, кто приложил руки.
Очень-очень жду и уповаю на ms3, буду рад чем-либо помочь (тестирован...
MiniShop3 - 1.0.0-alpha 16
Вчера в 13:12
Спасибо, точно, забыл про это поле. Может есть пример сниппета на запись в это поле? Не могу понять как обратиться к нужному файлу, получить его поле ...
[UserFiles] - Файлы пользователя. 188
Вчера в 11:13
Спасибо добрейшее. А тип поля «Текстовая область», как-то можно сменить на TinyMCE RTE?
[ExtraFields] Поле "не появляется/не включить" в "Настройках форм/шаблон Това... 2
10 декабря 2024, 22:05
[[!msOptions?
&options=`mount`
&tpl=`tpl.msOptions.Roman...
[Решено] Сортировка параметров опции 2
10 декабря 2024, 17:06
да, работает, спасибо!
[msProducts] Как вывести в каталог только те товары, у которых есть изображения в галерее? 2
09 декабря 2024, 12:36
Я разобрался :)
Достаточно было тупо < img… > обернуть в маркированный список, получилось как то так:
{
"header": "Изобр...
Как отобразить в таблице родительского MIGX изображения из дочернего MIGX? 8
07 декабря 2024, 12:38
Эта проблема возникает если у вас версия mysql ниже версии 8 из за этого не создается таблица при установке.
[SendIt 2.0.0] Пагинация и обновлённая загрузка файлов 25
1. При пересоздании конечного минимизированного файла предыдущий файл не удаляется. Тем самым, папка будет быстро и бесконтрольно пухнуть.
2. Конечный минимизированный файл пересоздаётся только в том случае, если меняется хэш содержимого минимизированного файла. Т.е. если изменить содержимое некоторого комментария исходного файла, то минимизированный файл пересоздаваться не будет, хотя исходный файл изменён. Логично.
3. Если не очищать кэш modx, то конечный минимизированный файл в версии 1.3.0 пересоздаётся так же быстро, как и в версии 1.2.2.
4. Если в версии 1.3.0 очистить кэш modx, то minifyX отрабатывает очень долго (в 10 раз дольше), не зависимо от того, пересоздаётся конечный минимизированный файл или нет.
Возникает вопрос: что делает MinifyX 1.3.0 при очистке кэша modx ?
У меня формируется 2 минимизированных файла (их размер различается в 10 раз):
.css размером 20 Кб
.js размером 200 Кб
В версии 1.2.2 скорость формирования этих файлах такая:
.css — x
.js — 10х
В версии 1.3.0 скорость отработки minifyX без очистки кэша modx (не зависимо от того, пересоздаются минимизированные файлы или нет):
.css — x
.js — 10х
В версии 1.3.0 скорость отработки minifyX после очистки кэша modx (не зависимо от того, пересоздаются минимизированные файлы или нет):
.css — x
.js — 100х
Т.е. здесь обработка .js выполняется уже в 100 раз дольше .css, хотя размер его в 10 раз больше .css
Может, последняя версия munee при обработке .js-файлов выполняет ещё какую-то масштабную обработку? Причём эта дополнительная масштабная обработка выполняется только при очистке кэша modx. Если кэш modx не очищать, то даже при пересоздании минимизированных файлов MinifyX 1.3.0 отрабатывает быстро (как и 1.2.2).
Об этом можно судить только протестировав время для двух вариантов. Я протестировал. Время увеличилось в 4 раза. Уверен, что и у любого другого протестировавшего разница будет существенной.
а) более долгой обработки
б) связи с кэшем modx?
Не понятно, почему xpdo не учитывает тип TV-параметра, указанный в его свойствах. Следуя концепции TV-параметров, при формировании SQL нужно учитывать тип TV-параметра, указанный в его свойствах. Если указан числовой тип, то и операции сравнения должны быть числовыми (значение не должно заключаться в скобки). А то, что на уровне БД значения TV имеют строковый тип — это исключительно способ хранения данных, который выбрали разработчики modx.
Согласно концепции TV-параметров, эти параметры являются типизированными. Соотсветственно, и способ их обработки должен отвечать их типу. xpdo всё мешает в кучу.
то xpdo всё равно сформирует sql-запрос со строковым сравнением (заключит нуль в кавычки):
Это ответ на пример с ORDER BY CAST
но для условия where (TV.value < 0)
Нелогично получается с точки зрения modx: тип TV-поля указывать можно, все необходимые операции с такими TV-полями посредством xpdo можно выполнять (т.е. формируем почти любые запросы), а корректно сравнивать числовые TV (элементарная операция) посредством xpdo — нельзя. Серьёзная дыра в модели xpdo. Не иначе.
Не указал сразу — речь идёт о полях TV. При работе с TV xpdo всегода заключает значения в кавычки.
Да, значения TV-полей физически (на уровне БД) имеют строковый тип. Но xpdo не принимает во внимание тип этих полей, указанных в свойствах TV. Всегда рассматривает их как строки.
Можно даже и без использования HTML5 реализовать. Будет работать и на старых браузерах.
Впрочем, в идеале можно предусмотреть и комплексный вариант: в зависимости от платформы и версии браузера использовать либо HTML5-реализацию баннера, либо flash-реализацию…
Ну… ошибки обычно ищут в имеющемся функционале. А если у тебя нет проверки набора исходных файлов? Где ошибку-то искать? Здесь уже корректнее говорить не о поиске ошибок, а о доработке функционала.
Вот как у тебя формируется имя готового файла:
Здесь присутствует только время создания. А информации о наборе исходных файлов, которым соответствует этот минимизированный файл, нет. Напрашивается добавить ещё и хэш от набора полных имён исходных файлов.
Вот здесь выполняется поиск минимизированных файлов, имеющих в имени baseFilename, '_' и 10 цифр, тогда как такие минимизированные файлы могут соответствовать совсем другим наборам исходных файлов:
Причин много:
1. На разных страницах сайта подключают одинаковые наборы файлов. В этом случае озвученная проблема себя никак не проявит.
2. Указывают разные базовые имена на каждой странице портала. В этом случае озвученная проблема себя никак не проявит.
3. Те, кто сталкивается с проблемами в работе MinifyX, отказываются от этого сниппета, не разобравшись в причинах проблем. Например, Муравьев Артём. Не все же могут себе позволить «торчать» с каждым сниппетом по 3 недели.
4. Ещё не обратили внимания на проблему.
5. Скромничают.
6. Перешли на другую CMS.
Например, для одной страницы (шаблона) указываем один набор параметров. Загружаем страницу => MinifyX создаёт минимизированный файл.
Далее на другой странице вызываем MinifyX с другим набором исходных файлов, но с тем же cssFileName. Загружаем эту страницу. В итоге MinifyX ничего не создаёт и подключает уже существующий минимизированный файл (содержащий стили для предыдущей страницы). Со всеми вытекающими.
Для обхода проблемы приходится для каждого набора подключаемых файлов указывать разные cssFileName.