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

только добавление идентификатора пользователя в урл — не создаст страницу пользователя.
Я не помогу вам, потому что наверное вы читали о каких то имеющихся сниппетах авторизации типа 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 часа ночи, значит покупатель сделавший заказ в час ночи вызовет сбой в ценах — купит не по той цене.
— ну и плюс не совсем пока представляю где правильнее хранить такие объемы данных, чтобы они были индивидуальны у каждого пользователя и доступны как для фронтенда так и для бекенда.
Я конечно придумаю решение, но в мире много умных и опытных людей и их помощь важна.

Тоже использовал этот официальный SDK от яндекс кассы на одном проекте. Удобно с ним работать.
Жаль только что ссылка на оплату живет только один час и если покупатель засомневался, не оплатил сразу, а через 2 часа все же решился — то переходя по ссылке на страницу оплаты он уже увидит ошибку.
Мой заказчик почти сразу же попросил дописать функционал с возможностью через админку генерировать новые ссылки для оплаты и отсылать их покупателю.

Вы правы, но я добавляю сам руками. Мне так спокойнее что ли.

здесь url не подойдет.
Здесь нужен абсолютный путь внутри операционной системы, которая установлена на вашем сервере.
Вы можете узнать этот путь разными путями, но проще всего создайте в корне сайта файл path.php c содержимым

<?php
echo $_SERVER['DOCUMENT_ROOT'];

и обратитесь к нему через браузер ваш сайт/path.php
То что увидите это и есть абсолютный путь к корню вашего сайта

require 'то что увидели/index.php';

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

Сложно будет пояснить. С javascript вы тоже не знакомы?
Можно привязать это к ссылке, но зачем? в вашем случае это вызовет необходимость разбираться еще в куче технологий. Используйте вместо ссылки форму

<form action="путь до snippet.php" method="POST">
        <input type="text" hidden value="идентификатор ресурса" name="id">
        <input type="submit" value="Удалить ресурс">
    </form>

и с помощью css стилизуйте так как посчитаете нужным.
Как прописывать путь тоже вопрос неоднозначный. Мой вам совет, чтобы сейчас не вникать в теорию относительных, абсолютных путей, разницы между url и uri просто расположите файл в корне сайта, а в форме вызывайте его

<form action="snippet.php" method="POST">

Вам необязательно делать этот код отдельным файлом, вы можете в админке сайта создать новый сниппет, в него вписать такой же код, только даже проще

<?php
    $id = $_POST['id'];
    $res = $modx->getObject('modResource',$id);
    $template = $res->get('template');

    if($template==5){
        $res->set('published',0);
    $res->save();
    }

, расположить вызов этого сниипета на какой-то странице, к примеру с идентификатором 6
Тогда в форме в атрибуте action можете указать [[~6]] или {6|url} если используете синтаксис шаблонизатора fenom

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

<form action="" id="commentForm" method="post" class="cmxform ajax_form">

Я вижу тут два пути
— проверять к какой группе относиться user и показывать форму в шаблоне только при соблюдении условия, мол если пользователь в такой-то группе то покажем кнопку — снять с публикации
— или же в сниппете проверять какой пользователь сейчас авторизован в контексте web, какая у него группа и там уже решать.
Но раз вы пишите, что «Да я ограничил показ формы доступен только группе users» то значит вы пошли по первому пути и проблем быть не должно.

Как так — страница обновляется и не проходит валидацию.
Раз вы вызываете ajaxform значит отправка формы должна проходить без перезагрузки страницы.
Попробуйте открыть консоль браузера и смотреть ошибки js, у вас явно что с jquery, может у вас крутой проект на vuejs а ajaxform требует jquery насколько я помню.
Лично мне не нравится что у вас в вызове ajaxform не переданы параметры — отправитель письма и имя отправителя. очень много раз встречался что если эти параметры не переданы, письма просто не доходят, но раз вы говорите что письмо приходит, то ройте только в ошибки со стороны js.

Тут нужно исходить из логики вашего приложения, понимать зачем вообще вы это делаете.
Возможно право снимать ресурс с публикации нужно давать не всем? А только определенным пользователям. Тогда нужно ограничить показ этой формы на фронтедне только если пользователь авторизован на сайте и это пользователь определенной группы — к примеру менеджер
Или по крайней мере делать проверку в файле snippet.php что это за ресурс с таким id. например проверять его шаблон и разрешать отключать только ресурсы с определенным шаблоном.

<?php

    /**
     * Подключение объекта modx
     */
    define('MODX_API_MODE', true);
    require 'путь к файлу в корне сайта/index.php';
    
    $id = $_POST['id'];
    $res = $modx->getObject('modResource',$id);
    $template = $res->get('template');

    if($template==5){
        $res->set('published',0);
    $res->save();
    }
?>

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

Но в целом, идея позволять пользователям сайта снимать ресурсы с публикации, так себе идея.
Кто-то откроет код сайта в браузере, заменит идентификатор ресурса на число 1, отправит форму и отключит главную страницу сайта например.

Файл snippet.php

<?php

    /**
     * Подключение объекта modx
     */
    define('MODX_API_MODE', true);
    require 'абсолютный путь к файлу в корне сайта/index.php';
    
    $id = $_POST['id'];
    $res = $modx->getObject('modResource',$id);
    $res->set('published',0);
    $res->save();
?>

Форма где то в шаблоне

<form action="путь до snippet.php" method="POST">
        <input type="text" hidden value="идентификатор ресурса" name="id">
        <input type="submit" value="снять с публикации">
    </form>