Когда-нибудь будут, как руки дойдут :)
блин, как жаль что комментарии не редактируются :(
со всем согласен, но такие вещи хотя бы как псевдомодули (или патчи, расшмрения) оформлять как-то можно бы :)
к тому же придется делать это вручную Зачем что-то вручную делать, если у MODX есть пригодный для этого API? На крайний случай — SQL или простой PHP-скрипт. Возможно, такой функционал действительно пользовался бы спросом, но я лично не припомню, чтобы это когда-либо требовалось (да, я видел новостные сайты, где alias новости идёт сразу после доменного имени, но до сих пор не понимаю целесообразности). Если не секрет, для чего потребовалось изменять ядро ради задачи, решаемой элементарным плагином?
Вы хорошо понимаете что такое рекурсия и как сделать выборку всех документов без ограничения количества вложенности? Не Wayfinder юзая, но свой код на php написав?
И я не понимаю, почему такой удобной функции до сих пор нет в самом ядре. Если бы все интересные и полезные функции в ядро отправлялись, MODX бы уже сдох наверно от переизбытка веса :) Но да, некоторые вещи даже очень важные в ядро почему-то не попадают. К примеру вот это я писал в далеком 11-ом году: Тюнинг MODx Revolution. Оптимизация кэша. Загрузка страницы менее чем за 0,4 сек. при > 1 000 000 документов. И все, что надо было — это просто добавить в документ галочку «не добавлять в кеш-карту». Это бы позволило MODX-у без проблем работать с десятками и сотнями тысяч документов. То есть, как не крути, а именно из-за этой мелочи MODX до сих пор себя плохо ведет с большим количеством документов. Ан нет… До сих пор не включено. До сих пор приходится юзать cacheOptimizer на больших проектах.
Примеры:
- каталог с большим уровнем вложенности и сотнями товаров. Грустно будет править url в каждом, да и ошибиться нетрудно.
- много статей — для удобства работы можно создать технические подпапки articles/dir1/dir1-1/article1 articles/dir1/dir1-2/article2 articles/dir2/dir1-1/article3 ... и можно не греть голову с url типа /articles/dir1/dir1-1/article1 а будем точно знать (и не переживать, что забыли подправить), что адреса будут articles/article1 articles/article2 articles/article3 ... Да и работы меньше при наполнении. :)
Я всё равно не понимаю. Давайте, разберём пример и я пойму, почему я не прав? Допустим, есть родительский ресурс news, у которого есть дочерние ресурсы. Соответственно, список статей доступен по адресу localhost/news/, а каждая новость доступна по адресу localhost/news/nazvanie. Но мы захотели, чтобы uri любой новости выглядел так: localhost/nazvanie. Для простоты допустим, что у нас ещё нет новостей. Итак, я кликаю правой клавишей по «Новости» -> «Создать ресурс». Заполняю поля. Нажимаю сохранить. Плагин замораживает uri у только что созданного ресурса новости, исключая uri родительского ресурса. И, каждый раз создавая ресурс, его uri будет замораживаться и не будет меняться при очистке кэша и пр. Допустим, даже, что у нас уже были какие-то дочерние ресурсы. Не составляет сложности пройтись единожды по этим ресурсам и подкорректировать uri, предварительно заморозив.
Можно и так, конечно. но у меня стоит проблема с перенесением достаточно большого количества страниц, к тому же придется делать это вручную, т.к. на старом сайте страшный контент, и нужно будет его чистить руками. Да и плагин плагином, но, на мой взгляд, так поудобнее все-таки. И я не понимаю, почему такой удобной функции до сих пор нет в самом ядре.
Ури замораживается только для текущего документа и не учитывается дочерними. Если заморозку не трогать, то меняя алиас какого-нибудь раздела, ури обновляются у всех подразделов и дочерних документов на любой уровень вложенности. То, что предлагает Саша, учитывается в формировании УРЛов всех дочерних документов автоматически. Вы же предлагаете морозить урлы отдельных документов.