anchor.diff:  
   #### Option #2
   
  -The second option is to pick a different name for the `LIBDIR`.  This is a configuration option that you can set (it defaults to `lib`).  Thus if you set it to something else, like `include` your application's `lib` directory would no longer be treated as a special directory and it would be placed into `WEBDIR` (i.e. become public).
  +The second option is to pick a different name for the `LIBDIR`. This is a configuration option that you can set (it defaults to `lib`). Thus if you set it to something else such as `include`, your application's `lib` directory would no longer be treated as a special directory and it would be placed into `WEBDIR` (i.e. become public).
   
   #### Other Folders
   
  -Beyond the `WEBDIR` and `LIBDIR` directories, the build pack also supports a `.bp-config` directory and a `.extensions` directory.
  +Beyond the `WEBDIR` and `LIBDIR` directories, the buildpack also supports a `.bp-config` directory and a `.extensions` directory.
   
  -The `.bp-config` directory should exist at the root of your project directory and it is the location of application specific configuration files.  Application specific configuration files override the default settings used by the build pack.  This link explains [application configuration files] in depth.
  +The `.bp-config` directory should exist at the root of your project directory and it is the location of application-specific configuration files.  Application-specific configuration files override the default settings used by the buildpack. This link explains [application configuration files] in depth.
   
  -The `.extensions` directory should also exist at the root of your project directory and it is the location of application specific custom extensions.  Application specific custom extensions allow you, the developer, to override or enhance the behavior of the build pack.  This link explains [extensions] in more detail.
  +The `.extensions` directory should also exist at the root of your project directory and it is the location of application-specific custom extensions.  Application-specific custom extensions allow you, the developer, to override or enhance the behavior of the buildpack. This link explains [extensions] in more detail.
   
   ## <a id="troubleshooting"></a>Troubleshooting ##
   
  -There are a couple of easy ways to debug the build pack.
  +There are a couple of easy ways to debug the buildpack:
   
  -  0. Check the output from the build pack.  It writes some basic information to stdout, like the files that are being downloaded.  It writes information should something fail, specifically, stack traces.
  +  0. Check the output from the buildpack.  It writes some basic information to stdout, like the files that are being downloaded.  It writes information should something fail, specifically, stack traces.
   
  -  0. Check the logs from the build pack.  The build pack writes logs to disk. Retrieve them with the `cf files` command.
  +  0. Check the logs from the buildpack.  The buildpack writes logs to disk. Retrieve them with the `cf files` command, as the following example shows:
   
       ```
       cf files <app> app/.bp/logs/bp.log
  
positive.code: -rw-r--r--  1 daniel  staff     0B Feb 27 21:40 my.class.php  <-- not public, http://app.cfapps.io/lib/my.class.php == 404
  ```
  
  This comes with a catch.  If your project legitimately has a `lib` directory, these files will not be publicly available because the build pack does not copy a top-level `lib` directory into the `WEBDIR` folder.  If your project has a `lib` directory that needs to be publicly available then you have two options.
  
  #### Option #1
  
  In your project folder, create an `htdocs` folder (or whatever you've set for `WEBDIR`).  Then move any files that should be publicly accessible into this directory.  In the example below, the `lib/controller.php` file is publicly accessible.
  
  Example:
  
  
negative.code: 
    This log is more detailed than the stdout output, however it is still terse.
  
    0. Set the `BP_DEBUG` environment variable to `true` for more verbose logging. This instructs the buildpack to set its log level to DEBUG and it writes to stdout. Follow [Environment Variables documentation] to set `BP_DEBUG`.
  
  [Environment Variables documentation]:../../devguide/deploy-apps/manifest.html#env-block
  [application configuration files]:./gsg-php-config.html
  [include_path]:http://us1.php.net/manual/en/ini.core.php#ini.include-path
  [extensions]:https://github.com/cloudfoundry/php-buildpack/blob/master/docs/development.md#extensions
  [provide your own Apache or Nginx configurations]:./gsg-php-config.html#engine-configurations
  [configuration option]:./gsg-php-config.html
  