Столкнулся с тем, что клиент попросил удалять из URL алиасы промежуточных родителей (выборочно). Документов достаточно много, и заморозка URL — не самый удобный вариант.
Уверен, не я один столкнулся с подобной проблемой.
Поиск привел в github. Да, требуется внести изменения в ядро, но, думаю, оно того стоит.
Решение здесь:
Необходимо создать в таблице modx_site_content поле exclude_alias_in_childs (boolean), сделать к нему индекс
и внести в MODX изменения, указанные на гитхабе.
У кого русский MODX, можно кроме
core/lexicon/en/resource.inc.php
подправить еще и
core/lexicon/ru/resource.inc.php
дав нужное название чекбоксу.
В результате на закладке документа «Настройки» появится чекбокс «исключить из Exclude resource alias in child aliases».
Если его включить, то алиас этого ресурса не будет участвовать в формировании URL дочерних ресурсов.
Как вариант, можно было бы написать плагин, срабатывающий при сохранении ресурса и решающий (по какому-то критерию), какой uri установить у ресурса. По-моему, это проще. Или я неверно понял задачу?
Это крайне проблематично. Дело в том, что установка uri выполняется не в самом плагине, а в modResource::refreshURIs(), к тому же еще и рекурсивно. Без модификации ядра тут вряд ли что-то можно сделать.
А как же поставить галко «Заморозить урл» и вписать нужное в настройках ресурса? Или я неверно понял задачу ))?
Документов достаточно много, и заморозка URL — не самый удобный вариант.
Понял, ставлю плюс в тему.
Я извиняюсь, что задаю вопрос, не разбираясь в механизм формирования uri и очистки кэша, но всё-таки сделаю это.
А что, если плагин будет замораживать uri при сохранении? Я, не вчитываясь, углядел в методе refreshURIs какую-то проверку на заморозку uri.
Опять таки, под неудобством заморозки URI автор имел ввиду ручную заморозку. Если организовать это в плагине, то я пока не вижу проблем.
Ури замораживается только для текущего документа и не учитывается дочерними. Если заморозку не трогать, то меняя алиас какого-нибудь раздела, ури обновляются у всех подразделов и дочерних документов на любой уровень вложенности. То, что предлагает Саша, учитывается в формировании УРЛов всех дочерних документов автоматически. Вы же предлагаете морозить урлы отдельных документов.
Можно и так, конечно. но у меня стоит проблема с перенесением достаточно большого количества страниц, к тому же придется делать это вручную, т.к. на старом сайте страшный контент, и нужно будет его чистить руками.
Да и плагин плагином, но, на мой взгляд, так поудобнее все-таки. И я не понимаю, почему такой удобной функции до сих пор нет в самом ядре.
Я всё равно не понимаю. Давайте, разберём пример и я пойму, почему я не прав?
Допустим, есть родительский ресурс news, у которого есть дочерние ресурсы. Соответственно, список статей доступен по адресу localhost/news/, а каждая новость доступна по адресу localhost/news/nazvanie. Но мы захотели, чтобы uri любой новости выглядел так: localhost/nazvanie.
Для простоты допустим, что у нас ещё нет новостей. Итак, я кликаю правой клавишей по «Новости» -> «Создать ресурс». Заполняю поля. Нажимаю сохранить. Плагин замораживает uri у только что созданного ресурса новости, исключая uri родительского ресурса. И, каждый раз создавая ресурс, его uri будет замораживаться и не будет меняться при очистке кэша и пр.
Допустим, даже, что у нас уже были какие-то дочерние ресурсы. Не составляет сложности пройтись единожды по этим ресурсам и подкорректировать uri, предварительно заморозив.
Примеры:
1. каталог с большим уровнем вложенности и сотнями товаров. Грустно будет править url в каждом, да и ошибиться нетрудно.
2. много статей — для удобства работы можно создать технические подпапки
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 ...
Да и работы меньше при наполнении. :)
И я не понимаю, почему такой удобной функции до сих пор нет в самом ядре.
Если бы все интересные и полезные функции в ядро отправлялись, MODX бы уже сдох наверно от переизбытка веса :)
Но да, некоторые вещи даже очень важные в ядро почему-то не попадают. К примеру вот это я писал в далеком 11-ом году: Тюнинг MODx Revolution. Оптимизация кэша. Загрузка страницы менее чем за 0,4 сек. при > 1 000 000 документов. И все, что надо было — это просто добавить в документ галочку «не добавлять в кеш-карту». Это бы позволило MODX-у без проблем работать с десятками и сотнями тысяч документов. То есть, как не крути, а именно из-за этой мелочи MODX до сих пор себя плохо ведет с большим количеством документов.
Ан нет… До сих пор не включено. До сих пор приходится юзать cacheOptimizer на больших проектах.
Вы хорошо понимаете что такое рекурсия и как сделать выборку всех документов без ограничения количества вложенности? Не Wayfinder юзая, но свой код на php написав?
к тому же придется делать это вручную
Зачем что-то вручную делать, если у MODX есть пригодный для этого API? На крайний случай — SQL или простой PHP-скрипт.
Возможно, такой функционал действительно пользовался бы спросом, но я лично не припомню, чтобы это когда-либо требовалось (да, я видел новостные сайты, где alias новости идёт сразу после доменного имени, но до сих пор не понимаю целесообразности). Если не секрет, для чего потребовалось изменять ядро ради задачи, решаемой элементарным плагином?
со всем согласен, но такие вещи хотя бы как псевдомодули (или патчи, расшмрения) оформлять как-то можно бы :)
блин, как жаль что комментарии не редактируются :(
Когда-нибудь будут, как руки дойдут :)
Если не секрет, для чего потребовалось изменять ядро ради задачи, решаемой элементарным плагином?
Василий, еще раз: то, что вы предлагаете, плагином не решается. Разве еще не ясно? Попробуйте влезть плагином в это изменение, да так, чтобы все дочерние документы обновились как надо:
$doc = $modx->getObject('modResource', $id); $doc->set('alias', $new_alias); $doc->save();
можно отключить вложенные URI, но
1.это не всегда подходит
к примеру, есть товар, который лежит в каталоге в
/каталог/потолки/подвесные потолки/подвесные_потолки_armstrong/название_конкретного_товара
а на выходе должно быть
/каталог/подвесные_потолки_armstrong/название_конкретного_товара
2.возникает проблема с уникальностью URI.
На самом деле я не навязываю этот способ, просто второй раз сталкиваюсь с такой проблемой, и подумал, вдруг кому еще пригодится :)
Как-нибудь попробую подумать на эту тему. Я изначально подумал про частный случай с двумя уровнями (новости/новость), не учитывая больший уровень вложенности. Тогда однозначно спасибо Александру. Если этого не будет в ядре, когда понадобится, обращусь к статье.
CustomUrls не решает эту задачу?
Насколько я его понял, он выполняет другие задачи. Не нашел я (правда, глубоко не вдавался) в нем возможности из
/каталог/потолки/подвесные потолки/подвесные_потолки_armstrong/название_конкретного_товара
сделать
/каталог/подвесные_потолки_armstrong/название_конкретного_товара
Да и на самом деле то, что предложено в этом топике, делается за 5 минут, и не требует больше никаких действий кроме как выставить/снять галочку.
Я не сторонник различных довесков, которые нагружают систему.
Да и банальная лень — проще сделать как проще :)
Действительно, почему-то удалены. Сегодня постараюсь выложить описание процесса
А можно как то сейчас их получить?
Спасибо заранее)
К сожалению, я за компьютером буду около 16-00. Все надо собрать с рабочего сайта.
Ок, тогда жду )