Александр Марков
10 нояб. 2015 г., 16:22

Исключение алиаса ресурса в URL дочерних ресурсов (2)

Продолжение топика об исключении алиаса из URL. Сегодня выяснилось, что указанные мной ссылки ведут в никуда, и я решил восстановить эту информацию, благо, сам постоянно использую эту доработку.
?
Речь об исключении алиаса ресурса из url дочерних объектов способом, предложенным bertoost, за что огромное ему спасибо.
Были споры о необходимости лезть в ядро, но, тем не менее, интерес к этому есть, поэтому я воссоздал эти изменения на github.
Итак, для этого требуется:
  1. Создать в таблице modx_site_content поле exclude_alias_in_childs (boolean), сделать к нему индекс;
  2. Внести изменения согласно github.com/modxcms/revolution/compare/2.x...Tramp1357:Tramp1357-patch-1
Править modx.mysql.schema.xml не обязательно, если не планируется перепостроение схемы.
Если изменения п.2 внести в стандартный дистрибутив MODX, то необходимость в п.1 отпадает: после установки с нуля всё будет работать из коробки.
Почему-то github не показывает изменения в modresource.map.inc.php (я тот еще гитхабер :) ). Там нужно просто добавить поле exclude_alias_in_childs b и индекс к нему. Если открыть сам файл, то изменения в нем есть.
Здравствуйте.
Можете пожалуйста расписать подробнее 1 пункт: 1. Создать в таблице modx_site_content поле exclude_alias_in_childs (boolean), сделать к нему индекс;
Хотя бы просто выложите скриншот, как это должно выглядеть в итоге.
Я думаю если непонятно как это — то это весьма опасно делать Вам самим. Это делается в базе. Я делал через PhpMyAdmin
Да опасного мало) Я тестирую на локальном хостинге. Я нашел в базе таблицу modx_site_content открыл эту таблицу и дальше нажал на вставить, а вот что куда прописывать?(( Да с PhpMyAdmi я пока на вы(((
Для меня это многое объяснило! Спасибо за помощь, буду разбираться!
Сылки на скриншоты не работают. Буду очень благодарен если обновите… очень уж надо…
Если эти изменения внести в стандартный дистрибутив MODX, то после установки все будет работать из коробки.
пожалуйста обновите скриншоты
тема очень насущная. Кто нибудь может сделать пару скриншотов для новичков из phpMyAdmin ?
Большое спасибо!
Александру спасибо за скрины!
Более простой способ — внести все изменения в файлы дистрибутива. Тогда все встанет автоматом при установке. И база тоже будет создана как надо.
а есть ли подробная инфа на русском о том в каких файлах и какие изменения сделать?
изменения нужно делать те, которые указаны на github по ссылке в топике. Русской информации нет. Скажу больше — ее нет и на английском. Я в свое время не один день потратил на поиски. Нашел случайно, когда уже отчаялся. А через пару месяцев те ссылки перестали работать, собственно, поэтому я и создал этот топик.
«Русской информации нет. Скажу больше — ее нет и на английском.» — я уже лично убедился в этом. Перелопатил весь интернет и ничего не нашёл. Сделал всё по инструкции как описано тут github.com/modxcms/revolution/compare/2.x...Tramp1357:Tramp1357-patch-1 — ВСЁ РАБОТАЕТ ОТЛИЧНО! Информация на вес золота )). Огромное спасибо.
Здравствуйте! Спасибо огромное за информацию! Пункт «Не использовать в URL» успешно добавился, но при попытке заменить modresource.map.inc на взятый с гитхабера сайт слетает… можно поподробнее про поле exclude_alias_in_childs b и индекс к нему?
Не нужно заменять полностью файлы, поскольку он может отличаться в разных версия MODX. Нужно просто добавить строку с описанием поля exclude_alias_in_childs.
Саша, не стоит редактировать файлы ядра. Описание колонки лучше в metadata.mysql.php прописать, или плагином.
Да, это тоже вариант, не подумал. Просто описал, как сам делаю :)
Просто описал, как сам делаю :)
И что потом происходит, когда MODX обновляешь? ;) Или не обновляешь?))
Да пока 2.3.6 и использую. Про 2.4+ пока не слышал, что ошибку исправили. Да и при обновлении мне несложно файлы обновить, всё равно ведь в ядро лезть надо :)
Единственно, что я сейчас исключил — это правку базы руками. Я просто в установочном пакете сразу данные про это поле прописываю в modx.mysql.schema.xml — и при установке всё уже есть. Но php всё равно править приходится.
Хотя согласен, твои идеи очень интересны, буду использовать :)
Про 2.4+ пока не слышал, что ошибку исправили.
Ты про эту? Я пока не отписался с подробностями, но коротко: выяснил в чем проблема. Они давно уже вынесли расширяющие пакеты из системных настроек в отдельную таблицу, но с этим у них косяков куча (я про них им писал еще в 13-ом году), в итоге у них чтение этих записей есть, а создания нет (да, и такое бывает :)). При этом именно при обновлении MODX фигачит эти настройки в отдельную таблицу, но MODX при инициализации по разному обрабатывает данные расширяющих пакетов из системных настроек и отдельной таблицы. В общем, в большинстве случаев помогает просто очистка таблицы modx_extension_packages (только не забывает про бекапы).
Да и при обновлении мне несложно файлы обновить, всё равно ведь в ядро лезть надо :)
Если ты все правильно делаешь, то в ядро не придется лезть.
Единственно, что я сейчас исключил — это правку базы руками. Я просто в установочном пакете сразу данные про это поле прописываю в modx.mysql.schema.xml — и при установке всё уже есть.
Ты и это можешь исключить. Когда пакет устанавливается, ты можешь инициировать свой модуль и выполнить добавление колонки средствами самого MODX-а. Вот смотри пример:
<?php $pkgName = 'modImporter'; $pkgNameLower = strtolower($pkgName); if ($object->xpdo) { $modx =& $object->xpdo; $modelPath = $modx->getOption("{$pkgNameLower}.core_path",null,$modx->getOption('core_path')."components/{$pkgNameLower}/").'model/'; switch ($options[xPDOTransport::PACKAGE_ACTION]) { case xPDOTransport::ACTION_INSTALL: case xPDOTransport::ACTION_UPGRADE: if ($modx instanceof modX) { $modx->addExtensionPackage($pkgNameLower, "[[++core_path]]components/{$pkgNameLower}/model/", array( // 'serviceName' => $pkgName, // 'serviceClass' => $pkgName, )); $modx->addPackage($pkgNameLower, MODX_CORE_PATH . "components/{$pkgNameLower}/model/", array( // 'serviceName' => $pkgName, // 'serviceClass' => $pkgName, )); $manager = $modx->getManager(); $manager->addField('modResource', 'externalKey'); $manager->addIndex('modResource', 'externalKey'); $modx->log(xPDO::LOG_LEVEL_INFO, 'Adding ext package'); } break; case xPDOTransport::ACTION_UNINSTALL: if ($modx instanceof modX) { $modx->removeExtensionPackage($pkgNameLower); } break; } } return true;
Это вот сюда фигачится: github.com/MODX-Club/MODX_SamplePackage/blob/master/_build/resolvers/resolver.register.php Только в транспортере надо подключить резолвер.
Ты про эту?
Не, я про эту (наборы параметров)
За информацию спасибо, буду пробовать
Нет, это уже в 2.4.2 поправлено, багфикс приняли.
Функция очень удобная и нужная. В Evo пользовался ею, при чем там она идет сразу с коробки. Честно говоря удивило, что такой функционал реализован в EVO и я его не нашел в REVO… Сегодня пробовал на OpenServer на 2.4.2-pl advanced. Сама строка «Не использовать в URL» с чекбоксом появилась, даже сохраняет, и в дереве ресурсов добавляет ea, но не работает. Все равно добавляет отключенные ресурсы в путь. Перепроверил дважды…
Перепроверь github.com/Tramp1357/revolution/commit/d30ba3b9cfaf4ccd1bde17d6c651460b0b9a3a2d Номера строк такие для версии 2.3.6, в других версиях они могут отличаться. Еще стоит почистить кэш. Метод стопудово рабочий, у меня работает на 6 боевых сайтах, не считая тестовых :)
Все правильно ) Метод рабочий, это я протупил с одной строчкой )))
Столкнулся с такой же проблемой и решил ее банальным CustomURL (https://rtfm.modx.com/extras/revo/customurls) с шаблоном [[+cu.parent_uri]]/[[+alias]]. Чем не метод?
Спасибо огромное, правда не сразу помогло, ковырял как мог, уж опустил руки и пытался разобраться с CustomURL, но о чудо, заработало
Кстати а как? Я пробовал тоже CustomURL недавно, сильно правда не вникал, но с первых двух попыток ничего не заработало. Можете поделиться инфой? Версия MODx 2.5.2
в gist все изменения прописаны. Единственное что — нужно не по номерам строк искать, поскольку в разных версиях MODX они могут отличаться. Просто искать именно эти строки и вносить изменения.
Добрый день. Подскажите пожалуйста, если эти изменения делать на уже работающем сайте, то без обновления modx будет работать?
Не совсем понял вопрос. Если сделаете изменения, то работать будет. После обновления MODX придётся повторить эти действия, т.к. приходится лезть в ядро MODX, и при обновлении эти изменения перетрутся.
Все делал по инструкции, но никаких изменений не произошло. С чем это может быть связано?
Попробуйте физически удалить /core/cache
Привет, можете дать скрины еще раз первого пункта? Не понимаю, какие значения прописать.
Добрый день. там не нужен никакой скрин. Нужно просто зайти в phpmyadmin, открыть базу сайта и в таблицу modx_site_content добавить поле exclude_alias_in_childs (boolean), сделать к нему индекс. Там на скрине была просто картинка из phpmyadmin
а помимо изменения файлов в сайте и бд, нужно что-нибудь еще включать, просто чего-то не появился этот чекбокс, все файлы менял на код, который на гите был.
Я же писал - нужно не полностью менять файлы, а менять именно эти строки. В разных версиях MODX эти файлы могут отличаться, и нужная строка будет не на той позиции.
Ну и кэш не забываем чистить. Можно даже руками удалить core/cache

Если всё сделать правильно, то проблем не возникнет.
да, все сделал, кеш почистил, работает, буду менять строки теперь а не файлы(ничего не поломалось, но на всякий случай), а как понять какие строки менять на гите?
по их содержимому. Номера искомых строк должны находиться там же или рядом с отмеченными на гитхабе
Может, я невнимательно прочитал ветку, но исключение родителя из адреса можно легко сделать без изменений в ядре, плагином на OnDocFormSave.
Немного сумбурно, но все же:
<?php if ($modx->event->name == 'OnDocFormSave') { $depth = 4; $parent = 2; $id = $resource->get('id'); //Если у ресурса уже стоит галочка на перезапись alias-а, выходим if ($resource->get('uri_override') == 1) return; $docParent = $resource->get('parent'); $parentIds = $modx->getParentIds($id, $depth, array('context' => 'web')); if (count($parentIds) == 0 && $docParent != $parent) $parentIds = $modx->getParentIds($docParent, $depth, array('context' => 'web')); elseif ($docParent == $parent) $parentIds[] = $parent; //Если сохраняется документ не из нужной нам ветки $parent, выходим if (!in_array($parent, $parentIds)) return ; $alias = str_replace($modx->makeUrl($parent), '', $modx->makeUrl($id)); $resource->set('uri', $alias); $resource->set('uri_override', true); $resource->save(); }
В этом примере исключаем алиас родителя с id=2 на вложенности до 4 уровней в ветке.
Соответственно, если нужно исключать на большей вложенности, увеличиваем $depth, а если нужно исключать несколько родителей, это несложно переделать на массив с нужными id.
всё это интересно, но сам топик о том, чтобы в документе один раз поставить галочку, и у всех его дочерних элементов его алиас в uri уже не указывался. Причем в любой вложенности.
Этот функционал есть по дефолту в версии 2.7.0
Пока не пробовал - 2.7.0 ломает работу modSmarty, а у меня все сайты на нём
Проще способ подойдет не для всех, но все же, используем только замороженые ури:

if (!$useFrozenPathUris) { $parentResources[]= "{$parentAlias}"; }


Добавить комментарий