Motivated by some traffic on security@
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
better indicator I'm running arbitrary code during build
up to the new version
rework compile to stop using cache altogether
have apache look at $PORT directly; no runtime conf file mangling
remove orphan comment
Per conversation with @pedro , I cloned the FB PHP template app and tested it on my buildpack. It works fine - https://high-cloud-2320.herokuapp.com/
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.
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?
merge pull request #4 into redis branch
@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?
@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.
Revert "merge pull request #4 into redis branch"
This reverts commit 60929fe, reversing
changes made to f902738.