Александр Мельник

Ну ладно я несовременный, с этим я согласен.
Но вот согласится с тем, что на сайте-форуме посвященному modx и minishop человек довольно вежливо выражает свое пожелание, а его за это ругают, ставят дислайки — этого я понять не могу.

Я ни в коем случае не говорю, что ими нужно пользоваться (хотя честно говорю не понимаю, почему говорят что это небезопасно. Версия 5,6 существовала чуть ни не десятилетие, вообще все что было написано на php за последние года использовало ее и это было нормально и безопасно.) Да это очень отлично, что буквально за пару лет php начал активно выпускать новые версии и развиваться и дорос до 8ки, но почему это делает 5,6 небезопасной?

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

Ну а в качестве примера, когда просто приходится использовать старые версии php могу привести то с чем сталкиваюсь я часто. Мы берем на обслуживание и доработку сайты, которые когда -то кто то разработал на скорую руку и оставил без поддержки. Такие сайты чаще всего делались супербюджетно и находятся на старых хостингах, где нет выбора версий языка к примеру. И либо заказчик не хочет никуда переезжать или же (буду откровенен) совсем не хочется просто так ради собственного развлечения переносить сайт на другой сервер, исправлять миллион возникший ошибок изза смены версии языка — если все отлично работает сейчас и на версии 5,6.

Конечно когда начинаешь разработку нового сайта на modx то уже нет смысла выбирать 5,6, тут я с вами совершенно согласен.

Даже в официальной англоязычной документации написано что php 5.6 поддерживается.
docs.modx.com/current/en/getting-started/server-requirements
и даже 5.3

MODX 2.x requires PHP 5.3.3 or higher,

использование гитхаб равно как и git не является чем-то сто процентно необходимым.
Это не более чем инструмент и использовать его или нет каждый решает сам.
А вот форумы! еще с 1991 года придуманы как раз для обсуждений.

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

как вариант — создайте поддомен, вместо страницы.
camera.site.ru
поддомены не защищаются стандартными сертификатами, значит там должно работать.

вы хотите чтобы одна страница вашего сайта открывалась по http?
ну для начала, так будет всегда по умолчанию. Если вы устанавливаете на сайт ssl сертификат, то после этого страница открывается так
http:/site.com/page
и так
site.com/page
Обычно чтобы избежать открытия по http настраивают редирект.
Если вы при установленном ssl сертификате и настроенном редиректе хотите добится чтобы одна из страниц открывалась по http вам необходимо изучать настройки вашего веб сервера — apache или nginx

о чем вы вообще?
Что значит для одной страницы сделать http?
http это протокол связи прикладного уровня в сетевой модели osi
Страница в modx — это ресурс имеющий свой uri

Что вы хотите то?

Вы очень сумбурно описали условия задачи. Чего вы хотите добиться?
Обычно когда «мат. часть я знаю, документацию изучил.» все работает. Если не работает — учи матчасть и документацию.

В общем дано:

— Минишоп2
— Категория товаров
— Группа пользователей с привилегией section_add_children
— Группа ресурсов с «данной» категорией товаров
— Сниппет ms2form

у вас установлен пакет minishop2, Вы в админке создали категорию товаров.
Вы создали через админ панель группу пользователей. Вы знаете что нахождение пользователя в группе не дает ему привилегии? Права, которые получит пользователь, будут определяться с помощью отведённой ему в этой группе роли.
Что вообще такое — группа ресурсов с «данной» категорией товаров??
Вы вызываете

{$_modx->runSnippet('!ms2form', [
    'parent' => $.get.mp,
])}
где? Зачем? с Какой целью?
<blockquote>я назначил эту политику: TicketSectionPolicy</blockquote>
причем тут Tickets к minishop?

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

Ради 1 строки вместо 3 тянуть jQuery?

Скажите, а что та фирма (или где вы работаете) занимается только разработкой с нуля проектов? Тогда конечно можно самим выбирать какие технологии использовать.
А мой мир выглядит так — директор находит на просторах интернета любые сайты, написанные на любых cms, движках и даже языках (пока не было только на C#), обещают им с СЕОшниками золотые горы и заключают договор. Сеошники сразу начинают говорить, ну мол ясно почему у вас все так плохо, у вас тут дескрипшены неверные, а тут нужно товары не так разместить, тут нужно сделать фильтр для товаров причем такой чтобы генерил урлы и позволял задавать тайтл свой для фильтрованных страниц и прочее в том же духе. И со всем этим приходят ко мне, мол — все делай. А это готовый сайт, сделанный 7 лет назад. К примеру вордпресс какой-то, у которого установлено 134 плагина, каждый плагин подключил свою версию jquery и так далее.
Согласитесь в такой ситуации, говорить о том, что я вам сейчас сайт перепишу, удалю jquery потому что она медленная (чем приведу 85 плагинов в негодность) — ну вообще не вариант. Причем это все нужно сделать на чистом энтузиазме, потому что лично заказчику совершенно все равно сколько и какие там библиотеки и плагины, ему сделали сайт 7 лет назад за 1000 рублей и платить за технические работы по нему он не собирается (тут особая странность нашей фирмы — мы типа только предлагаем услуги по СЕО, все программные работы для заказчика бесплатны и служат лишь для выполнения пожеланий СЕО).
Я это к чему, что есть и правда совсем разные миры в разработке и жизнь в них течет совсем разная, в каком то мире jquery это устаревшее и никому не нужное, сайты строит javascript собирает webpack, а есть миры (и их не мало) где сотни сайтов созданных черте когда и черте на чем, тоже нуждаются в поддержке, переделке и внедрению новых фич )

Ну так нужно учить только то, что реально тебе нужно в настоящий момент, а не гнаться на всем новомодным.

Правильные слова.
На данный момент я обслуживаю около 50 проектов в нашей компании. Но все это обычные сайты на разных cms (bitrix, modx, joomla, drupal, wordpress, opencart и еще более редкие). Плюс создаю новые, чаще всего на modx. Нигде в этих сайтах не используется vue react или не дай Бог angular. тут нигде (и в modx тоже даже нет нормального composer и поддержки psr-17). Поскольку мне ежедневно приходится работать именно с таким г… набором, то мне нет смысла (кроме собственного любопытства) изучать технологии (докер, vue и так далее). Но я их изучаю, но не использую (вернее только для своих тестов) и соответственно они напрочь вылетают из головы. Вот такая дилема)

Хотел написать, что вам же почему то не хочется писать .json() при работае с fetch хотя это всего7 символов, а почему кому-то должно хотеться переписывать

$('div').click(()=>{alert('hello world')})

на это

const divs = document.querySelectorAll('div');
if (divs) {
    divs.forEach((element)=>{
        element.addEventListener('click', ()=>{alert('hello world');});
    });
}

но наверное стоит уже заканчивать. Вы правы и молодец. Я не очень прав, но честно признаюсь — я просто офигеваю от обилия технологий и не успеваю их все вместить в свою голову. Я встаю утром до работы изучаю что то новое, работаю 9 часов, потом еще пару часов обучаюсь (и скажем так на пятом десятке это совсем не тоже самое что в 20 лет). И да, наверное все мои сомнения и мысли в первую очередь исходят из невысокого уровня знаний.

Можно ссылочку на подобные учебники?

learn.javascript.ru/xmlhttprequest

На сегодняшний день не обязательно использовать XMLHttpRequest, так как существует другой, более современный метод fetch.

В современной веб-разработке XMLHttpRequest используется по трём причинам:

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

Учебник Кантора тоже как бы намекает, что использование XMLHttpRequest сходит на нет, но вы правы в том, что fetch пока не умеет следить за процентом загрузки.

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

Но согласитесь вы с таким высказыванием?, что программист может сам решать что ему использовать, и если ему удобно работать с DOM через jquery то пусть работает. Не все программисты рисуют интерфейсы через новомодные фреймворки, добрый старый html никуда не делся.

В общем моя идея такая — если ты сделал рабочий проект, он работает хорошо и радует и разработчика и заказчика, то никто не должен говорить, что ты не модные библиотеки там использовал, какие инструменты использовать решает разработчик.

Ведь все началось с чего, Евгений (автор поста) написал что в одном видео разработчик смешал vue и jquery. Мне кажется — если у него все получилось, то он молодец.

Подскажи, как ты собираешься обойтись без axios, если ты хочешь работать с api в условном Vue?

не могу ничего ответить разумного, я не пользуюсь vue.
Ознакамливался с учебником 2 версии, сейчас вроде уже 3 вышла.
А в чем там проблема? Насколько я понимаю, принцип работы vue в том, что он умеет реактивно изменять dom (не хочу сейчас вдаваться в тонкости между dom в браузере и виртуальным dom с которым работает vue), отсылая запросы, получая json ответы и по этим данным опираясь на template изменять страницу. Почему fetch не сможет отправить запрос и вернуть json?

тут молчу, я об этом не знаю.

но потом приходит понимание, что не просто так же используются другие решения (иногда просто так :) )

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

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

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

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

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

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

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

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