|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
php-general Digest 15 Oct 2005 19:26:07 -0000 Issue 3739
php-general-digest-help
lists.php.net
Date: Sat Oct 15 2005 - 14:26:07 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
php-general Digest 15 Oct 2005 19:26:07 -0000 Issue 3739
Topics (messages 224177 through 224188):
Re: Still struggeling with my first script...
224177 by: Jochem Maas
Re: OPTIMIZING - The fastest way to open and show a file
224178 by: Chris Shiflett
Re: prevent user from getting scripts outside the web folder
224179 by: Chris Shiflett
224185 by: Graham Anderson
Comparison of class with recursive references causes fatal error
224180 by: Mark Evans
PHP5 and SuSE 10 Problem - Help Please
224181 by: Andrei Verovski (aka MacGuru)
Re: fckeditor and PDF and pesky users
224182 by: Edward Vermillion
Re: editor
224183 by: Hodicska Gergely
Re: php 5 upgrade - undefined index errors EVERYWHERE
224184 by: Michelle Konzack
Troubleshott GD & Freetype under Linux
224186 by: Feris Thia C.
Re: ampersand in dom with utf-8
224187 by: jonathan
224188 by: jonathan
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscribelists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscribelists.php.net
To post to the list, e-mail:
php-generallists.php.net
----------------------------------------------------------------------
attached mail follows:
Chris W. Parker wrote:
> twistednetadmin <mailto:twistednetadmingmail.com>
> on Friday, October 14, 2005 5:15 PM said:
>
>
>>All: Sorry..... I forgot to write what's wrong....stupid me...
>
>
> No problem. You'll get used to it. (I don't mean you'll get used to
> being stupid! I mean you'll get used to including all the relevant
> info!)
>
sometimes on this list you have to wonder if the opposite is true ;-)
having been here a while I can say that I'm quite used to it :-)
attached mail follows:
Ruben Rubio Rey wrote:
> $handle = fopen($filename, "r");
> $contents = fread($handle, filesize($filename));
> fclose($handle);
> echo $contents;
Replace this with:
readfile($filename);
It's faster for both you and PHP.
Hope that helps.
Chris
--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/
attached mail follows:
Graham Anderson wrote:
> my htaccess file for the folder containing the php script was not
> set properly
What does that mean? Are you telling us that /home/siren/includes/ is
within document root? If it's not, do you link to it from within
document root?
Do not store includes within document root. Using .htaccess can prevent
the direct access, but you're still taking an unnecessary risk.
Chris
--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/
attached mail follows:
No... Even Worse...and much stupider ;)
The php folder I was using for the test project [within the document
root] did not have ANY htaccess protection
He just opened up the folder in the browser.
That folder had an old version of my 'crucial_smil_functions.php' script
He got access to that
The real 'crucial_smil_functions.php ' script is outside the
document root
/home/siren/includes/crucial_smil_ functions.php
the script within the doument root that accesses the above:
/home/siren/www/siren/reel/Library/php/smil.php
kind of like building a fort and forgetting to lock the front door
g
On Oct 15, 2005, at 3:04 AM, Chris Shiflett wrote:
> Graham Anderson wrote:
>
>> my htaccess file for the folder containing the php script was not
>> set properly
>>
>
> What does that mean? Are you telling us that /home/siren/includes/
> is within document root? If it's not, do you link to it from within
> document root?
>
> Do not store includes within document root. Using .htaccess can
> prevent the direct access, but you're still taking an unnecessary
> risk.
>
> Chris
>
> --
> Chris Shiflett
> Brain Bulb, The PHP Consultancy
> http://brainbulb.com/
>
attached mail follows:
Hi All
I am coming up against a similar issue as
http://bugs.php.net/bug.php?id=31449
Take the following code for example (from the bug report)
<?php
class Recursive {
private $me;
function __construct() {
$this->me = $this;
}
}
new Recursive() != new Recursive();
?>
A "nesting level too deep" fatal error is thrown... I can kind of see
why this happens...
The bug report is closed as bogus with the following statement
"I don't think it's a bug. You can not compare these objects since they
contain circular references, so comparison process descends to the
endless loop. You may want to use custom method to compare objects -
bit-comparison of objects is generally not the best idea."
the question is how to solve this... I couldnt see any immediate way to
comare 2 objects easily.. Some idea's I came up with...
1. Serialize the 2 objects and then compare the serialized data.
2. Compare the 2 classes using get_class_methods() and get_class_vars()
Is there an easier way? Or has anyone got any better suggestions that I
can use?
Note: the above code is for PHP 5.. I am using PHP 4 and come up against
a similar issue when using mock objects to unit test an observer pattern.
Regards
Mark
attached mail follows:
Hi,
After having numerous problems after upgrade from 9.3 to 10.0 (i.e. dead USB), I simply reformatted my HD and installed SuSE 10 from scratch. Everything is almost fine except PHP5.04 - none of PHP program is working.
I have configured Apache2 with YaST2 http module, enabled PHP5 and disabled php4 module. I simply cannot figure out what have happened. Looks like PHP interpreter cannot find any include even if it is located in the same dir as running script.
Anyone have an idea what went wrong? On SuSE 9.3 the same setup worked without any problem.
[client 127.0.0.1] PHP Warning: main(./libraries/lib.inc.php) [<a href='function.main'>function.main</a>]: failed to open stream: No such file or directory in /srv/www/htdocs/phpPgAdmin/index.php on line 10
[client 127.0.0.1] PHP Warning: main() [<a href='function.include'>function.include</a>]: Failed opening './libraries/lib.inc.php' for inclusion (include_path='/usr/share/php5') in /srv/www/htdocs/phpPgAdmin/index.php on line 10
[client 127.0.0.1] PHP Notice: Undefined variable: misc in /srv/www/htdocs/phpPgAdmin/index.php on line 11
[client 127.0.0.1] PHP Fatal error: Call to a member function printHeader() on a non-object in /srv/www/htdocs/phpPgAdmin/index.php on line 11
[client 127.0.0.1] PHP Warning: main(./libraries/lib.inc.php) [<a href='function.main'>function.main</a>]: failed to open stream: No such file or directory in /srv/www/htdocs/phpPgAdmin/index.php on line 10
[client 127.0.0.1] PHP Warning: main() [<a href='function.include'>function.include</a>]: Failed opening './libraries/lib.inc.php' for inclusion (include_path='/usr/share/php5') in /srv/www/htdocs/phpPgAdmin/index.php on line 10
attached mail follows:
Richard Lynch wrote:
> A) Attempt to hack fckEditor to "allow" a PDF to get uploaded, and
> then display a link to the PDF instead of alink to the fckEditor
> output.
>
> B) Give them a separate, possibly confusing, input to upload files to
> tie in as links to the fckEditor area
>
> C) Dump fckEditor and only allow file upload, requiring them to
> compose HTML pages in some external application
>
> Has anybody faced this, and with VERY non-technical users had better
> luck one way or another?
>
> Which of these fit in best with PHP, and why?
>
Do they want the PDF to display in the page, or is a link to a PDF ok
for them?
Dunno about what's best for PHP, but I'd think about having a separate
upload box right below the fckEditor box, clearly marked as a PDF upload
box, and then do some linking magic when you process the form.
You said there were templates involved. Depending on how the content
from fckEditor is used in the templates, I'd see if I could just put
some kind of tag in the templates as a marker for the PDF link to go
into, or maybe some JS to add a tag into the fckEditor box when they
choose a file to upload. But it all really depends on how the backend is
handling the form and how it all eventually gets out to the browser as a
page.
I've got a more complicated thing going in my CMS that seems to be ok
for the folks to grasp that involves a PDF upload/manager section
thingie. But I'm not having to tie it in to fckEditor, and all the PDF's
go to one page anyway right now.
Good luck on however you end up working it out. Showing someone how
something works before they have a chance to formulate any ideas about
how they *think* it should work is always a lot easier that retraining
them after they've been frustrated at the "magic box that won't do what
I want it too".
attached mail follows:
>> I read somewhere about an editor, which has built in support for
>> phpdocumentator and creating unit test. Now I could not find it, I tried
>> a lot using Google without success.
> Could it be PHPEdit ?
Yes, thx, this is the editor which I tried to find. I already get it
last night, after I tried to google not "php editor unit test support",
but only "php editor simpletest".
Regards,
Felhő
attached mail follows:
Have encountered more problems...
I am using Debian Sarge and the package php5-pear is missing the
DB.php and my whole Database is not more working...
Using 'pear install DB' results in a Filesystem nightmare...
The new files are not registered inside the Debian Package Management.
Greetings
Michelle
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/3/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFDUREEC0FPBMSS+BIRAsvaAJwIjP048yQUpMYNdOmY93XGgq5lvQCfZ62P
Yy6JW7pDRs8xiV0i6BZavwc=
=rOq6
-----END PGP SIGNATURE-----
attached mail follows:
Hi All,
My PHP engine still cannot load JPEG library (GD) and Freetype fonts...
I use ./config.nice to reconfigure PHP coz it works... and I have compile it
with --jpeg-dir options. And seems not working at all.
How can I troubleshoot and resolve these problems ?
Regards,
Feris
attached mail follows:
I've been setting the
here's some output:
<?xml version="1.0" encoding="utf-8"?>
<menu>
<submenu>
<submenu_name>Starters</submenu_name>
<item>
<item_name> soupe au pistou with amaranth and grana
breadcrumbs</item_name>
</item>
<item>
<item_name>farm lettuces with reed avocado,
cr&egrave;me fraîche, radish and cilantro</item_name>
</item>
On the second item, this cr&egrave;me is ok but this
fraîche is causing the error.
-jonathan
On Oct 14, 2005, at 4:22 PM, Jasper Bryant-Greene wrote:
> jonathan wrote:
>
>> the real characters (presumably è) won't render correctly.
>>
>
> Are you outputting the correct character set information (UTF-8),
> and are you sure that UTF-8 is being used throughout the entire
> process?
>
> --
> Jasper Bryant-Greene
> General Manager
> Album Limited
>
> a: Freepost Album, PO Box 579, Christchurch 8015, New Zealand
> p: 0800 4 ALBUM (0800 425 286) or +64 21 232 3303
> e: jasperalbum.co.nz
> w: http://www.album.co.nz/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>
attached mail follows:
So I'm reading up on character encoding in XML documents as I think
this is the problem (after the many helpful suggestions on this list).
With regards to your second question; no, I'm not sure if I'm using
proper utf-8 througout the entire process. When I input from the form
I'm converting everything via htmlentities . This is why I'm getting
è etc... (On a side note, is there a function or way to check
to see if a form is using the native characters (from a copy and
paste of a word document like è) or the HTML entity è .
I've changed the content-type from text/xml to application/xml but
that doesn't seem to help.
As only UTF-8 and UTF-16 have to be supported, I'm concerned whether
the processor might think it is some other encoding.
The HTTP headers are:
Date => Sat, 15 Oct 2005 17:49:02 GMT
Server => Apache/1.3.33 (Unix) mod_jk/1.2.8 PHP/5.0.4
mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4
FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7a
X-Powered-By => PHP/5.0.4
Cache-Control => no-cache
Connection => close
Content-Type => application/xml
I guess pursuant to cc's suggestion, I should do an
html_entity_decode when I make the xml document and then do another
htmlentities on the html representatoin.
-jonathan
On Oct 14, 2005, at 4:22 PM, Jasper Bryant-Greene wrote:
> jonathan wrote:
>
>> the real characters (presumably è) won't render correctly.
>>
>
> Are you outputting the correct character set information (UTF-8),
> and are you sure that UTF-8 is being used throughout the entire
> process?
>
> --
> Jasper Bryant-Greene
> General Manager
> Album Limited
>
> a: Freepost Album, PO Box 579, Christchurch 8015, New Zealand
> p: 0800 4 ALBUM (0800 425 286) or +64 21 232 3303
> e: jasperalbum.co.nz
> w: http://www.album.co.nz/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]