Нашел сегодня еще одну очень неприятную багу. На самом деле она очень серьезная, и в отдельных случаях может не только доставить неудобства, но и к серьезным ошибкам привести. Когда мы выполняем $modx->getCollection($class), мы получаем массив объектов. Но это не простой нумерованный массив (типа array(0 => object, 1 => object) и т.д.). В этом массиве у нас каждый ключ — это id объекта, то есть ключи часто идут не по порядку (3,7,9,57 и т.д.). Те, кто использует ->getMany(), знают — этот метод возвращает связанные объекты. По сути этот метод внутри себя выполняет тот же самый getCollection(). Но проблема кроется всего в одной строчке: $this->_relatedObjects[$alias]= array_merge($this->_relatedObjects[$alias], $collection); То есть все связанные объекты попадают в общий массив $this->_relatedObjects. Уточняю: getMany() не просто делает выборку getCollection(), но и набивает эти объекты в общий пулл связанных объектов. И с этим массивом связанных объектов $this->_relatedObjects можно (а иногда и нужно) работать. Так вот, проблема в том, что array_merge не сохраняет ключи-id объектов, а набивает все в новый нумерованный массив. Фокус хорошо демонстрирует вот этот пример: <?php $a = array( 2=>'object'
);

$b = array_merge($a, array( 5=>'object', 7 => 'object', ));

print_r($b); На выходе мы получаем: Array ( [0] => object [1] => object [2] => object ) Последствия (от неудобств до проблем) Неудобство заключается вот в чем: Допустим, мы знаем, что уже получали все зависимые объекты, и теперь просто хотим проверить наличие объекта по его id. У наших объектов есть id-шники 7,9 и 12. По идее мы имеем возможность по id обратиться к ключу массива, то есть $object->_relatedObjects[$alias][7] должен нам вернуть нужный нам объект. Ан нет. Из-за этой баги у нас там теперь массив с ключами 0,1,2… То есть объект мы уже потеряли. А что произойдет, если мы опять выполним $object->getMany()? По сути 3 объекта он уже в себе имеет. Но из-за этой фишки с array_merge, мы получим уже 6 объектов, так как в новом массиве объектов ключи 7,9 и 12, а в текущем массиве 0,1,2, и теперь станет еще и 3,4,5. А если у нас id-шники 3453,6757,90980 и мы выполним getMany() много раз? :-) Еще пример. if(!$room = $modx->getObject('modResource', 107)){return '';}

// Получаем все связанные объекты $vars = $room->getMany('Variables');

print count($room->_relatedObjects['Variables']); // Считаем - 2 объекта

// Получаем один из имеющихся объектов $var = current($room->_relatedObjects['Variables']);

// Добавляем его же $room->addMany($var);

print count($room->_relatedObjects['Variables']); // Уже 3 объекта По сути это тоже самое, просто другим путем. Но суть в чем: вот одна строчка из этого метода $this->_relatedObjects[$alias][$objpk]= $obj; То есть затирается элемент массива объектов с ключем id этого объекта. Но по нашей схеме в зависимости от того, какой id у объекта, он во-первых, может затереть вообще другой объект (а тот мог быть измененным, а значит при сохранении главного объекта этот объект уже не будет сохранен), а во-вторых, этот новый объект может встать или впереди, или позади своей же копии, но эти две копии могут отличаться (новый объект перед добавлением изменили), так вот в зависимости от их очередности, при сохранении главного объекта, эти объекты будут сохранены, и не факт, что в правильной исторической последовательности. Вот как-то так…

Пожалуйста:-)

Если такая возможность появится штатно, будет очень здорово! Как всегда, Спасибо тебе за статью!

Привет, Илья! Да, результат addExtensionPackacge() — это как раз запись в эту настройку. Так что и так, и так можно. Надо попробовать добавить в extension_packages строчку и для процессоров. Тогда вообще не придется задумываться, что у меня какие-то левые объекты или процессоры — весь код будет стандартным)))) Не получится здесь одной строчкой обойтись. Задача того, что я делал — возможность подгружать любой процессор из любого пакета, при чем с автоформированием пути. Там слишком много тонкостей. Плюс мой метод возвращает реальное имя класса (сам знаешь, в процессорах используется return 'classname';) Все это никак не укладывается в одну строчку. Еще момент — ты вот своим методом подгрузишь мой процессор, а у меня там используется $this->loadClass(), а у тебя $this будет другим объектом. И все, код разваливается. Здесь любое решение будет костылями (и лучше использовать одни костыли). Решить это можно только тогда, когда Джейсон новый релиз выпустит, учитывающий все эти моменты. Мы вчера с ним основательно пообщались на этот счет. Уверен, он и других людей мнение учитывает, так что будет стандартное решение.

Кстати, есть второй способ прописать пакет, чтобы он подключался при инициализации MODx (по идее это тот же способ, только ручками): заходим в настройки системы, раздел «Система и сервер» и находим там параметр «Пакеты расширений» (extension_packages). Если мы до этого хоть раз запускали addExtensionPackage(), то в его значении уже будут все параметры в JSON — их можно исправить, что-нибудь добавить к ним… Если addExtensionPackage() не запускали, то можно там прописать ручками: [{"Rehab": { "path":"[[++core_path]]components/rehab/model/", "tablePrefix":"modx_rehab_", "serviceName":"Rehab", "serviceClass":"Rehab" } }] (конечно, в одну строчку) Для разных нужных методов, которые используются в разных местах я создал отдельный класс Rehab (в папке пакета) и в нем прописываю функционал. Благодаря этому я в любом месте могу написать $modx->Rehab->phonesToJSON($phones); и массив обработается с нужными проверками, дефолтными значениями. И результат будет каким надо. Если потребуется изменить алгоритм обработки телефонов, я всегда знаю, где искать этот код. А вот пути для процессоров прописывать приходится, конечно… Надо попробовать добавить в extension_packages строчку и для процессоров. Тогда вообще не придется задумываться, что у меня какие-то левые объекты или процессоры — весь код будет стандартным))))

Да. Но дело не только в радости глаза. Уверен, Джейсон сделает все красиво, с неймспейсами и т.п., и будет полная автоподгрузка. На сколько я слышал, у него наработки есть с существенными плюсами по производительности.

Для отступов использовать 4 пробела вместо табуляции. всегда юзал пробелы, где мог) табуляция меня раздражает)) Именовать классы НадоТак а я ещё люблю префиксы-аббревиатуры делать, так сказать группируя по неким общим признакам (напр. имя пакета — нпмВотТак). практически все остальное совпадает со стандартами, наверно работая с modx/xpdo само-собой подстроилось) такой код всегда радует глаз

Топик дополнил новым материалом.

Не так давно мы с Иваном vanchelo часа два убили, пытаясь разобраться в одной мистике, которая до конца нам так и не далась. Плюс к этому на облаке при вызове метода exit() постоянно вываливаются ошибка Catchable fatal error: Argument 1 passed to xPDOObject::load() must be an instance of xPDO, instance of modX given in www/core/xpdo/om/xpdoobject.class.php on line 404. Скорее всего эти оба момента взаимосвязаны, и Иван правильно предполагал по поводу APC, во всяком случае сейчас получил ответ от Шона: It's because of APC and sessions. You need to call this before calling exit() or die(): @session_write_close(); Так что имеем ввиду, на всякий случай.

Вот потому пусть лучше related остается на месте :-)