Кирилл Бакулин

Это первая часть статьи и она повещена целиком и полностью расчету СДЭК.
Вторая часть тут

Статья рассчитана на новичков, которые плохо понимают php и js код, старички могут сразу перейти на GitHub

Прежде всего хочу предупредить что я никого не хочу оскорбить или унизить, моя история началась пол года назад с покупки дополнений msCDEK и msRussianPost и в течении полугода мы теряли деньги, клиентов и решали проблемы до тех пор пока и мне и автору этих дополнений это не надоело.

Как говорит Василий «Критикуешь — предлагай» и под катом я расскажу как сделать самому всего в пару десятков строк кода эти сервисы доставки, а пока опишу проблемы, которые решает мой вариант реализации

• msRussianPost у меня не считала доставку заказной бандероли и заказной бандероли 1 класса
• Если стоит метод доставки например самовывоз, то автодополнение городов не работает, а консоль начинает усыпать ошибками которые крашут вообще весь расчет доставки
• В заказ в админке не пишется город
• Надпись о времени и цене доставки не удаляется при смене метода доставки
• Дополнительная цена не плюсуется к расчету доставки, а плюсуется к итоговой цене

И еще с десяток мелких проблем, из-за которых лично наш магазин с 5-10 заказами в день терял клиентов
Это не доработка решений вышеуказанных решений, а полноценная инструкция по созданию своих сервисов доставки на базе MS2. В общем не буду тянуть кота за хвост, за объяснением кода под кат

Добрый день. Направьте или лучше подскажите кто может сталкивался.
Задача следующая: Во время оформления заказа без оплаты или с подключенной оплатой необходимо производить запись в TV поле товаров которые будут оформлены.
1 TV поле числовое, в нем планируется фиксация кол-во оформления-продаж данного товара. Для последующей генерации блока популярные товары.
2 TV поле числовое, в нем планируется фиксация кол-во остатков данного товара.

Информация для разработчиков. Сложность средняя.
Практически все разработчики MODX используют тот или иной шаблонизатор. Большинство в рунете сделали свой выбор в пользу Fenom. Благодаря Василию конечно. Этот шаблонизатор достаточно простой и лёгкий. И его функционала хватает для решения практически всех своих задач. В этой статье мы посмотрим на него немного под другим углом и попробуем его возможности расширения.

Привет, друзья!

Сегодня мы расскажем о нашем опыте внедрения онлайн-кассы в маркетплейсе modstore.pro и хостинге modhost.pro.
Опишем всю цепочку — от выбора кассы и заключения договора до интеграции и первых пробитых чеков.

Привет, друзья.

Я подумал и решил, что выложить всем на обозрение исходники моего последнего проекта может быть весьма полезно. Так что вот они, держите.

Сайт отличается использованием файловых элементов и сборкой скриптов\стилей через Gulp. Если вы давно хотели узнать, как разрабатывают сайты MODX из PhpStorm — вот ваш шанс!

Для начала нужно установить pdoTools и HybridAuth. Затем нужно выгрузить исходники Startpage.
Внимание, работать только на чистом сайте! На рабочих проектах эксперементировать не нужно.

Описан алгоритм для модуля интернет-магазина minishop2. Для других модулей алгоритм похож, но объекты отличаются.

Задача: сделать автоматический пересчет стоимости товаров в зависимости от общего количества товаров, находящихся в корзине.

$cartArray = $cart->get(); // Массив товаров в корзине
$cartProduct = $cartArray[$key]; // Один товар в корзине

Решение: пройти по всему массиву корзины и изменить цену товаров.

Наверняка много кто использовал в своей практике TV-поля типа «Список» (множественный, одиночный, не важно) или «Тег». Здесь важно именно то, в каком виде в базе данных хранятся данные таких полей, ведь они сохраняют множественные значения. А хранят они их одной общей строкой в той же самой таблице ТВшек (естественно, по одной записи на один документ). К примеру, если мы отметили три значения 100, 1005, 10, в БД это запишется 100||1005||10. И здесь возникает вопрос как потом выполнить поиск по таким полям? Простой LIKE здесь не поможет, так как LIKE %100%, к примеру, найдет и '100||1000' и '1001||1005'. Данного вопроса мы уже касались здесь и подобный вопрос опять возник здесь.

Решил затестить чистый xPDO на скорость и противопоставить ему pdoFetch.

Ничего не имею против первого или второго. Напротив. Второе использую в работе регулярно. Однако, как я понял, изучение и применение чистого xPDO в своих разработках серьёзно поможет снизить нагрузку на сервер, ведь верно?

P.S.: Тестировалось на ахеренно быстром хостинге для MODX REVO — modhost.pro.

pdoFetch:

<?
$pdoFetch = $modx->getService('pdoFetch');
$setConfigArray = array(
		'return'	=> 'data',
		'parent'	=> '0',
		'limit'		=> '2000',
		'select'	=> 'id,pagetitle,uri,content',
	);
$pdoFetch->setConfig($setConfigArray);
$resources = $pdoFetch->run();
for($i=0; $i<count($resources); $i++)
{
	print $resources[$i]['pagetitle'];
}
print '<pre>'; print_r($pdo->getTime()); print '</pre>';

Результаты:

1ый запуск:
0.0118151: Total time
12 058 624: Memory usage

2ой запуск:
0.0111890: Total time
12 058 624: Memory usage

xPDO:

<?
$pdo = $modx->getService('pdoTools');
$q = $modx->newQuery('modResource');
$q->select( array("id","uri","pagetitle","content") );
$q->limit(2000);
$s = $q->prepare();
$s->execute();
while($row = $s->fetch(PDO::FETCH_ASSOC)) {
	print $row['pagetitle'];
}
print '<pre>'; print_r($pdo->getTime()); print '</pre>';

Результаты:

1ый запуск:
0.0021060: Total time
3 932 160: Memory usage

2ой запуск:
0.0016491: Total time
4 194 304: Memory usage

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

Хотелось бы поднять вопрос обновления остатков товара после оформления заказа.
Точнее, в момент совершения заказа на n-ое количество товара остаток должен уменьшиться на n заказанных штук.
Возможно, плохо гуглил, но информация какая-то разрозненная и нужно собрать по крупицам в кучу.
В общем, благодаря этому комменту написал такой плагин: