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

А кто этим должен заниматься, проект-менеджер?

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

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

простите но мне кажется это не задача программиста — полировать идею заказчика напильником. Раз уж мы говорим о проектах! то тогда это должен быть проект менеджер, руководитель и прочее. А программист как ни крути — делает лишь сайт.
Да сайт может быть простым или сложным, может быть микросервисным, может иметь интеграции с десятками сторонних сервисов, но все равно это — сайт.

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

Недавно моя знакомая устроилась работать контент менеджером в одну компанию. Компания шьет женскую одежду в городе Хмельницкий Украина. Я попросил показать сайт. И вы знаете он был на тильде, выглядит стильно, модно, молодежно. Имеет все что нужно обычному интернет магазину. И обходится в 150 грн в месяц. Не знаю сколько это в рублях. Это дешевле чем хостинг. А тут сразу макет, микроразметка, функционал. Уверен, скажи я им, а чего вы на тильде сидите как бедные родственники, давайте вам дизайн, верстку, программную часть, сео оптимизацию и все это за 100 000. Они покрутят у виска и скажут — ты что с ума сошел. И будут правы.

Наверное вы правы и каждый судит со своей колокольни.
Я вот не очень люблю слово — проект! От него веет пафосом и амбициями.
В моем понимании раз уж мы общаемся на сайте посвященном modx — то тут все делают сайты и только сайты, а ни какие не проекты)
МОжет быть сейчас кто-то найдет страницу в википедии и бросит в меня страницей, на которой очень четко дано определение, что такое — проект)) Как когда-то я написал здесь что jquery это фреймворк, поскольку под фреймворком я лично понимаю любую надстройку над любым языком, которая позволяет писать код на упрощенном синтаксисе, а мне все громко кричали что jquery это библиотека!
Лично в моем понимании — все что мы видим в браузере и взаимодействием через него — это сайт. Проект — это что то такое, что работает на сервере
, делает кучу полезного, но ему веб интерфейс и не нужен то совсем)
Но это что-то Остапа понесло, простите.

делать что-то на виксе или тильде, — это антонимы для фразы «серьезный проект».

это вам пока так кажется. В моей голове тоже конструктор еще пару лет назад ассоциировался с самым низкопробным, дешевым и несерьезным сервисом. Но времена идут. Искусственный интеллект наступает нам на пятки. Да я согласен с вами, что что-то со сложное бизнес логикой пока что конструкторы не потянут. Но они оторвут огромную часть рынка у простых роботяг-программистов. Потому что большинству заказчиков не нужны очень сложные решения, им важно продавать и чем дешевле тем лучше.
А конструктор позволяет не нести затраты на дизайн, верстку, программирование. ИИ генерит качественный html, css, js и плюсом микроразметку за бесплатно. Стильно выглядящий магазин, с разными вариантами оплаты, доставки, хорошо оптимизированный в плане сео — можно получить за 100 рублей (это я утрирую, не знаю цен но очень не дорого).
Да конечно сложные проекты будут, но их не так много.

Выскажу свое личное и субъективное мнение — даже фреймворки скоро начнут терять в популярности. Будущее за конструкторами. Да на нашем постсоветском пространстве еще нет интрументов-конструкторов такого же высокого уровня, как уже есть в более развитых странах.
Но та же тильда или wix через год два догонят. 95 процентов желаний заказчика можно будет организовать просто двигая блоки по экрану в визуальном редакторе. И только 5 ну максимум 10 процентов проектов, которые будут иметь ну очень мудренную логику — будут обращаться к программистам.
Ведь по сути, я не ошибусь если скажу, что все мы делаем на том же modx совершенно однотипные задачи — сайты услуг, лендинги, простые магазины.
Все это и намного больше уже можно за 3 клика наделать в конструкторе — подключать большинство существующих оплат, доставок, сторонних сервисов. А есть американские конструкторы сайтов типа shopify — так это вообще мощнейший инструмент, радует только что им пока не очень интересен рынок России.

if($key == $default) {
            $output .= "<link rel='alternate' hreflang='x-default' href='{$protocol}{$resource['http_host']}' />";
        }

Здесь наверное нужен continue;

Одним щелчком пальцев — нет нельзя.
docs.modx.pro/komponentyi/minishop2/snippetyi/mscart
Вот тут можно почитать, что на страницу оформления заказа передаются две переменные total и products и какие данные в них лежат. Скидки там нет.
Но если вам нужно, то вы можете посчитать ее сами, ведь массив products у вас есть, соответственно идентификаторы всех товаров заказа есть, по ним можете получить для каждого цену основную. Умножить на количество каждого товара и найти сколько бы стоил заказ без скидки.
Но это самое примитивное решение и у него есть минус — при динамическом изменении товаров в корзине (количества товаров или же удаление товара) это стоимость без скидки пересчитывать не будет.

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

Жить он будет ещё достаточно долго, в том или ином виде.

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

Единственный конкурент MODX для меня это node.js,

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

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

Такой странный вопрос. идентификатор пользователя записать в плейсхолдер через сниппет.
Первым делом хочется спросить — зачем. Ведь плейсхолдер — это переменная которую можно получить на странице.
Но и идентификатор пользователя можно сразу получить на странице. Зачем его записывать еще и в плейсхолдер. На фронтенде например так {$_modx->user.id} через феном.
Или в сниппете php через $modx->user->get('id')
Но если уж правда необходимо записать зачем то идентификатор пользователя в плейсхолдер, то как-то так

$modx->setPlaceholder('userId', $modx->user->get('id'));

Насколько я знаю, ничего подобного в modx нет.
Ну вы и сравнили, vk над которым работает около 150 программистов всех уровней и направлений и CMS ку простую.

Нашел данный сниппет в магазине. Олег, его скачали всего 50 раз. Вряд ли вам кто-то поможет. Попробуйте написать свое решение.

migx это тип ТВ, верно? ТВ привязаны к шаблонам, верно? Шаблоны привязные к ресурсам, верно?
Заводите сначала конфигурацию migx у которого скажем всего два поля — name и likes
называете конфигурацию — nameAndLikes
Создаете ТВ с именем nameAndLikes типы migx с конфигурацией nameAndLikes.
Привязываете этот ТВ к шаблону. Создаете ресурс с этим шаблоном.
Далее js который отслеживает клики по каким то иконкам на фронтенде. Если клик по + то ajax запрос на файл в котором подключили основной index.php для инициализации объекта приложения $modx
Получили нужный ТВ исходя из вашей логики. Хорошо расписано у Уткина ilyaut.ru/xpdo/xpdo-for-dummies-part-4/
Изменили значение, сохранили ресурс.

что такое ogimage? откуда вы его взяли и почему думаете что все должны о нем знать. Что это за сниппет вообще?

что такое — лайки к пунктам migx??? Что за пункты у migx такие?
migx это json для хранения данных.
Хотите сделать какие-то лайки — заведите у migx кроме основных данных еще и свойство — likes.
Напишите js скрипт, который будет на фронтенде реагировать на нажатия чего либо, пусть js шлет ajax запрос на какой-то php, который получает значения migx, находит нужный например по migxId и изменяет его значение likes.

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

Спасибо что ответили.
Нет, честно говоря не совсем понял вашу идею.
Попробую более подробно описать как будет строиться проект.
ИМ будет представлять из себя соединитель сторонних сервисов, поскольку у заказчика на данный момент уже по всем миру обычные магазины офлайновые и у них уже заключены договора на обслуживание с множеством различных компаний. Так например данные о товарах в электронном виде хранятся в одной компании, отдельно заключены договора с компанией которая предоставляет услуги «программы лояльности» которая уже ведет учет покупателей, выдачу им бонусных карт, построение сложных акций и так далее. Сейчас это все работает в их офлайн магазинах — данные передаются на кассовые аппараты и когда человек покупает товар, кассовый аппарат получает от сервиса по хранению товаров базовую стоимость товара, потом клиент дает карточку лояльности и по ней идет запрос от кассового аппарата на сервис по работе с лояльностью. Тот сервис проверят что за клиент, сколько у него бонусов, проверяет нет ли для него индивидуальных скидок и возвращает в кассовый аппарат данные — для него товар стоит столько то, если купит получит на бонусный счет столько-то и прочую инфу. Тоесть Цена товара для клиента оказалась индивидуальной и купи этот же товар другой — для него цена была бы другой.
Эту логику нужно соблюсти и в интернет магазине.
У нас у товара будет базовая цена, полученная от сервиса по хранению товаров. Она более менее стабильна (обновляется раз в полчаса). А есть цена которую нужно показать конкретному покупателю. Авторизовался человек на сайте, перешел в какой-то раздел с товарами, видит например 50 товаров в списке и у каждого товара уже стоимость конкретно для этого покупателя. И особо проблем тут нет — для начала представим самый простой путь — в момент открытия страницы сайт будет отсылать запросы на сервер который занимается программой лояльности и получать в ответ цену каждого товара — да это трудозатратно но пока представим такой вариант. И на фронтенде ему отрисуется страница с товарами и с его индивидуальными ценами. Но с ценами нужно же работать и на бекенде. Товар он может добавить в корзину, увеличить его количество и прочее и это все должно работать с его индивидуальной ценой. И так у каждого пользователя — к примеру на сайте одновременно 1000 покупателей и каждый должен работать со своей стоимостью товара.
Ну вот отсюда и мои вопросы и сомнения.
— если каждый пользователь при каждом открытии страницы будет отсылать по каждому товару запросы на сервер хранящий данные о покупателях, их скидках, то это будет очень высокая нагрузка на их сервер. Возможно это делать заранее, для каждого покупателя пару раз в день получая все цены, но дело в том, что информация меняется очень динамично — к примеру акция может закончиться в 23 часа ночи, а обновление цен запланировано на 3 часа ночи, значит покупатель сделавший заказ в час ночи вызовет сбой в ценах — купит не по той цене.
— ну и плюс не совсем пока представляю где правильнее хранить такие объемы данных, чтобы они были индивидуальны у каждого пользователя и доступны как для фронтенда так и для бекенда.
Я конечно придумаю решение, но в мире много умных и опытных людей и их помощь важна.