Disabling PHP 5.5.3 OPcache in MAMP

A student in my MCAD PHP and WordPress class ran into a curious issue where her changes to PHP scripts running in MAMP weren’t reflected when she refreshed the page in a browser, unless she opened the page in a new tab. Turns out OPcache is enabled by default in PHP 5.5.3 running in MAMP 2.2. Here’s a Stack Overflow post on how to disable it in your php.ini file.

The steps:

  1. Find your php.ini file. In my MAMP installation it was located at: /Applications/MAMP/bin/php/php5.5.3/conf/php.ini.
  2. Comment out the OPcache lines at the bottom by putting a semicolon in front:
    [OPcache]
    ;zend_extension="/Applications/MAMP/bin/php/php5.5.3/lib/php/extensions/no-debug-non-zts-20121212/opcache.so"
    ;  opcache.memory_consumption=128
    ;  opcache.interned_strings_buffer=8
    ;  opcache.max_accelerated_files=4000
    ;  opcache.revalidate_freq=60
    ;  opcache.fast_shutdown=1
    ;  opcache.enable_cli=1
    
  3. Stop and start your MAMP servers.

Deleting Ignored Files Mistakenly Committed to a Git Repo

This is not a common situation, but occasionally you may find yourself having force-committed a bunch of things (usually a bad sign to begin with, but that’s a whole ’nother post) and a few files that should be ignored sneak into your repo. You might have dozens of commits from that point on and not be aware of it, because your .gitignore file dutifully doesn’t track those files anyway.

So: how to remove those files from the Git cache? My research led me to rewriting commits, which is usually filed in the “Contents Dangerous. Open With Caution.” section of Git. Here’s some links:

So here was my process:

  1. Remove the files from the Git cache. I used an rm -rf command because I was getting rid of directories. For example:
    git filter-branch --index-filter 'git rm -rf --cached --ignore-unmatch <path to file or directory, from root level of your repo>' HEAD
    
  2. Prune Git. For example:
    rm -rf .git/refs/original/ && git reflog expire --all &&  git gc --aggressive --prune
    
  3. Force-push your edits, otherwise they will be rejected because you’ve rewritten history. (Couldn’t figure this part out until I read Thomas Hunter’s post linked above.)
    git push origin master --force
    

If you’ve got a bunch of files, I would suggest atnan’s gist linked above, or David Underhill’s script (second link). David’s script also prunes Git (my understanding is you can still have file references hanging around that need to be garbage-collected).

Ideally you would never end up in this situation, and hopefully you catch this before you’ve pushed changes to a remote and others have pulled the dirty repo down. In my case there didn’t seem to be ill effects introduced by rewriting commits and pushing to a remote, but it’s something I’d like to avoid as much as possible.

Clearing Out Drupal Features Checkboxes

Drupal has a Features module which allows for certain configuration settings (Views/Context/Content Types) to be exported to code. This way you can separate out configuration from content, and avoid having to sync databases up/down environments.

Except that sometimes (in my experience) you hit a wall with a created feature. I’m not sure where that limit is, but sometimes you end up with a feature that simply won’t allow you to re-create it cleanly.

In those cases my workaround has been to simply export just the specific component that changed, and then hand-merge the code myself. This can be troublesome if you have a lot of components, however.

checkboxes

(That’s maybe 1/20th of the checkboxes for this feature. Which is a lot of clicking.)

So here’s a quick line of jQuery you can run in your browser console to uncheck every component in your features module.

jQuery(".component-included.form-checkbox").removeAttr('checked');

I’ve also put this up as a gist.