I would like to add some additional features/functionality with already available WordPress plugin.
Is it possible to carry over my customization while updating the plugin?
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It only takes a minute to sign up.Sign up to join this community
The recommended way to get your enhancements into the plugin is: Send your fixes to the developer and ask her to merge them into the original. If your changes are rather personal customizations, this won’t happen.
If the plugin is written in a strict OOP style you can create a second plugin which extends just the classes from the original as you need it (sort of a child plugin). Unfortunately most plugin developers don’t see this need and don’t write their code accordingly. Be aware of the load order problem.
We could help better if you would describe which plugin you want to extend and what exactly you want to change.
Unfortunately it totally depends on the plugin (or more accurately, on the plugin author!) If the author was thinking pro-actively and created the plugin in such a way to make it extensible, then yes, you can create your OWN plugin that adds to the functionality in the existing plugin.
Do make note of what Toscho pointed out - that your plugin order matters (the link again is here).
The most common way to make a plugin extensible is to add hooks (action and filter hooks) that you can then leverage with your own plugin. If you have a good code editor (right now I'm rocking out on NetBeans) you should do a search through the plugin source files for:
apply_filters. If the plugin author has provided those hooks, this is a very convenient and easy way for you to over-ride defaults, or inject your own code.
If the plugin author is savvy, but is using the global namespace for the plugin functions, he/she may have wrapped the plugin's functions within
if ( function_exists() ) conditional statements. For this to work to your advantage, you have to make sure your plugin loads first (which may be a challenge). All you have to do is declare your function by the exact same name within the exact same namespace and then your function will replace the one used by the plugin.
If the plugin author is a good OOP coder, he/she may write the plugin code in a granular enough way that is open for extension (since, as the GOF would say, it is definitely closed for modification). Look for lots of granularity in the plugin class - that is to say methods that perform small, highly specific tasks - that can be overridden in your own class that extends the plugin's class. Of course, as Toscho mentions, the class needs to be architected in such a way that it can be overridden, and that its default implementation doesn't invoke itself completely.
Fork or Patch
If the plugin author is using gitHub, or has opened the source in some other way, you can either submit a patch to the author with your proposed modifications (your best bet is to modify the plugin to make it MORE flexible or powerful without removing or changing existing features or functionality), or you can just download the source, modify the plugin header to the extent that it will no longer be updated when the original author pushes an update out, and preferably submit your updated version to the author, or as its own entity directly to WordPress. Be aware that if you do submit the plugin to WP you will need to have a site for it and should be prepared to support it if others download it.
I know it's a very old question but I think I found the solution...
I've a plugin in which one of my client's developers have modified it to the limit of directories & sub directories, when updated the files get deleted and the plugin crashes. In order to make the original plugin independent of any core updates, I've moved the modified files and folders to a separate plugin in a directory named as
Using the code found at https://gist.github.com/wpsmith/af206df2cf6a38e4e2f0
I added the class defined by Tarvis Smith in
WPS_Extend_Plugin.php and included it in my plugin. Using the
WPS_Extend_Plugin class I've pointed the extended files/folders directory to the target folder
extension. There's no failure yet, but I not sure that is this the right way to extend a plugin or not!
// Require WPS_Extend_Plugin class require_once( 'classes/WPS_Extend_Plugin.php' ); // Extend Sitepress Multilingual CMS new WPS_Extend_Plugin( 'sitepress-multilingual-cms/sitepress.php', __FILE__, '3.9.0', 'CHERRY' ); // Extend AddThis new WPS_Extend_Plugin( 'extension', __DIR__, '0.1', 'CHERRY' );
I understand this question is really old but I felt this might help someone.
If you feel the changes would help the community, please submit them to the developer. However, if the changes are unique to your installation, you can continue reading the following.
I had this issue about carrying over changes to updated version of a theme.
We did a recursive diff from
modified_old_version and then applied the patch it created on the new version of the theme using the patch tool.
The patch tools create files with changes that could not be applied automatically. We had a few of those, and were easily able to identify and manually make those changes.
While making changes you have to make sure you don't change spacing for the entire file using editor features like auto-indent, etc. That is, make changes only where necessary. That would only make the process of carrying over the changes more time consuming later.