Propose an updated composer.json for PRO version about acf HOT 16 OPEN

Hi @mickaelperrin

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

from acf.

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?

from acf.

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.

from acf.

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.

from acf.

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?

from acf.

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.

from acf.

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.

from acf.

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.

from acf.

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

from acf.

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).

from acf.

+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.

from acf.

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.

from acf.

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.

from acf.

@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.

from acf.

@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 :)

from acf.

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

from acf.