• avatar umka
  • 0
Да, я в курсе, мне не требуется обрезка, мне нужно пропорционально уменьшить до нужных размеров :)
  • avatar umka
  • 0
GD — установлена, превьюшки она обрезает, тут не совсем в этом дело. А в том, что я использую tpl и tplFirst, и соответственно мне нужны различные размеры фото для первой и для остальных. В доках это описано — но у меня не завелось…
Вот настройки в SimpleGallery
Ну и кстати в options far=C не обрезает, обрезает zc=1
Ну, во-первых, на сервере должна быть графическая либа для ПХП, как её там, GD что ли. Проверьте, есть ли.

А во-вторых, не совсем понял про «В SimpleGallery конфигурации все по умолчанию кроме контроллера onetable.». А что там у вас?
  • avatar umka
  • 0
Да, полный, выводится на этом же ресурсе.
  • avatar ddot
  • 0
Это полный код?
parents или documents не указывал?
  • avatar paic
  • 0
13. Обновление
По этому вопросу не получалось написать кратко, поэтому вынес его в отдельную статью, с которой можно ознакомиться здесь
modx.evo.im/blog/6317.html
спасибо тебе за замечание)
  • avatar paic
  • 0
Сейчас нормально, спасибо.
Поправил, у меня теперь вот так: prntscr.com/18akouo
  • avatar paic
  • 0
Лучше, чтобы увеличенная картинка при наведении уходила вверх, а не вниз. Потому что если TV image самый нижний — увеличенная картинка уходит за нижний край монитора, а при дальнейшей прокрутке вниз вся страница начинает дергаться.

Поменял стили в стр.3 на top:-128px, но вместе с картинкой уехала вверх и кнопка Вставить и перестала работать.
А может и не работала изначально при таком раскладе, когда этот ТВ самый нижний — не успел протестить, а сейчас это все где-то прописалось в кэш и пока не получается вычистить до первичного состояния.
Если кнопку Вставить вернуть назад стилями — все-равно не работает.

Когда TV image где-то вверху, то все нормально.
Вчера столкнулся с казалось бы простой штукой, которая вывела меня из строя на полдня. Правда, это больше не к самому modx относится, а к пониманию PHP, но ошибка случилась именно в типовой конструкции от modx-а.

Обычно код плагина выглядит примерно так:


switch ($modx->event->name) 
{
    case 'OnDocFormSave': 
    /*что-то делаем*/;
    break;
}

И пока такое размещено в базе данных, все работает.

Но чтобы не хранить код в базе, выносим все в файл, например, plugin.php, а в самом коде плагина подключаем этот файл.

Так вот если подключить его вот так:

require_once(/*.путь к файлу..*/ "plugin.php");

, то код плагина перестает вызываться.

Правильным решенем было использовать require, а не require_once, вот так:

require(/*.путь к файлу..*/ "plugin.php");


Ну, либо добавить явный вызов функции, которая есть во включаемом файле, вот так:

require_once(/*.путь к файлу..*/ "plugin.php"); 
my_function($params);//функция из файла plugin.php
Как я делаю pagebuilder в BLADE gist.github.com/sashabeep/40cd5a08ac9fe7b9db2d710b7557bf4f

Немногие знают, что МultiTV тоже можно парсить сразу в шаблоне на 3.x без объявления tpl-ок

Как подключить контроллеры на пальцах gist.github.com/sashabeep/32355af4f27bf8d3732618a7f0208f7a
  • avatar paic
  • 0
12. Кастомизация
Компоненты Evo в большинстве своем — это универсальный инструмент. Для достижения нужного функционала используется параметры, конфигурации, конфиг-файлы и другие настройки, содержащиеся в самих компонентах.
Если «штатных» средств не достаточно, то дополнительно разрабатываются сниппеты, prepare или дополнительные плагины. Как правило, стандартные компоненты поддерживают такие расширения.

А вот вносить изменения непосредственно в код компонентов не рекомендуется, по причине:
— стандартный элемент при обновлении компонента «затрет» все ваши изменения, и сайт перестанет работать в нужном режиме, или вообще «слетит»
— если сайт в дальнейшем попадет в другие руки на доработку или обновление, то вам будет долго икаться, а ваша репутация точно не улучшится. Аналогичный сюрприз может прилететь и вам, поэтому обращайте на это внимание уже на этапе первого ознакомления
— даже если сайт останется у вас на поддержке — через пару лет вы уже и сами можете не вспомнить, где и что изменялось и можете наступить на свои же «грабли» при очередном обновлении.

Если все же решили «допилить», например, какой-то сниппет, то в этом случае кастомизированный элемент лучше переименовать, и не забыть о комментариях к измененному коду.

Это касается не только сниппетов и плагинов, но и шаблонов (чанков), и конфиг-файлов, которые бывают в составе компонентов (да и в самой cms v.1.4.х).

На них остановлюсь отдельно, т.к. они как раз чаще всего и нуждаются в изменениях, исходя из верстки сайта, и часто возникают вопросы, почему не работает (особенно если используется ajax, например, Commerce, eFilter, и др.).

Эти элементы тоже править не надо, а надо на их основе и примере создавать свои с другими наименованиями (или по другому адресу), а стандартные компоненты уже, как правило, поддерживают подключение «своих» конфигов и шаблонов (чанков).
При этом особое внимание уделять (и переносить себе) id, классы и атрибуты, содержащиеся в штатных элементах, поскольку чаще всего они там не для красоты, а являются обязательными, и при их отсутствии как раз и «не работает».

В ядро cms лучше вообще не вмешиваться, а добавление (изменение) виджетов админки и другие кастомизации админки решать с помощью плагинов.
  • avatar paic
  • 0
11. Резервная копия
Это страховка, позволяющая сэкономить много времени и сил, если что-то пошло не так. Позволяет быстро откатиться назад на рабочий вариант. И да, это аксиома.

Когда я рекомендую делать резервные копии.
В ходе разработки нового сайта:
— перед установкой нового компонента
— после завершения очередного этапа разработки
— при удачно найденном решении, дабы оно не потерялось при последующем «улучшении»
Существующего рабочего сайта:
— если что-то захотелось улучшить или поправить, не важно что и где, и в каком объеме.
— перед обновлением cms и / или ранее установленных компонентов
— после первичного наполнения
— после существенных изменений в ходе эксплуатации
— перед тем, как дать доступ в админку (на хостинг) другому лицу, вне зависимости кому и для чего
— после того, как вам дали доступ в админку чужого сайта (на хостинг), например, для оценки каких-то доработок или еще каких-то действий — во избежание дальнейших недоразумений, тем более что этот доступ могли дать не только вам

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

Объем резервирования выбирается исходя из объема решения предстоящих задач. Это может быть как полная резервная копия всего сайта (файлы и база данных), так и локальная, например, только база данных (сделать резервную копию базы данных есть возможность даже из админки сайта), или создание копии файла (файлов, директории), или копии кода какого-то элемента (сниппета, плагина, шаблона, чанка).
Спасибо.
  • avatar 3fir
  • 1
Бинго!
Где мой лайк?
Шучу. Удачи в работе!
Решение подсказали в группе в телеграмме.

Зайди в плагин blang — вкладка события, и сними галку ondocformsave и сохрани
Может кому пригодится.
Всем спасибо, кто откликнулся.
  • avatar 3fir
  • 0
В этом случае да.
Вы же написали, что вы начинающий, я подумал, что на стандартных плейсхолдерах evo шаблон построен.

Напишите в телеграм чате разработчиков. Там быстрее ответять.

t.me/evolutioncms
php 7.4, я ничего не менял.
Почему разницы нет, как я понял в версии 1 нельзя делать файловые шаблоны, а именно на файловых шаблонах, на блэйде у меня все и построено в 3 версии.