Что небезопасно:

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

Реальный (и единственный) безопасный способ

Для мониторинга разработчика представляется следующее:

• Используйте репозиторий git в BitBucket и добавьте его туда.
• Создайте автоматическое развертывание (с помощью Дженкинса) из Bitbucket на сервер (поэтому разработчик не будет иметь доступ к серверу) [ Я найду ссылку, где этот процесс подробно описан].
• Предоставьте роль РЕДАКТОРА разработчику, чтобы он не мог попасть в файлы сервера (уровни администратора могут попасть туда, используя установку плагинов или т. Д. Вместо этого вы будете делать важные вещи (устанавливать плагины и т. Д.), А он сможет сделать все остальное.
• Установите плагины для мониторинга только действий (аудит, ревизия, безопасность и т. Д.), И теперь их журналы не могут быть изменены разработчиком (потому что у него нет доступа напрямую к файлам сервера и БД, и постарается избежать тонкостей с кодированием, потому что его изменения в кодировании будут показаны в истории GIT).

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

Для управления версиями вы можете использовать Github. Он покажет, какие изменения были внесены в файлы. Это замедлит работу вашего разработчика, но они, вероятно, уже должны быть знакомы с этим.

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

VersionPress действительно соответствует вашим требованиям - https://versionpress.com/

Любые изменения в администраторе создадут файл VP, который вы можете найти здесь - wp-content/vpdb

Если вы также знакомы с CLI, то вы можете легко развернуть эти файлы VP из одной среды в другую, например, из промежуточной в производственную и наоборот

Вообще говоря, это звучит так, как будто вы хотите контролировать этапы развертывания, поэтому продвигаете изменения от разработки к этапу до производства; или каков бы ни был ваш точный процесс. Таким образом, вы предоставляете разработчику доступ только к среде разработки, например, но там вы хотите иметь представление обо всех внесенных изменениях. На мой взгляд, нет необходимости использовать плагины для контроля версий.

Использование git diff должно быть достаточно, чтобы отслеживать изменения файлов, это делает

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

Показать различия между коммитами:

git diff old new 
// file names only
git diff old new --name-only

Для получения дополнительных опций, пожалуйста, ознакомьтесь с документацией.

Я думаю, что это довольно очевидно, и в значительной степени это всего лишь вопрос мониторинга изменений.

Что касается базы данных, вы можете использовать mysqldump чтобы поместить вашу базу данных в файл

Клиентская утилита mysqldump выполняет логическое резервное копирование, создавая набор инструкций SQL, которые могут быть выполнены для воспроизведения исходных определений объектов базы данных и табличных данных. Он сбрасывает одну или несколько баз данных MySQL для резервного копирования или переноса на другой SQL-сервер.

mysqldump --skip-extended-insert --skip-comments -u username  -p dbname > dump.sql

Команда может быть указана для исключения определенных таблиц, например, вам не нужна таблица wp_posts в разработке, или вы включаете только конкретные таблицы, например, есть ли изменения в wp_users – короче говоря, можно достичь большей точности.

И затем вы используете diff к

Сравните ФАЙЛЫ строка за строкой.

diff old.sql new.sql

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

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

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

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

Кроме того, я хотел описать и проиллюстрировать процесс, не зависящий от плагинов.