Запустите в Console скрипт (естественно, сделав предварительно бэкап базы):

foreach ($modx->getIterator('modUser') as $user) {
	$profile = $user->getOne('Profile');
	$user->set('username', $profile->get('phone'));
	$user->save();
}

Ок, понял. Продолжаем с таблицами))

Мне кажется это не самый распространённый кейс: добавлять товары во вновь создаваемую категорию по условию. Во всяком случае за 4 года разработки сайтов у меня такого не было ни разу. Но в вашем случае нужна форма где будет выбираться категория и условия для добавления в неё товаров. Не думаю что у кого-то есть готовое решение.

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


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

Но если представить процесс чисто логически, то то, что я делаю, можно схематически представить так:

1. Отобрать все товары из корневой категории (Old_category-ID);
2. Отобразить все эти товары во вновь созданной категории (Old_category_ID).

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

P.S.
Мне кажется, что разработчик, который создал бы такое дополнения для Минишопа — очень помог бы конечным пользователям. Может что-то подобное и есть, я видимо не все знаю. Поэтому я и в чате тогда спросил — есть ли какой-то более продвинутый способ это делать?

ну не плагином, настройкой Минишопа о нулях, но всё равно странно, хотя решился вопрос в итоге)

Не понятно чем вас не устраивает вариант указать в файле импорта всех категории товара, как это описано в документации. Зачем писать другой скрипт, который по сути будет делать тоже самое: получать информацию из файла и вносить её в БД.

Друзья, а не подскажете как в уведомление в Телеграм запихнуть ссылку на оплату payment_link?

Замечу, что в отличии от тем которые используют бутстрапы, в данной теме взята только сетка, отступы и смежная область. Поэтому тема максимально четко использует стили. Например, если вы на сайте отключите блоки новостей, то css от этих блоков не пойдет в результирующий css, отключите корзину — ее стили так же не попадут.
Если нужна дешевая тема которую еще нужно очень сильно пилить, то есть и по дешевле, но там своих сил нужно затратить побольше. А тут из коробки все, расписано. Создавай только ресурсы и товары — шаблоны разделов готовы к работе. Все на fenom. Даже мультиязычность скоро будет из коробки. Уже протестирована на Polylang — полет нормальный.

Дело в том, что метод status() не запрашивает ничего у сервера, он обрабатывает ответ. Ну и всё что ты описал в качестве кейса и так работает. Смотри, когда ты что-то меняешь в корзине на фронте, тебе надо эти изменения передать на сервер, ты триггеришь метод change, который после получения ответа сервера, дергает метод status. И да, Коля сказал чистую правду, черновой вариант динамической корзины готов, надо протестировать как ведут себя опции при изменении в корзине, если до выходных будет время и желание напиши мне в телегу, дам доступы на сайт, где развёрнут пробник потестируешь.

Написать твое видение кода, протестировать его, убедиться в работоспособности и затем прислать его на github в виде PR
С большой вероятность он после некоторой оптимизации будет влит в ядро

За деталями общайся в наш чат.

Не обещаю очень большую активность, но точно помогу с тестированием

Что мне для этого нужно сделать?

Круто, могу помочь протестить

Семен — присоединяйся лучше к команде разработки и сделай это ))
Мир тебя не забудет

Для большей универсальности я бы ещё вынес всю работу по изменению html из метода status (js класс корзины)
в какой-нибудь отдельный метот, типа — applyHTMLChanges или лучше renderCart, так метод status будет чистым — отвечать только за получение данных актуальной корзины.

Так мы это уже почти сделали. Уже даже прототип есть.
Будет полностью динамичная обновляемая целиком корзина. При чем их может быть несколько на странице со своими чанками.
В 4.1 включить не успели, так как мало протестировано.

Сегодня был в работе магазин, в котором корзина и оформление — разные страницы.
Есть несколько компонентов, которые так или иначе пересчитывают корзину, ну и само собой все товары в ней.
Так вот в каждом таком компоненте авторы, в своем js, кто как реализует обновление данных корзины в html:
1) Кто-то циклом проходит и меняет в товарах цену и старую цену, а также результирующий блок
2) Кто-то целиком меняет весь кусок html кода корзины

Если в коробке miniShop2 будет универсальный метод получения актуальной корзины и обновляющий соответственно html на странице корзины, тогда в любом компоненте можно просто будет вызвать что-то типа

/**здесь любая логика по расчетам и.т.д*/
/**а в конце*/
miniShop2.Cart.status()

И всё сразу обновилось на странице на актуальные цифры.

Если понадобится что-то кастомное делать в чанке корзины, то поправить нужно будет только коробочный класс корзины (имею ввиду не исходники, а доработанную копию). То есть изменить только в одном месте.
Не придется лезть во все js других компонентов и везде менять реализацию обновления данных корзины.

Ну и ещё на ум пришел пример, если корзину делать на условном React, Vue, любом реактивном фреймворке, то как-то нужно получать стейт корзины из js, чтобы вьюха по стейту всё обновляла на странице.

Ну да, нейминг неудачный, исправлю. А метод запроса статуса зачем? Просто уже обсуждали этот вопрос, так реального кейса, когда такой метод может понадобится никто и не привёл.

Это ваше дело. Я в итоге разобрался.) Вопрос только — каждый ли будет делать столько попыток?

Возможно Ивану так проще отслеживать где чьи деньги.