Алексей Карташов

С помощью Office'а можно залогиниться в админке с фронтенда, но не наоборот.

Не за что)

Только имейте в виду — разлогиниться при таком подходе, практически нереально. Только если неделю на сайт не заходить, пока авторизационные куки не умрут.

Если автологин в админку не нужен, то первый блок if {} лучше закомментировать (тот, который «авторизовывает админа в админке»):

//    if (!$modx->user->hasSessionContext('mgr') && $modx->user->hasSessionContext($modx->context->key) && ($modx->user->get('sudo') || $modx->user->isMember('Administrator'))) {
//      $modx->user->addSessionContext('mgr');
//    }

Создаёте плагин, этот код вставляете в него, а затем во вкладке «Системные события» в большом и длинном списке ищете «OnWebPageInit», отмечаете чекбокс напротив него и сохраняете. Вуаля)

Супер!

никто до сих пор и не заметил =)

Похоже, готовые сайты вообще никто не обновляет)

*(если он авторизован на фронте, и является администратором)

switch ($modx->event->name) {
  case 'OnWebPageInit':
    if ($modx->context->key == 'mgr') {
      return;
    }

    /** авторизовывает админа в админке (если он не авторизован на фронте, и является администратором) */
    if (!$modx->user->hasSessionContext('mgr') && $modx->user->hasSessionContext($modx->context->key) && ($modx->user->get('sudo') || $modx->user->isMember('Administrator'))) {
      $modx->user->addSessionContext('mgr');
    }

    /** авторизовывает на фронте любого юзера, который авторизован в админке */
    if ($modx->user->hasSessionContext('mgr') && !$modx->user->hasSessionContext($modx->context->key)) {
      $modx->user->addSessionContext($modx->context->key);
    }

    break;
}

Я для себя написал универсальную функцию изменения системной настройки, которая 100 пудов её изменяет и новое значение доступно сразу же и без дальнейших причуд:

function changeSetting ($key = '', $value, $config = array()) {
  global $modx;

  if (empty($key)) { return false; }

  /* @var $response modProcessorResponse */
  $response = $modx->runProcessor('system/settings/update', array_merge(array(
    'key' => $key,
    'value' => $value,
    'namespace' => 'core'
  ), $config));

  if ($response->isError()) {
    $modx->log(modX::LOG_LEVEL_ERROR, '[avk] Cann\'t update setting with messages: '. print_r($response->getAllErrors()));
    return false;
  }
  $modx->reloadConfig();
  return true;
}

Вызывать надо вот так:

changeSetting('pdoFetch.class', 'pdotools.mypdofetch', array(
  'namespace' => 'pdotools'
));

Namespace указывать надо обязательно, если настройка из стороннего компонента.

Для ознакомления:
bezumkin.ru/sections/components/1857/#comment-15167

В своё время задавлся этим вопросом и даже пытался сделать что-то реальное, но в итоге… Всё расписано в том комменте)

AjaxSnippet — он как ниндзя, не заметен

Спасибо)

А какое поле ты подразумеваешь, говоря «имеющееся»? Какое-нибудь наименее используемое у ресурса? Я из таких знаю только Атрибут ссылки. Но у него длина ограничена 255 символами.

Это мне переписывать)

А вам сейчас просто переустановить расширение на тестовом сайте :-)

Я пока температурю. До рабочего компьютера не знаю когда доберусь

Ну, судя по всему, в созданном бекапе не экранированы какие-то спец.символы, которые в исходном html'е есть.

Надо переписывать, чтоб не голый html в базе хранить, а хэш.

Вам сейчас эта таблица и не нужна. Просто переустановите компонент на тестовом сайте и тестируйте

Ну так по смыслу это ни чем не отличается от того же выбора секции в форме добавления тикетов с фронта. Тот же заранее заданный список. Только вместо комбобокса — pillbox с автокомплитом. Надо просто это в одну кучу собрать.

Просто сделать такой интерфейс универсальным несколько сложнее. Из коробки будет заточенность только под бутстрап.

Ну разные окончания — тут уж пусть каждый сам решает что ему важнее. Можно сделать событие, в котором каждый сам будет исправлять теги как ему нужно — хоть через phpMorphy к начальной форме слова приводить.
Но лично я подразумевал, что процесс создания тегов контролируется администратором сайта, а не пользователями. Пользователям вообще нельзя теги давать, иначе они в них нах*есосят. Либо по-умолчанию эти теги делать неопубликованными, а потом постоянно в ручную проверять на корректность

В этом и вся фишка — в этом алгоритме твшки в выборках практически не учавствуют.
Единственное место, где они будут нужны — это вывод списка тегов на странице. И здесь вопрос решается очень и очень просто — pdoResource.
В pdoTools'е всё уже предусмотрено. Так что скорости будут максимальными

Ты не уловил посыл)
Главное не «тегирование из коробки», а «правильное тегирование». Правильное в коробку завернуть как раз не проблема, было бы оно правильным :-)

Может быть на следующей неделе соберу. Хз когда выздоровлю.

Я тут долго расписывал чем вредны теги, но надоело, если честно, и я забил)
Поэтому просто расскажу, как _надо_ делать тегирование.

Нужны:
1. Тикетс;
2. 2 tv;
3. 1 плагин;
4. 1 таблица.

Создаём раздел с тикетами. Называем его, к примеру «Теги» :-)
Создаём tv. В него будем записывать теги для страницы.
На сохранение ресурса (у которого д.б. теги), в плагине, смотрим в этот tv, разбираем теги и на каждый создаём тикет в нашем разделе «Теги». У этих тикетов-тэгов д.б. tv-шка, в которую мы в исходном виде записываем текст тега.
Потом записываем в нашу таблицу id ресурса и id тикета-тега (сколько тегов, столько и записей в таблице), не забывая перед этим очистить все прошлые записи для этого ресурса (ну вдруг мы отредактировали ресурс и какой-то тег удалили. Чтобы не заморачиваться с логикой — просто удаляем все записи для этого ресурса, а потом сохраняем текущие).
Выборку статей с данным тегом делать pdoResource'ом.

Собственно всё.
Я бы собрал пакетик на днях, да только болею я.

В общем, в чём профит.
На каждый тег будет отдельный ресурс. Да, если тегов 1000, то и ресурсов будет 1000. Если кого-то такой вариант не устраивает, то… не мои это проблемы)
Смысл в том, что у каждой страницы-тега можно редактировать урлы, контент, тайтлы, дескрипшены, да и вообще что душа пожелает — это же обычный ресурс. Это просто рай для любого более-менее грамотного сеошника. Вы в своих интернет-магазинах (и не только) сможете просто нереально расширить семантику, поднять траффика и позиции по куче низкочастотников. Достаточно небольшого уникального текста символов на 300, уникального тайтла и дескрипшена на каждой легированной странице. Вот и всё.
Все остальные варианты тегирования, в большинстве случаев, будут только во вред.

Между прочим, такие темы на платных закрытых вебинарах задвигают. А я вам готовый инструмент практически дал. Не упускайте шанс, как говорится.

Всем добра :-)

Вот честно говоря, ни разу с таким поведением не сталкивался. И до этого подобных жалоб не было. Так что тут что-то уникальное исключительно для вашего сайта.
Логика отдачи заголовка проста как топор и нарушений в её работе добиться очень сложно. Может из-за nginx'а что-то.
Единственное, что могу посоветовать, — попробовать на другом хостинге протестировать (только аккуратно, чтобы поисковики не успели тестовый сайт проиндексировать), на каком-нибудь из рекомендуемых для modx. Если ошибка повторится, то дело в сайте, надо будет копать глубже.

А по поводу вылета из индекса…
С одной стороны не на столько это критичная ошибка и не на столько критичный фактор, чтобы весь сайт из индекса выкидывать.
С другой — этих роботов, порой, хер поймёшь. У АГС'а тоже есть статистический процент ошибок. Тут только ответа Платона ждать.
А в вебмастере смотрели? Там может быть что-то на эту тему, если есть проблемы с индексацией.

А на данный момент, просто выключите плагин. Если это мешало индексации, то пара хороших ссылок с твиттера и зайдёт обратно, никуда не денется. Но сперва дождитесь ответа Платона.

Этот вопрос — основа основ и поднимается он в modx-сообществе с совершенно НЕзавидной регулярностью.
Как?! Как, делая сайты, можно не знать про абсолютные и относительные ссылки и пресловутый base href?
Это уже даже не смешно.
Может пора счёт вести?