Как редактировать плагин WordPress без нарушения процесса обновления

Вероятно, нет.

Рекомендуемый способ внедрить ваши улучшения в плагин: отправьте исправления разработчику и попросите его объединить их с оригиналом. Если ваши изменения скорее представляют собой персональные настройки, этого не произойдет.

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

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

К сожалению, это полностью зависит от плагина (или, точнее, от автора плагина!). Если автор подходил к разработке проактивно и создал плагин таким образом, чтобы его можно было расширять, тогда да — вы можете создать СВОЙ плагин, который добавит функциональность к существующему.

Обратите внимание на то, что подчеркнул Toscho — порядок загрузки плагинов имеет значение (ссылка снова здесь).

Хуки

Самый распространенный способ сделать плагин расширяемым — это добавить хуки (action и filter хуки), которые вы затем сможете использовать в своем плагине. Если у вас есть хороший редактор кода (я сейчас работаю в NetBeans), выполните поиск по исходным файлам плагина на наличие: do_action и apply_filters. Если автор плагина предусмотрел эти хуки, это очень удобный и простой способ переопределить настройки по умолчанию или добавить свой код.

Заменяемые функции

Если автор плагина опытный, но использует глобальное пространство имен для функций плагина, он мог обернуть функции плагина в условные операторы if ( function_exists() ). Чтобы это сработало в вашу пользу, ваш плагин должен загружаться первым (что может быть непросто). Вам нужно лишь объявить функцию с точно таким же именем в том же пространстве имен, и тогда ваша функция заменит функцию из плагина.

Наследование

Если автор плагина хорошо разбирается в ООП, он мог написать код плагина достаточно модульно, чтобы он был открыт для расширения (поскольку, как сказали бы GOF, он определенно закрыт для модификации). Ищите в классе плагина модульность — то есть методы, выполняющие небольшие, конкретные задачи, — которые можно переопределить в вашем собственном классе, расширяющем класс плагина. Конечно, как упоминает Toscho, класс должен быть спроектирован так, чтобы его можно было переопределить, и его реализация по умолчанию не должна полностью замыкаться на себе.

Форк или патч

Если автор плагина использует gitHub или открыл исходный код другим способом, вы можете либо отправить автору патч с вашими изменениями (лучший вариант — модифицировать плагин, чтобы сделать его БОЛЕЕ гибким или мощным, без удаления или изменения существующих функций), либо просто скачать исходный код, изменить заголовок плагина так, чтобы он больше не обновлялся при выходе обновлений от автора, и желательно отправить вашу версию автору или опубликовать её как отдельный плагин непосредственно в WordPress. Учтите, что если вы отправите плагин в WP, вам нужно будет создать для него сайт и быть готовым поддерживать его, если другие пользователи его скачают.

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

У меня есть плагин, в котором один из разработчиков моего клиента изменил его до предела директорий и поддиректорий. При обновлении файлы удаляются, и плагин перестает работать. Чтобы сделать оригинальный плагин независимым от любых обновлений ядра, я переместил измененные файлы и папки в отдельный плагин в директории с названием extension.

Используя код, найденный по ссылке https://gist.github.com/wpsmith/af206df2cf6a38e4e2f0

Я добавил класс, определенный Трэвисом Смитом в файл WPS_Extend_Plugin.php, и подключил его в своем плагине. С помощью класса WPS_Extend_Plugin я указал директорию расширенных файлов/папок на целевую папку extension. Пока что сбоев не было, но я не уверен, правильный ли это способ расширения плагина!

// Подключаем класс WPS_Extend_Plugin
require_once( 'classes/WPS_Extend_Plugin.php' );

// Расширяем Sitepress Multilingual CMS
new WPS_Extend_Plugin( 'sitepress-multilingual-cms/sitepress.php', __FILE__, '3.9.0', 'CHERRY' );
// Расширяем AddThis
new WPS_Extend_Plugin( 'extension', __DIR__, '0.1', 'CHERRY' );

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

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

У меня была аналогичная проблема с переносом изменений на обновлённую версию темы. Мы выполнили рекурсивный diff между old_version и modified_old_version, а затем применили созданный патч к новой версии темы с помощью инструмента patch.

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

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