Describe the bug
On Pantheon servers (I assume due to server configuration) the following errors are displayed post-2.7 upgrade:
Warning: include_once(/srv/bindings/e9808ad72e3c4b1da56e9e2418c897d8/code/wp-content/plugins/cmb2/includes/CMB2_Hookup.php): failed to open stream: No such file or directory in /srv/bindings/e9808ad72e3c4b1da56e9e2418c897d8/code/wp-content/plugins/cmb2/includes/helper-functions.php on line 44
Warning: include_once(): Failed opening '/srv/bindings/e9808ad72e3c4b1da56e9e2418c897d8/code/wp-content/plugins/cmb2/includes/CMB2_Hookup.php' for inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /srv/bindings/e9808ad72e3c4b1da56e9e2418c897d8/code/wp-content/plugins/cmb2/includes/helper-functions.php on line 44
Warning: call_user_func_array() expects parameter 1 to be a valid callback, class 'CMB2_Hookup' not found in /srv/bindings/e9808ad72e3c4b1da56e9e2418c897d8/code/wp-includes/class-wp-hook.php on line 288
Steps to reproduce (I have confirmed I can reproduce this issue on the develop branch):
- Sign up for free pantheon.io account and create sandbox site.
- Install CMB2 and see above errors.
Possible Solution
Appears to be due to #1328 changing the name of the class but not the name of the file itself. Expect changing CMB2_hookup.php → CMB2_Hookup.php would fix.
Your Environment
Works = MacOS Valet + Homebrew PHP 7.3.
Broken = Pantheon.
galengidman
All 18 comments
Well, oops. Yes the file name itself should have been renamed. I’ll get a hot fix pushed tomorrow.
jtsternberg
on 24 Jan 2020
Hmm interesting. the file-name is correct here. I need to look into svn to see if it doesn't properly register the file-name case.
jtsternberg
on 24 Jan 2020
Weird. It looks correct in .org SVN too. I wonder if something funky happened when I ran the upgrade on my end?
galengidman
on 24 Jan 2020
Figured it out.
Pantheon's workflow is Git-based, so when I updated the plugin and committed the change Git didn't view the filename change as a new file and didn't add it to the commit.
galengidman
on 24 Jan 2020
Ah ok bummer. I did check the WP.org download and the file is properly cased. This is an unfortunate issue, but one I'm not sure we can really fix other than to put it back, and I'm not sure it's worth it. Hoping the developer-savvy audience that this may occur for will know well enough to find the issue, or to find this thread.
jtsternberg
on 24 Jan 2020
Makes sense. At least now we have this thread for reference. Thanks for the hard work!
galengidman
on 24 Jan 2020
On WordPress.com VIP Go hosting, I also ran into this issue upgrading 2.6.0 to 2.7.0. Automattic's workflow is probably similar to Pantheon's.
Am I reading correctly that the fix is to delete the file and then re-add it, so that Git will realize that it is a change and commit it as such?
jonathanstegall
on 27 Jan 2020
Yes, I believe so.
tw2113
on 27 Jan 2020
I just followed this from @galengidman above. Works to get Git to recognize file change. No need to delete and re-add: https://github.com/CMB2/CMB2/issues/1333#issuecomment-578244979
damonsharp
on 27 Jan 2020
@damonsharp it kind of looks like I can do git config core.ignorecase false and that would be sufficient? Or did you find that you had to do things from the other answers on that question?
jonathanstegall
on 27 Jan 2020
@jonathanstegall For me just running git config core.ignorecase false was sufficient for Git to recognize the file name change and allow me to add it to a new commit.
galengidman
on 27 Jan 2020
@jonathanstegall I initially ran git mv -f OldFileNameCase newfilenamecase in my case, but adding it as a config is better.
damonsharp
on 27 Jan 2020
I find that git config core.ignorecase false keeps both the lowercase and the uppercase file. Which is fine, I imagine. But presumably using git mv would've prevented this.
jonathanstegall
on 27 Jan 2020
Hit this issue as well. CMB2 in my plugin didn't commit the file case change, but git mv -f OldFileNameCase newfilenamecase worked for me. Thank you all for the solution(s). 👍
JiveDig
on 3 Feb 2020
This is really a nasty issue. I spent 6 hours yesterday to try to find out why metboxes worked in my dev environment on OSX but not in production at OVH. It turned out that CMB2_Hookup.php was still named CMB2_hookup.php. This did not break things on OSX with PHP 7.2 but it did on the OVH server with PHP 7.3. Renaming fixed the problem.
I don't know why my file used the old spelling. Maybe because my dev environement is under git?
It's annoying when this kind of problem only occurs in the production environment, and I suspect that other people may run into the same problem.
Couldn't this particular issue, which is due to the unfortunate old naming of the class file, be resolved in helper-functions/cmb2_autoload_classes?
chrilleferna
on 30 Dec 2020
@chrilleferna we may be able to put a shim in there to make sure it finds the old file, but it's not something I can easily test, as I don't have that issue on my file-system. Would you be willing to test this theory on your server?
jtsternberg
on 30 Dec 2020
Yes, I would be happy to test!
chrilleferna
on 30 Dec 2020
I just had the same problem today with my git workflow, so a shim might be good for others, too.
mark-barnes-sp
on 17 Feb 2021
Related issues
GaryJones
·
3Comments
jflagarde
·
6Comments
noquierouser
·
8Comments
needtakehave
·
7Comments
kidatart
·
7Comments
Most helpful comment
I find that
git config core.ignorecase falsekeeps both the lowercase and the uppercase file. Which is fine, I imagine. But presumably usinggit mvwould've prevented this.