I can see how you you might read @swalkinshaw’s comment as not nice. I guess the repetition was just a 20 characters thing, but I originally read it as a persistent reminder you’d get from a mentor who knows how tough it is to tenaciously scrutinize and take action on error output.
I originally clicked “like” on @swalkinshaw’s reminder to check the logs because a 500 error is typically an Nginx issue and likely reported in the Nginx logs. You reported only “now I’m just getting a 500 error” with no other info or indication of having tried to research the issue. The suggestion to check the logs is probably the most helpful advice anyone could give.
Errors are always an unwelcome interruption and disappointment. Error output often contains info that is unfamiliar and which is often unhelpful. It’s a pain to deal with. Still, “check the logs” is the right thing to do. @swalkinshaw’s response wasn’t dressed up, but having read probably 1000s of his rational interactions with people, I knew he meant no offense.
I’m sad you ran into the the original issue you reported. To share an example of taking action on an error message, when I searched the original issue of invalid number of arguments in * directive I quickly saw a several instances of people missing a semicolon in their Nginx conf. Your error message gave you a file and line number to check:
invalid number of arguments in "include" directive in /etc/nginx/sites-enabled/thewaitstaffteam.theportlandcompany.com.conf:50.
It would be appropriate to inspect that file on the server, that line. I understand that Nginx confs may not be familiar, so you may not have noticed that a missing semicolon was a problem. In that case, you might post “I get an error specifying a file and line number, here is a copy of that file. Can anyone help me see the problem here?”
Preferably before even posting, you could check for recent action in the codebase for the related lines. Suppose you examine the line 50 indicated in your error message and see that it has include h5bp/location/cache-busting.conf. You could find the related file in Trellis and check for changes to that section, e.g., this line with note “add missing semicolon”. Such a technique won’t always yield such an obvious fix for the problem, but even if you’d searched the Trellis repo for a string from line 50, e.g., cache-busting.conf, you’d probably have found the discrepancy between your files and the latest upstream Trellis.
Ok, I get it that one might not know to take all those steps. And yes, it’s easy for me to lay them out in hindsight now that we know the problem was a missing semicolon. But I think I would have been justified to have originally responded “check the error message,” encouraging you to pay attention to line 50 of the indicated file. Such a response would have been guiding you on the next step to take, just as “check your logs” was the next step for a 500 error.
Ok, you’ve subsequently reported that /var/log/nginx/error.log didn’t show anything helpful. Searching discourse or the trellis codebase for error.log will reveal a site-specific log at /srv/www/example.com/logs/error.log. Hopefully that log will have something useful. But maybe not.
If this other log doesn’t show anything helpful, here are the next steps I’d take. If a playbook fails, it’s possible for the server to be left in a weird state. Try SSHing into the server as a sudoer (root, or the value of your admin_user)…
# restart php just to be sure
sudo service php7.1-fpm reload
# check nginx config -- should indicate all 'ok'
sudo nginx -t
# reload nginx or maybe `sudo service nginx start` if it says it's not running
sudo service nginx reload
Then rerun the server.yml and rerun deploy.yml playbooks just to make sure any missing pieces are provisioned and deployed.
If this site is multisite, you may get a 500 error unless you use wp-cli to install:
and pulled a version of Trellis that existed with a flaw for less than 24 hours. I’m guessing you need the fix in 
