Support Forum
Hello,
I need to bundle MetaBox.io and some of its premium extensions in my custom plug-in that relies on MetaBox to manage custom fields.
What is the best way to accomplish this so that this is completely transparent to the admin? I don't want the admin to have to install other plug-ins and I don't want them to need to update the plug-ins directly.
I tried using composer but it looks like the composer package only includes the MetaBox free core, how do I include all the premium add-ons through composer?
I also tried putting all MetaBox plug-ins into the mu-plugins directory but it didn't work.
Any pointer is appreciated.
Thanks,
Mauro
Hi Mauro,
To make it completely transparent, Composer is the best solution. All premium extensions have supported Composer. Please see this docs for how to use it:
Thanks for the pointer! I tried it and my composer.json file is attached.
I get the following errors:
Problem 1
- The requested package meta-box/mb-relationships could not be found in any version, there may be a typo in the package name.
Problem 2
- The requested package meta-box/mb-rest-api could not be found in any version, there may be a typo in the package name.
-- composer.json --
{
"repositories": [{
"type": "composer",
"url": "https://packages.metabox.io/[my api key]"
}],
"require": {
"meta-box/meta-box-group": "dev-master",
"meta-box/meta-box-columns": "dev-master",
"meta-box/mb-custom-table": "dev-master",
"meta-box/mb-relationships": "dev-master",
"meta-box/mb-rest-api": "dev-master",
"meta-box/mb-revision": "dev-master",
"meta-box/mb-term-meta": "dev-master",
"meta-box/meta-box-geolocation": "dev-master",
"meta-box/meta-box-tabs": "dev-master"
}
}
This seems to be the biggest negative about Meta Box and a frequent issue for a lot of developers... Distributing Meta Box with our projects.
For me, it's not about sticking something in the repository or even selling a premium plugin, it's just about having to go through 15+ steps every time I build a new web site in order to get everything installed so that my own plugin will work. And Composer (if it works) is great, but Meta Box really needs to be rebuilt so that it can be distributed much more easily.
Maybe that's a separate premium product, Meta Box as a library instead of a plugin. I'd pay ANOTHER couple hundred dollars for that.
At the very least it's gotta be made easier to install the core plugin and all of the premium addons. If I put my license key in Meta Box AIO, it should access my account and let me install/activate the premium addons as well as the free ones.
Hey guys,
To use Composer with free plugins on wordpress.org (where MB Rest API & MB Relationships are hosted), please use https://wpackagist.org/. It allows you to bundle any plugins for Composer.
Updated: I've just written a guide on doing that. See it here:
https://metabox.io/how-to-use-composer-to-install-meta-box-extensions-from-wordpress-org/
It has a video tutorial in case you prefer watching!
@Dave: Thanks for your suggestion. That's what we talked about on Facebook :). I really appreciate that. We talked about making a customizer, where users can select what they want and it will generate a package for that. Yes, I guess it's possible and it's on my plan. What you say about the AIO is true and let me try if I can bundle free plugins inside that.
Thanks for this!
I'm still running into a few issues.
I added all components I need and I've run composer install. The result differs from the composer install of metabox as documented on this site elsewhere since that one installed meta-box within the vendor/ directory.
This method instead created a wp-content/plugins/ directory into my target directory, and now the autoload.php returns an error because it can't find the plugins.
---- This is my composer.json ----
{
"repositories": [
{
"type": "composer",
"url": "https://packages.metabox.io/XXX"
},
{
"type": "composer",
"url": "https://wpackagist.org"
}
],
"require": {
"meta-box/meta-box-group": "dev-master",
"meta-box/meta-box-columns": "dev-master",
"meta-box/mb-custom-table": "dev-master",
"meta-box/mb-revision": "dev-master",
"meta-box/mb-term-meta": "dev-master",
"meta-box/meta-box-geolocation": "dev-master",
"meta-box/meta-box-tabs": "dev-master",
"wpackagist-plugin/meta-box": "dev-trunk",
"wpackagist-plugin/mb-rest-api": "dev-trunk",
"wpackagist-plugin/mb-relationships": "dev-trunk"
},
"extra": {
"installer-paths": {
"meta-box/meta-box/": ["my-foundation/meta-box"],
"meta-box/mb-rest-api/": ["my-foundation/mb-rest-api"],
"meta-box/mb-relationsihps/": ["my-foundation/mb-relationships"]
}
},
"autoload": {
"files": [
"meta-box/meta-box/meta-box.php",
"meta-box/mb-rest-api/mb-rest-api.php",
"meta-box/mb-rest-api/mb-rest-api.php"
]
}
}
---- This is composer's output ----
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 11 installs, 0 updates, 0 removals
- Installing composer/installers (v1.5.0): Downloading (100%)
- Installing meta-box/meta-box-group (master): Downloading (100%)
- Installing meta-box/meta-box-columns (master): Downloading (100%)
- Installing meta-box/mb-custom-table (master): Downloading (100%)
- Installing meta-box/mb-revision (master): Downloading (100%)
- Installing meta-box/mb-term-meta (master): Downloading (100%)
- Installing meta-box/meta-box-geolocation (master): Downloading (100%)
- Installing meta-box/meta-box-tabs (master): Downloading (100%)
- Installing wpackagist-plugin/meta-box (dev-trunk): Checking out trunk
- Installing wpackagist-plugin/mb-rest-api (dev-trunk): Checking out trunk
- Installing wpackagist-plugin/mb-relationships (dev-trunk): Checking out trunk
Writing lock file
Generating autoload files
I added require_once('vendor/autoload.php'); to my core plug-in file and now I get this error:
Fatal error: require(): Failed opening required '/Users/mauro/GitHub/my_wordpress/wp-content/plugins/my-foundation/vendor/composer/../../meta-box/meta-box/meta-box.php' (include_path='.:/Applications/MAMP/bin/php/php7.2.1/lib/php') in /Users/mauro/GitHub/mundana_wordpress/wp-content/plugins/my-foundation/vendor/composer/autoload_real.php on line 66
In the short term, it would be ideal if you circulated a couple different composer.json files with all meta-box components already set up.
One version would just install everything in wp-content/plugins, the other one should instead go get the plug-ins and install them in a custom path, as a part of our own custom plug-in (or theme). And ideally it should "just work".
As a long term solution, I think MetaBox AIO is a step in the right direction -- but I couldn't make it work.
IMHO it should include everything from MetaBox.io (not just the premium extensions), have a settings panel (for users) and a config file (for developers) to decide what components to activate, and a flag to show/hide the settings UI panel -- and of course one would need the API Key to make the premium components work.
Then you could have just that one as a composer package.
Just my 2 cents 🙂
Mauro, I really appreciate your feedback!
I've just created a "full" composer.json
file, so you can just grab it and remove what you don't need:
https://github.com/wpmetabox/library/blob/master/composer/composer.json
I'm trying to do what you say for the settings panel. I have an idea of building that based on Composer. Another option is improving the Meta Box AIO to support all free plugins. Either way, there's some work to do 🙂
Awesome thanks! I'll play with this and let you know how it goes.
Hi Anh,
Please note a comma is missing on line 6 and there's an extra comma on line 10.
Line 39 has an extra trailing "s" on the plug-in name (meta-box/meta-box-include-exclude).
Once I fixed those typos, I was able to checkout the whole thing through composer. Then I added vendor/autoload.php to my custom plug-in and I get another issue: it will try to instantiate some classes twice -- one time from the standard wordpress plug-in and another time from my custom plug-in.
CMB2 does a smart thing in this: since it's thought to be bundled with themes and plug-ins, it will only load the most recent version of itself. I think you should consider implementing a similar check on each plug-in initialiser.
I removed the existing plug-ins, now I get this error:
Fatal error: require(): Failed opening required '/Users/mauro/GitHub/mundana_wordpress/wp-content/plugins/mundana-foundation/vendor/composer/../meta-box/mb-relationships/mb-relationships.php' (include_path='.:/Applications/MAMP/bin/php/php7.2.1/lib/php') in /Users/mauro/GitHub/mundana_wordpress/wp-content/plugins/mundana-foundation/vendor/composer/autoload_real.php on line 66
How do I fix this?
Looks like all autoload specified at the end of the file will fail. I tried removing one and the next one fails.
Hi again, please note there is no link to go to Page 2 of this topic on this page.
So, I figured out there are more typos and issues with the provided composer.json file:
Line 46: "vendor/meta-box/mb-relationsihps/": ["wpackagist-plugin/mb-relationships"],
Relationships is misspelled, that causes the autoload error below because it places the plug-in in a misspelled directory.
In the autoload section, the file names are wrong. It appears that the main plug-in file for some of the plug-ins are named mb-[plugin-name].php where the plug-in directory is meta-box-[plugin-name] and MB Text Limiter's main plugin file instead is only named text-limiter.php -- that is confusing. May I suggest in the future to standardise all the naming of both directories and plug-in init files to one naming convention -- be it mb-[plugin name] or meta-box-[plugin name] ?
Once those issues were fixed, WordPress will finally load and it looks like MetaBox functionality is available.
I see you included the updater plug-in through composer. But if we go this route and include everything through composer, shouldn't we also update plug-ins through it?
If I update through MetaBox Updater instead, will it recognise the correct install path for the plug-ins installed through composer?
Another note: many plug-ins have the .svn directory inside, is this the intended behaviour? Shouldn't all version control information be removed during the install of the components?
Hi Mauro,
Thanks a lot for your bugs. I've just fixed those typos in the composer.json
file, and remove the updater, cause it does nothing. The update is controlled by Composer in this case.
May I suggest in the future to standardise all the naming of both directories and plug-in init files to one naming convention — be it mb-[plugin name] or meta-box-[plugin name] ?
Yes, it should be mb-[plugin name]
. I'll remember that.
Another note: many plug-ins have the .svn directory inside, is this the intended behaviour? Shouldn’t all version control information be removed during the install of the components?
It's the default behaviour of the WPackagist. I found a way to fix this. Please check it out.