Recently I’ve decided to start doing Drupal theme development using SASS to compile the stylesheets. It’s fast, easy to keep organized and I should’ve started doing it sooner. However I have noticed that this is relating directly to how certain node modules have *.info files, which are EXACTLY like the *.info files included in the theme folder for Drupal 7 themes.
It came to my attention the new folder node_modules includes *.info files which Drupal requires for each individual theme. One per theme, which resulted in causing many issues with Drupal’s administration area. I troubleshooted a bit on stack overflow and found this question. The solution was to add a post install script that removes the info files in the node_modules folder. In addition I added a new file called .npmrc which combined seems to have fixed my issue.
I came across this as I found it to be important. Currently Degree Search is split into three branches:
Master: Current live version
3.0: Different version, stopped work once laravel 5 was released
5.0: Most recent version implemented in laravel 5.
At this point I no longer wanted the current version to be what I work on anymore, so I decided to change branches. However there doesn’t appear to be very straightforward, especially since the 5.0 branch doesn’t have a shared history from master, I pushed it remotely from my local dev environment.
Note: please make a backup branch of master before doing this, it’s easier this way
Following this Stack Overflow I was able to find something that not only merged the master history, but also replaced the files with my current dev branch. While on the master branch I ran these commands:
The writer of the answer also suggests more detailed messaging in the commit, so you could instead do this:
git checkout yourbranchname
git merge --strategy=ours --no-commit master
git commit # add information to the template merge message
git checkout master
git merge yourbranchname
This solved my issues of having to deal with the master branch, considering it’s being migrated to a newer version. All that was left after this was to switch to the backup older branch for the live site and test the new master branch. Other than a few things that got wiped away in the branch switch, everything merged correctly.
This is something I’m trying to remember, and it’s something that’s been answered before here.
I’ve beginning to experiment with HHVM as an alternative to using PHP, so I figured this would be useful to try out. Switching out the language that’s called when using PHP on the terminal is as simple as using this command:
This will do it without any input, and you should be able to check by running. php -v. If you get hhvm version stuff, you should be good.
My next important question was how to switch back to using PHP. Again, simple:
sudo /usr/bin/update-alternatives --config php
It will then ask you to select from a list of options. My options were:
There are 2 choices for the alternative php (providing /usr/bin/php).
Selection Path Priority Status
0 /usr/bin/hhvm 60 auto mode
1 /usr/bin/hhvm 60 manual mode
* 2 /usr/bin/php5 50 manual mode
Press enter to keep the current choice[*], or type selection number:
I recently decided that I no longer needed to use DreamHost for hosting my website now that I’ve been using Octopress.
The initial setup for this appears to be quite straightforward, but it is advised that you follow the exact directions otherwise you will have issues. I had some initially, and I ended up having to destroy my repository and start over again.
It appears my ability to use rake preview is broken, but that might really be related to my VM not appearing to forward the 4000 port, which I can’t tell if that’s an issue with the machine or not. I may just replace the VM.
I also noticed that this process doesn’t really seem to enjoy posting from more than one computer. I found out the hard way and I ended up having to blast the repository completely and start from scratch. I found that once you run rake setup_github_pages and tried to generate and deploy the site it would say something along the lines of being out of sync.
After running rake setup_github_pages, don’t run generate or deploy, but instead go into the new _deploy folder and run git pull origin master. It should merge your current master branch into the folder. There will be an index merge conflict, which is easy to delete the old one. Doing this should allow you to run rake deploy successfully to commit the blog.
If you don’t plan on maintaining this blog with more than one computer, then this probably isn’t the biggest problem for you.
Now the next step would be to edit the port used by nginx. Each server(it you have it configured that way) would need to be switched from 80 to 8080. The location of my config files are /etc/nginx/sites-available.
If you’re using this on a vagrant and have ports forwarded, for example I use homestead for laravel, you will need to change the forwarded port from 8000 to 8080, otherwise it won’t work properly, and nginx will likely not show your sites.
Finished, now test:
To test, you can run varnishstat, and that should give you data live as you access the domain affected by varnish.
I can confirm that this does in fact work with homestead and elixir. However, I notice that the server hangs at provisioning on terminal. It doesn’t freeze, it continues to load, but it is one little weirdness that I’ve found. Again, server still works, this is likely a ruby issue.
I’ve been looking using grunt/gulp for automation of my different tasks, such as css/js minification, and image manipulations so when I found out about automating tests for phpunit, I decided to give a try.
Note: I haven’t really seen anything relating to this other than this, but I couldn’t quite get it to work using his bash script, so I ended up a making a few adjustments to his.
I develop using a Vagrant VM, so while installing most of this stuff on the host machine will work fine, I want it to be mostly kept to the VM. The tests are also running against the VM’s databases, not the local machine, so it makes more sense to keep dev separate from the Host Mac OSX.
 Install terminal-notifier
I used homebrew, so I just ran update and installed terminal-notifier:
brew update && brew install terminal-notifier
This added terminal-notifier to my applications folder, it also linked the app to my $PATH, which allows me to call it from the terminal.
 Install Vagrant-Notify
I will be using terminal-notifier for this, since it’s the stock notification app for Mac. This piece was a bit weird when initially installing. It worked best for me when I installed the plugin with the Vagrant vm off, it will give me an error about ruby running if the machine was already running. Killing the rogue ruby task with activity monitor would fix this as well.
From inside the folder with your Vagrant:
vagrant plugin install vagrant-notify
This piece will require another file called notify-send, preferably saved in usr\local\bin
Make sure this file has no extension and is executable. sudo chmod +x /usr/local/bin/notify-send
This is the part where I couldn’t quite get it to work like in the tutorial I included, so I ended up moving around the numbers that were being submitted to the script from gulp. These are the numbers that worked for me, YMMV. I believe the gulp-notify sends more by default now.
 Install Gulp, and dependencies
Used NPM for this on my Vagrant VM, since this is where gulp will be called:
I gathered this from a couple of different gulp.js files.
Note: Can be edited from host or guest machine, since in my case the gulp file will be at the base of my project folder.
 Check that it works
You can run gulp, or you can use gulp test
Which should return a notification of some sort. This will likely not be the best way to address phpunit tests, especially since currently there are only 3 tests. That’s not a lot, but if the project was much bigger, say 30-40 tests, I can see this being a dumb idea. I’ll likely not use this for larger projects, or at least implement a count that only runs the tests every so often.
The difficult part about this was getting the script to return the proper notifications. It initially wouldn’t give the message, and instead was using the default img that is included with the script. I ended up moving the numbers around and that seemed to address the issue.
I noticed that after migrating dev work to my new Vagrant vm, jekyll doesn’t seem to want to regenerate posts whenever I make a change and try to preview it. The simple change I found from a stackoverflow post is instead of calling just jeykll build –watch, use jekyll build –watch –force_polling.
Both generate rake watch and rake preview use this line, so make sure to replace both. This seems to have solved my issue with rake preview/watch. The question also has an answer suggesting that vagrant uses a special driver for the file syncing between guest and host machines, making the regeneration not work properly, so that’s something to keep in mind.
Fixed a typo, it should be “sudo cp /usr/local/opt/nginx/*.plist /Library/LaunchDaemons“ not “sudo cp /usr/local/opt/nginx/*.plist /Libary/LaunchDaemons“
Also added chown for file, in case it doesn’t have proper permissions.
For the longest time I couldn’t get the piece to work, but I finally figured it out using launchctl as a somewhat basis for troubleshooting. I used homebrew to install nginx which is easier and works for the most part. First the instructions on how to install nginx using homebrew:
brew update && brew install nginx
Next what you want to do is have launchctl start nginx automatically for you. You can do this in several ways, but I’ll cover two:
Option 1 - Symbolic link
For this option you will symbolic link the .plist file included with nginx to have launchctl launch nginx using the proper permissions. Then use launchctl to list the resulting loaded file.
The link you’ll need to use is something along these lines:
I updated from 5.5.8 to 5.5.11 today. After the upgrade, I noticed that anything using fpm/php had stopped working with nginx, I was getting a Bad Gateway Error. Checking my console I noticed fpm had spewed out a few errors since the update time, indicating that it wasn’t working. I tried running php-fpm from the command line, and it started right up with no problems, all my php sites worked after that. This gave me the impression that something with my plist file, the file for starting php automatically, wasn’t working correctly. That’s when I decided to make a note of this in an article.
In other words:
If you are upgrading from 5.5.8 to 5.5.11 using the command brew upgrade be aware that the .plist file used in .11 might be spelled differently than what’s in .8. This, depending on how your environment is setup could break your php-fpm, and possibly php. Make sure to swap out the file names by running these commands first: