Skip to content

PHP 5.3.10 and Apache 2.2.22 upgrade #4

merged 10 commits into from Mar 27, 2012

4 participants

tmaher commented Mar 27, 2012

Motivated by some traffic on security@

  • Apache from 2.2.19 to 2.2.22
  • PHP from 5.3.6 to 5.3.10
  • fixed APC (it was built but not enabled)
  • added mcrypt module at compile-time
  • Cut "hello world" slug size from 22MB to 9.5MB (stripped debugging symbols; removed apache docs)
  • Stopped using per-app buildpack CACHE_DIR; should significantly reduce storage overhead
  • switched display_errors from On to Off

The last one is the only thing that I anticipate actually impacting the experience of PHP developers. In the current buildpack, display_errors is On. All errors are sent to stdout (read: the user's
browser). With display_errors Off, they only go into the system. This is normal production practice.

The build artifacts are already in place in the php-lp bucket. If you want to see an example of the new buildpack in action, check out


@pedro pedro was assigned Mar 27, 2012
tmaher commented Mar 27, 2012

Per conversation with @pedro , I cloned the FB PHP template app and tested it on my buildpack. It works fine -

I'm now merging the pull request myself. I'll re-test with a new app once it's live to make sure I haven't broken FB provisioning.

@tmaher tmaher merged commit f902738 into heroku:master Mar 27, 2012

Hi there,
Could you give me detailed instruction?
I'm newbie and really need your help now.
I don't know how to use this. I'm building an app that need GD library. I'm a Windows' user.
How can I use this buildpack?

winglian commented Apr 2, 2012

@pedro Why was this merged in? It doesn't show the steps to recreate the binary so doesn't allow anyone who forks from this point to build a working binary. Also why was support for the cache removed?

tmaher commented Apr 2, 2012

@winglian - This was merged in to upgrade to PHP 5.3.10 and Apache 2.2.22, as well as flip the PHP config display_errors to off (general security best practice and minimizes error spew on the page being displayed).

For the build instructions - #3 (comment) but the conversation might be better tracked in #6 as part of the move to Vulcan

For the cache: It's a little tricky. Buildpack caches are intended to create app-specific persistent artifacts from build to build, and those artifacts for whatever reason don't belong in the git repo itself. For Ruby, you'd use this to have the build system pull in various Ruby gems the app uses and (if necessary) compile shared libraries. For PHP, an obvious use would be to pull in pear/pecl dependencies and stash them there. However, that wasn't how this buildpack was actually using it. Instead, what happened was that the build system was copying the PHP & Apache binaries from the S3 bucket and copying them into the cache, ostensibly to save itself the work from re-downloading them again out of S3. However, in between builds, the cache itself is archived into S3, and then fetched back to the build system. So, there was no actual efficiency improvement, and in fact it winds up creating a bunch of useless copies of the PHP & Apache binaries.

Now, it'd certainly make sense to add some sort of automatic pear/pecl extension fetching system (similar to Ruby's builder), and that'd totally make sense to use the cache. I think we'd welcome a pull request of that nature.

@ryanbrainard ryanbrainard added a commit that referenced this pull request May 4, 2012
@ryanbrainard ryanbrainard Revert "merge pull request #4 into redis branch"
This reverts commit 60929fe, reversing
changes made to f902738.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.