Максим

Максим

Был в сети 10 декабря 2023, 17:27
Заказы принимаю
Спасибо! Опередили меня буквально на пару дней (день разработки и день составления статьи)!
А мне одному не хватает заготовки для медиасорсов? Или я почти переписав так и не разобрался до конца с ним и постоянно использую костыльно-ориентированное программирование?
Ну причем тут города? Я привел для примера и объяснил, что бы у вас было понимание, что делает данный плагин… Что бы вы могли увидеть схожесть ситуаций и понять, что я так же мог столкнуться с такой проблемой… Но не столкнулся…
Предположил, что ModX мог отдавать старый кеш шаблона\страницы так как в системных настройках видит соответствующий домен… Поэтому и предложил до начала обработки кеша изменить домен на корректный… Я давно не лазил в модуль кеширования и не помню что и как там реализовано…
Просто еще раз напомню, что с такой реализацией у меня и контент в полях корректный и роботсы и сайтмапы…
Классный ответ 1С разработчика!))) По опыту могу сказать, что даже типовую конфу Торговли под нормальную работу нужно допиливать. Поэтому вот вам ссылка на документацию компонента и там есть ссылка на описание протокола 1С… Там все доступно описано…
Устанавливайте, настраивайте, выгружайте, зрительно проверяйте, что бы файл(ы) содержал(и) всю необходимую информацию и отдавайте 1С разработчику.
Если конфа самописная — то по-любому пилить импорт в 1С придется…
Вы можете следить за сортировкой в категории. Но насколько я помню с сортировкой у опций всегда была беда. И это еще одна из причин, по которой разработчик должен использовать функционал расширения свойств товара.
Ну 10 лет сразу видно… То обращаетесь к переменным, которых еще не существует, то утверждаете, что феном не отрабатывает и в виде аргумента указываете ошибку JS в которой сказано, что функция credit не определена… И про логи молчите…
Покажите результат (сгенерированный код) последнего последнего варианта и лог ошибок после генерации кода. Предварительно очистив лог ошибок.
А лучше так:
1) Код
2) Результат
3) Лог
Вообще у поисковых систем есть понятие «Основное зеркало». Я бы отталкивался от него. Соответственно, если поддомен — дубль сайта, то я бы сделал 302 редирект на основной домен. Если поддомен содержит уникальную информацию, то я бы реализовывал либо контекстами, либо самописным функционалом…
А вообще, когда-то давно реализовывал самописным функционалом города. Вот код его плагина:
<?php
/** @var modX $modx */
switch ($modx->event->name) {
    case 'OnHandleRequest':
        $host = $_SERVER['HTTP_HOST'];

        /** @var city $cityService */
        $cityService = $modx->getService('city', 'city', MODX_CORE_PATH . 'components/city/model/', array());
        if (!$cityService) {$modx->log(xPDO::LOG_LEVEL_ERROR, 'Could not load city class!');return;}

        $city = $cityService->getCity($host);
        if (empty($city)) {return;}

        $server_protocol = $modx->getOption('server_protocol', array(), 'http');

        if (!$city['active']) {$modx->sendErrorPage();return;}

        foreach ($city as $key => $value) {
            if (in_array($key, $cityService::EXCLUDE_FIELDS) || empty($value)) {continue;}
            else if ($key == 'key') {
                $cityService->setSettings('http_host', $value);
                $cityService->setSettings('site_url', $server_protocol . '://' . $value . '/');
            }
            else if ($key == 'name_site') {
                $cityService->setSettings('site_name', $value);
            }
            else if ($key == 'name') {
                $cityService->setSettings('city', $value);
            }
            else {
                $cityService->setSettings($key, $value);
            }
        }
        break;
}
Отсюда вас могут интересовать строки:
$cityService->setSettings('http_host', $value);
$cityService->setSettings('site_url', $server_protocol . '://' . $value . '/');
Попробуйте на этом же событии установить эти системные настройки в соответствии с доменами в запросе… У меня тогда такое сработало и работает до сих пор!
В примере, указанном вами, цены отличаются…
Но если уж так хочется без дополнения, то я бы написал сниппет получения уникальных опций из категории товаров (GROUP BY или DISTINCT) и вызывал бы его указывая интересующие опции… При этом я бы делал так, что бы сниппет принимал список опций и на основании списка строил корректный запрос в базу, оборачивал результат в чанк и выводил…
Я иногда удивляюсь тому, как люди методом тыка пытаются решать проблемы… Есть Документация Тинкофф
Ознакомившись (даже бегло) становится понятным, что любая оплата будет происходить в 2 запроса… Первый — инициализация платежа в банке, которая возвращает ссылку на форму банка. По опыту взаимодействия могу сказать, что время жизни ссылки регулируется как раз в этом методе. Так же для инициализации платежа нужна уникальная строка для обозначения заказа в вашей базе… Тут уже ясно, что заказ на вашем сайте должен быть уже сформирован и вы должны знать его идентификатор (ID).
Как бы там не было, но стоит так же получать ответ от Банка… Успех или нет… Для этого в лк банка указывается ссылка для нотификаций. По опыту — эту ссылку тоже можно перепределять в методе init (инициализация платежа).
И теперь уже совсем очевидно, что общение с банком в ModX корректнее всего реализовывать на бекенде… Соответственно придерживаясь логики miniShop2…
Так что создавайте класс платежа и не нужно будет костылить на фронтенде. Сложного там нет ничего, если немного почитать документацию и вникнуть…
Если нет цели собирать компонент и нужно добавить таблицу с моделью, то я всегда ручками писал… Особо сложного ничего нет… А в ModX 3 еще и DI добавили… С ним отпадают все заморочки с подключением какстомной модели…
Если не сработает стандартная PHP конструкция
$resp->material->{$type}->width
, то рекомендую написать сниппет или модификатор, который корректно обработает данные и вернет желаемый результат. Все же стоит помнить о том, что Fenom — это шаблонизатор. И как в любом шаблонизаторе должно быть минимум логики.