Когда я первый раз столкнулся с WordPress, помогая знакомым, то обратил внимание, что нет общей информации для начинающих. Вообще, мало тех, кто делится своими выводами и впечатлениями о том, что важно знать вначале. Этот как в большом магазине, где уже как-то привыкли, что все обо всем вроде бы и так должны знать. Но на самом-то деле нет - знают не обо всем. И далеко не все. Есть те, кто первый раз. И им нужно хотя бы кратко рассказать про главное.

Так вот, - я не видел, чтобы кто-то обратил внимание на то, что делая первые шаги в WordPress, важно быть осторожным, например в выборе плагинов (потому что они оставляют следы даже после удаления, засоряют базу). Или на то, что миллион загрузок у какого-то плагина, еще не означает что он лучший. Или на то, что бывают случайные незаметные ошибки, которые могут приводить к большим отрицательным последствиям (о которых долгое время можешь даже не знать).

Здесь коротко, пару абзацев - только о самом главном. Потому что я как раз сейчас, опять "по касательной", столкнулся с WordPress для одного проекта. И, пока помню о важном, тезисно здесь это зафиксирую.

Далее...

Столкнулся с тем что нужен был самоподписанный сертификат. Такое бывает, например, тогда, когда кому-то httpS нужен для своих внутренних целей, например - только для админского доступа. Покупать ради этого сертификат просто нет смысла, но в то же время хочется быть всегда уверенным что это "правильный" сайт (и этот "служебный" httpS отображается в браузере без предупреждений). Странно, но хорошей инфы - "по пунктам" все сразу в одном месте не нашел.

Здесь будет описан такой вариант: корневой сертификат, который устанавливается через консоль в хранилище сертификатов Windows клиента, а для сайта (сервер Apache) - свой сертификат (и ключ), подписанный этим корневым.

Такая схема удобна тем, что установив на клиента(ов) один раз корневой сертификат можно потом для домена и субдоменов подключать новые сертификаты только на сервере, не затрагивая компьютеры клиентов каждый раз. Поскольку все сертификаты подписанные корневым сертификатом (раз установленным на клиенте), автоматически "признаются" браузером уже без предупреждений.

Далее...

Есть много советов как обезопасить WordPress. В числе прочих - изменить адрес формы логина и папку "wp-admin" админ панели. Но большинство предлагаемых решений мне не понравились. Я попробовал все что нашел и решил сделать все по-своему. Админ панель (wp-admin) обезопасил через редирект в .htaccess на протокол httpS (порт 443) недоступный снаружи без пароля. И форму логина тогда можно было уже не переименовывать.

Но есть в этом решении одна важная деталь. Адрес необходимый для работы Ajax содержит так же папку "wp-admin", и его надо оставить открытым, исключить из перенаправления. Для этого нужно в .htaccess добавить одно дополнительное правило.

Далее...

Где находятся сохраненные игры Герои 3?

Есть такая старая добрая игра Герои 3 (Heroes III). Древняя игрушка, в которую многие продолжают до сих пор играть, несмотря на ее предельную простоту. Наверное так же играют в шахматы например - еще более древнюю и простую вроде бы игру :).

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

Удивительнее всего то, что попытки найти информацию через поисковики меня ни к чему не привели. Но мне все же удалось найти самостоятельно этот скрытый список сохраненных игр.

Далее...

Этот скрипт показывает список активных и неактивных пользователей удаленного рабочего стола, зашедших на компьютер через удаленный доступ RDP.

Если пользователь вышел из из удаленного доступа не завершив терминальную сессию - он все равно будет присутствовать в списке.

Скрипт не показывает локального пользователя, - только тех кто зашел по RDP.

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

У этого скрипта есть одна особенность - когда пользователь завершает сессию (а не просто закрывает), то иногда проходит около минуты, прежде чем скрипт перестанет его показывать в своем списке.

Далее...

На первый взгляд, ротация бэкапов - задача не сложная.

Казалось бы, что может быть проще - сохранять строго определенное количество папок или архивов с бэкапом, именуя их с использованием даты.

На самом деле не все так просто. Первый вопрос, который возникает сразу - что произойдет если какие-то важные рабочие файлы какое-то продолжительное время не будут изменяться? Будет происходить "холостой" бэкап, а последующая ротация бэкапов через некоторое время приведет к тому, что все эти файлы в старых версиях бэкапов будут одинаковы.

Поэтому для разумного бэкапа лучше все-таки делать анализ резервируемых данных.

И одного простого скрипта, одинакового для всех, здесь может быть недостаточно.

Далее...

Для Windows есть много разных программ для "зеркалирования" - создания точной резервной копии папки.
Но эти программы удаляют и перезаписывают старые версии файлов в бэкапе. А мне нужно было во время синхронизации не удалять старые версии файлов, а сохранять (например в заданную третью папку).
Когда просматривал разные известные программы для бэкапа, обнаружил, что обычно в них идея "третьей папки" вообще отсутствует. Есть две - исходная (откуда) и целевая (куда - "зеркальная"), а так, чтобы результат сравнения этих двух папок (отличающиеся старые или уже удаленные файлы) сохранялся в третью папку - такого вообщем-то нет.
Или почти нет.

Далее...