php-general Digest 8 Jan 2010 07:25:00 -0000 Issue 6527
Topics (messages 300889 through 300897):
Re: First time PHP user question
300889 by: Jim Lucas
cannot access SimpleXML object property
300890 by: Mari Masuda
300891 by: Jonathan Tapicer
300892 by: Mari Masuda
Re: PHP programming strategy; lots of little include files, or a few big ones?
300893 by: clancy_1.cybec.com.au
300894 by: clancy_1.cybec.com.au
300896 by: Robert Cummings
300897 by: clancy_1.cybec.com.au
Re: Site Moved From PHP4 to PHP5 Server - header, location no longer working
300895 by: Vernon Webb
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 ---
Ashley Sheridan wrote:
> On Thu, 2010-01-07 at 08:32 -0500, Rick Dwyer wrote:
>
>> Thanks Ashley & Nathan.
>>
>> As it turns out, there is more than one "tmp" folder... and I was
>> looking in the wrong one. When I SSH'd in the correct one, I created
>> the missing file and it began to work properly.
>> Thanks for chiming in.
>>
>> --Rick
>>
>>
>> On Jan 7, 2010, at 7:58 AM, Ashley Sheridan wrote:
>>
>>> On Thu, 2010-01-07 at 09:19 +0000, Nathan Rixham wrote:
>>>> Rick Dwyer wrote:
>>>>> Hello List.
>>>>> I have been playing around with PHP, running a few tutorials and
>>>> I came
>>>>> across an error message I could not resolve.
>>>>>
>>>>> The tutorial is Generating One Time URL's by Oreilly:
>>>>> http://www.oreillynet.com/pub/a/php/2002/12/05/one_time_URLs.html
>>>>>
>>>>> Basically the PHP code is supposed to read from a text file and
>>>> write to
>>>>> a text file and serve a text file all located in the "tmp"
>>>> directory of
>>>>> the server.
>>>>>
>>>>> However, I receive the error that the referenced files in the PHP
>>>> code
>>>>> could not be found:
>>>>> "Warning: readfile(/tmp/secret_file.txt) [function.readfile]:
>>>> failed to
>>>>> open stream: No such file or directory
>>>>> in/home/mysite/myfolder/get_file.php on line 67"
>>>>>
>>>>> Line 66 and 67 look like this:
>>>>>
>>>>> $secretfile = "/tmp/secret_file.txt";
>>>>> readfile($secretfile);
>>>>>
>>>>>
>>>>> However, in the tmp folder, I have created a simple text file
>>>> called
>>>>> "secret_file.txt" so I know it exists and it has the permissions
>>>> set to
>>>>> 644, so it should be readable.
>>>>>
>>>>> Can someone point out to me what I am doing wrong? Thanks,
>>>>>
>>>> try permissions of 777 and see if the error disappears; odds are v
>>>> high
>>>> that the httpd user php is running under doesn't have group or owner
>>>> permissions for /tmp & that secret file.
>>>>
>>>> regards
>>>>
>>>>
>>> That shouldn't fix it. 644 permissions allow the owner, group users
>>> and anybody else to read file. Have you tried is_file("/tmp/
>>> secret_file.txt"); to see if it actually exists? Also, don't forget
>>> that Linux is case sensitive when it comes to filenames, so
>>> secret_file.txt is completely different from Secret_File.txt, and in-
>>> fact you can validly have both in the same directory.
>>>
>>> Thanks,
>>> Ash
>>> http://www.ashleysheridan.co.uk
>>>
>>>
>>
>> --Rick
>>
>>
>>
>
> There isn't more than one /tmp folder, that is impossible. There was
> probably more than one tmp folder, and you weren't looking in the right
> one.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
Actually, Ash, you can have more then one /tmp folder. Depends on what app is
looking at it.
If you have PHP running with Apache and Apache is jailed, the the /tmp folder
would be from the perspective to the jail the the actual OS.
So, if apache was jailed to /var/www/ you could then have a /tmp/ and a
/var/www/tmp/
Apache would never see the /tmp/ only the /var/www/tmp/
--- End Message ---
--- Begin Message ---
Hi,
I am working with an XML document and have a SimpleXML object whose var_dump
looks like this:
---
object(SimpleXMLElement)#2 (10) {
["@attributes"]=>
array(1) {
["id"]=>
string(7) "3854857"
}
["type"]=>
string(7) "Article"
["createDate"]=>
string(25) "2006-09-06T16:42:20-07:00"
["editDate"]=>
string(25) "2007-07-16T09:15:53-07:00"
["creator"]=>
string(19) "Michael Gottfredson"
["status"]=>
string(5) "ready"
["field"]=>
...snip a bunch of stuff...
}
---
Assuming the above object is referenced by $current_object, I can access the
values of most stuff with $current_object->creator or whatever. However, I
cannot figure out how to access the value of id. I tried the following, none
of which worked for me:
1. $current_object->@attributes->id (gives Parse error: syntax error,
unexpected '@', expecting T_STRING or T_VARIABLE or '{' or '$' in
/Applications/apache/htdocs/test.php on line 33)
2. $current_object->'@attributes'->id (gives Parse error: syntax error,
unexpected T_CONSTANT_ENCAPSED_STRING, expecting T_STRING or T_VARIABLE or '{'
or '$' in/Applications/apache/htdocs/test.php on line 33)
3. $current_object->{...@attributes}->id (no error but is null)
4. $current_object->{'@attributes'}->id (no error but is also null)
Does anyone know how I can reference the value of id? Thanks!
Mari
--- End Message ---
--- Begin Message ---
On Thu, Jan 7, 2010 at 6:56 PM, Mari Masuda <mari.mas...@stanford.edu> wrote:
> Hi,
>
> I am working with an XML document and have a SimpleXML object whose var_dump
> looks like this:
>
> ---
> object(SimpleXMLElement)#2 (10) {
> ["@attributes"]=>
> array(1) {
> ["id"]=>
> string(7) "3854857"
> }
> ["type"]=>
> string(7) "Article"
> ["createDate"]=>
> string(25) "2006-09-06T16:42:20-07:00"
> ["editDate"]=>
> string(25) "2007-07-16T09:15:53-07:00"
> ["creator"]=>
> string(19) "Michael Gottfredson"
> ["status"]=>
> string(5) "ready"
> ["field"]=>
> ...snip a bunch of stuff...
> }
> ---
>
> Assuming the above object is referenced by $current_object, I can access the
> values of most stuff with $current_object->creator or whatever. However, I
> cannot figure out how to access the value of id. I tried the following, none
> of which worked for me:
>
> 1. $current_object->@attributes->id (gives Parse error: syntax error,
> unexpected '@', expecting T_STRING or T_VARIABLE or '{' or '$' in
> /Applications/apache/htdocs/test.php on line 33)
>
> 2. $current_object->'@attributes'->id (gives Parse error: syntax error,
> unexpected T_CONSTANT_ENCAPSED_STRING, expecting T_STRING or T_VARIABLE or
> '{' or '$' in/Applications/apache/htdocs/test.php on line 33)
>
> 3. $current_object->{...@attributes}->id (no error but is null)
>
> 4. $current_object->{'@attributes'}->id (no error but is also null)
>
> Does anyone know how I can reference the value of id? Thanks!
>
> Mari
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
$id = (string)$current_object['id'];
--- End Message ---
--- Begin Message ---
On Jan 7, 2010, at 2:31 PM, Jonathan Tapicer wrote:
> On Thu, Jan 7, 2010 at 6:56 PM, Mari Masuda <mari.mas...@stanford.edu> wrote:
>> Hi,
>>
>> I am working with an XML document and have a SimpleXML object whose var_dump
>> looks like this:
>>
>> ---
>> object(SimpleXMLElement)#2 (10) {
>> ["@attributes"]=>
>> array(1) {
>> ["id"]=>
>> string(7) "3854857"
>> }
>> ["type"]=>
>> string(7) "Article"
>> ["createDate"]=>
>> string(25) "2006-09-06T16:42:20-07:00"
>> ["editDate"]=>
>> string(25) "2007-07-16T09:15:53-07:00"
>> ["creator"]=>
>> string(19) "Michael Gottfredson"
>> ["status"]=>
>> string(5) "ready"
>> ["field"]=>
>> ...snip a bunch of stuff...
>> }
>> ---
>>
>> Assuming the above object is referenced by $current_object, I can access the
>> values of most stuff with $current_object->creator or whatever. However, I
>> cannot figure out how to access the value of id. I tried the following,
>> none of which worked for me:
>>
>> 1. $current_object->@attributes->id (gives Parse error: syntax error,
>> unexpected '@', expecting T_STRING or T_VARIABLE or '{' or '$' in
>> /Applications/apache/htdocs/test.php on line 33)
>>
>> 2. $current_object->'@attributes'->id (gives Parse error: syntax error,
>> unexpected T_CONSTANT_ENCAPSED_STRING, expecting T_STRING or T_VARIABLE or
>> '{' or '$' in/Applications/apache/htdocs/test.php on line 33)
>>
>> 3. $current_object->{...@attributes}->id (no error but is null)
>>
>> 4. $current_object->{'@attributes'}->id (no error but is also null)
>>
>> Does anyone know how I can reference the value of id? Thanks!
>>
>> Mari
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> $id = (string)$current_object['id'];
Thank you. I also found I could do it with
$current_object->attributes()->id
--- End Message ---
--- Begin Message ---
On Wed, 6 Jan 2010 19:11:07 -0800, dae...@daevid.com ("Daevid Vincent") wrote:
>
>
>> -----Original Message-----
>> From: Al [mailto:n...@ridersite.org]
>> Sent: Wednesday, January 06, 2010 5:09 PM
>> To: php-gene...@lists.php.net
>> Subject: [PHP] Re: PHP programming strategy; lots of little
>> include files, or a few big ones?
>>
>>
>>
>> On 1/6/2010 7:18 PM, clanc...@cybec.com.au wrote:
>> > I have a flexible program, which can do many different
>> things according to the type of
>> > data it is fed. Ideally the flexibility is achieved by
>> calling different functions,
>> > though when the functionality is ill-defined I sometimes
>> just include blocks of code.
>> >
>> > Ideally, from the point of program maintenance, each module
>> should not be too long --
>> > preferably just a page or so. This doesn't raise problems
>> in a compiled language, but in
>> > an interpreted language like PHP the programmer must decide
>> whether to lump a whole lot of
>> > functions into a single large include file, or to include
>> lots of little files as the
>> > particular functions are needed.
>> >
>> > The first case can lead to memory bloat, as there are
>> likely to be a lot of unused
>> > functions in memory on any given pass, whereas the second
>> case may require lots of little
>> > files to be loaded.
>> >
>> > Are there likely to be significant performance costs for
>> either approach, and what are
>> > your feelings about the relative virtues of the two approaches?
>
>I think it's a case by case basis. Generally File I/O is expensive, but
>then again, as you say, having everything in a couple files is also
>sub-optimal for organizing and keeping things modular.
>
>I suggest you go with smaller files that are organized into logical
>'chunks'. For example, functions that are used frequently are grouped into
>a common.inc.php rather than by topic (such as file/date/xml/forms/etc).
>And then use topical includes for the rest.
>
>More importantly, I suggest you get a good caching system like memecached
>or any of the others out there. Then you can pre-compile and load these
>files and the whole point becomes close to moot.
>
>ÐÆ5ÏÐ
>http://daevid.com
Thank you all for your comments. I did not know about bytecode caches. They're
an
interesting concept, but if I am interpreting the paper
http://itst.net/654-php-on-fire-three-opcode-caches-compared correctly they
only double
the average speed of operation, which is rather less than I would have
anticipated.
As I would have to understand yet another system to implement them, and I
suspect I'd have
to do a significant amount of rearranging, I don't think I will worry about
them unless my
webpages unexpectedly become extremely popular.
Al's suggestion that my code is probably infinitesimal compared with PHP
suggests that I
shouldn't be worrying about memory requirements. On the other hand I agree
with David
that the advantages of using relatively small easy to understand modules
probably outweigh
the costs of loading a larger number of files.
--- End Message ---
--- Begin Message ---
On Wed, 06 Jan 2010 23:20:26 -0500, kolb0...@umn.edu (Daniel Kolbo) wrote:
>Daevid Vincent wrote:
>>
>>
>>> -----Original Message-----
>>> From: Al [mailto:n...@ridersite.org]
>>> Sent: Wednesday, January 06, 2010 5:09 PM
>>> To: php-gene...@lists.php.net
>>> Subject: [PHP] Re: PHP programming strategy; lots of little
>>> include files, or a few big ones?
>>>
>>>
>>>
>>> On 1/6/2010 7:18 PM, clanc...@cybec.com.au wrote:
>>>> I have a flexible program, which can do many different
>>> things according to the type of
>>>> data it is fed. Ideally the flexibility is achieved by
>>> calling different functions,
>>>> though when the functionality is ill-defined I sometimes
>>> just include blocks of code.
>>>> Ideally, from the point of program maintenance, each module
>>> should not be too long --
>>>> preferably just a page or so. This doesn't raise problems
>>> in a compiled language, but in
>>>> an interpreted language like PHP the programmer must decide
>>> whether to lump a whole lot of
>>>> functions into a single large include file, or to include
>>> lots of little files as the
>>>> particular functions are needed.
>>>>
>>>> The first case can lead to memory bloat, as there are
>>> likely to be a lot of unused
>>>> functions in memory on any given pass, whereas the second
>>> case may require lots of little
>>>> files to be loaded.
>>>>
>>>> Are there likely to be significant performance costs for
>>> either approach, and what are
>>>> your feelings about the relative virtues of the two approaches?
>>
>> I think it's a case by case basis. Generally File I/O is expensive, but
>> then again, as you say, having everything in a couple files is also
>> sub-optimal for organizing and keeping things modular.
>>
>> I suggest you go with smaller files that are organized into logical
>> 'chunks'. For example, functions that are used frequently are grouped into
>> a common.inc.php rather than by topic (such as file/date/xml/forms/etc).
>> And then use topical includes for the rest.
>>
>> More importantly, I suggest you get a good caching system like memecached
>> or any of the others out there. Then you can pre-compile and load these
>> files and the whole point becomes close to moot.
>>
>> ÐÆ5ÏÐ
>> http://daevid.com
>>
>> "Some people, when confronted with a problem, think 'I know, I'll use
>> XML.'"
>> Now they have two problems.
>>
>>
>
>I had a similar issue but with classes (not functions).
>I opted to keep my classes short and succinct, rather than shoving all
>the method functionality into one all-purpose class.
>Instead of blindly loading all the little classes on each http request,
>I used (and was recommended on this list to use) __autoload(). The
>script would only load my classes if the individual request needed it.
>This helped to avoid the memory bloat. I've heard magic functions like
>__autoload are a bit slower, but the code is so much cleaner b/c of it.
>
>Also, an opcode cache as suggested previously would facilitate the rapid
>include of many small files.
>
>Unfortunately, php does not offer an __autoload() type function to
>autoload functions.
>
>If you are able to encapsulate your functions functionality into classes
>you may be able to use the above solution of using an opcode cache to
>help __autoload() a bunch of small classes.
Although PHP doesn't offer an _autoload() function to autoload functions, it
does provide
function_exists, and this can readily be used to achieve the same end:
If (!function_exists(feedback_handler)) { include
('Feedback_handler.php'); }
--- End Message ---
--- Begin Message ---
clanc...@cybec.com.au wrote:
Thank you all for your comments. I did not know about bytecode caches. They're
an
interesting concept, but if I am interpreting the paper
http://itst.net/654-php-on-fire-three-opcode-caches-compared correctly they
only double
the average speed of operation, which is rather less than I would have anticipated.
I strongly advise that you take the time to try a bytecode cache. Within
linux environments I am partial to eaccelerator. In IIS environments I
now use WinCache from Microsoft. From my own observations with a
multitude of different types of PHP web applications I find that the
speed gain is closer to 5 times faster on average.
As I would have to understand yet another system to implement them, and I
suspect I'd have
to do a significant amount of rearranging, I don't think I will worry about
them unless my
webpages unexpectedly become extremely popular.
That's your perogative, but you started this thread with a question
about file access times. By your latest argument (above) you may as well
ignore it since when and if the issue becomes salient then you can worry
about it. However, I think that's disingenuous at best since your pages
will appear slower on average, and you're just wasting CPU resources.
Al's suggestion that my code is probably infinitesimal compared with PHP
suggests that I
shouldn't be worrying about memory requirements. On the other hand I agree
with David
that the advantages of using relatively small easy to understand modules
probably outweigh
the costs of loading a larger number of files.
You've missed several points. Bytecode caches allow you to skip the trip
to the filesystem. They allow you to skip the parse and compile stage of
PHP. They almost always make your shit run faster.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
On Thu, 07 Jan 2010 22:48:59 -0500, rob...@interjinn.com (Robert Cummings)
wrote:
>clanc...@cybec.com.au wrote:
>> Thank you all for your comments. I did not know about bytecode caches.
>> They're an
>> interesting concept, but if I am interpreting the paper
>> http://itst.net/654-php-on-fire-three-opcode-caches-compared correctly they
>> only double
>> the average speed of operation, which is rather less than I would have
>> anticipated.
>
>I strongly advise that you take the time to try a bytecode cache. Within
>linux environments I am partial to eaccelerator. In IIS environments I
>now use WinCache from Microsoft. From my own observations with a
>multitude of different types of PHP web applications I find that the
>speed gain is closer to 5 times faster on average.
Five times faster is certainly more attractive than twice as fast. But under
what
circumstances is this achieved? Unfortunately these days it is difficult to
find any solid
information on how things actually work, but my impression is that caches only
work for
pages which are frequently accessed. If this is correct, and (as I suspect)
somebody looks
at my website once an hour, the page will not be in the cache, so it won't
help. Also one
of the more popular parts of this website is my photo album, and for this much
of the
access time will be the download time of the photos. Furthermore as each
visitor will look
at a different set of photos, even with heavy access it is unlikely that any
given photo
would be in a cache.
Despite these comments the access times for my websites seem to be pretty good
--
certainly a lot better than many commercial websites -- but have a look at
http://www.corybas.com/, and see what you think. (I am in the process of
updating this,
and know that the technical notes are not currently working, but there is
plenty there to
show you what I'm trying to do.)
>> As I would have to understand yet another system to implement them, and I
>> suspect I'd have
>> to do a significant amount of rearranging, I don't think I will worry about
>> them unless my
>> webpages unexpectedly become extremely popular.
>
>That's your perogative, but you started this thread with a question
>about file access times. By your latest argument (above) you may as well
>ignore it since when and if the issue becomes salient then you can worry
>about it. However, I think that's disingenuous at best since your pages
>will appear slower on average, and you're just wasting CPU resources.
Unfortunately I am cursed with an insatiable curiosity, and spend far too much
time
thinking about philosophical questions like this. But I have also been
programming almost
forever, and I have learned that it would now take me five times as long as (I
hope) it
would take you to implement something new like byte code caching.
>> Al's suggestion that my code is probably infinitesimal compared with PHP
>> suggests that I
>> shouldn't be worrying about memory requirements. On the other hand I agree
>> with David
>> that the advantages of using relatively small easy to understand modules
>> probably outweigh
>> the costs of loading a larger number of files.
>
>You've missed several points. Bytecode caches allow you to skip the trip
>to the filesystem. They allow you to skip the parse and compile stage of
>PHP. They almost always make your shit run faster.
Perhaps. But my visitors appear to be happy now, and my hosts aren't
complaining that I'm
overloading their system.
Clancy
PS. It does sadden me that there don't seem to be many people here who are
interested in
the philosophy of programming, as against the quick and dirty fix.
--- End Message ---
--- Begin Message ---
It's the oddest thing. I've found the logs but there is no error at all, the
server just hangs and the only way to get it back is to restart Apache.
________________________________
From: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk]
Sent: Thu 1/7/2010 9:04 AM
To: Vernon Webb
Cc: php-gene...@lists.php.net
Subject: RE: [PHP] Site Moved From PHP4 to PHP5 Server - header, location no
longer working
On Thu, 2010-01-07 at 08:57 -0500, Vernon Webb wrote:
Didn't know there were php logs, I thought they would be included in
the Apache logs, where do I find the php logs?
~V
________________________________
From: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk]
Sent: Thu 1/7/2010 8:42 AM
To: Vernon Webb
Cc: php-gene...@lists.php.net
Subject: RE: [PHP] Site Moved From PHP4 to PHP5 Server - header,
location no longer working
On Thu, 2010-01-07 at 08:40 -0500, Vernon Webb wrote:
That's the odd thing, there is nothing being indicated in the
error logs the server just hangs and I have to restart apache in order to get
the site back up. First I thought it might be the server so I move over to a
different server, but I still have the same issue. What I feel is really odd is
the fact that it worked in a previous version of php, so waht's changed?
~V
________________________________
From: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk]
Sent: Thu 1/7/2010 7:52 AM
To: James McLean
Cc: Vernon Webb; php-gene...@lists.php.net
Subject: Re: [PHP] Site Moved From PHP4 to PHP5 Server -
header, location no longer working
On Thu, 2010-01-07 at 16:50 +1030, James McLean wrote:
On Thu, Jan 7, 2010 at 1:35 PM, Vernon Webb
<ver...@comp-wiz.com> wrote:
> I move a number of sites from one server to another
and one the one server we had php4 and now we have php5 and since then my
server seems to hang every time there is a header, location redirect. Anyone
have any ideas on how to resolve this? Is there something I can easily change
in the php.ini file that will resolve this issue?
Off the top of my head it sounds like something is
being output before
the header, which causes an error. If you also have
error display
turned off, you will likely just see a white screen
with no useful
information.
Make sure none of your includes have trailing
whitespace or are trying
to print out information before the header itself.
Best bet is to turn on errors and log them, then you
will see where
the output started if infact that is your issue.
Cheers
Don't turn on errors if this machine is public, as it could
potentially give out more information to people than you want. First, look at
the error logs for PHP, which record all the errors you've had with the site,
whether you have them displayed or not.
Thanks,
Ash
http://www.ashleysheridan.co.uk
<http://www.ashleysheridan.co.uk/> <http://www.ashleysheridan.co.uk/>
<http://www.ashleysheridan.co.uk/>
Have you checked both the PHP and Apache error logs? Things like
invalid commands in an .htaccess file can cause server crashes.
Thanks,
Ash
http://www.ashleysheridan.co.uk <http://www.ashleysheridan.co.uk/>
<http://www.ashleysheridan.co.uk/>
They could be in a variety of places depending on how your system is set up. It
should show you if you do a phpinfo(); in a page on its own.
Thanks,
Ash
http://www.ashleysheridan.co.uk <http://www.ashleysheridan.co.uk/>
--
This message has been scanned for viruses and
dangerous content by comp-wiz.com <http://comp-wiz.com/> , and is
believed to be clean.
--- End Message ---
