Александр

Александр

Был в сети 30 июня 2026, 15:55
Заказы принимаю
Спасибо, хорошее решение! Только таким способом вы отрезаете 2 события: msOnBeforeValidateOrderValue и msOnValidateOrderValue, и вызываться, насколько я понимаю, будут эти события у родителя, то есть валидация будет происходить по стандарту в miniShop2. Конечно, это только если использовать это в плагинах, но тем не менее, почему не сделать так?
public function validate($key, $value)
    {
        if ($key != 'comment') {
            $value = preg_replace('/\s+/', ' ', trim($value));
        }

        $response = $this->ms2->invokeEvent('msOnBeforeValidateOrderValue', array(
            'key' => $key,
            'value' => $value,
        ));
        $value = $response['data']['value'];

        switch ($key) {
            case 'receiver':
                // Transforms string from "nikolaj -  coster--Waldau jr." to "Nikolaj Coster-Waldau Jr."
                $tmp = preg_replace(
                    array('/[^-a-zа-яёЁіїєґў’ʼ`\s\.\']/iu', '/\s+/', '/\-+/', '/\.+/', '/(\'|’|ʼ|`)+/'),
                    array('', ' ', '-', '.', "'"),
                    $value
                );
                $tmp = preg_split('/\s/', $tmp, -1, PREG_SPLIT_NO_EMPTY);
                $tmp = array_map(array($this, 'ucfirst'), $tmp);
                $value = preg_replace('/\s+/', ' ', implode(' ', $tmp));
                if (empty($value)) {
                    $value = false;
                }
                break;
            default:
                return parent::validate($key, $value);
        }

        $response = $this->ms2->invokeEvent('msOnValidateOrderValue', array(
            'key' => $key,
            'value' => $value,
        ));
        $value = $response['data']['value'];

        return $value;
    }
Василий, похоже я неправильно выразился и суть моего сообщения была неверно понята.

Речь как раз о том случае, когда автор согласился с тем, что баг есть, утвердительно написал, что решит в ближайшее время, но это время всё никак не наступает.

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

А про прихоти и собак речи и не было, не знаю, зачем Вы это добавили.
Я может что-то не понимаю, но по-моему в этой ситуации выигрывают оба. Автор получает обратную связь, баг-репорт, практически, о работе своего расширения, что позволяет ему улучшить своё расширение, получить отзывы от реальных проектов, как кто использует его продукт, узнать какие функции интересны людям, чтобы сделать и продукт более функциональным, и привлечь большую аудиторию. А мотивирует его то, что отвечать за свои слова надо вовремя всего лишь статистикой: «Неотвеченные тикеты: 2/150».
И от этого в выигрыше все: довольные покупатели, которые получили корректно работающее то, что хотели, и автор расширения, возможно получив новый опыт, улучшив, исправив свой продукт, сообщество MODX в целом от новой возможности, которую можно внедрить на свой сайт.
Так то оно так, только некоторые расширения продолжают существовать в магазине с неисправленными багами, на которые не было дано ответа. Выходят обновления, новые фичи, а старые баги кочуют из версии к версии, из-за нерешенных тикетов в том числе.

Есть смысл сделать возможность установки тикету статус «решенный» при каждом комментировании, после которого тикет стане только для чтения. И автоматически проставлять этот статус через N-ное количество времени у тикетов, на которые автор дополнения дал ответ, а клиент статус не поставил.
Здравствуйте. Не проверял, но нужно дополнительно присоединить таблицу с TV для родителя. Что-то такое:
{'msProducts' | snippet : [
	'templates' => 3,
	'limit' => 0,
	'parents' => 0,
	'tpl' => 'yandexProductsAndPricesOffer',
	'leftJoin' => [
		'parentCategory' => [
			'class' => 'msCategory',
			'on' => 'msProduct.parent = parentCategory.id'
		],
		'parentCategoryTV' => [
			'class' => 'modTemplateVar',
			'on' => 'parentCategoryTV.id=parentCategoryTVvalue.tmplvarid'
		],
		'parentCategoryTVvalue' => [
			'class' => 'modTemplateVarResource',
			'on' => 'parentCategoryTV.contentid=parentCategory.id'
		]
	],
	'select' => [
		'msProduct' => '*',
		'parentCategory' => '*',
		'parentCategoryTVvalue' => '*'
	],
	'where' => [
		'parentCategoryTVvalue.categoryYandexProductsAndPricesEnabled:=' => 1
	],
	'showLog' => 1
]}
1) Не работает с последним msOptionsPrice2. Думаю это как-то связано с:
2.5.2 beta (24.04.2018)
Change «saveProductModification» [msopModification]
Change «isWorkingClassKey, isWorkingTemplates, loadControllerJsCss» [msoptionsprice]
2.5.1 beta (23.04.2018)
Change «msOptionsPriceMsOnGetProductPrice,msOptionsPriceMsOnGetProductWeight,msOptionsPriceMsOnBeforeAddToCart» [msOptionsPricePlugin]
Add «msoptionsprice_mid» [js]
2) При установке даже на чистый MODX на демо modhost.pro не загружаются лексиконы. В меню вместо «cityFields» написано «cityfields_action». Также вместо ошибок выводятся названия лексиконов.

3) Можно ли как-то интегрировать это решение с msOptionsPrice2? Т.е. города и информацию для городов добавлять через cityFields, а цены регулировать msOptionsPrice2?
Например, если товар «iPhone 5» в двух цветах: красный и белый. 2 региона: Москва и Санкт-Петербург. В таком виде, как это сделано сейчас, можно лишь изменить отдельно цену для региона и отдельно цену для цвета, а если добавить как модификатор, то можно будет и для разных регионов и разных опций выставлять цену. К тому же, можно будет выставлять старую цену отдельно для каждой модификации.
Здравствуйте, Володя. Скажите, как можно объединить 2 ваших дополнения: GeoLocation (для создания разных регионов и указания им разных данных, напр., контактных) и msOptionsPrice2 (для создания разных опций товаров и указания им соответственно разных цен). Идея такая: чтобы в msOptionsPrice2 появился новый «модификатор» Город/Регион, наравне с color, size и др. Отличие лишь в том, что этот параметр нельзя изменить в карточке товара, а он устанавливается в 1 месте на весь сайт.
Если у товара в модификациях только 1 регион, то этот товар отображать только в этом регионе.
Если у товара несколько регионов, то отображать в этих регионах, а в других скрывать.
Если у товара не указан регион, то отображать во всех.
Проблема до сих пор существует…
Для демонстрации запустил всё это на тестовом сервере на modhost, там точно также эта ошибка срабатывает…

Страница на русском:
s11792.h9.modhost.pro/category/


На английском: s11792.h9.modhost.pro/en/category/ — не отображает значения словаря minishop2


На английском: s11792.h9.modhost.pro/en/category/?cultureKey=en — всё работает…


Настройки en контекста:


Если через .htaccess прописывать cultureKey, то всё ок до тех пор, пока не срабатывают ajax-запросы, например, в mfilter2. И после фильтрации записи словаря снова отображаются коряво…
Скажите, пожалуйста, не сталкивались ли с проблемой отображения лексиконов на одной из версий сайтов? У меня на русской версии всё нормально (контекст web), с английской проблемы (контекст en): не отображается текст лексикона в minishop2 (msProducts), вместо него отображается имя лексикона. Но! Если прописать в конце адресной строки ?cultureKey=en — всё нормально… В настройках контекста cultureKey прописан.
Если у вас нет такой ошибки, напишите свои настройки второго контекста, а также плагин, которым это всё подключается, пожалуйста.