PHP agent release notesRSS

New Features

• WordPress tab in the New Relic UI

  We're pleased to announce a new UI tab just for WordPress-specific data! WordPress applications now show information about their hooks, plugins, and themes.

  For more information, see WordPress-specific functionality.

New Features

• On Linux, abstract sockets are now supported for agent to daemon communication. An abstract socket can be created by prefixing the value of the port setting in your newrelic.ini file (e.g. newrelic.daemon.port = "@newrelic-daemon") or newrelic.cfg file (e.g. port = "@newrelic-daemon").
• The daemon can now be passed a --define <setting>=<value> flag that allows setting arbitrary parameters from your newrelic.cfg file. These parameters will take precedence over settings from that file.
• Drupal 8 requests that are successful full page cache hits for anonymous users (handled by Drupal\page_cache\StackMiddleware\PageCache) are now given the name WebTransaction/Action/page_cache.
• Support for automatically naming transactions has been added for Symfony 2.8 and 3.0.
• Support for automatically naming transactions has been added for MediaWiki 1.18.0 and newer.

Upgrade Notices

• It is now possible to disable reporting of errors for exceptions that are handled by an exception handler installed with set_exception_handler() by enabling the newrelic.error_collector.ignore_user_exception_handler setting.
• Calls to newrelic_notice_error with improper parameters will no longer record an error with the message "?". Instead, no error will be recorded. newrelic_notice_error will now return true if an error is saved, null if the arguments are invalid, and false otherwise. If newrelic_notice_error is called with two parameters and the second parameter is not a valid exception, no error will be recorded: The first parameter is now entirely unused.

Bug Fixes

• On Redhat Enterprise Linux 7 and related systems such as CentOS and Fedora, the systemctl start|stop newrelic-daemon commands were not working due to a bug in the newrelic-daemon init script when executed by systemd. This has been fixed.
• On some Linux systems, an SELinux policy could prevent the newrelic-daemon from determining the correct hostname. Affected systems were unable to report data because a valid hostname is required by New Relic. This has been fixed. This issue could also prevent the newrelic-daemon from determining the correct hostname when running in a chrooted environment, or any environment in which access to the /proc filesystem is limited.
• Detection of Zend Framework 2.5 and later was unreliable when the framework was installed via Composer. This has been fixed.
• Detection of Laravel 5.1 and later was unreliable when artisan optimize was used. This has been fixed.
• The agent now sends the attribute request.headers.contentLength as an integer rather than a string.

New Features

With this release, the agent reports TransactionError events. These new events power the beta feature Advanced Analytics for APM Errors (apply here to participate). The error events are also available through New Relic Insights.

New Features

• To easily distinguish dynamically assigned hosts, users can now assign a display name to a host with the setting newrelic.process_host.display_name.
• The New Relic PHP Agent now supports the latest Production Release of 64-bit FreeBSD, which is currently at 10.2-RELEASE.

Upgrade Notices

• Transactions run under PHP's CLI Web server will now report as Web transactions instead of background transactions. If you want the agent to continue reporting them as background transactions, use the newrelic_background_job() API function to mark the transaction as a background job.

Notes

• The agent now collects the following information in web transactions (not yet shown in the New Relic UI): Accept, Host, Content-Length, and Content-Type HTTP request headers, and HTTP request method.

New Features

• Users can now delete applications from the UI after 20 minutes of inactivity. Previously, this required a restart of the New Relic PHP daemon.

Upgrade Notices

• We rearchitected the daemon to enable future improvements.
• Daemon log levels are now simpler. While verbose and verbosedebug will still work, debug now gives you all the debugging information. Agent log levels remain unchanged.

End of Life Notices

• For the few customers who start the daemon manually, the newly renamed command-line flags can be found with the -h or --help flags. The following old flags will be removed in a future release:
  • [-p pidfile]
  • [-d level]
  • [-c config]
  • [-l logfile]
  • [-P port]
  • [-s]
  • [-n]
  • [-b SSL-certificate-bundle]
  • [-S SSL-certificate-path]
  • [-H host]
  • [-x proxy]
  • [-a auditlog]

Bug Fixes

• A memory leak that could occur when a large number of PDO or mysqli statements were prepared and executed has been fixed.

Bug Fixes

• This release fixes a rare bug where applications that had the ionCube loader enabled and called set_exception_handler() repeatedly could crash.

New Features

• Exceptions that are ignored by Laravel 5's default exception handler will also now be ignored by the PHP agent's error reporting feature. This can be controlled by adding or removing entries in the dontReport property of Laravel's default exception handler, as described in the Laravel documentation.

Bug Fixes

• Under certain circumstances, version 4.23.0 of the PHP agent could crash when newrelic_set_appname() or newrelic_end_transaction() were called and a custom exception handler had been installed via set_exception_handler(). This has been fixed.
• Under certain circumstances, Drupal applications that rely on the newrelic_set_appname() API function to start transactions would not see the Drupal tab in the New Relic UI. This has been fixed.

New Features

• Exceptions that are uncaught and handled only by a last resort exception handler installed via set_exception_handler() will now generate errors that can be viewed in the APM UI. Previously they would not be sent to New Relic at all.

  As a result of this, some customers will see more errors in the APM UI than they had previously seen.

Bug Fixes

• In certain circumstances, such as an exception being thrown during database connection, errors generated by uncaught exceptions could result in the stack trace shown in APM including function argument values, which could potentially expose database passwords and other sensitive information. This problem has been fixed.

  We now catch these formerly-uncaught exceptions and thus have control over how the stack trace is built, ensuring that function argument values will no longer show up in those stack traces.