Для разработчиков

Некоторое время назад мне сделали замечание, что использовать @ — «плохая привычка». На предложение доказать, что это именно так, я получил ссылку на Хабр, со статьей про управление ошибками.

Окей, наконец-то я узнал, как именно ими управлять, но чем же плоха привычка подавлять сообщения об ошибках, если ты знаешь, что делаешь?

На мой взгляд, плохого здесь нет и быть не может. Применение @ — это такое же управление ошибками, как и функция error_reporting() или директива в php.ini.

Однако, детальный разбор показал несколько иное.

Как известно, при создании собственных таблиц в MODX принято наследовать или xPDOSimpleObject, или xPDOObject.

Отличие между ними ровно одно — в SimpleObject уже прописан первичный ключ id, а в Object — нет. То есть, если вы хотите, чтобы у вашей таблицы создавалось поле id с становилось primary key — нужно наследовать SimpleObject.

Я, однако, люблю простые таблицы ключ-значение, в которые добавляю первичным ключом два и более полей сразу. Например, в репозитории пакет может быть в нескольких категориях, значит нужно создать таблицу extraCategoryMember из двух полей category_id и package_id.

Ключ id мне здесь совершенно не нужен, ведь он будет расти при каждой операции добавления пакета в категорию, а таких операций может быть очень много. Конечно, вряд ли INT(10) скоро закончится, но зачем хранить лишнее?

Предлагаю всем желающим готовую функцию для установки компонентов через Api.

Можно делать из консоли, можно из сниппета — не важно. Собственно загрузка файла выделена в отдельную функцию, которая пытается работать через file_get_contents(), если это не запрещено. Иначе использует cUrl.

Параметров всего 2: имя компонента и id провайдера пакетов (по умолчанию — 1, то есть, modx.com).

Очередная модель от известного велосипедостроителя — меня.

Суть в следующем: заменить все фильтры в чанке на функции внутри сниппета, сделанного на pdoTools.
При этом, сами фильтры должны лежать как и раньше, сниппетами, а не быть жестко закодированы, чтобы их можно было удобно изменять и использовать также в в плагинах, или еще где.

Бета с индеком 0 доступна в репозитории. Нулевая она потому, что я не успел сделать оформление и управление заказами и решил привести в порядок то, что есть, а не торопиться и делать тяп-ляп.

Но обещание выпустить в конце этой недели было дано и его нужно выполнять. Поэтому, бета 0, «для посмотреть».
Магазин на ней построить нельзя, но любопытство утолить — очень даже. Хотя, если вам не нужны заказы — то можно уже использовать по полной!

Также, в поддержку, запустил отдельный сайт на котором открыта админка — minishop2.com.

Не все читают «звезданутые» заметки, поэтому я коротко расскажу, что нового в MS2. В двух словах — всё переписано с нуля, от miniShop осталось только название.

Провел первый тест скорости выборки товаров, на скорую руку. Просто раскопировал 10000 товаров, со всеми свойствами в одной категории и почистил кэш.

Первая загрузка после очистки кэша, limit 10


Вторая загрузка, limit 10

Еще один текст с modcoach.info, в котором я рассказываю чем работаю с сервером.

Сразу говорю, разные Denwer и подобные приложения, эмулирующие GNU/Linux веб-сервер на Windows я не использую. Это потому, что на мой взгляд, разрабатывать сайты и приложения нужно в той среде, в которой он будет работать (или в очень похожей).

Не знаю, как сейчас дела у современных эмуляторов, но вряд ли у них есть php-apc, запуск заданий по cron, разные права доступа для разных юзеров, указание процессов php дляя каждого сайта, командный интерпретатор bash и прочие нативные фишки линуксового окружения.

Поэтому, мой выбор — свой собственный VPS или VirtualBox. Для первого случая заметка тут, а для второго — тут.
Не важно, что вы выберете, главное, что по определенному адресу у вас будет настоящий GNU/Linux. Шеф-повар рекомендует Ubuntu.

Возможно, miniShop2 будет первым компонентом, 100% совместимым с ajaxManager. Во всяком случае, я очень стараюсь так сделать.

Не многие задумывались, что вместе с MODX Revolution поставляется и phpThumb. Это, фактически, единственная и самая крутая библиотека для работы с изображениями на PHP.

В MODX принято работать с ней через сниппет phpThumbOf, однако у него есть существенные недостатки, например серьёзные тормоза и странное кэширование. Поэтому, верным способом будет работа с библиотекой напрямую.

При разработке "Файлохранилища" мне пришлось покопаться в том, как устроен phpThumb и как он интегрирован в MODX, в результате чего появился универсальный рецепт использования этой библиотеки для генерации изображений.

Заодно решил известную проблему с генерацией уменьшенной копии, с обрезкой из левой верхней части картинки.

Есть распространённая проблема: компоненты из репозитория обычно идут с системными настройками, которые выглядят примерно так:

А хотелось бы вот так:

Все потому, что у объекта modSystemSetting нет полей для хранения ключа записи в словаре, в отличии от параметров сниппетов или плагинов.

Лично мне было лень разбираться, откуда же берутся нормальные записи для настроек ядра, если в объекте и БД их нет, но сегодня я себя переборол и всё прояснилось.