I was using Types 3.1.2 and upgraded to 3.2.3. When I did that all my sites started returning a HTTP 500 error. When I looked at the PHP error log, I saw this.
[Fri Dec 21 13:49:51.818757 2018] [php7:error] [pid 8315] [client 73.174.140.193:47025] PHP Fatal error: require_once(): Failed opening required '/nas/content/staging/brnfitness/wp-content/plugins/types/vendor/toolset/toolset-common/inc/autoloaded/upgrade/Command/AddRelationshipTableColumnAutodeleteIntermediaryPosts.php' (include_path='.:/usr/share/php') in /nas/content/staging/brnfitness/wp-content/plugins/types/vendor/toolset/toolset-common/utility/autoloader.php on line 116
Upon investigation, I noticed that the folder "command" was renamed to "Command" somewhere between those two versions. I use git to auto-deploy via automated scripts and my local macOS filesystem is case insensitive, however, my hosting provider, WPEngine, is case sensitive. So when I deployed, I was deploying "command" as the folder name because Git on my Mac didn't notice the change in capitalization.
One could argue that my local file system should be setup to be case-sensitive, but I don't think that's a fragile strategy as not everyone will do that. I think a better strategy is to not use capital letters in folders or filenames to prevent this from happening across the board.
Anyway, this was extremely frustrating and took about 2 hours to fix across my 20 sites.
Sorry for the inconvenience. I described the issue to one of the Types developers who asked me to escalate so that he can work on it. That won't be until after Christmas, but you wouldn't be affected by this until the next Types release in any case.
The Types developers replied that this sort of deployment is not expected, or supported, and so if problems with capitalisation affect deployment of Toolset plugins by some means other than through the standard WordPress plugin upgrade mechanism, you will need to make sure case-sensitivity is not a problem in the deployment yourself.
It was recommended that you adjust the deploy script so that the plugin directory is first deleted/completely emptied and then the plugin is downloaded again.
If you have Types managed by git, you might choose to do something like this:
cd types
# delete all files and directories except dotfiles, so the .git directory is preserved
rm -rf *
git reset --hard origin/master
You are deploying this way because of problems using wp-cli with Toolset, right?
I'm still in discussions with the installer developer to get to the bottom of why the Toolset updates are not being recognised by WordPress, and I'll update you in the other thread when I have something concrete to report. (Now everyone is back from the holidays that shouldn't be too long.)
Thanks for following up. Unfortunately that solution will not work in my situation.
If my repository has a filename called "test.php" and Types changes the filename to "Test.php", my git repo on my case insensitive file system will not detect that change so it won't make its way to the repository.
I'll think I'll have to figure something else out. This is not related to wp-cli though.
I do development on my Mac, which uses the APFS file system and by default, case sensitivity is turned off.
I use a Git repository for revision control that includes my theme and WordPress plugins. I use wp-cli to update WordPress and its plugins and then commit those changes to my local Git repository.
Next, I push those changes upstream to my Bitbucket repository. When changes are made to the master and production branches of my repos, they are automatically deployed to the correctly WPEngine hosting environment. WPEngine uses Apache on Staging and Nginx on Production...of which I believe both have case-sensitive file systems.
Thus, when a character's case is changed in a filename, I run into this issue.
