Our WordPress setup is based off Bedrock, which uses Composer to manage php dependencies, including plugins. I know this was talked about before:
http://support.advancedcustomfields.com/forums/topic/composer-support/
The upshot of this is that we can lock down plugins to a specific version. This is great for us and means we can always be certain the version in git will work (even if we don’t touch it for 9 months).
The issue is that we are unable to bring in ACF pro via composer because it’s not in the WordPress Plugin directory. There is a work around / hack, but it uses the connect.advancedcustomfields.com
url.
https://gist.github.com/fThues/705da4c6574a4441b488
This hack as 3 problems:
Are there any plans or other work arounds for this?
Some sort of versioned & documented API that lets you download a version would be an improvement. Ideally, ACF 5 would replace ACF 4 in the plugins directory and we can use composer to install it.
Hi @adamtomat
This is quite an important feature and the developer is well aware of it.
Hopefully it should be possible soon 🙂
For anyone else landing here, looking to install ACF Pro via composer – check out acf-pro-installer.
A good stop-gap until it gets supported out the box.
@adamtomat Thank you for promoting acf-pro-installer
.
If anyone has questions about it, feel free to ask them here. I will try to help you as good as I can 🙂
I had the license key added in a different way (not using dotENV).
But I still don’t know what to do exactly when there’s a new version: which number should I change? the one specified in the version, one in the URL, or the one in the require?
It depends how you set everything up. I assume you have the following repository added:
{
"type": "package",
"package": {
"name": "advanced-custom-fields/advanced-custom-fields-pro",
"version": "5.4.1",
"type": "wordpress-plugin",
"dist": {
"type": "zip",
"url": "https://connect.advancedcustomfields.com/index.php?p=pro&a=download"
},
"require": {
"philippbaschke/acf-pro-installer": "^1.0",
"composer/installers": "^1.0"
}
}
}
Please notice that package.dist.url
does not contain the version number (acf-pro-installer
will add it automatically).
You definitely need to update the package.version
field to the new desired version.
If you require an exact version like this:
"require": {
"advanced-custom-fields/advanced-custom-fields-pro": "5.4.1"
}
then you need to update the version there as well.
If you just require any version like this:
"require": {
"advanced-custom-fields/advanced-custom-fields-pro": "*"
}
you can just leave it like this.
ACF PRO should be updated when you run composer update
now.
Please let me know if you have any problems when you use this procedure. Please provide the content of your composer.json
file to make debugging easier. 🙂
Hi,
This may be a dumb question but what about installing the basic version (not PRO) with Composer?
Thanks
Not dumb at all! Since it’s in the WP plugin repo you can grab it from WordPress Packagist here. Or drop this into your composer.json file:
"wpackagist-plugin/advanced-custom-fields": "5.6.3"
This case might help to implement composer for advanced custom fields pro:
https://deliciousbrains.com/composer-premium-wordpress-plugins/
Dear ACF Support, any action on this? Would love to see something à la Delicious Brains.
Note that some current problems may have arisen. Seemingly caused by the most recent Composer update: Github issue
@philippbaschke the installer works great when I install as "type": "wordpress-plugin"
, but the admin menu doesn’t show up when I install as "type": "library"
. It seems like it’s not autoloading and/or enabling.
I got a reply from Elliot on this topic 🙂
Delicious brains did a fantastic job on integrating a premium plugin into composer. I remember when this blog post was first published and I was very impressed with their solution.
Unfortunately, we don’t have a similar setup just yet, but this is definitely something I would like to address next year.
Let’s keep our fingers crossed.
In case someone lands here, couple updates as of early 2019:
@bigskillet if you’re installing it as a “library”, it will be installed in vendor
dir. The ACF plugin itself doesn’t utilize namespaces and autoloading so it’ll just sit there, doing nothing.
It won’t be activated as a WordPress plugin, you need to load the library yourself and hook it into WordPress’ lifecycle + configure some internal ACF settings. You can do it in a form of plugin / mu-plugin or in functions.php. I prefer using muplugins_loaded
hook instead of plugins_loaded
to make sure ACF Pro is loaded before any plugins that rely on it:
define( 'ACF_PATH', 'vendor/advanced-custom-fields/advanced-custom-fields-pro/' );
define( 'ACF_ABSPATH', '/absolute/path/to/project/' . ACF_PATH );
/**
* Load ACF plugin as library managed by Composer.
*/
function load_acf_library()
{
require_once ACF_ABSPATH . '/acf.php';
}
add_action( 'muplugins_loaded', 'load_acf_library' );
/**
* Configure ACF Settings in bulk.
*/
function acf_settings()
{
// Absolute path to ACF plugin folder including trailing slash
acf_update_setting( 'path', ACF_ABSPATH );
// URL to ACF plugin folder including trailing slash
acf_update_setting( 'dir', home_url( '/' ) . ACF_PATH );
}
add_filter( 'acf/init', 'acf_settings' );
Thank you for your response, @ihorvorotnov.
Since I last posted, I’ve decided to not load plugins via Composer, since from what I understand, plugins are not updatable through the admin if they’re installed via Composer.
@bigskillet Well, yes and no. They are updatable, unless you’ve disabled plugin updates via wp-config constant or have incorrect user:group settings on the server. However, if you have an automated deployment routine that runs composer install
– those admin updates will be overwritten.
@ihorvorotnov Well, for some reason this ain’t working to me as you described.
Like muplugins_loaded hook is never fired at all, I place a wrong path inside and no error.
I also tried to ‘update_option(‘dummy’, 123)’, but that ain’t added to database either.
It’s on my localhost and I have a WPMS installed, but can’t see a reason why this wouldn’t work.
Any ideas?
@bobz I’m assuming WPMS means Multisite? Not a fan personally and not using it for years, but AFAIK it should work the same way, added once on a network level, activated for all sites. If muplugins_loaded
doesn’t work for you for some reason, try plugins_loaded
instead.
However, muplugins_loaded
should run. See here: https://core.trac.wordpress.org/browser/tags/5.0.3/src/wp-settings.php#L295
Does you mu-plugin have a proper plugin header comment? If add_option()
doesn’t work as well, I suspect your code isn’t running at all.
Right @ihorvorotnov I think problem is I’m including ACF in theme folder and trying to load it from there, but that’s too early. So the only proper way to load it from theme folder is if I install it as a ‘wordpress-plugin’.
This is a little elaborate, but I’ve setup my own WP website as a composer repository using SatisPress:
https://github.com/cedaro/satispress
All my premium plugins – and I use a few – are installed and maintained there. Then I pull them down from there as standard composer packages to my own/client sites.
I don’t have any security on that repository, but it’s an obscure URL and that’s good enough for me.
It has proven an effective and easy way to do it.
Who knew a WordPress site could double as a composer repo!?
In the default SatisPress approach, a plugin that would normally be referenced in composer as:
composer install wpackagist-plugin/advanced-custom-fields
…is instead referenced as:
composer install satispress/advanced-custom-fields-pro
The SatisPress plugin lets you change that repo name if you so desire.
All in all, reliable and great, because it’s one approach for all my premium plugins.
FINALLY… one other benefit. I can create my own custom plugins for this and that, and also have them automatically available as composer packages, just by installing them on that WP site. Nothing more to do. No need to put them on a public composer repo.
So I like it 🙂
So the code above provided by @ihorvorotnov to hook on muplugins
did not work for me but ffraenz/private-composer-installer that he suggested did to install the plugin via composer.
In order to include the plugin in my theme, I first changed the package type to library
, instead of wordpress-plugin
, that way it installs in the vendor folder since I had to use composer within my theme (see below).
Then I used this official resource and just replaced the paths with those that composer creates i.e., /vendor/advanced-custom-fields/advanced-custom-fields-pro/
.
The use-case is that I scaffold many projects the same way and it’s always been a PITA to have a scaffold that requires I install both Timber and ACF Pro to get up and running; I mean what’s the point of a scaffold if it doesn’t scaffold everything that’s needed.
Since Timber is either installed as a WordPress plugin from WordPress (what I want to avoid) or via composer from within the theme and not as a "type": "wordpress-plugin"
, which means that it won’t install into wp-content/plugins/
annoyingly enough, either Yeoman would have to run two composer install
s, one in the root directory of WordPress and the other from within the theme, or I had to figure out how to combine them. The easiest way is to include ACF Pro in the theme, plus I like that it is locked down since all my work is premium custom-tailored theme development.
The topic ‘Installing ACF5 via Composer’ is closed to new replies.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Privacy Policy. If you continue to use this site, you consent to our use of cookies.