If your question is not covered below you can get support concerning the FirePHP Server Library here
and the DeveloperCompanion Client Extension here.
General
Where do I get Support, report Bugs and send Feedback?
There are several channels depending on your needs and whether it involves the server library or client extension.
Concerning the FirePHP Server Library specifically
Please see the FirePHP Open Source page.
Concerning the DeveloperCompanion Client Extension
Please see the DeveloperCompanion mailing list: http://groups.google.com/group/devcomp
Private & Confidential
Please contact Christoph Dorn.
Who is behind all this?
Christoph Dorn has been developing FirePHP since 2007. FirePHP,
DeveloperCompanion
and the underlying technology are Christoph's attempt to
make things easier for developers.
Installing FirePHP
Do I need to uninstall the FirePHP Extension to use the DeveloperCompanion Extension?
Yes! You need to disable or uninstall it. DeveloperCompanion is designed
to replace the existing FirePHP Firefox Extension.
How do I upgrade to FirePHP 1.0?
See Upgrading to FirePHP 1.0 proper at Configuration/Traditional.
Is the 1.0 release of the FirePHP Server Library backwards compatible?
Yes. It is 100% backwards compatible and existing code should continue to work without modification.
Traditional Inclusion (DEPRECATED)
If FirePHP 1.0 is included using the FirePHPCore/* files (i.e. the way it has been included in the past), messages will be directed to the
Firebug Console if the FirePHP Firefox Extension or DeveloperCompanion is installed on the client.
require_once('FirePHPCore/FirePHP.class.php'); // or
require_once('FirePHPCore/fb.php');
Please note that if FirePHP 1.0 is included in this way the new security features do NOT take
effect! You are encouraged to upgrade the inclusion method and use
DeveloperCompanion on the client.
New Inclusion (PREFERRED)
If FirePHP 1.0 is included using the FirePHP/* files, messages will be directed to the Firebug Console or
DeveloperCompanion Console if DeveloperCompanion is installed on the client.
This method of inclusion takes full advantage of the new build-in security features. See Install for more information.
require_once('FirePHP/Init.php'); // or
require_once('FirePHP/fb.php');
Make sure you have FirePHP configured and Insight authorized.
See Upgrading to FirePHP 1.0 proper at Configuration/Traditional if you are upgrading
from an older version of FirePHP that uses the FirePHPCore/* files.
It is not working! How do I troubleshoot?
Troubleshooting
How do I add multiple authorization keys on the server?
Multiple authorization keys can be used with any server installation to allow more than one client to access FirePHP.
If using constants
define('INSIGHT_AUTHKEYS', 'client-auth-key-1,client-auth-key-2,...');
If using credentials.json
{
"cadorn.org/insight/@meta/config/0": {
"allow": {
"ips": [
...
],
"authkeys": [
"client-auth-key-1",
"client-auth-key-2",
...
]
}
}
}
See Install and Advanced Configuration for information on the various configuration options.
Integrating & Using FirePHP
How can I set the label/title for a log message? The old way does not work!
This assumes you are using the Insight/Console API.
$console->label('Label')->log('Hello World');
I am using FirePHP with my own logger. How can I get the correct file and line info?
You can either determine the file and line info yourself and set it for each message:
$console->options(array(
'file' => $file
'line' => $line
))->...
or you can instruct FirePHP to adjust the stack trace for all messages with:
$console = $console->option('encoder.trace.offsetAdjustment', 3);
See Insight/Console API for more information.
Why don't I get a new group when I close a group and log to a new one with the same name?
Groups are given names in addition to titles for the express
purpose of being able to log to the same group multiple times throughout the request.
If you want to open a new group every time you can omit the name completely and just call $console->group()->open().
How do I share FirePHP between multiple applications on the same server?
FirePHP is designed to reside with a specific application or in a central place on a server where it is accessible to all
applications. The FirePHP phar or extracted zip archive can be placed anywhere on a server as long as all applications
can include the code with sufficient permissions.
Each hostname (or more specifically application) should have it's own package.json file as it describes the
specific application. It should reside with the application in a source version control system.
Multiple applications may share the same credentials.json file. This file is typically expected to be found next
to the package.json file but can be relocated via a configuration option.
For more information see:
Should I follow the $inspector & $console naming conventions?
Yes, you should follow the naming conventions used in the Insight API reference.
The current naming scheme takes into account planned enhancements to the various APIs and the overall logging,
debugging and development methodology. It is also useful to use consistent names when communicating verbally,
in documentation and on mailing lists.
The naming scheme may undergo some changes over time as the evolving big-picture is better understood.
I am getting a PHP Fatal error: Allowed memory size of 25165824 bytes exhausted! What do I do now?
FirePHP works by encoding logged variables into a JSON-based transport format in order to send it to the client.
The time and resources required to accomplish this are directly proportional to the size of the variables being logged.
When thinking of the size of a variable and specifically an object one must include all object members and their references
as the entire object graph will be traversed.
To make this encoding process practical for larger applications there are certain limits enforced by the encoder that restrict
the depth of traversal in various ways.
There is an article outlining the encoder options here
(see the FirePHP 1.0 heading).
The encoder options are documented in the Insight API reference along with a feature to exclude specific class
members (see Class Member Filters).
There are various optimizations and optional extensions planned to speed up the encoding process and support much
larger object graphs.
Why was fb() changed to p()?
The previous fb() and now p() functions are designed for temporary development and debugging
output and are intended to be removed from the code when done. To leave logging statements in the code use the new
Insight/Console API.
The function name was changed for the following reasons:
fb() implies Firebug which is no longer accurate for FirePHP 1.0 as other logging targets are supported.fb() and p() should not be left in code after dev/debug and this way fb() in code will fail and the developer is
encouraged to convert to using the Insight/Console API. This is a necessary step developers should go through.p() is shorter and closer to the idea of printing a variable.p() has a different method signature and only supports a variable & label.
To continue using fb() in FirePHP 1.0 you can include:
require_once('FirePHP/fb.php');
See FirePHP API for complete information.
For information on how to use p() see here.
How do I get the log messages for a page that issued a HTTP redirect?
All requests are tracked in the Requests Table for a launched Workspace in DeveloperCompanion.
Double-clicking any request will load it into the Companion Request Inspector.
Log messages for a page that issued a HTTP redirect can also be kept in the Firebug Console. The following must be true for this to work:
- The Persist toggle must be activated in the Firebug Console panel.
- Messages must be logged to the
page target. See API/Insight.
How do I stop E_NOTICE errors from showing up in the console with every request?
FirePHP by default captures all errors configured for error_reporting
in the php.ini file even if
display_errors
is turned off.
To turn off E_NOTICE errors you have several options:
Set error_reporting in php.ini to E_ALL & ~E_NOTICE. This will completely disable E_NOTICE errors for all applications.
Disable application wide (for the connected client) using: FirePHP::plugin('firephp')->scope('app')->showErrors(E_NOTICE, false);
Disable url specific (for the connected client) using: FirePHP::plugin('firephp')->scope('url')->showErrors(E_NOTICE, false);
Disable application wide using DeveloperCompanion Application Inspector. Requires license.
Disable url specific using DeveloperCompanion Request Inspector:
A DeveloperCompanion license is required.
Open DeveloperCompanion, launch or select the appropriate Workspace and make sure the Application Inspector is active.
If you see a Request box below the Application box exit the Request Inspector by clicking on the red X to the left.
Using the browser make a request to the URL you wish to remove the errors for. The request should show up in the Requests
table of the Application Inspector. Double-click the request to launch the Request Inspector.
In the Request Inspector locate the on() panel (bottom right) and resize it to fit all content.
Check Insight: Show all PHP Errors (except:) and click Reload at the top of the window in the Request box. This will reload
the request and ask the server to list all error types.
Check E_NOTICE.
These FAQs will move to the DeveloperCompanion site in time.
Do I need Firebug installed to use DeveloperCompanion?
No. DeveloperCompanion will work without Firebug installed however the two tools are integrated
and additional features are available if used together. One such feature is the channeling of log messages to the Firebug Console.
A new Insight panel for Firebug used to activate and deactivate the
new Insight intelligence system.
Ability to inspect requests from the Firebug NET panel.
Why is DeveloperCompanion not hosted on addons.mozilla.org?
The Mozilla Add-ons policy is at odds with the needs and goals of DeveloperCompanion. Among other things, extensions
hosted with Mozilla may not load and execute external JavaScript code and each update must be manually reviewed which
is impractical.
All of Mozilla's extension development and security recommendations and best practices are being followed and taken
very seriously where applicable.
Will there be a standalone version or support for other browsers?
Yes, that is definitely a goal. Implementing the initial tool as a Firefox Extension was the easiest way to get around runtime and installation
issues on various platforms and tight integration with Firebug.
Once the tool stabilizes, the next step is to select an application platform that supports writing applications in HTML + CSS + JavaScript
with full system access and can generate installable programs for various operating systems. The initial standalone version will work
in conjunction with a thin Firefox Extension. Support for other browsers will be added via thin extensions for their respective extension systems.
A thin extension refers to a standardized interface used to interact with the browser and extend the native browser tools. This interface
is needed to obtain the current state of the browser, access content and browser-specific developer tools and various other features.
Various interfaces of this kind are currently being developed by different browser communities that will hopefully result in a common standard over time.
The runtime platform for DeveloperCompanion and all protocols and utility libraries are open source and CommonJS based. If you are interested
in getting involved to expand the support to other browsers please get in touch.
Will other programming languages (other than PHP) be supported?
Yes, that is definitely a goal. The entire tool and all underlying projects, protocols and technologies have been
designed and implemented to be language agnostic. Once the PHP support stabilizes the first additional language
will be JavaScript in the browser and on the server.
There are also plans for Java, Ruby and Python support. The main task in adding support for a language is to implement
two libraries that form the foundation of the logging, encoding and transmission system. These projects are:
Once these infrastructure libraries exist for a language one or more convenience libraries can be developed (in the spirit of FirePHP)
that make using the system in various applications easy. The idea behind having a consistent set of libraries is to standardize an API that works
cross-language where developers can expect a certain amount of functionality and conventions no matter what language they program in.
An overview of what is involved in building a set of libraries can be found here.
If you are interested in working on this feel free to get in touch.
What is the difference between the free DeveloperCompanion and the paid version?
You can find a major feature comparison here: http://developercompanion.com/
The free version will focus on logging to the Firebug Console for now as it is designed to replace the deprecated
FirePHP Extension and work with the new FirePHP 1.0 server library (the sole focus of the FirePHP project going forward).
The paid version will focus on an optimum PHP & JavaScript
development workflow and toolchain setup to make users highly efficient.
The current feature set is just the beginning for the paid version and many more
features are on the way. Feature prioritization will be based on user feedback
and perceived need.
How much does the paid version cost?
The price of the full version is $99 USD. It is a one-time licensing fee with free updates for life. The idea is to develop a tool a developer
purchases once and that stays with them for life. It is always registered to an individual and can be installed on any number of computers used by
that individual throughout their career.
Why is the paid version so cheap given the features it will have?
Christoph has a vision that will take several
levels of tools and services to accomplish.
DeveloperCompanion is just the beginning of a complete toolchain automation platform and the kind of developer tooling
that will be available for all programming languages. A large userbase is required to achieve this.
DeveloperCompanion is the first access point to this open source toolchain automation
platform and priced to achieve a large userbase by keeping the barrier to entry low.
The next level of tooling will be available as a monthly service. It will provide access to a continuous
integration, build, testing and software distribution, monitoring and feedback system that can be used for any PHP and
JavaScript based project. This service will tentatively start at $33 per developer per month + usage fees priced at utility levels.
Beyond this there is a lot more planned in terms of features to enable efficient development at a personal and organizational
level but these aspects are still being formulated.
Using DeveloperCompanion
I don't see any messages. FirePHP::to('request')->console()->log() does not work!
If you have not authorized the hostname or logged messages to the Firebug Console please take a look at
Authorizing.
If FirePHP is setup and the hostname is authorized you need to trigger an inspect for the request data to be loaded
into the Companion Window. This can be done in various ways.
If you are trying to log to the Firebug Console you need to change the following:
$inspector = FirePHP::to('request'); // Logs to Companion Window
// to
$inspector = FirePHP::to('page'); // Logs to Firebug Console
$inspector->console()->log('Hello World');
How do I stop DeveloperCompanion from modifying my User-Agent request header?
By default DeveloperCompanion is backwards compatible with the FirePHPCore server
library. This necessitates modifying the User-Agent request header.
If you have upgraded to FirePHP 1.0 on the server you can switch this backwards compatibility off.
In the Firefox menu go to Tools -> DeveloperCompanion -> Options and uncheck FirePHPCore Compatibility and your
User-Agent header will no longer be modified.
Automatic disabeling of backwards compatibility if FirePHP 1.0 is detected on the server.
How do I get messages to show up in the Companion Window instead of the Firebug Console?
If you are using the Insight API all you need to do is to change
the target from page to request.
$console = FirePHP::to('page')->console(); // Logs to the Firebug Console
$console = FirePHP::to('request')->console(); // Logs to the DeveloperCompanion Window
To load the debug data logged for a request into the companion window (i.e. to inspect it) see
Workflow.
If you are using the FirePHP API as opposed to the new
Insight API you can redirect the messages:
$firephp->setLogToInsightConsole('Firebug'); // or
FB::setLogToInsightConsole('Firebug');
Make sure you have FirePHP properly installed and configured on the server which
has changed from previous releases.
This will log to a console in DeveloperCompanion called Firebug. You can also pass a $console object to redirect messages to.
To load the debug data logged for a request into the companion window (i.e. to inspect it) see
Workflow.
Why are some of my variables truncated?
When variables are sent from the server to the client they must be compacted to limit the amount of data sent. The primary
solution to achieve this is to limit the length of arrays and objects and limit the depth of traversal. The default
limits are set relatively low to ensure the best user experience from the start.
You can increase the limits via the default configuration options or as needed
via the Insight/Console API.
How do I use triggerInspect() or show() and have it not snap the focus to the window? Sometimes I just want it to get the data.
The purpose of triggerInspect() and show()is to bring the logged data to the user's attention immediately after the request has completed.
To inspect requests manually see here.
The data is always sent (even if no inspect is triggered) as long as Insight is activated.
The FirePHP Extension is being phased out in favour of
DeveloperCompanion and later FireConsole.
The FirePHP project will continue and focus on the server library only.
For a more detailed explanation see Clients.
FireConsole is being incubated as part of
DeveloperCompanion and will be released once the underlying open source libraries stabilize.
DeveloperCompanion provides for free all (and more) features FireConsole will initially offer.
For a more detailed explanation see Clients.
