El Capitan – gulp watch not responding

bedrock
21

Well, not really. Gulp watch worked the night i finished importing the database, albeit a bit slower than normal, but when I fired it up yesterday I was back to square one – it just keeps spinning and never reaches the site.

One of the steps I took during my error search was updating trellis to the latest version. That included going from the old roots/bedrock box to the trusty64 box. Don’t know if this has anything to do with it, but when I try to reprovision my staging server I get an error on setting the root password for MariaDB.

Will take another look tonight and post a more detailed status.

22

Ah, this rings a bunch of bells for me, but my memory is failing me somewhat. I recently had to blow away my trellis setup and set it up from scratch. I was also getting that nginx error (is that fixed for you now?) and also getting the root password MariaDB error.

Check out this github issue, and specifically this, which points you to this to fix the mariaDB password issue.

I can’t for the life of me remember how I fixed the nginx issue… maybe that’s why I blew away my ansible folder in the first place :stuck_out_tongue:

23

As far as ERR_CONNECTION_REFUSED: make sure you don’t have conflicting VMs running

24

Great @clov3rly – thanks a ton, it definitely looks like the same issue I’m having! Added the patch referenced in #239 to my staging environment, i.e. adding login_user="root" and login_password="{{ mysql_root_password }}" to ansible/roles/mariadb/tasks/main.yml, like so:

- mysql_root_password: Abgsfn22-
- name: Set root user password
  mysql_user: name=root
              host="{{ item }}"
              password="{{ mysql_root_password }}"
              check_implicit_admin=yes
              state=present
              login_user="root"
              login_password="{{ mysql_root_password }}"

However, after running ansible-playbook -i hosts/staging server.yml to apply the patch, my staging environment instead gives me a 500 Internal Server Error. :confused: What was your experience of applying this patch, @clov3rly?

25

Nevermind, my bad – I’d forgotten to add the *staging.*domain.com part of the domain back in to wordpress_sites.yml after the ansible rebase. Thanks again, @clov3rly!

26

I had the same problem suddenly as @poggen after running vagrant provision after some troubleshooting I figured out this was caused by always parameter in roles/wordpress-setup/templates/wordpress-site.conf.j2

Changing

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options SAMEORIGIN;
add_header X-Xss-Protection "1; mode=block" always;

To

add_header X-Content-Type-Options "nosniff";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Xss-Protection "1; mode=block";

And doing another vagrant up solves the problem.

I’m not good enough with nginx to know what always does and why it’s not working. Something with the nginx version?

Or shall we change it in Trellis also?

ref. Best nginx configuration for improved security(and performance) · GitHub

27

I had a very similar problem with mysql, because of El Capitan’s ‘rootless’ permissions, any dev tools installed in any root folder except for usr/local/bin/ stops responding from the command line, even with sudo.
I fixed it by just running a reinstall with homebrew, which reinstalls it into that folder, worked for fixing the same issue with ruby and gems like Jekyll too.
I bet if you ran a brew install for nginx it would fix it, though I might be way off.