At my former workplace, we were using BitBucket (BB) for hosting our git repos and ActiveCollab (AC) for our issue tracking. BitBucket allows you to reference issues in your commit messages – but only if you’re using their issue tracker. ActiveCollab allows you to import git repositories and scan them, but configuring and maintaining them is a pain. Also, we had in place the workflow that when an issue was fixed, you had to reassign it to the user who opened it in AC. This seemed like an unnecessary manual step to me that begged to be automated, so I automated it: meet acbb_connector (great name, I know).

acbb_connector is a little tool that you deploy on your AC server that receives a webhook callback from BB every time a commit is made and uses the AC API to manage the issue. So you push a commit like:

fixed syntax error
fixes #188

and it gets parsed, fixes issue 188 of the project that corresponds to the BB repo the commit is coming from and reassigns it to the user that opened the issue.

Documentation on how to install and configure is on the github page.

Run this command to add a git alias:

git config --global alias.changed-between '!f() { git log --pretty="%H" --author="$(git config user.email)" $1..$2 | while read commit_hash; do git show --oneline --name-only $commit_hash | tail -n+2; done | xargs ls 2>/dev/null | sort | uniq; }; f'

Then use it like this

git changed-between 07d2882 4881cdd

Which will give you an output like:

src/AppBundle/Controller/BaseController.php
src/AppBundle/Controller/UserController.php
src/AppBundle/Entity/Address.php
src/AppBundle/Form/AddressType.php

Since it runs on localhost, it’s a bit tricky to set it up in a Vagrant box, where your box probably has it’s own hostname (e.g. myapp.dev). This blog post is written for Ubuntu 14.04 with PHP and apache.

Mailcatcher Web GUI

Here’s how to set up Mailcatcher in your Vagrant box.

Provisioning

First you need to provision your Vagrant box to install Mailcatcher. If you don’t already have a provisioning script, you can add one to your Vagrantfile like this:

config.vm.provision :shell, path: "vagrant/provision.sh"

Then create vagrant/provision.sh in your project directory:

#!/bin/bash

# install mailcatcher (http://mailcatcher.me/)
apt-get install -y ruby-dev libsqlite3-dev
gem install mailcatcher
# enable apache proxy modules to configure a reverse proxy to mailcatchers webfrontend
sudo a2enmod proxy proxy_http proxy_wstunnel

# replace sendmail path in php.ini with catchmail path
CATCHMAIL="$(which catchmail)"
sed -i "s|;sendmail_path\s=.*|sendmail_path = $CATCHMAIL|" /etc/php5/apache2/php.ini

# restart apache
apachectl restart

Note that I replace the default sendmail path in the php.ini* for apache with Mailcatcher’s own catchmail, which causes all mails to be sent there. If you also send mails from the command line (e.g. cronjobs), you’ll also need to replace sendmail in /etc/php5/cli/php.ini.

If you’re sending your mails with SMTP, you have to configure smtp_port instead.

This script is only run automatically when your box is first setup. You can run it manually by calling:

vagrant provision

*you could also just configure this in your apache config like:

php_admin_value sendmail_path "/usr/local/bin/catchmail"

But I feel more comfortable knowing that it’s in my php.ini and won’t suddenly start sending mails if I change around my apache config and suddenly that rule is in the wrong Directory or something.

Starting Mailcatcher on ‘vagrant up’

Just add this to your Vagrantfile to start Mailcatcher when you run vagrant up:

 config.vm.provision :shell, inline: "mailcatcher", run: "always"

Accessing Mailcatcher web gui

Since the Mailcatcher web gui, where you can view all captured mails, runs on localhost, it’s not accessible via your app or website frontend by default. This is how I configured my Apache virtualhost conf to enable this (only relevant parts):

ServerName myapp.dev

# proxy pass mailcatcher to internal webserver
ProxyRequests Off
ProxyPass /mailcatcher http://localhost:1080
ProxyPass /assets http://localhost:1080/assets
ProxyPass /messages ws://localhost:1080/messages

Then restart your apache and you should be able to access myapp.dev/mailcatcher in the browser.  Now any mails your app sends should be instantly displayed there instead of actually being sent.

Luckily, PHP offers some great tools for working with data that we usually take for granted. When posting multipart form-data to a PHP script, the POST values will automatically become available as an array of values in the $_POST superglobal, the files will automatically be processed and be made available in the $_FILES superglobal. Unfortunately, this doesn’t work for PUT requests. This is probably by design, as with a PUT request you are actually sending a specific file to a specific location on a server. This is supported, as is sending an url-encoded querystring as the payload. What doesn’t work out of the box though is sending multipart data in a PUT request.

Consider the following pseudo code on the client side:

curl_setopt_array(
  CURLOPT_POSTFIELDS => array(
    'user_id' => 3,
    'post_id' => 5,
    'image' => '@/tmp/current_file'),
  CURLOPT_CUSTOMREQUEST => 'PUT'
  );

If you get rid of the CURLOPT_CUSTOMREQUEST bit, this will be sent as a POST, and the data will be available in the $_POST and $_FILES arrays respectively. With PUT, the data will not be parsed by PHP at all. So I wrote a method to do it manually. Unparsed multipart data looks something like this:

------------------------------b2449e94a11c
Content-Disposition: form-data; name="user_id"

3
------------------------------b2449e94a11c
Content-Disposition: form-data; name="post_id"

5
------------------------------b2449e94a11c
Content-Disposition: form-data; name="image"; filename="/tmp/current_file"
Content-Type: application/octet-stream

�����JFIF���������... a bunch of binary data

Here’s a method that will parse this:

/**
 * Parse raw HTTP request data
 *
 * Pass in $a_data as an array. This is done by reference to avoid copying
 * the data around too much.
 *
 * Any files found in the request will be added by their field name to the
 * $data['files'] array.
 *
 * @param   array  Empty array to fill with data
 * @return  array  Associative array of request data
 */
function parse_raw_http_request(array &$a_data)
{
  // read incoming data
  $input = file_get_contents('php://input');

  // grab multipart boundary from content type header
  preg_match('/boundary=(.*)$/', $_SERVER['CONTENT_TYPE'], $matches);

  // content type is probably regular form-encoded
  if (!count($matches))
  {
    // we expect regular puts to containt a query string containing data
    parse_str(urldecode($input), $a_data);
    return $a_data;
  }

  $boundary = $matches[1];

  // split content by boundary and get rid of last -- element
  $a_blocks = preg_split("/-+$boundary/", $input);
  array_pop($a_blocks);

  // loop data blocks
  foreach ($a_blocks as $id => $block)
  {
    if (empty($block))
      continue;

    // you'll have to var_dump $block to understand this and maybe replace \n or \r with a visibile char

    // parse uploaded files
    if (strpos($block, 'application/octet-stream') !== FALSE)
    {
      // match "name", then everything after "stream" (optional) except for prepending newlines
      preg_match("/name=\"([^\"]*)\".*stream[\n|\r]+([^\n\r].*)?$/s", $block, $matches);
      $a_data['files'][$matches[1]] = $matches[2];
    }
    // parse all other fields
    else
    {
      // match "name" and optional value in between newline sequences
      preg_match('/name=\"([^\"]*)\"[\n|\r]+([^\n\r].*)?\r$/s', $block, $matches);
      $a_data[$matches[1]] = $matches[2];
    }
  }
}

And here’s how to use it:

$a_data = array();
parse_raw_http_request($a_data);
var_dump($a_data);

In the above example, the var_dump would look something like this:

Array (
  [user_id] => 3
  [post_id] => 5
  [files] => Array (
    [image] => [binary data]
  )
)

I hope this helps.

Update
I’m happy to see that a few people have used the code above and some have changed it to meet their requirements. Check out commenter Jas’ version for multiple file and input-type support.

<xsd:import namespace="http://schemas.xmlsoap.org/soap/envelope/" schemaLocation="http://schemas.xmlsoap.org/soap/envelope/"/>

My first thought was to match all the schemaLocations in the schemas and cache them manually, but it seemed to me there must be a better way..
There is and it’s called a catalog.

“What’s a catalog” I hear you say:

Basically it’s a lookup mechanism used when an entity (a file or a remote resource) references another entity. The catalog lookup is inserted between the moment the reference is recognized by the software (XML parser, stylesheet processing, or even images referenced for inclusion in a rendering) and the time where loading that resource is actually started.
– xmlsoft.org

So, it turns out libxml has catalog support. A catalog is basically an XML file that libxml will parse and use to map references. I was doing the schema validation with DomDocument::schemaValidate and since DomDocument uses libxml behind the scenes, this works for PHP as well. libxml2 per default looks for an xml catalog in /etc/xml/catalog and DomDocument is hardwired to that location as well. *

You can add XML catalogs with a little tool called xmlcatalog that comes with libxml (I think). The usage is pretty straightforward, call up the man page to get an overview or read it online. Here’s how I added a catalog to map the Soap envelope schema location to a local path:

1. Create /etc/xml if it doesn’t yet exist.

2. Copy the Soap envelope schema from http://schemas.xmlsoap.org/soap/envelope/ to a local path, let’s say /etc/xml/soap-envelope-1.1.xsd

3. Create the catalog file (if it doesn’t exist yet) and add our new rule:

xmlcatalog --create --noout --add "rewriteURI" "http://schemas.xmlsoap.org/soap/envelope/" \
"file:///etc/xml/soap-envelope-1.1.xsd" \
/etc/xml/catalog

The file created at /etc/xml/catalog should then look something like:

<?xml version="1.0"?>
<!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
 <rewriteURI uriStartString="http://schemas.xmlsoap.org/soap/envelope/" rewritePrefix="file:///etc/xml/soap_1.1_envelope.xsd"/>
</catalog>

4. Restart apache

Your schema validation should be quick as a flash after that.

* You can change this default location by setting the XML_CATALOG_FILES environment variable.