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

В очередной раз понадобилось изменить таблицу сайта, менять которую не предусмотрено.

Что обычно люди делают в таких случаях? Верно, редактируют ядро или нужный компонент, и больше их не обновляют. Но ведь это неправильно, и можно решить вопрос иначе.

Пишем обычный плагин, выставляем для него событие OnMODXInit и меняем модель для нужных классов системы или дополнений. Например, я добавил id менеджера в заказ miniShop2:

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

Долгое время я пользовался простыми и быстрыми редакторами для разработки, типа Geany и Notepad++. Просто не понимал, зачем мне тяжеловесная IDE, если и этих редакторов хватает с головой?

Я помню свой код, что откуда выходит и как работает, зачем мне подсказки от программы, которая грузится полторы минуты? Тем более, я люблю по-быстрому забежать на сервер, подправить пару опечаток и сохранить файл. Мне не нужно создавать проект, синхронизировать его с сервером и т.д.

Однако, всё поменялось, когда я написал miniShop. Компонент вышел большой, и со временем я понял, что просто запутываюсь в нём. Заодно я понял, что допустил много грубых ошибок, по незнанию — например доставучие уведомления о необъявленных переменных или ключах массива, те самые — E_NOTICE.

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

Сразу говорю, всё освоено методом тыка, без чтения литературы или чьих-то инструкций. Подозреваю, что освоил я процентов 5 от общего функционала, однако и этот объем позволил мне работать радикально быстрее и выдавать в разы более качественный код.