Cómo editar un plugin de WordPress sin romper su proceso de actualización

Probablemente no.

La forma recomendada de incluir tus mejoras en el plugin es: Envía tus correcciones al desarrollador y pídele que las incorpore al código original. Si tus cambios son más bien personalizaciones personales, esto no sucederá.

Si el plugin está escrito en un estilo estrictamente OOP (Programación Orientada a Objetos), puedes crear un segundo plugin que extienda solo las clases del original según tus necesidades (una especie de plugin hijo). Desafortunadamente, la mayoría de los desarrolladores de plugins no prevén esta necesidad y no escriben su código en consecuencia. Ten en cuenta el problema de orden de carga.

Podríamos ayudar mejor si describieras qué plugin deseas extender y qué es exactamente lo que quieres cambiar.

Desafortunadamente, todo depende del plugin (o más precisamente, del autor del plugin). Si el autor pensó de manera proactiva y creó el plugin de forma que sea extensible, entonces sí, puedes crear tu PROPIO plugin que añada funcionalidad al plugin existente.

Toma nota de lo que señaló Toscho: que el orden de tus plugins importa (el enlace nuevamente está aquí).

Hooks (Ganchos)

La forma más común de hacer un plugin extensible es añadir hooks (action hooks y filter hooks) que luego puedes aprovechar con tu propio plugin. Si tienes un buen editor de código (actualmente estoy usando NetBeans), deberías buscar en los archivos fuente del plugin: do_action y apply_filters. Si el autor del plugin ha proporcionado esos hooks, esta es una forma muy conveniente y fácil de anular valores predeterminados o inyectar tu propio código.

Funciones Pluggables

Si el autor del plugin es astuto pero está usando el espacio de nombres global para las funciones del plugin, puede haber envuelto las funciones del plugin dentro de condicionales if ( function_exists() ). Para que esto funcione a tu favor, debes asegurarte de que tu plugin se cargue primero (lo cual puede ser un desafío). Todo lo que tienes que hacer es declarar tu función con exactamente el mismo nombre dentro del mismo espacio de nombres y entonces tu función reemplazará la usada por el plugin.

Extensión

Si el autor del plugin es un buen programador OOP, puede escribir el código del plugin de manera lo suficientemente granular que esté abierto para extensión (ya que, como diría el GOF, definitivamente está cerrado para modificación). Busca mucha granularidad en la clase del plugin - es decir, métodos que realizan tareas pequeñas y altamente específicas - que puedan ser sobrescritos en tu propia clase que extienda la clase del plugin. Por supuesto, como menciona Toscho, la clase debe estar diseñada de tal manera que pueda ser sobrescrita y que su implementación predeterminada no se invoque completamente a sí misma.

Bifurcar o Parchear

Si el autor del plugin está usando gitHub, o ha abierto el código fuente de alguna otra manera, puedes enviar un parche al autor con tus modificaciones propuestas (tu mejor opción es modificar el plugin para hacerlo MÁS flexible o potente sin eliminar o cambiar características o funcionalidades existentes), o simplemente descargar el código fuente, modificar el encabezado del plugin hasta el punto que ya no se actualizará cuando el autor original lance una actualización, y preferiblemente enviar tu versión actualizada al autor o como su propia entidad directamente a WordPress. Ten en cuenta que si envías el plugin a WP, necesitarás tener un sitio para él y deberás estar preparado para dar soporte si otros lo descargan.

Sé que es una pregunta muy antigua pero creo que encontré la solución...

Tengo un plugin en el que uno de los desarrolladores de mi cliente lo ha modificado hasta el límite de directorios y subdirectorios, cuando se actualiza los archivos se eliminan y el plugin falla. Para hacer que el plugin original sea independiente de cualquier actualización del núcleo, he movido los archivos y carpetas modificados a un plugin separado en un directorio llamado extension.

Usando el código encontrado en https://gist.github.com/wpsmith/af206df2cf6a38e4e2f0

Agregué la clase definida por Travis Smith en WPS_Extend_Plugin.php y la incluí en mi plugin. Usando la clase WPS_Extend_Plugin he apuntado el directorio de archivos/carpetas extendidos a la carpeta objetivo extension. Hasta ahora no hay fallos, ¡pero no estoy seguro de que esta sea la forma correcta de extender un plugin o no!

// Requiere la clase WPS_Extend_Plugin
require_once( 'classes/WPS_Extend_Plugin.php' );

// Extiende Sitepress Multilingual CMS
new WPS_Extend_Plugin( 'sitepress-multilingual-cms/sitepress.php', __FILE__, '3.9.0', 'CHERRY' );
// Extiende AddThis
new WPS_Extend_Plugin( 'extension', __DIR__, '0.1', 'CHERRY' );

Entiendo que esta pregunta es muy antigua, pero sentí que esto podría ayudar a alguien.

Si consideras que los cambios beneficiarían a la comunidad, por favor envíalos al desarrollador. Sin embargo, si los cambios son específicos para tu instalación, puedes continuar leyendo lo siguiente.

Yo tuve este problema sobre cómo transferir cambios a una versión actualizada de un tema. Hicimos un diff recursivo desde old_version hasta modified_old_version y luego aplicamos el parche que generó en la nueva versión del tema usando la herramienta patch.

Las herramientas de parche crean archivos con cambios que no pudieron aplicarse automáticamente. Tuvimos algunos de esos y pudimos identificarlos y hacer esos cambios manualmente con facilidad.

Al hacer cambios, debes asegurarte de no modificar el espaciado de todo el archivo usando funciones del editor como autoindentado, etc. Es decir, haz cambios solo donde sea necesario. Eso solo haría que el proceso de transferir los cambios sea más tardado más adelante.