etch не поддерживает процентную загрузку, fetch не понимает коды ответа, Fetch требует постоянно писать .json(),

мне кажется это странные аргументы. Axios все это умеет только потому что это библиотека по работе с запросами. В ней написан код, создающий синтаксический сахар для работы и не более.
Так можно говорить, что javascript не умеет назначать прослушку событий на группу элементов, нужно навешивать в цикле listener, а в jquery можно написать $('div').click(()=>{}); и за одну строки и сделать выборку и навесить колбек. Значит jquery лучше?) Все это не более чем сахар.

Ну я не могу спорить, мне немного странно слышать фразу — «устаревшая библиотека, которая даром не нужна», у меня так когда то бывшая жена говорила про сумочку)

Я точно также читаю в разных учебниках javascript что объект XMLHttpRequest признан устаревшим и от его использования нужно отказываться. Поэтому axios это некий сумбур из устаревшего XMLHttpRequest с привязкой туда promise, в то время как fetch работает с promise нативно.
В общем сколько людей столько и мнений.

Но если не говорить о том, что это библиотека хорошая мы ее любим, а эта плохая — мы ее не любим (она из прошлой коллекции зима лето), то остается факт — и то и то библиотеки, без которых можно обойтись. Подключаем их мы не для того чтобы сделать программу лучше, а только для своего удобства.

Хотя с точки зрения качества кода — это ненужный элемент.

Почему ненужный? Нативный fetch — это низкоуровневый инструмент, у него есть ряд недостатков и он не везде удобен. Например, fetch не поддерживает процентную загрузку, fetch не понимает коды ответа и любой статус воспринимает как «успешно», даже если сервер вернул 500, либо вообще умер. Fetch требует постоянно писать .json(), что еще одно подтверждение того, что это низкоуровневый инструмент.

Axios — это удобная обертка над XMLHttpRequest, с интерсепторами, исключениями на основе кода ответа и удобным api. Ты можешь написать свою обертку над XMLHttpRequest, но, опять же, здесь за тебя уже все сделали.

jQuery, в свою очередь — это устаревшая библиотека, которая даром не нужна в современном js, и сравнивать ее с axios немного странно.

Почему? Зачем?

А ты попробуй просто взять и поработать с нативным fetch'ем, подергать какие-нибудь эндпоинты, а потом потихоньку придешь к пониманию, что все как-то не слишком удобно.

Вы не понимаете, это другое)

По axios с одной стороны да, привычка.
Но с другой стороны это более лаконичный синтаксис по сравнению с нативным fetch.
В axios проще засеттить значения по умолчанию: в моём случае адрес коннектора и заголовки именно там, где эти значения получены. Чуть проще обрабатывать HTTP ошибки (хотя к MODX это плохо относится, другая парадигма ответов).

Axios я использую не потому что привык это делать в мире MODX и jQuery, а потому что увидел его уже в мире Vue.js и видел регулярно. Да и вообще он появился раньше, чем появился fetch)

Переходя на другую технологию может и было бы легче использовать старые добрые инструменты (тот же jQuery.ajax()), но потом приходит понимание, что не просто так же используются другие решения (иногда просто так :) )

В своё время jQuery был прекрасным инструментом, но сейчас это уже legacy — развитие браузеров и JavaScript оставило его не у дел. И теперь уже нет такой нужды использовать его. Конечно, полно сайтов ещё долго будут использовать jQuery, но чем дальше — тем болезненнее слезать.

И уж точно не нужно его приносить в другой мир, где есть инструменты, которые решают те же задачи, но по-своему (обычно лучше, быстрее, надёжнее и т.д.).

И за модой тоже нужно следить. Мода это же не плохо, иногда она становится новым стандартом на много лет. За прекрасным пример отставания от моды и стандартов далеко ходить не нужно)

Маленький совет, лучше сделать поддомен video.*.ru, чтобы потом удобнее если что мигрировать на другой хостинг.
Да и с поддоменом вы можете видео хранить на хостинге, где подешевле место и трафик.

Подскажите пожалуйста как выполнить сортировку у msOptionsPrice.modification по опции size?

Согласен с вами Евгений.
Но с другой стороны не могу не спросить (ни в коем случае не для осуждения, мои уровни знаний не позволяют осуждать).
Вот вы пишите что в своей программе используете axios для запросов. Почему? Зачем?
Ведь сам язык javascript имеет отличные инструменты для отправки и получения запросов, асинхронность и прочее.
Могу ошибаться, возможно есть адекватные причины использовать axios но скорее всего — это просто привычка. Вы знакомы с этой библиотекой, вы знаете ее синтаксис и не задумываясь подключаете ее в код проекта. Хотя с точки зрения качества кода — это ненужный элемент. Тогда почему если кто то любит jquery не подключить эти несчастные 19 килобайт (могу ошибаться но примерно столько весит сжатая) и не использовать ее для запросов или еще для чего-то? Ведь и axios и jquery есть сторонние библиотеки, «раздувающие» наш код.

Поэтому я не совсем понимаю, когда говорят — вот так правильно, а в вот так нет, скорее в разработке применимо — вот так модно, а вот так не модно)

Да их полно, наберите онлайн конвертер видео. Можете этим воспользоваться convertio.

Спасибо за ответ!
Я не против, это требование клиента. Буду пробовать его убедить, разместить видео на youtube.
А если вдруг не получится, можете подсказать какие-то еще варианты решения? С помощью чего можно оптимизировать выдачу видео пользователям?

Будете просто переплачивать за хостинг. Даже обучающие ролики, нельзя в таком размере отдавать. Это слишком. Представьте кто-то захочет посмотреть на мобильном интернете ваш ролик. Не знаю, почему вы против youtube. Видео может быть доступно только по ссылке. Там и оптимизация, и встроенный плеер. И бесплатный траффик, на хостинге могут быть проблемы с этим.

Супер.

Получилось исправить! Параметр SMTP хосты (mail_smtp_hosts) необходимо установить в виде: ssl://smtp.mail.ru

7.1. На других тоже не работает.

Версия php какая? Попробуйте поставить другую.

Не особо слежу за ютуб обучениями, но такой подход — это такой же трэш)

Даже если нужно будет фронтенд раскидать между командами — то это точно будет не так.
Варианты:
1) Разные фреймворки — но по разделам, админка например на одном фреймворке, пользовательская на другом.
2) Если прям хочется поделить одну страницу — то всё просто в пределах одного фреймворка, но использованием одного нормального хранилища с модульной структурой, типо Vuex или Redux. ​

Поэтому, что это видео, что то на английском — всё это жуткий bad practice. Остаётся надеяться, что все просмотревшие восприняли это как учебный эксперимент и никогда не подумают повторять.

В логах ничего, в спаме тоже нет. Порт поменяла — не работает.
С локального сервера все приходит. Не понимаю, в чем может быть проблема

товаров не много, благодарю, разобрался

пардон увидел в начале msimportexport, уже разобрался в принципе, благодарю

Если вы внимательно почитаете, я вам и про csv.php написал.

Открываем Console,
пишем небольшой код для чтения csv файла (ну с этим то в интернете нет проблем)
далее цикл по товарам и запускаем:

$response = $modx->runProcessor('gallery/upload', array(
        'file' => $file, // Путь к файлу от корня сервера
        'id' => $product_id // id товара
    ),
    array('processors_path' => MODX_CORE_PATH . 'components/minishop2/processors/mgr/')
);

if ($response->isError()) {
    echo 'ОШИБКА: '.implode(", ", $response->getAllErrors());
    echo '<br />';
}

если товаров много — то в стандартные 30 секунд скрипт не уложится…