Propose an updated composer.json for PRO version

[mickaelperrin]

Hi,

I am currently using the project https://github.com/PhilippBaschke/acf-pro-installer to get ACF PRO installed through composer.

While it works great, I need to manually set the version of each ACF version to get the update installed.

That would be great if you could maintain a repository with a simple composer.json file that could be used to enable updates through composer.

Something like https://github.com/johnpbloch/wordpress but with the package format used in https://github.com/PhilippBaschke/acf-pro-installer.

Even if I am a PRO user, a composer.json in this repository should help installation / upgrade through composer also for free version.

What to do you think about that?

Thanks,

[elliotcondon]

Hi @mickaelperrin

Thanks for the topic.

I'm happy to admit that I don't know much about composer, and understand that a lot of developers use it in their WP workflow.

Can you better explain the issue about 'set the version of each ACF version'?

• I don't understand this.

Can you also tell me more about the https://github.com/PhilippBaschke/acf-pro-installer repo?

• is this a good solution?
• what are the current limitations with this solution?

[mickaelperrin]

Hey @elliotcondon,

Thanks for opening a discussion about this request.

Composer helps a lot development of wordpress plugin by managing dependencies and autoloading, but it is also used a lot to deploy whole wordpress project.

In this case, we install everything (wordpress core, plugins and themes) through the help of a single composer.json file.

In this case, automatic updates are generally disabled in wordpress and only managed through composer.

Normally a single call to composer update should be sufficient to grab and install all new versions of wordpress core and plugins.

The problem with acf-pro-installer is that:

• we have to know that a new acf pro version is released,
• we have to know which version exactly is released,
• we need to edit the composer.json file for each project on which we use acf pro and replace the acf-pro version to be installed,
• and only then we can run the composer update command.

In fact acf-pro-installer is mainly used to hide the acf pro key and prevent it to be displayed / comitted in composer.json / composer.lock files.

I think we could find a simple way to get auto-updates by simply providing a github repository with a single composer.json file properly committed in branches / tags. That would be a great addition for pro users as the auto-upgrade of the free version is already provided by the wpackagist repository.

JohnBlock did a similar approach to manage auto-updates of wordpress core in https://github.com/johnpbloch/wordpress. Well know composer projects templates like BedRock moved to a similar approach years ago to resolve that kind of issue.

Hope it helps,

Let me know if you need more informations.

[mickaelperrin]

I tried an experiment here, but sadly it doesn't work. I wasn't aware of https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md.

So, the only way to achieve that is wether to implement a custom satis repository coupled with your licensing system or use the private packagist service: https://packagist.com/pricing which gives you the opportunity to distribute your private package and authenticate allowed users.

[elliotcondon]

Hi @mickaelperrin

Thanks for the info. I'm sure we can find a simple solution for this.
Just to be clear, the only issue with 'acf-pro-installer' is that it doesn't know the ACF PRO available update info (new versions, etc).

I'm not sure if this is any help, but I have a public API that can provide update information:
http://connect.advancedcustomfields.com/v2/plugins/get-info?p=pro

Can you also explain how a "github repository with a single composer.json file properly committed in branches / tags" would work?

[mickaelperrin]

Hey @elliotcondon,

Indeed, "the only issue" is that composer can't reach informations about new versions of ACF PRO.

However, it should be done in a composer way, and so far I have no idea how to handle this. When I opened the issue I had a solution in mind, "that github repository with a single composer.json file properly committed in branches / tags".

I did an experiment in the following github repository https://github.com/mickaelperrin/acf-pro but sadly that can't work because of https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md.

So far, I have no other idea, how to resolve this in composer except the two propositions I exposed in my previous answer: a custom satis repository or the use of packagist.

[elliotcondon]

Hi @mickaelperrin

Thanks for the info. I'll do some research too and hope to find a good solution for composer.

[drzraf]

Using bedrock-WordPress I experience the same issue.
I'd like to fetch directly ACF-pro from upstream.
Couldn't a private gitlab repo hosting the pro version could be opened and reserved to people providing licence key? This could be easily automated using github api (I don't know if it would scale to thousand of licence keys btw).
Then having a composer.json would be a must-have.

[drzraf]

Complaining here again :)
composer can't fetch ACF-pro from you-know-where because no composer.json is provided.

In the short term, could you please add this in a composer.json file to the next tarballs?

{
    "name"        : "elliotcondon/advanced-custom-fields-pro",
    "description" : "Customise WordPress with powerful, professional and intuitive fields.",
    "keywords"    : ["wordpress"],
    "homepage"    : "https://www.advancedcustomfields.com",
    "license"     : "GPL-2.0+",
    "type"        : "wordpress-plugin",
    "authors"     : [
	{
	    "name"     : "Elliot Condon",
	    "homepage" : "https://www.advancedcustomfields.com"
	}
    ],
    "require"     : {
	"composer/installers" : "^1.0",
	"php"                 : ">=5.3.0"
    }
}

In the long run, providing a composer/packagist-friendly way to fetch ACF-pro would be neat.

[techieshark]

Hi all,

Just checking in on this. I'm interested in using ACF plugin with Roots Bedrock - it looks like currently the best way to use composer is via one of these below. (If anyone else knows differently please let me know, thanks!)

For standard ACF, use:

composer require wpackagist-plugin/advanced-custom-fields

(Before running the above, you'll need to add the wpackagist repo as follows to your local composer.json)

  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org",
      "only": ["wpackagist-plugin/*", "wpackagist-theme/*"]
    }
  ],

For ACF Pro, see:
https://github.com/pivvenit/acf-pro-installer

[drzraf]

Even though we have paid license number we've relied on https://github.com/wp-premium/advanced-custom-fields-pro/ for years because even though releases tend to lag, it's so much simple to simply composer update.

Still, recently I gave another shot to ffraenz/private-composer-installer so I can comment about my setup:

1. wikimedia/composer-merge-plugin (because I maintain packages in a separate .json to not mess-up with Bedrock's provided composer.json and upcoming updates)
2. ffraenz/private-composer-installer which allows URL substitution of custom URL in repositories (for fetch tarballs)
3. ~/.config/composer/config.json (~/.composer/config.json) tweaks

It's very cumbersome.

• Version number is set in the repositories instead of require (I choose to store it system-wide anyway, at ~/.config/composer/config.json, because of the API key)
• None of the usual composer goodies (downgrade/branch/version listing/info/...)
• Does not even work with GravityForms (and many other paid plugins). Eg: you'd need gotoandplay/gravityforms-composer-installer. Once again: thank you wp-premium.
• If you add composer2 changes to the party (plugin-api incompatibility and merge-plugin adaptation time), it's a burden.

In the end: Yes, it's doable and somehow works. But it's not simple (nor ideal).

[JiveDig]

+1 here.

We just switched from https://github.com/PhilippBaschke/acf-pro-installer to https://github.com/ffraenz/private-composer-installer/ and updated to Composer 2 at the same time. It's all working but definitely not as simple as a dedicated composer package would be.

[tyrann0us]

Why not use https://github.com/cedaro/satispress? It was created for exactly the purpose discussed in this issue. Also see https://stackoverflow.com/a/59610919/1410103 for details.

Off-topic: Regarding Bedrock, I cannot recommend it, because it’s a boilerplate, resulting in the “mess” described by @drzraf. I highly recommend https://github.com/wecodemore/wpstarter/tree/version-3 instead. It’s a Composer plugin, meaning you require it as every other package and configure it in composer.json. For details, see https://discourse.roots.io/t/research-bedrock-vs-wp-starter-by-gmazzap/14044/4.

[JiveDig]

Why not use https://github.com/cedaro/satispress?

I can't personally use that because we're bundling ACF Pro inside our premium theme/plugin. AFAIK Satispress is meant for projects you manage where you want separate plugins to be managed via Composer.

[bradyvercher]

@JiveDig Hey Mike! SatisPress should work fine that use case. It exposes plugins as packages in a Composer repository, so it's completely up to you how you consume them. It just depends on whether managing a separate WordPress instance is worth the benefits SatisPress provides.

I'm not totally familiar with the workarounds for ACF Pro, but if a composer.json was added, it would probably install to the plugins directory automatically, just like SatisPress. In either case, you could use the installer-paths config option in composer.json to customize where ACF Pro is installed so you could bundle it as a library in your premium theme/plugin instead.

[JiveDig]

@bradyvercher Hey dude! Long time no talk! Hope things are well. This is great news! I've never used SatisPress before, but I'll take a look and see if I can get it to work. I'm not a pro with tooling and dependency management, so I'm always nervous when I have to change things :)

[mattneal-stafflink]

ACF now has composer support, you just have to add an auth.json with your credentials.

[Luckyfella73]

It is great you provided support for installing acf-pro via composer!

One concern I have is having my license key in a json file that can be accessed via browser. Is it possible to deny direct access (via .htaccess?) but allow your package to call it?

[mattneal-stafflink]

It is great you provided support for installing acf-pro via composer!

One concern I have is having my license key in a json file that can be accessed via browser. Is it possible to deny direct access (via .htaccess?) but allow your package to call it?

Have you tested to see if a .json file is accessible on your server already? Can you upload a dummy one to test if your server already disallows .json files being accessed?

I suggest using https://roots.io/bedrock/ which stores your credentials one level up which avoids this being a concern at all. You can block access yourself via your Apache .htaccess, or nginx config file.

[Luckyfella73]

Have you tested to see if a .json file is accessible on your server already? Can you upload a dummy one to test if your server already disallows .json files being accessed?

I suggest using https://roots.io/bedrock/ which stores your credentials one level up which avoids this being a concern at all. You can block access yourself via your Apache .htaccess, or nginx config file.

Yes, I uploaded a testfile, called it auth.json and was able to access it directly via browser. And yes - I could put the file outside the webroot but how to tell ACF where to look for the file (if not in the same directory as my composer.json which is located in webroot)?

The documentation says nothing about how to relocate the auth.json that's why I wondered if someone had thought that out before (I'm sure that's the case :) ) - so I guess I have to look out for some helpful .htaccess rules.

[mattneal-stafflink]

Yeah definitely don't go trying to move it out of your working directory unless you know what you're doing. Adding a .htaccess deny from all for .json should be the easiest way. There's a million resources out there for that :)