Ганин Роман

А в чем сложность бекапов?
На Ansible элементарно делается.

---
 - hosts: 'all'
   gather_facts: no
   vars_files: 
    - 'vars/main.yml' 

   tasks:
    - name: 'Sync'
      synchronize: src=/var/www/{{ username }}/ dest=/backup/{{ username }} owner=no group=no delete=yes
      tags: 'update'
    
    - name: 'DB backup'
      mysql_db: state=dump name={{ username }} target=/backup/{{ username }}/{{ username }}.sql login_user=root login_password={{ mysql_root_pass }}
      tags: 'update'

    - name: 'Sync restore'
      synchronize: 
       src: /backup/{{ username }} 
       dest: /var/www/
       delete: yes 
       rsync_opts:
        - "--exclude=.sql"
      become: yes
      become_user: "{{ username }}"
      tags: 'restore'

    - name: 'Del MySQL database'
      mysql_db: 'name={{ username }} login_user=root login_password={{ mysql_root_pass }} state=absent'
      tags: 'restore'

    - name: 'Add MySQL DB'
      mysql_db: 'name={{ username }} encoding=utf8 login_user=root login_password={{ mysql_root_pass }} state=present'
      tags: 'restore'

    - name: 'DB restore'
      mysql_db: state=import name={{ username }} target=/backup/{{ username }}/{{ username }}.sql login_user=root login_password={{ mysql_root_pass }}
      tags: 'restore'

modx.pro/help/7072/#comment-49706

1. файл core/components/minishop2/model/minishop2/minishop2.class.php
строка 263 — функция getCustomerId создает пользователей, если их нет. Здесь можно добавить сохранение телефона. Только потом минишоп нельзя обновлять)
2. плагин на событие msOnChangeOrderStatus
происходит в нем примерно следующее:

<?php
$user = $modx->getObject('modUser', $order->get('user_id'));
$prof = $user->getOne('Profile');

if ($prof->get('logincount') > 0 || $order->get('status') > 1) return;

$pass = $user->generatePassword(6);
$user->set('password', $pass);
$user->save();

$message = "<p><strong>Ваши данные для входа в личный кабинет на сайте ".$modx->getOption('site_name')."</strong></p>
            <table>
            	<tr><td><strong>Логин:</strong></td><td>".$user->get('username')."</td></tr>
            	<tr><td><strong>Пароль:</strong></td><td>".$pass."</td></tr>
            </table>";
$modx->getService('mail', 'mail.modPHPMailer');
$modx->mail->set(modMail::MAIL_BODY, $message);
$modx->mail->set(modMail::MAIL_FROM, $modx->getOption('emailsender'));
$modx->mail->set(modMail::MAIL_FROM_NAME, $modx->getOption('site_name'));
$modx->mail->set(modMail::MAIL_SENDER, $modx->getOption('emailsender'));
$modx->mail->set(modMail::MAIL_SUBJECT, 'Ваши данные для входа на сайт');
$modx->mail->address('to', $prof->get('email'));
$modx->mail->setHTML(true);
if (!$modx->mail->send()) {
    $modx->log(modX::LOG_LEVEL_ERROR,'An error occurred while trying to send the email: '.$modx->mail->mailer->ErrorInfo);
}
$modx->mail->reset();

Это будет отдельное письмо, сам заказ отправляется минишопом, туда я не влезал.

То есть создаем группу ресурсов, отправляем туда ресурс-категорию, и при добавлении в акцию группы ресурсов, под нее попадают все товары категории? Если это так, то круто.

Не стоит выбирать все комментарии, если можно сразу получить их количество.

$comments = $modx->getCount('TicketComment', array('published'=>0) );

Это быстрее на порядки.

Потому что у тебя не JSON указан. Должно быть так:

[[!pdoUsers?
    &groups=`4`
    &tpl=`userCardPro`
    &select=`{
        "modResource":"COUNT(resource.id) as users_work"
    }`
    &leftJoin=`{
        "modResource":{"class":"modResource","alias":"resource","on":"modUser.id=modResource.createdby"}
    }`
    &showLog=`1`
]]

ИМХО — зря заминусовали. Вопрос-то стоял «как сделать доступ к определенной странице сайта одному единственному пользователю». С одной стороны да — ответили. Через группу и т.п. С другой стороны, это вопрос, который действительно касается слабой и темной стороны MODX-а — предоставление прав конкретным пользователям. Представьте, что вы запускаете социалку на MODX, где пользователи могут писать свои топики и предоставлять права каким-то отдельным друзьям. Сейчас, если пытаться такое реализовать, придется плодить 100500 групп пользователей. Потому что в MODX нет механизма предоставления прав на что-либо конкретно пользователям. Есть предоставление прав группам пользователей на группы ресурсов и т.п. А уже потом разбираться к каким группам относятся пользователи и документы. Это не есть гуд. И это действительно запутанно. Так же в MODX нет такого понятия как owner (то есть владелец сущности). На мой взгляд это тоже было бы правильно учитывать. Если я создатель какой-то сущности — значит я имею на нее все права. Это по логике. Но на практике такого нет.

В свое время я заморочился допиливанием механизма политик MODX-а, чтобы учитывались индивидуальные права пользователей, без необходимости добавления ресурсов и пользователей в группы. То есть можно было давать права как отдельным людям, так и отдельным группам. Конечно же пришлось использовать CRC. Если кому интересно, вот некоторые коды:
modzilla.class.php — основной класс модуля
modzillaproject.class.php CRC Проект
modzillaaccess.class.php кастомный класс политик безопасности.
modzillaaccessprojects.class.php что-то там тоже с правами связанное.

Писалось все это очень давно, так что в деталях многого не помню уже. Но это работало. По этому вопросу материал в помощь:
modxclub.ru/blog/dokumentatsiya-dlya-spetsialistov/26.html
modxclub.ru/blog/dokumentatsiya-dlya-spetsialistov/28.html
modxclub.ru/blog/113.html

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

1. Pacman
2. Организация рутины при свежей установке modx
Я примерно, как во втором варианта собираю сейчас.

Хотел пройти мимо, но я не удержался :)

Откуда вообще могут взяться дубли по url, если этих url нигде нет?

Вот прям в тему сегодняшняя статья:
habrahabr.ru/post/253943/
Нигде урлов на документы нет, но они всё-равно в индексе. Странно, да?)

Ссылки с сайтов — не единственный источник урлов для поисковых систем.

Была как-то пару лет назад история с метрикой примерно следующего содержания:
У какого-то крупного ресурса есть страницы закрытого раздела (типа личного кабинета). К этим страницам доступа без логина/пароля нет. Из вне отдавалась 403/401 (не суть).
Суть в том, что в индексе яндекса оказались тысячи страниц с личными кабинетами тысяч пользователей.

Т.е., понятное дело, что ссылки из выдачи яндекса вели на те самые закрытые разделы, которые для незалогиненного на этом сайте пользователя отдавали страницу входа (или типа того), но в кеше поисковика были полностью скопированные страницы личных кабинетов — с фио, адресами, историями покупок. Аааа! Вспомнил! Тема усугублялась тем, что то был не просто сайт, а магазин с интим-товарами xD
Тема ищется на хабре (мне лень искать, честно). Так вот, там, на хабре, начали копать и выяснилось, что в индекс попали только те из закрытых страниц, на которых была установлена яндекс.метрика. Оказывается яндекс молча решил отправлять в индекс то, что ему захочется, но вот всех остальных он об этом как-то забыл предупредить. На свои сервера он отправлял не просто урлы, а копии html, из-за чего случился тот самый казус.
После этой истории в настройках счётчика появилась опция включения запрета на индексацию: help.yandex.ru/metrika/code/stop-indexing.xml
К слову сказать, хитрожопый яндекс спрятал эту опцию в блоке «Дополнительно» (который в исходном состоянии «закрыт») и сделал её по умолчанию отключённой:

Что как бы намекает на то, что у тысяч, а может быть и у сотен тысяч пользователей, эта настройка останется выключенной и яндекс с чистой совестью продолжит индексировать то, что ему захочется.

А знаете, в чём прикол?
В том, что и на modx.pro, и на modstore.pro (в т.ч. в личном кабинете) — везде установлена метрика, у которой отключена эта настройка! Т.е. юридически вы разрешили яндексу индексацию личных кабинетов пользователей. Вот ведь какая ирония xD
Понятное дело, что яндекс с тех времён стал поумнее и страницы, которые не запрещено индексировать и при этом отдают 403/401/etc, — он в индекс не засунет.
Это, опять же, к слову о том, почему важны правильные коды ответов сервера и которые на том же fl.ru, скорей всего, были некорректно настроены из-за чего приватные документы и попали в индекс.

Однако это не говорит о том, что он эти данные не использует в своих бигдата и датамайнингах. К слову сказать, если ту настройку выключить, то всё-равно нет гарантии, что зыкрытые страницы не отправляются на сервера яндекса. В индекс-то они не попадут, да. Но вот данные о таких страницах яндекс может бережно складировать для дальнейшего анализа. Тут надо код метрики анализировать и пользовательское соглашение читать (чтобы быть уверенным либо нет), но кто это делает?

И вот в подтверждение моих слов — на modstore.pro метрике разрешено индексировать все страницы сайта. Но личный кабинет закрыт, все его страницы отдают 401 и поэтому этих страниц в индексе нет.
Кроме одной — страницы создания тикета в техподдержку modstore.pro/cabinet/tickets/ticket
Почему? Потому что она единственная из всех закрытых страниц отдаёт код 200 ОК. Поэтому и в индексе. Благо хоть в кеше лежит версия для неавторизованных пользователей, что вселяет надежду на то, что исходные коды html всё-таки не отправляются (хотя я бы не тешил себя иллюзиями).

Такая вот история.
Поэтому, +1 к источникам данных о страницах и их урлах для поисковиков.

Но есть и ещё один источник. Вы думаете гугл и яндекс пилят свои браузеры просто потому что могут? Ха!
Браузеры пилятся для абсолютно тех же целей — сбор максимально возможной информации о пользователях и сайтах. Вот только в браузерах никаких подобных настроек нет. Ну может быть есть что-то про отправку анонимной статистики, но я не проверял. Лиса — наше всё.

2. Если на сайте есть страницы, которые Яндекс исключил из поиска, наверное — он должен где-то их показывать? Не вижу

Конечно должен. И как раз в вебмастере и показывает. Но ты их не видишь, потому что на modx.pro неканонические урлы редиректят на канонические, к примеру modx.pro/topic редиректит на modx.pro/topic/
Поэтому у modx.pro дублей практически и нет.
Вась, но я давно уже понял — в контексте seo ты судишь обо всех сайтах на основе своих собственных показателей, что в корне неверно — выборка-то нерепрезентативна! xD
И если ты не сталкивался с подобными проблемами, это же не значит, что у других их нет, верно?)

Я не смог найти способ проверить наличие дублей, вообще.

Как-то ты плохо искал)

Все статьи в интернете больше походят на набор бабушкиных сплетен «зайдите в гугл, поищите так, а потом на яндекс, поищите эдак — видите, у вас разные результаты, значит у вас там где-то дубли!».

И как обычно передёргиваешь)
Смысл в том, что советы действенные, вот только ручками особо не анализируешься. Поэтому такие советы автоматизируются. Для гугла, например, нужно собрать всё страницы в основном индексе, потом все страницы из «соплей» (supplemented index).
Да, у гугла 2 индекса — основной, который и есть основная выдача и дополнительный, в котором содержатся проиндексированные, но по какой-то причине не попавшие в осной индекс, страницы. Например из-за того, что это дубликат)
А потом оба этих массива анализируются по нескольким параметрам и выявляются дубли.
Но это плохой метод, анализ следствия ткскзать, а не причины. Для полного анализа дублей используются XENU, PageWeight или онлайн сервисы.