php-general Digest 1 Sep 2010 20:20:02 -0000 Issue 6921
Topics (messages 307795 through 307817):
Re: Looking for open source Learning Management System suggestions
307795 by: Michael Shadle
307796 by: Richard S. Crawford
require_once
307797 by: David Mehler
307798 by: Peter Lind
Backtrace in fatal error?
307799 by: Paul Freeman
307800 by: Paul Freeman
307801 by: Simon J Welsh
307802 by: Richard Quadling
307803 by: freeman3.centrum.cz
307804 by: Richard Quadling
json_encode() behavior and the browser
307805 by: Christoph Boget
307806 by: João Cândido de Souza Neto
307807 by: João Cândido de Souza Neto
307808 by: João Cândido de Souza Neto
307809 by: Christoph Boget
307810 by: Christoph Boget
307811 by: João Cândido de Souza Neto
307812 by: Christoph Boget
307813 by: João Cândido de Souza Neto
307814 by: João Cândido de Souza Neto
307815 by: Christoph Boget
307816 by: João Cândido de Souza Neto
'dl() is deprecated' Error in PHP5.2.3
307817 by: Bruce Bailey
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Aug 31, 2010, at 7:53 PM, Bastien Koert <phps...@gmail.com> wrote:
>>
>>
> Our company built one on top of wordpress. You can easily build most
> of it with stock plugins and it has UIs for idevices...worth
> considering
Yeah - obviously anything can be built and a lot of things can be extended...
But were on a tight deadline for the first pass and would like something a
little more out of the box (ideally)
--- End Message ---
--- Begin Message ---
I'm late to this thread, so I don't know what's been mentioned here already.
However, I'd be remiss if I did not recommend Moodle (http://www.moodle.org)
as an open-source learning management system. The learning curve is a bit
steep, especially if you're going to mess around in the code, but it's
powerful and flexible.
On Tue, Aug 31, 2010 at 8:57 PM, Michael Shadle <mike...@gmail.com> wrote:
>
>
> On Aug 31, 2010, at 7:53 PM, Bastien Koert <phps...@gmail.com> wrote:
>
> >>
> >>
> > Our company built one on top of wordpress. You can easily build most
> > of it with stock plugins and it has UIs for idevices...worth
> > considering
>
> Yeah - obviously anything can be built and a lot of things can be
> extended... But were on a tight deadline for the first pass and would like
> something a little more out of the box (ideally)
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Sláinte,
Richard S. Crawford (rich...@underpope.com)
http://www.underpope.com
Publisher and Editor in Chief, Daikaijuzine (http://www.daikaijuzine.com)
--- End Message ---
--- Begin Message ---
Hello,
I've got probably a simple question on require_once. I've got a file
that has require_once at the top of it pulling in another file of
functions. Later on in this file I've got another require_once
bringing in a second file. In this second file I have a function call
to a function defined in the first files' top require_once functions
file. I'm getting a call to undefined function.
Should I change he require_once to require at the top of the first
file to fix? I thought require_once meant it was in that file and
anything pulled in later?
Thanks.
Dave.
--- End Message ---
--- Begin Message ---
On 1 September 2010 08:00, David Mehler <dave.meh...@gmail.com> wrote:
> Hello,
> I've got probably a simple question on require_once. I've got a file
> that has require_once at the top of it pulling in another file of
> functions. Later on in this file I've got another require_once
> bringing in a second file. In this second file I have a function call
> to a function defined in the first files' top require_once functions
> file. I'm getting a call to undefined function.
> Should I change he require_once to require at the top of the first
> file to fix? I thought require_once meant it was in that file and
> anything pulled in later?
> Thanks.
> Dave.
The file is included properly, otherwise your script would halt.
You're likely looking at an issue of scope: the functions might be
included in a scope you don't expect them to be.
Regards
Peter
--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>
--- End Message ---
--- Begin Message ---
When fatal error occurs is it possible to output also the backtrace in the
error log? The simple error message with file line
only is quite useless...
--- End Message ---
--- Begin Message ---
When fatal error occurs is it possible to output also the backtrace in the
error log? The simple error message with file line
only is quite useless...
--- End Message ---
--- Begin Message ---
I think you need a PHP extension to do this. XDebug works rather nicely for
this.
On 31/08/2010, at 8:49 PM, Paul Freeman wrote:
> When fatal error occurs is it possible to output also the backtrace in the
> error log? The simple error message with file line
> only is quite useless...
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
---
Simon Welsh
Admin of http://simon.geek.nz/
Who said Microsoft never created a bug-free program? The blue screen never,
ever crashes!
http://www.thinkgeek.com/brain/gimme.cgi?wid=81d520e5e
--- End Message ---
--- Begin Message ---
On 31 August 2010 09:49, Paul Freeman <freem...@centrum.cz> wrote:
> When fatal error occurs is it possible to output also the backtrace in the
> error log? The simple error message with file line
> only is quite useless...
<?php
namespace baz;
set_error_handler(
function($ErrNo, $ErrStr, $ErrFile, $ErrLine, $ErrContext){
echo 'An error occurred.', PHP_EOL;
var_export(debug_backtrace(true));
// Allow PHP to continue executing.
return false;
},
-1
);
register_shutdown_function(
function(){
echo 'We died a terrible death.';
var_export(debug_backtrace(true));
}
);
function bar() {
echo 'In ', __FUNCTION__, PHP_EOL;
echo 1 / 0; // Divide by zero warning.
foo();
}
function foo() {
echo 'In ', __FUNCTION__, PHP_EOL;
$a = \SNAFU; // Fatal error
}
bar();
?>
outputs ...
In baz\bar
An error occurred.
array (
0 =>
array (
'file' => 'Z:\\bad.php',
'line' => 24,
'function' => 'baz\\{closure}',
'args' =>
array (
0 => 2,
1 => 'Division by zero',
2 => 'Z:\\bad.php',
3 => 24,
4 =>
array (
),
),
),
1 =>
array (
'file' => 'Z:\\bad.php',
'line' => 33,
'function' => 'baz\\bar',
'args' =>
array (
),
),
)
Warning: Division by zero in Z:\bad.php on line 24
In baz\foo
Fatal error: Undefined constant 'SNAFU' in Z:\bad.php on line 30
We died a terrible death.array (
0 =>
array (
'function' => 'baz\\{closure}',
'args' =>
array (
),
),
)
So, it looks like extension or a core mod only.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
Thanks!
I didn't notice the register_shutdown_function function.
But it executes always I want to run it only to track fatal error. Also I
can't get the backtrace properly:( I can't use 5.3 so I guess it works
differently in 5.2
Richard Quadling wrote:
> On 31 August 2010 09:49, Paul Freeman <freem...@centrum.cz> wrote:
>> When fatal error occurs is it possible to output also the backtrace in
>> the error log? The simple error message with file line only is quite
>> useless...
>
> <?php
> namespace baz;
>
> set_error_handler(
> function($ErrNo, $ErrStr, $ErrFile, $ErrLine, $ErrContext){
> echo 'An error occurred.', PHP_EOL;
> var_export(debug_backtrace(true));
>
> // Allow PHP to continue executing.
> return false;
> },
> -1
> );
>
> register_shutdown_function(
> function(){
> echo 'We died a terrible death.';
> var_export(debug_backtrace(true));
> }
> );
>
> function bar() {
> echo 'In ', __FUNCTION__, PHP_EOL;
> echo 1 / 0; // Divide by zero warning.
> foo();
> }
>
> function foo() {
> echo 'In ', __FUNCTION__, PHP_EOL;
> $a = \SNAFU; // Fatal error
> }
>
> bar();
> ?>
> outputs ...
>
> In baz\bar
> An error occurred.
> array (
> 0 =>
> array (
> 'file' => 'Z:\\bad.php',
> 'line' => 24,
> 'function' => 'baz\\{closure}',
> 'args' =>
> array (
> 0 => 2,
> 1 => 'Division by zero',
> 2 => 'Z:\\bad.php',
> 3 => 24,
> 4 =>
> array (
> ),
> ),
> ),
> 1 =>
> array (
> 'file' => 'Z:\\bad.php',
> 'line' => 33,
> 'function' => 'baz\\bar',
> 'args' =>
> array (
> ),
> ),
> )
> Warning: Division by zero in Z:\bad.php on line 24
> In baz\foo
>
> Fatal error: Undefined constant 'SNAFU' in Z:\bad.php on line 30
> We died a terrible death.array (
> 0 =>
> array (
> 'function' => 'baz\\{closure}',
> 'args' =>
> array (
> ),
> ),
> )
>
> So, it looks like extension or a core mod only.
>
--- End Message ---
--- Begin Message ---
On 1 September 2010 13:38, <freem...@centrum.cz> wrote:
> Thanks!
> I didn't notice the register_shutdown_function function.
> But it executes always I want to run it only to track fatal error. Also I
> can't get the backtrace properly:( I can't use 5.3 so I guess it works
> differently in 5.2
>
> Richard Quadling wrote:
>
>> On 31 August 2010 09:49, Paul Freeman <freem...@centrum.cz> wrote:
>>> When fatal error occurs is it possible to output also the backtrace in
>>> the error log? The simple error message with file line only is quite
>>> useless...
>>
>> <?php
>> namespace baz;
>>
>> set_error_handler(
>> function($ErrNo, $ErrStr, $ErrFile, $ErrLine, $ErrContext){
>> echo 'An error occurred.', PHP_EOL;
>> var_export(debug_backtrace(true));
>>
>> // Allow PHP to continue executing.
>> return false;
>> },
>> -1
>> );
>>
>> register_shutdown_function(
>> function(){
>> echo 'We died a terrible death.';
>> var_export(debug_backtrace(true));
>> }
>> );
>>
>> function bar() {
>> echo 'In ', __FUNCTION__, PHP_EOL;
>> echo 1 / 0; // Divide by zero warning.
>> foo();
>> }
>>
>> function foo() {
>> echo 'In ', __FUNCTION__, PHP_EOL;
>> $a = \SNAFU; // Fatal error
>> }
>>
>> bar();
>> ?>
>> outputs ...
>>
>> In baz\bar
>> An error occurred.
>> array (
>> 0 =>
>> array (
>> 'file' => 'Z:\\bad.php',
>> 'line' => 24,
>> 'function' => 'baz\\{closure}',
>> 'args' =>
>> array (
>> 0 => 2,
>> 1 => 'Division by zero',
>> 2 => 'Z:\\bad.php',
>> 3 => 24,
>> 4 =>
>> array (
>> ),
>> ),
>> ),
>> 1 =>
>> array (
>> 'file' => 'Z:\\bad.php',
>> 'line' => 33,
>> 'function' => 'baz\\bar',
>> 'args' =>
>> array (
>> ),
>> ),
>> )
>> Warning: Division by zero in Z:\bad.php on line 24
>> In baz\foo
>>
>> Fatal error: Undefined constant 'SNAFU' in Z:\bad.php on line 30
>> We died a terrible death.array (
>> 0 =>
>> array (
>> 'function' => 'baz\\{closure}',
>> 'args' =>
>> array (
>> ),
>> ),
>> )
>>
>> So, it looks like extension or a core mod only.
>>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
No. I think you've missed the point. Neither set_error_handler() or
register_shutdown_function() report the fatal stack.
This would need to be in an extension or a mod to the core code.
Userland code can't access it.
The stack trace shown in the shutdown function is just the shutdown
function, not why there is a shutdown.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
I'm curious if the behavior of json_encode() is influenced by the
browser at all. I have a page that returns search results. If I
access the page and perform a search using Chrome, the following error
shows up in the log:
PHP Warning: json_encode() [<a
href='function.json-encode'>function.json-encode</a>]: Invalid UTF-8
sequence in argument in [PAGE] on line [LINE]
If I access the page and perform a search, the exact same search using
the exact same parameters, using Firefox then I get the expected
results. When I var_dump() the return value of json_encode(), I see
that it is a null in the case where I accessed using chrome but the
expected string in the case where I accessed using firefox. In both
cases, the input array is identical.
Given the identical input and different output, the only thing I can
figure is that the headers sent to the server as part of the request
figure in to how json_encode() behaves. Is that the case? Or am I
barking up the wrong tree?
To be clear, I'm not talking about how the browser ultimately handles
the json encoded data. I know there can be issues with that. I'm
talking about the process before the data is even shipped to the
browser -- about how json_encode() behaves when executed as part of
the PHP script.
thnx,
Christoph
--- End Message ---
--- Begin Message ---
It can have something to do with your browser codification (UTF8,
ISO-8859-???).
--
João Cândido de Souza Neto
"Christoph Boget" <cbo...@hotmail.com> escreveu na mensagem
news:aanlkti=45-heto2myhq116gv6bfxvdba_yxfzjnqk...@mail.gmail.com...
> I'm curious if the behavior of json_encode() is influenced by the
> browser at all. I have a page that returns search results. If I
> access the page and perform a search using Chrome, the following error
> shows up in the log:
>
> PHP Warning: json_encode() [<a
> href='function.json-encode'>function.json-encode</a>]: Invalid UTF-8
> sequence in argument in [PAGE] on line [LINE]
>
> If I access the page and perform a search, the exact same search using
> the exact same parameters, using Firefox then I get the expected
> results. When I var_dump() the return value of json_encode(), I see
> that it is a null in the case where I accessed using chrome but the
> expected string in the case where I accessed using firefox. In both
> cases, the input array is identical.
>
> Given the identical input and different output, the only thing I can
> figure is that the headers sent to the server as part of the request
> figure in to how json_encode() behaves. Is that the case? Or am I
> barking up the wrong tree?
>
> To be clear, I'm not talking about how the browser ultimately handles
> the json encoded data. I know there can be issues with that. I'm
> talking about the process before the data is even shipped to the
> browser -- about how json_encode() behaves when executed as part of
> the PHP script.
>
> thnx,
> Christoph
--- End Message ---
--- Begin Message ---
You should set the charset of your page by meta tag in its head.
2010/9/1 Christoph Boget <christoph.bo...@gmail.com>
> > It can have something to do with your browser codification (UTF8,
> > ISO-8859-???).
>
> But why would that be the case? Is json_encode() actually encoding
> the string differently in each case? And would it encode it
> differently if I wrote a script to take the same input and ran it from
> the command line?
>
> Is there a way I can get around this on the back end? Make it so that
> it'll behave the same in all cases?
>
> thnx,
> Christoph
>
--
João Cândido de Souza Neto
--- End Message ---
--- Begin Message ---
You should set the charset of your page by meta tag in its head.
2010/9/1 Christoph Boget <christoph.bo...@gmail.com>
> > It can have something to do with your browser codification (UTF8,
> > ISO-8859-???).
>
> But why would that be the case? Is json_encode() actually encoding
> the string differently in each case? And would it encode it
> differently if I wrote a script to take the same input and ran it from
> the command line?
>
> Is there a way I can get around this on the back end? Make it so that
> it'll behave the same in all cases?
>
> thnx,
> Christoph
>
--
João Cândido de Souza Neto
--- End Message ---
--- Begin Message ---
> It can have something to do with your browser codification (UTF8,
> ISO-8859-???).
But why would that be the case? Is json_encode() actually encoding
the string differently in each case? And would it encode it
differently if I wrote a script to take the same input and ran it from
the command line?
Is there a way I can get around this on the back end? Make it so that
it'll behave the same in all cases?
thnx,
Christoph
--- End Message ---
--- Begin Message ---
> You should set the charset of your page by meta tag in its head.
Do you have a source of reference to which you point me?
thnx,
Christoph
--- End Message ---
--- Begin Message ---
http://www.w3.org/TR/html4/charset.html
I hope it can help you.
PS: json_decode works only in utf8.
--
João Cândido de Souza Neto
"Christoph Boget" <cbo...@hotmail.com> escreveu na mensagem
news:aanlktikpqdckrq7ctjwccgspz-c4fxpcnxxn_u48+...@mail.gmail.com...
>> You should set the charset of your page by meta tag in its head.
>
> Do you have a source of reference to which you point me?
>
> thnx,
> Christoph
--- End Message ---
--- Begin Message ---
> http://www.w3.org/TR/html4/charset.html
> I hope it can help you.
> PS: json_decode works only in utf8.
I understand charsets. I understand the difference between the
charsets. What I don't understand is how json_encode() is taking the
*exact same input* and behaving differently (breaking in one case,
working in another) depending on the browser being used. And taking
your statement that json_encode() works only in utf-8 as a given, how
can I guard against the different behaviors on the backend, where
json_encode() is getting executed. Should I do some kind of header
sniffing prior to every call to json_encode() and massage the data
accordingly depending on what I find? That seems somewhat excessive.
But based on what you are saying and based on what I'm witnessing, it
seems like there is no other way around that.
thnx,
Christoph
--- End Message ---
--- Begin Message ---
Are you setting the charset in your html head?
If not, its using the charset set in your browser, which can be different
from one to another.
In this case, you must set if via meta tag to avoid it.
--
João Cândido de Souza Neto
"Christoph Boget" <cbo...@hotmail.com> escreveu na mensagem
news:aanlktimbfbgunifhthztp+2jnhzgmo8uqvwydq4vd...@mail.gmail.com...
>> http://www.w3.org/TR/html4/charset.html
>> I hope it can help you.
>> PS: json_decode works only in utf8.
>
> I understand charsets. I understand the difference between the
> charsets. What I don't understand is how json_encode() is taking the
> *exact same input* and behaving differently (breaking in one case,
> working in another) depending on the browser being used. And taking
> your statement that json_encode() works only in utf-8 as a given, how
> can I guard against the different behaviors on the backend, where
> json_encode() is getting executed. Should I do some kind of header
> sniffing prior to every call to json_encode() and massage the data
> accordingly depending on what I find? That seems somewhat excessive.
> But based on what you are saying and based on what I'm witnessing, it
> seems like there is no other way around that.
>
> thnx,
> Christoph
--- End Message ---
--- Begin Message ---
Sorry about the error:
In this case, you must set IT via meta tag to avoid it.
--
João Cândido de Souza Neto
""João Cândido de Souza Neto"" <j...@consultorweb.cnt.br> escreveu na
mensagem news:16.27.07419.e0e5e...@pb1.pair.com...
> Are you setting the charset in your html head?
>
> If not, its using the charset set in your browser, which can be different
> from one to another.
>
> In this case, you must set if via meta tag to avoid it.
>
> --
> João Cândido de Souza Neto
>
> "Christoph Boget" <cbo...@hotmail.com> escreveu na mensagem
> news:aanlktimbfbgunifhthztp+2jnhzgmo8uqvwydq4vd...@mail.gmail.com...
>>> http://www.w3.org/TR/html4/charset.html
>>> I hope it can help you.
>>> PS: json_decode works only in utf8.
>>
>> I understand charsets. I understand the difference between the
>> charsets. What I don't understand is how json_encode() is taking the
>> *exact same input* and behaving differently (breaking in one case,
>> working in another) depending on the browser being used. And taking
>> your statement that json_encode() works only in utf-8 as a given, how
>> can I guard against the different behaviors on the backend, where
>> json_encode() is getting executed. Should I do some kind of header
>> sniffing prior to every call to json_encode() and massage the data
>> accordingly depending on what I find? That seems somewhat excessive.
>> But based on what you are saying and based on what I'm witnessing, it
>> seems like there is no other way around that.
>>
>> thnx,
>> Christoph
>
>
--- End Message ---
--- Begin Message ---
> Sorry about the error:
> In this case, you must set IT via meta tag to avoid it.
Ok, let's try this using a different approach. Consider the following
pseudo-code:
<?php
$result = mysql_query( 'SELECT name, date FROM table WHERE field = "value"' );
$array = array();
while( $row = mysql_fetch_assoc( $result ))
{
$array[] = $row;
}
$string = json_encode( $array );
?>
Why does the charset of the browser matter one whit to the value of
either $row['name'] or $row['date'] such that it would break
json_encode() in one case and not the other. Is it that PHP is taking
the string which is returned as part of the result set and encoding it
to match the charset passed in from the browser?
thnx,
Christoph
* Disclaimer : the actual code (and data repository) I am using is
slightly different from the above but is similar enough so that it's a
valid representation
--- End Message ---
--- Begin Message ---
In this case, you are right. It has nothing to do with the browser.
You´ll need a more detailed debug so you can see excatly what´s happening.
--
João Cândido de Souza Neto
"Christoph Boget" <cbo...@hotmail.com> escreveu na mensagem
news:aanlktikctht0nxz1hi0ezj=i2m3716wepd=deppke...@mail.gmail.com...
>> Sorry about the error:
>> In this case, you must set IT via meta tag to avoid it.
>
> Ok, let's try this using a different approach. Consider the following
> pseudo-code:
>
> <?php
> $result = mysql_query( 'SELECT name, date FROM table WHERE field =
> "value"' );
> $array = array();
> while( $row = mysql_fetch_assoc( $result ))
> {
> $array[] = $row;
> }
>
> $string = json_encode( $array );
> ?>
>
> Why does the charset of the browser matter one whit to the value of
> either $row['name'] or $row['date'] such that it would break
> json_encode() in one case and not the other. Is it that PHP is taking
> the string which is returned as part of the result set and encoding it
> to match the charset passed in from the browser?
>
> thnx,
> Christoph
>
> * Disclaimer : the actual code (and data repository) I am using is
> slightly different from the above but is similar enough so that it's a
> valid representation
--- End Message ---
--- Begin Message ---
Hi
Can someone explain to me why I'm getting the 'dl() is deprecated' error?
I'm running PHP5.2.3 and I believe that I have the php.ini settings correct:
error.log:[2010-08-24T13:38:53] <b>PC Error</b>: dl()
[function.dl]: dl() is deprecated - use extension=test.so in your
php.ini
bash-2.05b$ php --version
PHP 5.2.3 (cli) (built: May 4 2009 16:23:02)
bash-2.05b$ php -i | grep -i safe
Thread Safety => disabled
safe_mode => Off => Off
safe_mode_exec_dir => no value => no value
safe_mode_gid => Off => Off
safe_mode_include_dir => no value => no value
sql.safe_mode => Off => Off
bash-2.05b$ php -i | grep -i dl
enable_dl => On => On
I thought that 'dl' wasn't deprecated until version 5.3.x
Thanks in advance,
Bruce
--- End Message ---
