PHP Fatal error: Call to undefined function apply_filters()
mikelking opened this issue · 7 comments
wp-includes/load.php on line 317
Recently (this afternoon), I decided to try and build our tree using;
composer require johnpbloch/wordpress 4.6
Since then I've been stuck at the php fatal. It looks' like something is not fully hydrating in the build. To troubleshoot further I manually pulled the wordpress-4.6.tar.gz form .org and unpacked it over the destination. The fatal has ceased.
Any thoughts on how to troubleshoot further? I've tried the same in our vagrant system as well as Jenkins and they all stop at the same failure point.
I'll take a look. Sometimes the script barfs.
I just threw together a stock install from this package and did not receive this error. I imagine it must have something to do with plugins, themes, or something else happening in addition to the core package. I can say that the filter triggering this error is new to 4.6, so maybe start looking there for a possible conflict in your site's custom code.
Thanks for coming by to report the issue!
Thanks @johnpbloch for answering back. I know this is a fairly automated system so I did some more digging and even ended up creating my own wordpress repo built from the wp release tarballs then modified the composer manifest accordingly. Anyway long story short it was the wp-cli/wp-cli version 0.20.4 being incompatible with current release. It took a while to get everything downgraded to support the 0.24.1 version.
I wish I could say that this exercise made me more comfortable with the entire process and composer over all. Still trying to digest all the hackery that went into getting back on track.
"repositories": [
{
"type": "vcs",
"url": "https://github.com/mikelking/wordpress"
},
{
"type": "composer",
"url": "https://wpackagist.org"
}
],
"require": {
"php": ">=5.4",
"composer/installers": "v1.0.12",
"mikelking/wordpress": "4.6",
Cheers,
m
It sounds to me as if this was a conflict between the version of WordPress itself and the version of WP CLI being used, is that correct? If so, I think we can close this issue.
As far as managing this sort of conflict, etc. in the future, you could always require WP CLI from your site's composer.json
and use vendor/bin/wp
rather than wp
, which would ensure that you're always using a compatible version.
Indeed I think we can close. We did have the wp-cli required in the composer.json but it was locked to the older version and there were symphony dependencies that were oddly holding it there. Anyway it was a god learning experience. Thanks for your help and patience.
Upgrading wp-cli from 0.21.1 to 0.24.1 fixed the issue for me too
wp cli update