Incompatibility with a WP Composer installation #13497
Comments
LeoColomb
changed the title
jeherve
added
[Focus] Jetpack DNA
[Status] Needs Author Reply
|
Could you tell me more about your setup? |
|
Most simple setup:
{
"repositories": [
{
"type": "composer",
"url": "https://wpackagist.org"
}
],
"require": {
"php": ">=7.1",
"automattic/jetpack": "^7.0",
"composer/installers": "^1.7",
"vlucas/phpdotenv": "^3.4.0",
"oscarotero/env": "^1.2.0",
"roots/wordpress": "5.2.3",
"roots/wp-config": "1.0.0"
},
"extra": {
"installer-paths": {
"web/app/plugins/{$name}/": ["type:wordpress-plugin"]
},
"wordpress-install-dir": "web/wp"
}
}
FROM composer:latest as vendor
COPY composer.* ./
COPY web ./web
RUN composer install \
--ignore-platform-reqs \
--no-interaction
FROM wordpress:cli
COPY . .
COPY --from=vendor /app/vendor ./vendor
COPY --from=vendor /app/web ./web
RUN wp plugin list
|
|
Thanks. You're most likely running into this issue: Ideally you wouldn't be copying the Jetpack plugin into Bedrock seems to support this out of the box, thanks to the Line 5 in a9959f2 That is why the Jetpack plugin properly gets copied to the /web/app/plugins/ directory when you run composer install instead of using your custom Dockerfile.
Unfortunately in your set up we don't get to that step, as it fails before WordPress can be installed, as all of Jetpack's packages got autoloaded from the root of your project instead ( Line 144 in 8d4f7b9 Could you try to move plugins out of the root's |
|
Thanks for your reply.
That's a 4 yo question, I'm speaking about a recent issue raised directly with the 7.5 release of Jetpack.
I'm not sure to follow you... I do run a
That is already done by the |
Right, but all Jetpack packages (those were added in Jetpack 7.5) can also be found in the root's That is why you run into that 4 year-old issue I linked to earlier: you end up using
Excellent. That would mean I am wrong; it's not the Jetpack plugin that's the problem, but the other packages required by the Jetpack plugin. Maybe since those are not WordPress plugins, they do not get moved?
Do you see a |
|
@jeherve Thanks for your answer.
Yes, I do: I think the main issue is declaring a |
BTW note these files are present here because Jetpack GitHub releases are made on built branches where vendor files are present. They are packed in the downloaded release zip file. In a standard way to use composer, vendor files are kept outside of the parent package. |
LeoColomb
changed the title
Right. That's to expected as the file is needed. The problem here is that those packages are typically only loaded after WordPress has been loaded. In your case that's not what happens, since the packages are loaded right away from the main autoloader of your app.
Right, since we are in a WordPress plugin things are a bit different from a more typical setup. |
jeherve
added
[Pri] Normal
[Type] Bug
|
@jeherve Thanks for your reply.
For sure. But there are tons of ways to include necessary files. Also this file seems to load deprecated features, so are we sure we do want to load it in any case?
Well, not necessary! 🙂 As you have already the script to "build", doing this should be quite simple. That said this is a different issue, do you want I open another one to discuss about this? |
Yep, that file is needed for Jetpack to work properly.
For sure. We've started playing with actions on our end as well, and may switch to using them in the future. Regardless, the final version of Jetpack that gets shipped to SVN will always ship with the packages defined in Back to that original issue, we'll see what we can do to address this, since #12923 and #12943 weren't enough to catch everything. |
Sure. 100% right.
Shouldn't, since I get the Jetapck plugin/package from Packagist.
As long as you include the |
|
I bumped into this issue when trying to set up a site using WP Starter. I think the problem is that Jetpack's Lines 14 to 28 in 3a0874e This was the stack trace: I can confirm that version If it would be helpful to provide my project |
@jeherve Is it worth opening a PR with my suggestion? |
|
For sure. I think that's something that could be incorporated to the script we use to generate the built branches that are tagged and released on GitHub. This happens here: jetpack/tools/build-release-branch.sh Line 239 in 154db22 This way, we could edit |
* Remove composer dependencies listing for built branches Ref: #13497 * Improve removing composer packages listing script Simplifying by using composer regexp capability * Cleaning up the composer edition in the build script
Context
Output
Notes
Seems very related to the
jetpack-compatpackage.The text was updated successfully, but these errors were encountered: