Compiling the extension for PHP 5.3.5 on MediaTemple DV 4

We just enabled the MSSQL extension via FreeTDS on a Media Temple DV 4 VPS. Here’s a line by line of how we did it, borrowing heavily from
, but adding the particulars for the MediaTemple DV and for the particular version of PHP (5.3.5) that we were using:

Make a directory to hold these sources:

cd /
mkdir /source
cd /source

Grab the source of FreeTDS:


tar zxvf freetds-stable.tgz
cd freetds-0.91

./configure –enable-msdblib –prefix=/usr/local/freetds
make && make install

For some reason these files need to be copied over:

cp include/tds.h /usr/local/freetds/include
cp src/tds/.libs/libtds.a /usr/local/freetds/lib

cd /source

Adjust for your desired version of PHP (this example is 5.3.5):

tar xvfz php-5.3.5.tar.gz
cd php-5.3.5

cd ext/mssql
./configure –with-mssql=/usr/local/freetds

Now, when we first ran the make command we had to deal with a type redefinition in

nano /source/php-5.3.5/ext/mssql/php_mssql.h

Copy the extension to the proper directory… You can find out what directory it is with this command:

php -i | grep extension_dir

In our case it was /usr/lib64/php/modules.

cp modules/ /usr/lib64/php/modules

Edit php.ini file (this is the global one):

nano /etc/php.ini


Then restart your web server:

/etc/init.d/httpd restart

Other PHP MSSQL Resources:

Custom Repositories for GitHub Forked Composer packages

So today we had to make a custom repository so that our composer installs could look for custom changes to a particular package that was causing a problem with one of our client’s production applications.

The only current change in this particular package was a solitary “if” statement added to a single line of code. This statement checks to make sure that the object operated on is indeed an object: in certain situations in the production app it throws a fatal exception claiming a “non-object.”

First we had to ask two (rhetorical) questions:

(1) Where do PHP Composer packages come from?


(2) How do you get composer to install a non-composer package?

The first step was to fork the package on GitHub:

The original package is Piotr Śliwa’s excellent:

And the fork lives here:

We looked at simply adding the forked package to Packagist, but although we intend on maintaining this as a “real long-term fork”, that is only if this change or an equivalent fix are not added to the primary package in the near to medium term. Since that seems like an edge case, we were happy to go the VCS route. Satis and Toran Proxy just looked like overkill for this simple implementation.

Once the forking was complete, we cloned the forked package into GitHub for Mac (nice!).

We branched into “missing-object-protection” (the name of the branch will be important later).

We edited the file “lib/PHPPdf/Core/ComplexAttribute/ComplexAttribute.php”, committed the change, and pushed.

Then on to editing composer.json.

We tried to run “composer require” and “composer update” on a development version of the application, after “composer remove” took care of the original psliwa/PHPPdf package. However, we ran into the issue that our newly created PHPPdf branch no longer satisfied the requirements for the PDF Bundle dependencies that was also used by the production app!

Back to GitHub we went, and we forked:


Then we cloned that into the desktop and made a solitary commit to the new fork’s master branch: a single commit updating the requirements in that project’s composer.json.

Then we updated our repositories in our development machine’s composer.json, just after the “require-dev” entry, so it contained entries for both newly forked packages:

    "repositories": {
        "yourcomputergenius/php-pdf": {
            "type": "vcs",
            "url":  ""
        "yourcomputergenius/php-bundle": {
            "type": "vcs",
            "url": ""

We were able to leave the names the same in the “require” section of the composer.json file — one of the beautiful (and maddening) things about composer is the presence of these sorts of conventions. Composer is smart enough to figure out which packages are being replaced by custom repos.

However, we did update the “require” section of composer.json to look for the “dev-missing-object-protection” branch, as below:

        "psliwa/php-pdf": "dev-missing-object-protection"

The long and short of the day is that the application runs “composer update” and successfully grabs those two packages from the forked repos. Hooray!

This post is part of the thread: Software Development – an ongoing story on this site. View the thread timeline for more context on this post.

Why 3rd Party Providers (i.e. Google) for OpenID/OAuth is a bad idea:

Why OAuth 3rd Party Providers are a bad ideaScreenshot 2015-01-07 09.44.01

Both @LucidChart and @SaneBox are using the old methods… and probably many more startups as well!

@LucidChart Why no version numbers insert?

Screenshot 2015-01-05 07.59.01

Screenshot 2015-01-05 07.59.31

Screenshot 2015-01-05 07.59.50


Updates to PHP 5.4 Cause Errors in Pagelines


The error is: Warning: Creating default object from empty value in /wp-content/themes/platform/includes/class.layout.php on line 167


And the solution (turn off displayed errors):


add to wp-config.php
ini_set( ‘display_errors’, 0 );

Somewhere in here there is a way to display 500 Errors in Remote Browsers with II 7.x

Fascinating stuff about what Job Offers tell us about corporate architecture

Getting Excited about Sophos new UTM Offerings


Sophos UTM Offerings

Contact us if you are interested!

Super Cool: The Rise of IO Domains

New Favorite Inexpensive Desktop

We have been recommending these to everyone:

Just don’t buy up the whole stock of them as we have more clients to order them for!