Артем

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

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

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

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

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

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

Ведь что такое по своей сути vuejs как не фреймворк языка javascript. Но этого мало, над ним придумывают фреймворк vuetify что уже звучит дико

Ты путаешь теплое с мягким. Vue — фреймворк для создания интерфейсов, Vuetify — библиотека с готовыми элементами интерфейса в стиле MD, написанная для Vue.
Если тебе нужно приложение в стиле MD, то ты можешь его нарисовать с нуля, самостоятельно написав каждый низкоуровневый компонент типа инпутов или радиобаттонов, либо можешь просто взять Vuetify, где все это уже за тебя сделали и оттестировали, и написать условную админку в едином стиле без лишней головной боли.

Но автор умудрился намешать ExtJs, Vue.js и даже jQuery и всё это подрубается в админку через iframe!

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

но помню одно правило хорошего плохого инженера

исправил опечатку

Присылайте PR — Артем соберет новую версию.

Его уже смерджили уже как год почти: github.com/nizart91/localizator/pull/15

Евгений что то явно употребляет

Похоже на тяжелое употребление документации, не позавидуешь.

Как заготовка — прикольно, но для админки, на мой взгляд, NextJS лишний, тем более со своим файловым роутингом, который на больших проектах заставляет страдать.
Ты взял NextJS потому что привык и удобно, либо из-за какой-то его конкретной фичи?

Хотя очень хотелось бы еще получить доступ, например, к counter.measure_unit.

{$product['counter.measure_unit']}

То же самое и для value:

{$product['counter.value']}

НО не исключает к сожалению по ID

Этот код и не должен что-то исключать. Результирующий массив лежит в переменной $result, в ней и нужно смотреть. $array_test уже не нужен.

{foreach $result as $id => $value}
  id: {$id} - count: {$value}
{/foreach}

{set $result = []}
{foreach $array_test as $row}
  {if $row.id in keys $result}
    {$result[$row.id] += $row.count}
  {else}
    {$result[$row.id] = $row.count}
  {/if}
{/foreach}

Тут речь про то, чтоб повысить в системных требованиях минишопа минимальную версию php

Тут речь про то, чтобы исправить шорткат на старый list, потому что никто в здравом уме не будет без мажорного релиза повышать требуемую версию php с 5.3 на 7.1.

P.S. Стрелочки с мобильной версии настолько удобные, что я даже случайно плюсанул тебе, ну да ладно.

Это деструктуризация массива — шотркат для конструкции list, который доступен с PHP >= 7.1.
Поэтому, когда ты добавляешь туда еще один знак «равно», то ломаешь код.
Либо повышай версию php до 7.1, либо заменяй на

list($operator, $key) = $components;

По рукам бы надавать автору этой строчки:


Просто удали ее и проблема будет решена.

Как человек, написавший на MODX большой сервис (65+ кастомных таблиц), настоятельно не рекомендую брать CMS для сервисов. В один момент она просто начнет мешать и замедлять разработку и вместо того, чтобы писать логику сервиса, ты будешь пытаться приспособить эту CMS к твоим задачам и писать костыли.

Достаточно понимать, что xPDO не умеет в банальные UNION, более того, она даже мешает выполнять запросы, в которых есть UNION.

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

Если приложить утюг к языку, то тоже мало пользы будет, но полезность утюга это не отменяет. С технологиями то же самое.

Верстальщик != Разработчик. Очень часто бывает такое, что верстальщики довольно далеки от разработки и умеют только в html + css, а знания фронтенда и js у них близки к нулю.
Собственно, это просто один из таких представителей.

miniShop2.Order.submit();

in лучше действительно не юзать, как уже подсказали.
Тут описал подробно, почему именно.

Зачем высчитывать все эти расхождения, если можно просто заново проиндексировать массив на основе нового значения?
Я предполагаю, что в этом массиве у тебя собраны сразу все необходимые id:

<?php

$array = [246 => 1, 267 => 2, 296 => 3, 308 => 4, 309 => 5];
$affectedResource = 308;
$newIndex = 2;

$array[$affectedResource] = $newIndex - 0.5;
asort($array);
$index = 1; // индексирование будет начато с единицы
foreach ($array as $id => &$oldIndex) {
    $oldIndex = $index;
    $index++;
}

return $array;

Если тебе не принципиально, чтобы первый индекс был единицой, то можно еще проще:

<?php

...
asort($array);
return array_flip(array_keys($array));

Обычно в лк делается функционал для таких целей, где клиент видит все свои заказы, их статусы и может повторно запросить ссылку на оплату/поменять способ оплаты.
В общем-то, вывод заказов и их статусов — действительно тривиальная задача, в modstore даже есть готовый компонент для этой цели.