Алексей

К товарам в MS не применимо?

Для расширения полей минишопа и так есть 2 компонента — msFieldsManager и msAddField

Плюсую за генерацию имени файлов, так как менеджеры грузят, что попало, бывает в классе загрузки меняю имя на поле alias товара, а если файлов несколько, там уже это предусмотрено и к файлам автоматически добавляется порядковый номер. Кстати с галереей есть несколько доработок, которые частенько требуются:

1) Нормальное уменьшение изображения, если оно превысило максимальную ширину или высоту.
Часто, менеджеры заливают все подряд и желательно качественно обрабатывать этот момент.
Сейчас если происходит превышение, то ресайз происходит на стороне загрузчика plupload — а он не лучшим образом справляется с этим. Его плюс — это то что он намного быстрее это делает, на стороне браузера и не требуется заливать огромную картинку на сервер, но качество страдает.
Специально сейчас сделал тест на новой версии minishop2 по умолчанию и на проекте, где я реализовал ресайз средствами самого php в обход plupload. Исходником было это изображение raw.githubusercontent.com/nwtn/image-resize-tests/master/assets-unoptimized/3B-1.jpg

Вот сравнение, ресайз был до 300 по ширине, слева plupload, справа phpthumb:



Соглашусь, что результат не сказать прям земля и небо, но справа четче кнопки на джойстике, надпись PS4 на консоле.
Кстати у plupload есть еще парочка недостатков: можете увидеть что он не совсем правильно отресайзил по высоте, снизу полоска в 1 пиксель. При ресайзе, получилась высота 147.6923 и plupload решил округлить вниз. Это уже известный баг и вроде даже в поздних версиях поправлен, но не в той, с которой идет minishop2.
И еще немаловажный факт: при сжатии phpthumb файл стал весить 8кб, а при сжатии plupload 32кб! в 4 раза, мне кажется это существенно, особенно если учесть, что качество изображения явно не лучше в 4 раза, а на мой взгляд даже похуже.

2) Возможно стоит сделать генерацию нескольких превью под DPI 2x и добавить srcset в чанки. В наше время, когда половина трафика идет через мобильные устройства, это уже, я думаю, должно идти по умолчанию. Многие клиенты жалуются, что на телефонах фото мыльные, сейчас даже не на айфонах DPI 2x идет частенько. И на многих ноутбуках по умолчанию включено 1.25.

3) Возможность поворачивать изображения, чтобы не заставлять менеджеров обрабатывать фото перед заливкой в сторонних программах.

Но каждый вызов каждого снипета оформлять такой жуткой хренью…

Попробуйте библиотеку modHelpers. Там всё проще.

// Постоянное кэширование.
{snippet('pdoCrumbs', ['showAtHome' => false, 'showHome' => true], 0)}

Не забудьте сделать бекап базы через SSH:

mysqldump -h localhost -P 3306 -umodx_new -p modx_new > dump.sql

Импортировать бекап обратно можно так:

mysql -h localhost -P 3306 -umodx_new -p modx_new < dump.sql

1. Есть + возможность доставить нужные из репозитория
2. Есть + опять же репозиторий
3. Есть + еще всякие специфичные штуки, типа опций VueJS

4. Есть + пакетное выполнение и анализ кода по всей директории\проекту

Ну и не забываем что их продукты стоят денег.

Только для тех разработчиков, которые не могут оформить Open Source лицензию.

Сегодня только правил вёрстку после VSCode — там банальнейшие ошибки, которые человек просто не видел, включая орфографические опечатки («desctop») и двойные указания свойств, которые PhpStorm сразу подчёркивает, из коробки.

VSCode — это типа Notepad++, с IDE его сравнивать не нужно.

Должен еще и хостинг это поддерживать.

Я на modhost.pro специально собирал ImageMagick 7 с поддержкой webp.

Помогло интересное и простое решение
habr.com/post/424427/

Нужно поднять свой служебный домен и настроить с него проксирование на api.telegram.org/

Nginx config

server {
listen 80;
server_name proxyapitelegam.example.ru;
location / {
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass https://api.telegram.org/;
client_max_body_size 100M;
}
}

Дальше остаётся подставить свой домен

<?php
$title= $resource->get('pagetitle');
$alias= $resource->get('uri');

if ($resource->get('published') == "1")  {

$fp=fopen("http://proxyapitelegam.example.ru/bot777777777AAAAAAAAAAA7777777/sendMessage?chat_id=-chatname&text={$title} http://site.ru/{$alias}","r"); 
while(!feof($fp)) 
{  $content .= fread($fp,1024); } 
fclose($fp); };

Данные по запросам к БД вызывают сомнение. Почему они разные?

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

Я когда переходил не феном тоже сравнивал. Разницы в скорости при вызове сниппетов через стандартный синтаксис и через феном никакой.

Как посоветовали выше установите debugParser и посмотрите что там. Но судя по всему проблема на фронте. Воспользуйтесь данным сервисом tools.pingdom.com выберите Sweden (он ближе всего к нам) и смотрите по таймингам и размерам что сколько загружается и сколько весит.

CKEditor на фронтенде тоже неплохо подключается. Деактивируем в настройках MarkItUp, текстовое поле в чанке

<textarea class="form-control" placeholder="[[%ticket_content]]" name="content" id="content"   
 rows="40"></textarea>

подключаем скрипт на странице

<script src="/assets/components/ckeditor/ckeditor.js"></script><script>CKEDITOR.replace('content');</script>

Загруженные картинки просто перетаскиваются в текст. Заказчики с MarkItUp никак не дружат.