replacement for firephp (devtools)

[Erik Krause]

Hello,

classical firebug is close to it's end and firephp for devtools is not
in sight. Is there an alternative providing server side logging?

According to
> https://developer.mozilla.org/en-US/docs/Tools/Web_Console/Console_messages#Server
chromephp should be possible to use. Any experience?

--
Erik Krause
http://www.erik-krause.de

[Jan Honza Odvarko]

On Thursday, September 29, 2016 at 7:05:09 PM UTC+2, Erik Krause wrote:

Hello,

classical firebug is close to it's end and firephp for devtools is not
in sight. Is there an alternative providing server side logging?

According to
> https://developer.mozilla.org/en-US/docs/Tools/Web_Console/Console_messages#Server
chromephp should be possible to use. Any experience?

Yes, server side logging is supported directly by Firefox DevTools
You can use server side lib listed here:
https://craig.is/writing/chrome-logger

... send logs over HTTP down the to browser, enable 'Server' filter in the Console panel and see the logs.

Honza

[Lawrence San]

In other words, you install the server library... but even though it's meant to accompany the Chrome extension, you don't need any extension for it in Firefox?

Or, if I misunderstood... is there some way of installing a Chrome extension into Firefox now?

--
You received this message because you are subscribed to the Google Groups "Firebug" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebug+unsubscribe@googlegroups.com.
To post to this group, send email to fir...@googlegroups.com.
Visit this group at https://groups.google.com/group/firebug.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebug/1dfc85ef-438a-40a8-b0bc-6354b813d022%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Erik Krause]

Am 30.09.2016 um 13:45 schrieb Jan Honza Odvarko:

> You can use server side lib listed here:
> https://craig.is/writing/chrome-logger

Hmm. There seems to be no active development either. No contributions
since 3 years. And the library is pretty inconvenient compared to
FirePHP. No global disable f.e. Any active users here? Any experience?

[Jan Honza Odvarko]

On Saturday, October 1, 2016 at 4:24:24 AM UTC+2, San wrote:

In other words, you install the server library... but even though it's meant to accompany the Chrome extension, you don't need any extension for it in Firefox?

Correct, no extension needed in Firefox.

Honza
 

[Jan Honza Odvarko]

On Saturday, October 1, 2016 at 9:17:20 PM UTC+2, Erik Krause wrote:

Am 30.09.2016 um 13:45 schrieb Jan Honza Odvarko:

> You can use server side lib listed here:
> https://craig.is/writing/chrome-logger

Hmm. There seems to be no active development either. No contributions
since 3 years. And the library is pretty inconvenient compared to
FirePHP. No global disable f.e. Any active users here? Any experience?

Only the Chrome logger protocol is supported at this moment.

Honza

 

[Erik Krause]

Am 01.10.2016 um 21:17 schrieb Erik Krause:
> Hmm. There seems to be no active development either. No contributions
> since 3 years. And the library is pretty inconvenient compared to
> FirePHP. No global disable f.e.

Well, I've modified ChromePHP, added global enable / disable and changed
the arguments order to be compatible with FirePHP. This functionality
must be switched on, so ChromePHP original functionality is not
toouched. PM me if you want it...

[alfonsoml]

Wouldn't it be better if you contact the ChromePHP maintainers and add that functionality there, so it's available for everyone?

[Erik Krause]

Am 06.12.2016 um 12:50 schrieb alfonsoml:
> Wouldn't it be better if you contact the ChromePHP maintainers and add that
> functionality there, so it's available for everyone?

I did. Or rather: I followed the usual procedure for open source
software and added to the project. There is an ongoing pull request, but
you can find my version on https://github.com/ErikKrause/chromephp

[Lawrence San]

Erik, what you did is probably much better than what I'm using at the moment, and I'll take a look at your version soon. But for what it's worth, I'm using an extremely simple script to temporarily substitute for FirePHP (which I was using before). This isn't really my code; I just simplified/adapted it from someone else's posted elsewhere:

function phpToConsole( $data ) {

    ob_start();

    $output = 'console.log(' . json_encode( $data ) . ');';

    $output  = sprintf( '<script>%s</script>', $output );

    echo $output;

}

​I call it (i.e. log something to the Consol​e) simply like this:

     phpToConsole( "[PHP] My log message including $myVariable goes here." );

I keep the phpToConsole script in a separate file, and pull it in with a require_once in every other PHP file, but the script is so short it could simply be placed at the top of every file that needs it.

Almost featureless, but it's dead simple and works for now.

Lawrence

[Erik Krause]

Am 06.12.2016 um 22:50 schrieb Lawrence San:
> I'm using an extremely simple script to temporarily substitute for FirePHP
> (which I was using before).

Well, keep it small and simple ;-) Very nice!

What I liked most about FirePHP was the global disable. That's what I
added to ChromePhp. And the optional possibility to reuse olf firePHP
calls (which I have hundreds in my projects and don't want to replace
them all).

[Erik Krause]

Am 06.12.2016 um 21:51 schrieb Erik Krause:
> I did. Or rather: I followed the usual procedure for open source
> software and added to the project. There is an ongoing pull request, but
> you can find my version on https://github.com/ErikKrause/chromephp

Yesterday I wondered why some calls caused an empty log. I soon
discovered that json_encode doesn't handle resources. So I added a
special handling for resources and output all other types with print_r,
which should account for most other special cases. See above link for
the updated version.

[Lawrence San]

Erik Krause <erik....@gmx.de> wrote:

Yesterday I wondered why some calls caused an empty log. I soon discovered that json_encode doesn't handle resources. So I added a special handling for resources and output all other types with print_r, which should account for most other special cases.

​Interesting; I didn't know json_encode had that limitation, but then I'm only a fairly basic PHP coder. The only "resources" (externals) I've ever called were a few file handles. I just found the official PHP List of Resource Types, and I never even heard of most of them. In fact the list is incomprehensible to me -- no explanation of what anything means -- and even clicking to go to one resource type's own manual page is still incomprehensible. (For example, I have no idea what cubrid lob2 is, and when I click further its page says "Create a lob object." Gee, thanks for clearing that up, guys.)

Anyway, did FirePHP handle resources (little pun there) OK?

[Erik Krause]

Am 18.12.2016 um 18:36 schrieb Lawrence San:
> ​Interesting; I didn't know json_encode had that limitation, but then I'm
> only a fairly basic PHP coder. The only "resources" (externals) I've ever
> called were a few file handles. I just found the official PHP List of

> Resource Types <http://php.net/manual/en/resource.php>, and I never even

> heard of most of them.

Me neither :-)

> In fact the list is incomprehensible to me -- no
> explanation of what anything means -- and even clicking to go to one
> resource type's own manual page is still incomprehensible. (For example, I

> have no idea what *cubrid lob2* is, and when I click further its page

> says "Create a lob object." Gee, thanks for clearing that up, guys.)

Well, a LOB is a Large OBject (often in a database) and if you'd use
CUBRID, you probably knew what it is like you know how to use
mysql_connect or imagecreate. Both create a resource.

> Anyway, did FirePHP handle resources (little pun there) OK?

Yes, that's why I found the problem. I always sent database resources
via FirePhp to the console...