Installation Failure

I Simply downloaded the ZIP file, extracted it in my web-root, all I get is an error.
http://devserver-017.info/

I checked all the items listed here https://learn.getgrav.org/troubleshooting/internal-server-error, and found nothing missing and I made all the changes recommended.

Is there a way to test my host to see what the problem is?

You are getting a 500 error which means something with the server. The only way to know is to look at your server error logs. These should be in your user account somewhere (try /logs/ folder`), if not you might need to contact your hosting provider.

Without know the exact error, it's hard to know exactly what's going on, but you can try taking a stab in the dark with these potential 500 server error fixes

rhukster, my post mentioned that had checked all the items at the url you referenced..

Regarding logs, what do you make of this message in the php error log?

PHP Fatal error: Uncaught exception 'RuntimeException' with message 'Creating directory '/home/www/www.devserver-017.info/htdocs/cache/compiled/files' failed on error mkdir(): Permission denied' in /home/www/www.devserver-017.info/htdocs/vendor/rockettheme/toolbox/Fil e/src/File.php:400\

It looks like your folder permissions are to low

i can see why that error would happen. The permissions are 755 and the owner is not the account apache uses, so 755 prohibits writing by apache into that directory. This problem would be resolved by changing the owner to www-data or changing the permissions to 766, because apache is the group that owns that folder. But neither of those fixes addresses the main problem.

The permissions worked just fine for the software running in that domain, prior to simply extracting grav into it. I think this is bug in Grav, not a problem with the hosting. Instead of throwing a 500 error, grav could check the permissions of the folder it wants to write in before attempting to make the directory. If Grav detected the mismatch of the permissions, it could make the adjustment when php makes the directory and the problem would be fixed without any hassles. Grav also could have included the directory being created with the download, so it would not have to be created by php. Either of those changes in Grav would prevent this problem, Can you explain why this is a hosting problem and not a grav problem?

How about shipping cache/compiled with permissions set to 775 instead of 755?

The file owners are set to the developers responsible for them. The webprocess/php gets it permissions by being a member of the group owning the files. This arrangement is published as a best practice at serverfault.com, for the case where webfiles are maintained by a group of developers.. link: http://serverfault.com/questions/357108/what-permissions-should-my-website-files-folders-have-on-a-linux-webserver

Running exec is dangerous only if parameters entered by site visitors are used, which does not apply to this case. Regarding the speed of exec, it is fast running nothing but whoami, unless the server has a problem that would be affecting all the sofware it runs, not just Grav.

Unless you do something to Grav to prevent this 500 error, I don't see how you can have credibility when the download page says "Simply download the ZIP file, extract it in your web-root, and you are ready to start using Grav!"

Two developers from our shop downloaded and extracted into a webroot on different se rvers and both of us had problems. There is nothing wrong with either of our host environments and neither of us made mistakes. The problem is that Grav has some holes in its portability

What is it with CMS makers that every problem with installation is a problem where the host has something wrong? It is not just Grav, all CMS providers do this. Since the CMS providers typically have developers speaking to customers who are non-developers, the customers are intimidated and basically humiliated into accepting that there is something deficient in our systems and our brains that is the cause of our installation problems. Why don't you take responsibility of a disappointing customer experience, tell your customers that you are sorry for the inability of your system to adapt to their environment, and then make it so it does adapt? Even if the end result a product to what you deliver now, that service attitude would make your customers think you are great instead making them feel like they are incompetent. Your customers we not incompetent. Your software falls short of meeting our needs.