- Lance Johnson 12.17.2015
I always hate it when I'm responsible for my own loss of productivity, so I am posting this just in case anybody else out there runs into this problem and, like me, turns to Google to try and solve it. ExpressionEngine 3 was released earlier this year. Green Egg Media is a member of the ExpressionEngine Developer Preview Program, but we have have been moving actualy client work over to EE3 only slowly as we wait for the product to mature and get some results on how it is performing out in the wild. Our first production EE3 site is scheduled to launch in January, 2016, so we're just putting the finishing touches on now.
We manage all of our code using GIT, and as I was moving the code over to our staging server, I was having a problem: I was receiving only a blank white page for both index.php and admin.php. Worse, despite having $config['debug'] = '2'; in my config.php file, as documented in EE's System Configuration Overrides, I was getitng no error messages displayed.
Make sure you also have the following variable correctly set in index.php and/or admin.php depending on where you want your errors displayed:
$debug = 1;
Once I managed to get errors to display correctly, I received this error message:
Fatal error: Class 'EllisLab\ExpressionEngine\Service\Database\Database' not found in /system/ee/EllisLab/ExpressionEngine/app.setup.php on line 184
One of my team members reported having encoutered a similar problem previously, which she fixed by simply adding a fresh copy of ExpressionEngine 3's system/ee folder to to file system. I tried this, and it worked, but I realized that it wasn't a practical solution. I mean, isn't version control supposed to prevent you from having to manually move files around in your file system? And even though I know it is very bad practice to modify core files, sometimes it is absolutely necessary, so what would I do in the case that one of the system/ee files had been changed for some astronomically good reason? There had to be something more.
I always hate it when I'm responsible for my own loss of productivity. In this case, it turns out that the problem that I was having had been caused by a foolish addition that I made to .gitignore at the very beginning of the project. See, in "EE 2 Land" there are separate config.php and database.php files, and since the members of the Green Egg Media team may all be working on their own local environments, our workflow is such that we wrote a custom configuration script that team members would run after cloning the repository to, among other things, set file permissions and create a local version of database.php in their local file system, but we listed database.php in .gitignore in order to keep any given team member's local changes from breaking any other team member's install. I foolishly, errently left database.php in my EE 3 .gitignore, despite the fact that EE 3 has moved the database settings into the main config.php file which is now located at /system/user/config/config.php. Notice something about that fatal error? Yep, the core service class is called Database.php, which in case-insensitive operating systems is identical to database.php. Once I removed database.php from the .gitignore file, lo and behold, there were several files in the system called database.php or Database.php that had been left out of the repository. Adding those to the repo fixed my issues.
This is probably an edge case. I suspect that most people don't have database.php in .gitignore, but perhaps you've stumbled upon this article with a similar error that might be caused by something else you have in .gitignore. In any case, maybe I'll find my own blog post on Google the next time I do something silly like this.
AWS Elastic Load Balancers communicate with EC2 instances over standard HTTP, which can cause issues when WordPress is setup to use SSL. A single line of code in wp-config.php can fix this problem.