Sharing codebase between plugins

Discussion:

Nikola Nikolov

2014-06-04 21:27:07 UTC

What do you do when you want to avoid code duplication by sharing the same
code base between multiple plugins?

Here's the situation that I'm in:

I have a plugin that adds some custom post types and functionality. Another
plugin that uses similar functionality is going to be developed. Possibly
in the future more plugins that use those post types will also be created.

So the idea is to separate out a "core" plugin that will allow any of the
plugins to function both on their own and combined, without having to ship
the code with each one(well - probably we'll need at least an archive of
the core plugin).

Now my question is how to handle that dependency(note that my client would
prefer if the core plugin is not listed on the plugins page - not sure if
that's really possible).

Right now I've thought about the following solutions:
- Have each of the plugins contain a .zip archive with the core plugin.
Then perhaps use https://github.com/thomasgriffin/TGM-Plugin-Activation in
order to define the dependency in each plugin. I'm just not sure how it
would handle updates - so when the user updates a sub-plugin it should
update the core plugin if the sub-plugin is bundled with an updated version
- Copy the core plugin as a mu-plugin if it's not already there. Again not
sure how to handle updates. Also when should I copy the plugin files - what
if FTP credentials are required?

I think my main concern are updates.

For instance how to make sure that I'm using the correct core base? What if
the user updates one of the sub-plugins and that updates the core plugin,
but they don't update the rest of the sub-plugins? Ideally I should have
things compatible between versions, but what if I have to introduce a
change that is not compatible?

I also looked at the Plugin Dependencies plugin (
https://wordpress.org/plugins/plugin-dependencies/ ), but I don't really
want to add another plugin to the bundle.

Thanks,
Nikola

Guus (IFS)

2014-06-05 13:52:45 UTC

Permalink

I am using a library file with some useful stuff in multiple plugins and
just set a constant to check if the code is already included.

<?php // start of library file
if (!defined('_MY_LIBRARY_FILE_INCLUDED')) {
#define('_MY_LIBRARY_FILE_INCLUDED',true);
libraryFunction1() {
// code
}
libraryFunction2() {
// code
}
}
// end of library file
?>

-----Original Message-----
From: Nikola Nikolov
Sent: Thursday, June 05, 2014 5:27 AM
To: wp-***@lists.automattic.com
Subject: [wp-hackers] Sharing codebase between plugins

What do you do when you want to avoid code duplication by sharing the same
code base between multiple plugins?

Here's the situation that I'm in:

I have a plugin that adds some custom post types and functionality. Another
plugin that uses similar functionality is going to be developed. Possibly
in the future more plugins that use those post types will also be created.

So the idea is to separate out a "core" plugin that will allow any of the
plugins to function both on their own and combined, without having to ship
the code with each one(well - probably we'll need at least an archive of
the core plugin).

Now my question is how to handle that dependency(note that my client would
prefer if the core plugin is not listed on the plugins page - not sure if
that's really possible).

Right now I've thought about the following solutions:
- Have each of the plugins contain a .zip archive with the core plugin.
Then perhaps use https://github.com/thomasgriffin/TGM-Plugin-Activation in
order to define the dependency in each plugin. I'm just not sure how it
would handle updates - so when the user updates a sub-plugin it should
update the core plugin if the sub-plugin is bundled with an updated version
- Copy the core plugin as a mu-plugin if it's not already there. Again not
sure how to handle updates. Also when should I copy the plugin files - what
if FTP credentials are required?

I think my main concern are updates.

For instance how to make sure that I'm using the correct core base? What if
the user updates one of the sub-plugins and that updates the core plugin,
but they don't update the rest of the sub-plugins? Ideally I should have
things compatible between versions, but what if I have to introduce a
change that is not compatible?

I also looked at the Plugin Dependencies plugin (
https://wordpress.org/plugins/plugin-dependencies/ ), but I don't really
want to add another plugin to the bundle.

Thanks,
Nikola

Nikola Nikolov

2014-06-05 13:56:53 UTC

Permalink

I see,

I have a couple of concerns with such an approach though:

#1 Size - the core plugin is actually going to consist of multiple
directories, scripts, images, etc. so it's not really efficient to have it
included in each and every one of the extra plugins.
#2 Updates - using your approach is difficult to use a specific version of
the library. Say the user updates one of your plugins, but not the rest.
Then you might use the latest version of the library, or an old version of
the library(in which case, you might get fatal errors, due to undefined
functions, etc.)

Thanks for sharing though,
Nikola

Post by Guus (IFS)
I am using a library file with some useful stuff in multiple plugins and
just set a constant to check if the code is already included.
<?php // start of library file
if (!defined('_MY_LIBRARY_FILE_INCLUDED')) {
#define('_MY_LIBRARY_FILE_INCLUDED',true);
libraryFunction1() {
// code
}
libraryFunction2() {
// code
}
}
// end of library file
?>
-----Original Message----- From: Nikola Nikolov
Sent: Thursday, June 05, 2014 5:27 AM
Subject: [wp-hackers] Sharing codebase between plugins
What do you do when you want to avoid code duplication by sharing the same
code base between multiple plugins?
I have a plugin that adds some custom post types and functionality. Another
plugin that uses similar functionality is going to be developed. Possibly
in the future more plugins that use those post types will also be created.
So the idea is to separate out a "core" plugin that will allow any of the
plugins to function both on their own and combined, without having to ship
the code with each one(well - probably we'll need at least an archive of
the core plugin).
Now my question is how to handle that dependency(note that my client would
prefer if the core plugin is not listed on the plugins page - not sure if
that's really possible).
- Have each of the plugins contain a .zip archive with the core plugin.
Then perhaps use https://github.com/thomasgriffin/TGM-Plugin-Activation in
order to define the dependency in each plugin. I'm just not sure how it
would handle updates - so when the user updates a sub-plugin it should
update the core plugin if the sub-plugin is bundled with an updated version
- Copy the core plugin as a mu-plugin if it's not already there. Again not
sure how to handle updates. Also when should I copy the plugin files - what
if FTP credentials are required?
I think my main concern are updates.
For instance how to make sure that I'm using the correct core base? What if
the user updates one of the sub-plugins and that updates the core plugin,
but they don't update the rest of the sub-plugins? Ideally I should have
things compatible between versions, but what if I have to introduce a
change that is not compatible?
I also looked at the Plugin Dependencies plugin (
https://wordpress.org/plugins/plugin-dependencies/ ), but I don't really
want to add another plugin to the bundle.
Thanks,
Nikola
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers

Guus (IFS)

2014-06-05 14:18:47 UTC

Permalink

Thanks for your comments. I agree with you as I indeed experienced the
problems you describe with different versions, but over the years I have
developed e.g. a 'mini library' with some stuff that is very basic and
doesn't really change, so that's why I use that trick. So yes, you need to
know when, why and how to do this.

Related to performance I don't think Wordpress is that efficient in general,
although I don't know the core code. With just skipping the code in the
second file with the define or just including another file after the check
shouldn't take much processing time.

-----Original Message-----
From: Nikola Nikolov
Sent: Thursday, June 05, 2014 9:56 PM
To: wp-***@lists.automattic.com
Subject: Re: [wp-hackers] Sharing codebase between plugins

I see,

I have a couple of concerns with such an approach though:

#1 Size - the core plugin is actually going to consist of multiple
directories, scripts, images, etc. so it's not really efficient to have it
included in each and every one of the extra plugins.
#2 Updates - using your approach is difficult to use a specific version of
the library. Say the user updates one of your plugins, but not the rest.
Then you might use the latest version of the library, or an old version of
the library(in which case, you might get fatal errors, due to undefined
functions, etc.)

Thanks for sharing though,
Nikola

Nikola Nikolov

2014-06-05 15:46:20 UTC

Permalink

Right, having a more or less non-changing library is a good use case.
I meant more like the size of each individual plugin and the fact that it
will be increased by the full size of the core plugin. Again in my case I'm
talking about a full-size plugin that gets some of it's functionality
chopped away into separate smaller plugins.

I'll keep on thinking and post here if I find a good solution.
Nikola

Post by Guus (IFS)
Thanks for your comments. I agree with you as I indeed experienced the
problems you describe with different versions, but over the years I have
developed e.g. a 'mini library' with some stuff that is very basic and
doesn't really change, so that's why I use that trick. So yes, you need to
know when, why and how to do this.
Related to performance I don't think Wordpress is that efficient in
general, although I don't know the core code. With just skipping the code
in the second file with the define or just including another file after the
check shouldn't take much processing time.
-----Original Message----- From: Nikola Nikolov
Sent: Thursday, June 05, 2014 9:56 PM
Subject: Re: [wp-hackers] Sharing codebase between plugins
I see,
#1 Size - the core plugin is actually going to consist of multiple
directories, scripts, images, etc. so it's not really efficient to have it
included in each and every one of the extra plugins.
#2 Updates - using your approach is difficult to use a specific version of
the library. Say the user updates one of your plugins, but not the rest.
Then you might use the latest version of the library, or an old version of
the library(in which case, you might get fatal errors, due to undefined
functions, etc.)
Thanks for sharing though,
Nikola
com
I am using a library file with some useful stuff in multiple plugins and

Post by Guus (IFS)
just set a constant to check if the code is already included.
<?php // start of library file
if (!defined('_MY_LIBRARY_FILE_INCLUDED')) {
#define('_MY_LIBRARY_FILE_INCLUDED',true);
libraryFunction1() {
// code
}
libraryFunction2() {
// code
}
}
// end of library file
?>
-----Original Message----- From: Nikola Nikolov
Sent: Thursday, June 05, 2014 5:27 AM
Subject: [wp-hackers] Sharing codebase between plugins
What do you do when you want to avoid code duplication by sharing the same
code base between multiple plugins?
I have a plugin that adds some custom post types and functionality. Another
plugin that uses similar functionality is going to be developed. Possibly
in the future more plugins that use those post types will also be created.
So the idea is to separate out a "core" plugin that will allow any of the
plugins to function both on their own and combined, without having to ship
the code with each one(well - probably we'll need at least an archive of
the core plugin).
Now my question is how to handle that dependency(note that my client would
prefer if the core plugin is not listed on the plugins page - not sure if
that's really possible).
- Have each of the plugins contain a .zip archive with the core plugin.
Then perhaps use https://github.com/thomasgriffin/TGM-Plugin-Activation in
order to define the dependency in each plugin. I'm just not sure how it
would handle updates - so when the user updates a sub-plugin it should
update the core plugin if the sub-plugin is bundled with an updated version
- Copy the core plugin as a mu-plugin if it's not already there. Again not
sure how to handle updates. Also when should I copy the plugin files - what
if FTP credentials are required?
I think my main concern are updates.
For instance how to make sure that I'm using the correct core base? What if
the user updates one of the sub-plugins and that updates the core plugin,
but they don't update the rest of the sub-plugins? Ideally I should have
things compatible between versions, but what if I have to introduce a
change that is not compatible?
I also looked at the Plugin Dependencies plugin (
https://wordpress.org/plugins/plugin-dependencies/ ), but I don't really
want to add another plugin to the bundle.
Thanks,
Nikola
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________

wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers

Stephen Rider

2014-06-16 21:03:44 UTC

Permalink

Hi Nikola --

#1 -- I wouldn't worry too terribly about size. Is the plugin multiple megabytes of data?

#2 -- You might take a look at my own Strider Core. https://code.google.com/p/strider-core/
Feel free to borrow the "best version" mechanism for your own purposes, but if you do, PLEASE be sure to change all "strider_core" strings to something else -- Very Important.

Stephen Rider

Post by Nikola Nikolov
I see,
#1 Size - the core plugin is actually going to consist of multiple
directories, scripts, images, etc. so it's not really efficient to have it
included in each and every one of the extra plugins.
#2 Updates - using your approach is difficult to use a specific version of
the library. Say the user updates one of your plugins, but not the rest.
Then you might use the latest version of the library, or an old version of
the library(in which case, you might get fatal errors, due to undefined
functions, etc.)
Thanks for sharing though,
Nikola

_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers

Nikola Nikolov

2014-06-17 08:48:45 UTC

Permalink

Hi Stephen,

I think in the end I'll have core shipped with every plugin by using
svn:external in each project that uses the core in order to keep everything
synced. And then I guess I'll figure out a way to load the newest version
of core in order to provide the best conflict-free functionality(since I
should be keeping some backwards-compatibility, but plugins that require
the newer version might break).

Thanks everyone for their comments,
Nikola

Post by Stephen Rider
Hi Nikola --
#1 -- I wouldn't worry too terribly about size. Is the plugin multiple megabytes of data?
#2 -- You might take a look at my own Strider Core.
https://code.google.com/p/strider-core/
Feel free to borrow the "best version" mechanism for your own purposes,
but if you do, PLEASE be sure to change all "strider_core" strings to
something else -- Very Important.
Stephen Rider

Post by Nikola Nikolov
I see,
#1 Size - the core plugin is actually going to consist of multiple
directories, scripts, images, etc. so it's not really efficient to have

Post by Nikola Nikolov
included in each and every one of the extra plugins.
#2 Updates - using your approach is difficult to use a specific version

Post by Nikola Nikolov
the library. Say the user updates one of your plugins, but not the rest.
Then you might use the latest version of the library, or an old version

Post by Nikola Nikolov
the library(in which case, you might get fatal errors, due to undefined
functions, etc.)
Thanks for sharing though,
Nikola
On Thu, Jun 5, 2014 at 4:52 PM, Guus (IFS) <

same