Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
And I wonder why do you think it is so important to show the characters like eacute; or auml; in every browser... ? For me, to show correct multibyte characters in the gpc section would make more sense. Therefore I think the best solution is to keep the best visibility in the user's native charset / encoding. phpinfo() no longer encodes accented characters to eacute; or auml;. I changed this on Wed Oct 9 10:39:39 2002 in version 1.215 of info.c. As I said before, IE and Mozilla automatically changes the font preference if no suitable glyph for a character is found on rendering. So with some charsets, specifying the face name in CSS declaration has no effect. And? Isn't that what phpinfo() does now? No charset/encoding is specified, so IE/Moz automagically changes it. Please look at the attached HTML file and the image (the file would be dropped in the list). The HTML file is encoded in UTF-8 and the image is rendered by IE5.5 . Note that the font used to render the Japanese characters are not Arial Unicode MS but MS PGothic. Hope it helps. Well, it renders nicely under Mozilla for me too. I don't understand the point though, so here are my questions: 1) what is wrong with the way phpinfo() works *right now*? 2) what could/should be changed to fix it? If I call a page with phpinfo(), and pass it a query string with encoded chars, then I do see the _GET[var] part of the info in the Japanese characters, and all the rest of the page looks fine. i.e.: http://devel.easydns.com/~cmv/.info.php?var=%E6%97%A5%E6%9C%AC%E8%AA%9E This is under Moz 1.2 on my machine. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c
Why did you remove the charset info? I want my charset back since it enables correct handling of the output. Everything these lines commented out by you do is telling the receiver what charset he gets. That is compareable to http charset info which will be generated by those modules also. This way you can enable mbsting or iconv with any charset you like. This has nothing to do with the other thing you did in this patch: changing behaviour of php_escape_html_entities(). I guess you did not understand what you removed? No, I do understand what I did. Every browser I tested displayed the phpinfo() page correctly when the charset was not specified ... i.e., they guessed the right charset. If you explicitly specify a charset, then you need to encode the characters according to that character set. The problem is, that encodings such as eacute; and Auml; (which show up on the credits page), don't work under all charsets/encodings. I will test it again, with the charset declaration back in, but I'm relying on people with non-Western browsers and charsets for some feedback on how the choice of charset affects the rendering of the pages. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Plan for PHP 5.0
If someone gives me an account on an OSX box (or even better, puts an OSX box into my mailbox! ;-) I will make it work. Don't know how useful/useable this is, but Sourceforge's compile farm includes a box with OSX (10.1). - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard css.c
Log: don't define fonts ... use the browser defaults Reason being? Yasuo Ohgaki's post earlier today said: First problem, CSS should not contain specific font name. Otherwise, characters may be broken under some browsers when font does not have type faces needed. Although, to be honest, I think his problem is more with the character set that is being sent with phpinfo pages. I'm guessing he has a Japanese version of Arial, that's missing some of the characters like eactue; etc.. Since the page is probably outputting charset=shift-JIS or whatever, the page looks broken. I'm waiting to hear a response from him on this issue, which might affect my changes to the css page. The definitions end in generic font families. There's no shame in defining a __readable__ __preference__. Especially Andale Mono, since it is one of the few monotype fonts, that has a readable difference between the l and a 1 and the O and 0. I've seen more people fiddling with their fonts, because they're pretty than because they're readable. Docs should aim to be readable. Agreed. Which is why the default fonts on people's browsers should be set to be readable already, no? Also, some people have emailed suggesting I remove them because of the CSS styling that they apply themselves to the phpinfo() output, using their own font defs. What's more problematic in the css code below, is the 75% default on td/th. If you nest that, the inner td, is 75% of 75% of the body. But there is no nesting of tables in phpinfo()'s output. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard css.c
This is getting a little more complicated than I think is necessary. There are two issues here, I think: a) Fonts. Some people didn't like Arial, so I reverted to letter the browser decide. Some people didn't like that, and they'd like the font specifications back in. I'm going to add the font specifications back in again. I like Arial, personally, but I will put Verdana as the first font. This is in keeping with the look of php.net anyway, so I can justify it. There is nothing stopping anyone from specifying use my own fonts in their browsers. b) Charsets. I don't pretend to know what the charset deciding code in ext/standard/info.c is trying to do. I guess it's looking to see if your browser supports multi-byte charsets, or what encoding you prefer ... and then defaulting to US-ASCII if nothing else works. Seemed reasonable to me. I suppose, what Yasuo has pointed out, is that some (many? all?) multibyte fonts or versions of those fonts don't support the HTML entity encoding that is used on some of the phpinfo() pages ... mainly people's names in the credits pages, but also any or or that show up in other data. These need to be encoded *somehow* if the page is to be XHTML compatible, and I'm not about to implement utf8_encode() in C. :) I don't know what the solution to this is. My instinct is to ask why don't we just hardcode the pages to use US-ASCII, or ISO-8859-1? Would this not solve the charset issues? - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard css.c
a) Fonts. Some people didn't like Arial, so I reverted to letter the browser decide. Some people didn't like that, and they'd like the font specifications back in. This will simply break output under some browser. It's more important to show info, but show a little nicely on some systems while printing garages on some systems. But the old phpinfo() specified fonts, so are you saying it was broken then too? If anyone prefer any specific font, they should use their own CSS. But I bet 99% of the people will have versions of either Arial or Verdana or Helvetica that *will* work. Why not make life easier for the majority, since the 1% is going to have to specify their own font anyway? I don't know what the solution to this is. My instinct is to ask why don't we just hardcode the pages to use US-ASCII, or ISO-8859-1? Would this not solve the charset issues? No. Why you bother? Letting browser decide is more feasible and most importantly, it works. Okay ... so don't output the charset meta tag at all? If you are not certain how to make phpinfo() work under most environment, I can help. If you can make it work under most environment *and* look good (i.e. as much like it used to, sans-serif fonts and all), then great! CVS is a wonderful thing. :) - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard css.c
Yes and No. It works withh my browser, but I just happen to know some browsers do not like it. Let's be more conservative. I'd rather have a nice looking page that works on 99% of the browsers, than a not-so-nice looking one that works on 100%. Okay ... so don't output the charset meta tag at all? That's better. And you must not try to convert chars to entities. This is the worst thing... Text cannot be read even with HTML sources. But the characters need to be converted. It isn't valid XHTML if we don't specify a charset. Testing on Mozilla, if I have a document that contains: Hello Theacute;o, welcome to my Straße! This only renders completely properly if the charset is ISO-8859-1. HTML entities render in UTF-8 and US-ASCII, but the ß does not. Even using the character set your emails to me come in (ISO-2022-JP) renders the HTML entities correctly, but fails on the un-encoded character. I really think the best solution (not perfect, but best) is to specify some fonts so the pages look nice, and hard code in the ISO-8859-1 font. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] auto_prepend/append: does the PHP engine cache the
Lance, I just noticed this post, and PWEE sounds pretty interesting. One thing that would definitly make me consider using it in a production environment would be the ability to change configuration based on the name of the vhost being accessed. For example, we've got several sites all running the same code on the same IP. I use an auto_prepended file to check the hostname being accessed, and then include() some site-specific variables to change the look and feel of the site. Take a look at: http://domains.dslreports.com/ http://bell.easydns.ca/ http://domains.canadacomputes.com/ If I could set up PWEE with something like this: ?xml version=1.0? Environments Application name=DNS_PARTNERS namespace= Server vhost=domains.dslreports.com Constants Constant name=DATABASE_HOSTNAME value=dsl / /Constants /Server Server vhost=bell.easydns.ca Constants Constant name=DATABASE_HOSTNAME value=bell / /Constants /Server ... etc ... /Application /Environments Is this possible in PWEE right now? If not, would you consider adding support for it? - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: phpinfo() output
Sebastian Bergmann wrote: Currently API Versions: PHP: 20020307 PHP Extension: 20020429 Zend Extension: 20020903 is rendered instead of API Versions: PHP: 20020307 PHP Extension: 20020429 Zend Extension: 20020903 Okay, I'll look into this. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard config.m4 css.ccss.h info.c /main php_ini.c /sapi/aolserver aolserver.c /sapi/apachephp_apache.c
It obviously is not compatible with current browsers as it is really ugly in IE and NS. It looks pretty much identical to the way it did before in MSIE 5+ and NS 6+ and Mozilla. It only looks ugly (i.e. not as nice as before) in NS 4.x, a broswer that almost no one uses anymore. Indeed, why did you have to change it? Just to get CSS in there? As I said, it was to reduce the size of the file considerably. Only thing I'm gonna do is revert your patch..if you don't fix the CSS to work with any browser, that is. I'm not gonna waste my time on this thing more than doing that revert. If we want a truly cross-browser phpinfo() page, it should be text-only or plain, unformatted, uncoloured tables. Yes please. If that is what is really wanted, then just disable the code that outputs the CSS. You are left with plain, perfectly valid HTML. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard config.m4 css.ccss.h info.c /main php_ini.c /sapi/aolserver aolserver.c /sapi/apachephp_apache.c
Just out of curiosity, what was the size before/after? Right now, it reduces the size to about 75% of the original. But a few minor changes could drop that easily to 50%. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard config.m4 css.c css.h info.c /main php_ini.c /sapi/aolserver aolserver.c /sapi/apache php_apache.c
I must have missed some discussion where it was decided to change this..? Can't seem to find any in the archives either. There wasn't. And why is there even need to change it? It has worked fine (for ANY browser) for very long time now. I was simply trying to reduce the amount of HTML that phpinfo() generated, and moving to a CSS formatting model acheived that while still maintaining compatability for current browsers. My question back would be how many people here *really* care what the output looks like? Is anyone making that info available in a production site? I doubt it. I'm guessing this page is almost exclusively used for debugging purposes by site developers, or other diagnostic reasons ... in which case as long as the info is there and legible, I don't see the issue. However, if there are, then you can easily replace the stylesheet with your own style to skin the page ... something that would've been much more difficult with the old version. The HTML itself in the current page is as plain as it gets, pretty much. If we want a truly cross-browser phpinfo() page, it should be text-only or plain, unformatted, uncoloured tables. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: ICAP/MCAL
libmcal is now at http://sourceforge.net/projects/libmcal/ - Colin Georg Richter [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hello all, Obviously MCAL is the follower of ICAP. The icap library isn't more available, subdomain icap.chek.com is not connected. ICAP Extension functions are included in MCAL too, MCAL can use the icap driver too. Whats to do? Kill ICAP? Documentation Note? Georg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] XMLRPC Bug
Is anyone reading this list? I haven't heard a thing since last week when I posted what I think might be a serious bug in the extension (see also http://bugs.php.net/?id=14521). Basically, you define a method. When executed, the server passes it the appropriate parameters. However, what is really passed is actually a one-element array with the paramaters as the only value. For example, if your server sends the data $foo, what the method actually receives is someting like array( 0 = $foo); This is true in all cases, *except* where $foo is an unindexed array. In those cases, the method receives $foo, not array($foo). It should, I'm pretty sure, be one or the other, and I think the unindexed array case is correct: if you send it $foo, it should receive $foo. I'm hoping the developers could look into this soon ... I'm eager to start using this extension, but want to be fairly sure it works first. :) - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] XMLRPC Bug
Not true, I've been using it, it works fine, I'm not quite sure about that bug though (too tired now to check it out also... :) Well, when you *do* get some sleep :) ... take a look at the bug I posted: http://bugs.php.net/?id=14521 I can see how the extension would be useable, if you never send an unindexed array to a method function. But when you do, it returns unexpected values. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] news.php.net seems to be down
I can't get to it either through the web, or through NNTP. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] xmlrpc extension in 4.1.0
Zak Greant [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On December 10, 2001 03:42 pm, Colin Viebrock wrote: Any docs on using this extension? Hey Colin, There is an article on Zend - http://www.zend.com/zend/tut/tut-xml-rpc-client.php Unfortunately, that tutorial is based on using Edd Dumbill's XML-RPC class. The extension that's now part of PHP 4.1.0 is based on Dan Libby's XML-RPC-EPI C library, so the syntax is entirely different. FWIW, though, most of the docs on http://xmlrpc-epi.sourceforge.net/ seem to apply to the PHP class. I just had some questions about using SSL, and about what I think might be a small bug in the implementation (see http://bugs.php.net/?id=14414). - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] xmlrpc extension in 4.1.0
FWIW, though, most of the docs on http://xmlrpc-epi.sourceforge.net/ seem to apply to the PHP class. I just had some questions about using SSL, and about what I think might be a small bug in the implementation (see http://bugs.php.net/?id=14414). Heh. That's what I get for sending a link without reading the content. :) S'ok! Actually, that bug report is for something in PEAR, not the XML-RPC extention. The bug I *really* meant is at: http://www.geocrawler.com/lists/3/SourceForge/10636/0/7291199/ - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] xmlrpc extension in 4.1.0
Any docs on using this extension? - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #10172 Updated: get_class() doesn't return lowercase for DomX objects
Well .. the documentation always documents the 'current' state as much as it can, so it is right to update the docs. I agree. However, I don't like the idea to lowercase all classes. I'ld rather see the original notation of classes not to be changed at all. No idea why there was every introduced lowercases Except, that would entail making function names and class names case-sensitive, which they aren't now. That is much more of a major change to the language (with huge compatability issues) than what I am proposing. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] http://www.php.net/license/
I suppose the text here needs to be revamped in light of the Zend license change. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] configure error in PHP3
I don't know where else to post this, so ... I'm trying to build PHP3 from the latest snapshot file (php3-200110020900), and the configure script fails with: ... checking for ASPELL support... no checking for MCAL support... no checking for ftp support... no ./configure: syntax error near unexpected token `else' ./configure: ./configure: line 8891: `else' My config line is: ./configure \ --with-apxs=/usr/local/apache/bin/apxs \ --enable-versioning \ --enable-track-vars \ --disable-magic-quotes \ --with-mysql \ --with-mcrypt \ --with-xml \ --with-zlib \ --with-ftp \ --enable-sysvshm \ --enable-sysvsem \ --with-gd \ --with-ttf \ --with-pcre-regex \ I've tried it with and without the ftp line .. that doesn't seem to matter. FWIW, I'm doing this because of the file-upload problem described at: http://marc.theaimsgroup.com/?l=php-generalm=97498417629870w=2 Any help would be appreciated. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: configure error in PHP3
FWIW, I get the same error with just a simple ./configure with no flags. The configure file is available to see at http://tex.privateworld.com/~cmv/configure - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: configure error in PHP3
Well, this was solved by removing the configure script that came with the snap, and running ./buildconf (thanks Derick). I'm guessing that the script that automagically generates these snaps is building a bad configure file ... somehow. - Colin Colin Viebrock [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... FWIW, I get the same error with just a simple ./configure with no flags. The configure file is available to see at http://tex.privateworld.com/~cmv/configure - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] about domxml api-change in 4.0.7
FWIW, I've needed to hack my code to handle three differences between the 2
different API versions. To be honest, I can't keep track of which API was
in which release of PHP, so I'll just call them API A) and API B).
1) Names of tags:
API A) $node-name
API B) $node-tagname
2) Tag attribute value:
API A) $node-children[0]-content
API B) $node-value
3) Is a node a text node:
API A) $node-type == XML_TEXT_NODE
API B) strtolower(get_class($node)) == 'domtext'
I haven't installed libxml 2.4.2 and PHP 4.0.7rc1 yet, but I'm wondering if
someone can tell me which API version is in use? This script should tell
you:
?php
$__x = xmltree('a b=cd/a');
if ($__x-children[0]-name=='a'
$__x-children[0]-attributes[0]-name=='b'
$__x-children[0]-attributes[0]-children[0]-content=='c'
$__x-children[0]-content=='d') {
echo 'API A';
} else if ($__x-children[0]-tagname=='a'
$__x-children[0]-attributes[0]-name=='b'
$__x-children[0]-attributes[0]-value=='c'
$__x-children[0]-children[0]-content=='d') {
echo 'API B';
} else {
echo 'something totally new :(';
}
- Colin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] about domxml api-change in 4.0.7
I haven't installed libxml 2.4.2 and PHP 4.0.7rc1 yet, but I'm wondering if someone can tell me which API version is in use? This script should tell you: By your script, B is in use for 4.0.7. I'm going to look at this tonight, perhaps we can merge the 2 somehow before .7 goes final... Either way is fine with me, whichever leaks less memory. I was just worried it might be version C. :) - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] weirdness on make install
This is with using the 4.0.6 release tarball. config and make work fine, but make install fails with a weird message I've never seen before: Making install in pear make[1]: Entering directory `/home/cmv/sources/php-4.0.6/pear' make[2]: Entering directory `/home/cmv/sources/php-4.0.6/pear' shtool:mkdir:Error: invalid number of arguments (at least 1 expected) shtool:mkdir:Hint: run `/home/cmv/sources/php-4.0.6/build/shtool mkdir -h' or `man shtool' for details +--+ | The installation process is incomplete. The following resources were | | not installed: | | | | Self-contained Extension Support | | PEAR: PHP Extension and Add-on Repository | | | | To install these components, become the superuser and execute: | | | | # make install-su | +--+ make[2]: *** [install-data-local] Error 5 make[2]: Leaving directory `/home/cmv/sources/php-4.0.6/pear' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/cmv/sources/php-4.0.6/pear' make: *** [install-recursive] Error 1 Yes, I am root when doing this. Configure line is: ./configure \ --with-apxs=/usr/local/apache/bin/apxs \ --enable-versioning \ --with-mysql=/usr/local/mysql \ --enable-sysvshm \ --enable-sysvsem \ --disable-debug \ --enable-track-vars \ --disable-magic-quotes \ --with-ttf \ --with-pear=/pear \ --with-config-file-path=/usr/local/php Now, this machine already has Apache with PHP3 compiled as a DSO. I'm just following the instructions in the manual about getting both working as DSOs. Ideas? - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: weirdness on make install
Nevermind ... I just saw the bug report and notice that it's fixed in CVS. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] 4.0.7 coming ... ?
Just planning some upgrades here at easyDNS and wondering if there is a plan yet for when 4.0.7 might be released? - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] phpinfo output
Anyone else here notice that the additional information blocks for modules compiled into PHP is pretty much sorted in reverse alphabetically order? Just wondering if we could switch it to forward alpha order, if possible. And why zlib seems to come up in the wrong location. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Reworking DOMXML
I prefer style #1 as well -- it preserves backward compatability and is consistent with the libxml2 docs. Plus, it is then similar to other PHP functions that use an object or handle as the first argument (e.g. mysql_, fopen, fwrite, curl, etc.). - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] curl problem
Seems like recent cURL module always outputs the header to STDOUT, even if the curl_setopt ($c, CURLOPT_HEADER, 0) was called. I do not know if it's cURL library or PHP cURL module problem, but obviously it is going to break a lot of scripts this way. I reported this already: bug #12018 Sterling has been fixing some other cURL stuff, but he's told me (offlist) that he can't look at this problem until next week. Hopefully someone else can stand up and take a quick look. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Fw: ezmlm warning
I don't know who is in charge of the new mail server, but I'm getting a lot of bounce messages from the server. Here is a copy of the latest (btw, that IP at the end is pb1.pair.com - 216.92.131.4) - Colin --- Below this line is a copy of the bounce message I received. Return-Path: Received: (qmail 54679 invoked from network); 30 Jun 2001 13:38:11 - Received: from unknown (HELO toye.php.net) (64.0.151.153) by pb1.pair.com with SMTP; 30 Jun 2001 13:38:11 - Received: (qmail 21418 invoked for bounce); 30 Jun 2001 13:35:19 - Date: 30 Jun 2001 13:35:19 - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: failure notice Hi. This is the qmail-send program at toye.php.net. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: 216.92.131.4 does not like recipient. Remote host said: 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) Giving up on 216.92.131.4. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] CVS Account Request
Full name: Chris Roman Email: [EMAIL PROTECTED] ID:rmn96 Purpose: To report my bug Try http://bugs.php.net/ You don't need a cvs account to report bugs. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] news.php.net is back.
(the server software will be released soonish. keep an eye on http://news.php.net/ for an announcement.) Looks good ... although clicking on the rss link produces: Warning: Cannot add header information - headers already sent by (output started at /usr/local/www/news.php.net/nntp.inc:14) in /usr/local/www/news.php.net/group.php on line 19 .. and then the XML data. Can we build this into the main website somehow (a link, I suppose, and interface integration)? - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] DOM/XML in 4.0.7
For 4.0.6 I rolled back the DOM/XML changes. It seems as if the current upgrade isn't being fixed. Maybe we should revert it back to what it was in 4.0.6 until it gets a thorough make over? You love to make me work, huh? :) Seriously, if we stick with the 4.0.6 version, that's fine. However, I've heard various reports of major memory leaks in it. I'd rather have a leak-free version with a new syntax than a leaky version with the old syntax. Whichever makes more sense is fine with me. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] php -l still broke (bug #10348)
Hrm, how about a semicolon at the end of the 3rd line? :) It leaks, but it works. Zeev, my point was that php -l should've picked up on that, right? :) Jani, here is my config line: ./configure \ --with-mysql=/usr/local \ --disable-pear \ --enable-track-vars \ --disable-debug \ --disable-magic-quotes \ --enable-ftp \ --with-gettext \ --with-xml \ --with-dom \ --enable-wddx \ --with-curl \ --with-pgsql \ --with-zlib \ --enable-versioning \ --enable-sockets \ --with-openssl \ --with-snmp \ --with-readline \ --with-mcrypt - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.0.6RC4 out.
Please test it http://www.php.net/~andi/php-4.0.6RC4.tar.gz Compiles nicely under RH7.0 (will test with Debian later). Two failed tests with the CGI, though: Running tests in /usr/local/sources/php-4.0.6RC4//ext/standard/tests/time = microtime() function ... passed strtotime() function (002.phpt) ... failed Running tests in /usr/local/sources/php-4.0.6RC4//tests/lang snip OO Bug Test (Bug #7515) (029.phpt) ... failed My config: ./configure \ --with-mysql=/usr/local \ --disable-pear \ --enable-track-vars \ --disable-debug \ --disable-magic-quotes \ --enable-ftp \ --with-gettext \ --with-xml \ --with-dom \ --enable-wddx \ --with-curl \ --with-pgsql \ --with-zlib \ --enable-versioning \ --enable-sockets \ --with-openssl \ --with-snmp \ --with-readline \ --with-mcrypt - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] php -l still broke (bug #10348)
Okay, you said to take this out of the bug database, so ... php -l *still* doesn't work for me with the RC4 tarball: [cmv@sunniva Reg]$ cat x.php ?php $a = array(1,2,3) print_r($a); ? [cmv@sunniva Reg]$ php -v 4.0.6RC4 [cmv@sunniva Reg]$ php -l x.php [cmv@sunniva Reg]$ php x.php X-Powered-By: PHP/4.0.6RC4 Content-type: text/html br bParse error/b: parse error in bx.php/b on line b4/bbr [cmv@sunniva Reg]$ - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] bug/dev
I know the lists are just back online, so I shouldn't be making feature requests ... but it would be nice if the bug reports had their own mailing list instead of being sent to the dev list. I can see why you might not want this (dev people work on bugs), but I'm sure some people would like to be a part of the dev list without having to sift through 300+ bug reports a day. Just a thought. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.0.6RC2
No, we'll revert it to 4.0.5 version, not 4.0.4.
Is this the version that includes the complete rewrite of the DOMXML
module?
Basically, which will work now:
$rootname = $XML_TREE-root-name;
or
$rootname = {$XML_TREE-children[1]}-tagname;
?
Please say the second one.
- Colin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.0.6RC2
Can you please check 4.0.6RC1? (http://www.php.net/~andi/php-4.0.6RC1.tar.gz) Getting make errors with CURL (which I never got before): upgrade to cURL 7.7.3 Thanks, Sterling ... that fixed the cURL problems. Well, it looks like my scripts all seem to work without any changes, so I guess I'm okay with whatever DOMXML version is in 4.0.6RC1. :) - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] issues about domxml in 4.0.6
I've contacted Uwe, and if he doesn't object (or respond ;) within the next day or so, I'll revert the commit in the 4_0_6 branch (leaving head alone). Whoa. Are you saying that 4.0.6 will revert to the domxml syntax that was in 4.0.4 and previous? And that 4.0.5 will just have it's own syntax? I've already updated all my scripts to the new syntax, assuming it was the way of the future. Don't tell me we are back-pedalling now! - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] multiselects and arrays
What I do when I need multidimensional arrays from forms, is name my
variables:
INPUT NAME=i::foo::bar VALUE= ...
i.e., I delimit the dimensions with ::. Then, on the page they are posted
to, I do:
?
parseInputVars('i');
?
And here is the code for that function, which looks for all the variables
that start with 'i::' and creates the multidimensional array needed.
?
###
#
# parseInputVars
#
# - parses HTTP_POST variables into a multi-dimensional
# arary, using '::' as the delimiter, and also runs
# a function on each element of the array during parsing,
# and optionally another function on the entire array
# after parsing
#
function parseInputVars($var, $function=false, $global_function=false) {
global $HTTP_POST_VARS, $$var;
if (is_array($HTTP_POST_VARS)) {
$temp = '';
foreach($HTTP_POST_VARS as $k=$v) {
$s = explode('::',$k);
if ($s[0] == $var) {
$s2 = array();
foreach ($s as $k2=$v2) {
if ($k2) {
$s2[] = $v2;
}
}
if (is_object($v) || is_array($v)) {
$temp .= sprintf(\$t[%s] =
unserialize(urldecode(\%s\));,
join('][',$s2), urlencode(serialize($v))
);
} else {
if ($function) {
$temp .= sprintf(\$t[%s] = %s(urldecode(\%s\));,
join('][',$s2), $function, urlencode($v)
);
} else {
$temp .= sprintf(\$t[%s] = urldecode(\%s\);,
join('][',$s2), urlencode($v)
);
}
}
}
}
eval($temp);
$$var = $t;
if ($global_function) {
$global_function($$var);
}
}
}
?
--
Colin Viebrock
Co-Founder, easyDNS Technologies Inc.
http://www.easyDNS.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
I don't think it is trivial to implement this without: a) Creating a second version of our hash tables (I don't like duplicate code). b) Adding more complexity to the already complex hash tables. I don't know enough about Zend internals to speak with any authority, but wouldn't an easy way of doing this be to: a) store *only* the mixed case version of the class name in the hash table, and b) change get_class(), etc. so that they automatically pass the result through strtolower() (or whatever) first ... unless the optional second argument is passed, in which case it's just returned as is. You wouldn't need a bigger nor an additional hash table, AFAICT, and only what I imagine is relatively minor code changes to the get_class(), etc. functions. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
The question was under what key the class entry should be stored... At
any
rate, it's a non-issue; Saving the 'beautiful' version of the class name
is possible, but is a bit hacky IMHO. There should be an optional case
sensitive mode, and we'll introduce one in one of the future versions of
PHP.
Yeah ... I posted before reading the remainder of the thread. :)
One problem with case sensitivity (perhaps) is that it may make some
scripts non-portable.
Say I develop a super-duper PEAR class using case-sensitive code (cause
that's what I have on my server). Someone who is running PHP in
case-insensitive mode will complain when my code says:
if (get_class($foo)=='Some_Class_Name')) { ...
So all code that might be shared either a) needs to only us lowercase names,
b) coders need to implicity lowercase their comparisons by changing the
above line to:
if (strtolower(get_class($foo))=='some_class_name')) { ...
or c) we also need a way to switch between sensitivity modes through PHP
code (either an ini_set() call, or something else).
Also, case-sensitivity means I can write code with functions like
StrReplace() and MySQL_Fetch_Row(), which will seriously cause problems on
non-case-sensitive installs ... unless all variations of PHP functions are
reserved.
- Colin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] Re: 4.0.4?
If we are to do this then we should definatly separate the distributions and the actual scripts, could we make phpweb_scripts phpweb_dist if somtone checksout phpweb then they get both byt we can also get phpweb_scripts separately. (cvs cando this automatically) Agreed. The phpweb tree should just contain the site files. distributions tree should contain all the downloads (including those big .chm files, please). I don't have a collection of all the old distributions, nor the CVS karma to do this, so ... can someone else set this up? - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] Re: 4.0.4?
why? (my thought is that the archived distributions shouldn't be under cvs control at all, and shouldn't be part of the mirrored website.) Well, I think we should at least have the latest, and second-latest versions available on mirror sites. All the third-latest-and-earlier versions should be kept *somewhere* and available. We don't need CVS to do it (since no one is going to modify them), and we certainly don't need to clog up all the mirror sites with them. Is that what you're saying Jim? - Colin [p.s. I'm moving this discussion over to php-dev, rather than webmaster.] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
Any opinions? Have I overlooked something that makes this more difficult
than
it seems? I'm willing to work on this if I can gather some positive
concensus.
For one thing, I would have to change all my code from:
if (get_class($var)=='foo_class')) { ... }
... to:
if (get_class($var)=='Foo_Class')) { ... }
... (assuming I know how it was declared), or to:
if (strtolower(get_class($var))=='foo_class')) { ... }
... which I personally think is kludgy. Ditto for function_exists(), I
assume. Or are you suggesting something like:
getOriginalDeclaredName('foo_class');// returns 'Foo_Class';
... which I don't have a problem with, I suppose. Then again, I don't write
the Zend code. :)
I don't follow how having the full case of the original declaration would
help you.
- Colin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.0.6
I'd make mstring - mbstring. The question is if it's worth splitting this up into more than one extension. Probably not. So we should probably be picking out of wchar, mbstring, jpstring. Rui, what do you think? I'm not Rui, but my vote would be for mbstring (or mb_string). If this handles any multi-byte character strings and Unicode, then it's going to be used for a lot more than Japanese strings. Hopefully, this will save me from porting String::Unicode into PHP. :) - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] distributions in /phpweb
Can I make a suggestion to take the distributions directory out of the phpweb repository, and make it it's own CVS repository? This would a) allow people to just mirror the downloads instead of the whole site and b) make it much quicker when people do a cvs update when they only want to edit some of the layout files. :) - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #10145 Updated: strtime() result?
I added an error of level E_NOTICE for this. Thanks. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] hebrew error messages?
Parse error: parse error, expecting `T_PAAMAYIM_NEKUDOTAYIM' or `'('' in
/path/to/file.php on line 246
Zeev/Andi ... ? :)
- Colin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #10423: HTTP_ENV_VARS is bigger, overwrites session vars
Specifically in my case, HTTP_ENV_VARS['USER'] is now being set. It took me a while to figure out why my scripts, which use $USER as a session variable, were getting messed up. That is because PHP inherits the environment from Apache, which in turn inherits it from the shell in which you started the server. Use something like 'env -i apachectl start' when starting apache or replace the line HTTPD=/path/to/httpd with HTTPD="env -i /path/to/httpd" in apachectl, if using it. that way you'll get a clean environment. If you need specific variables to be set (like those for Oracle) use Apache SetEnv directive. Yeah, I figured as much. I just wondered why PHP seemed to pickup $HTTP_ENV_VARS['USER'] now, when it didn't before (I don't think). Anyway, I just changed my php.ini from: variables_order = "EGPCS" to variables_order = "GPCS" Finally, if register_globals is off, is $GLOBALS useable? I have some functions that manipulate variables in the global scope. yes it is, AFAIK. in fact, you will find it handy to have a wrapper function/class over all these HTTP_*_VARS arrays to validate stuff ;) I can't face wading through 4 megs of code to switch to using HTTP_POST_VARS all the time. :) What kind of a wrapper function/class are you suggesting? So this is not a bug, and you might want to close it. Consider it done. :) - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] 4.0.5 and mcrypt
Just curious whether the work Derick has been doing to fix the mcrypt functions is going to make it into 4.0.5? It was mcrypt and sockets that we were waiting on, right? And the sockets stuff is confirmed now, right? -- Colin Viebrock Co-Founder, easyDNS Technologies Inc. http://www.easyDNS.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt
I think my main point is valid though. Placing popular extensions in one place and unpopular ones in another draws an arbitrary line in the sand which makes it impossible to intuitively guess where things should be. The only way for this to be handled elegantly is for all extensions to live in the same place. Either the extention you want comes with PHP, or you get it from PEAR. I don't think that's too non-inuitive. :) Of course, no matter what we decide, there is nothing to stop people from *not* contributing their code into the main PEAR repository. Not all Perl modules are in CPAN. Or for starting their own PEAR-ish repository ... PHP Library of Unlisted Modules = PLUM ;) So no matter what some non-intuitiveness will eventually creep in. I just think that'll be a by-product of PHP becoming so popular. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] always building cgi...
On the implementation side, I'm not convinced of the usefulness of such a change. The way libphp4.la is built directly depends upon the chosen SAPI module (thread-safety, shared/static). As of today, there are only a few possible combinations. From day-to-day experience, I have yet to see an installation where web-servers run parallelly (and which use PHP/require the same build options). FWIW, 99% of the time when I build PHP I build the Apache module and the CGI at the same time with the same ./configure scripts. The module is for the website and the CGI is for cron scripts, inetd daemons, etc.. I am very much in favour of a way to compile both at once. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Disable sessions?
Okay, this may be a stupid question ... but what is the php.ini directive to disable sessions? I've got several virtual hosts running on one box, and I'd like for one of them to not use sessions at all. If there isn't a directive to do it, may I suggest: session.save_handler = none -- Colin Viebrock Co-Founder, easyDNS Technologies Inc. http://www.easyDNS.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] DOMXML rewrite
I noticed that you did a rewrite of the domxml code lately. Would that be
why the following code I have doesn't work anymore?
$tree = xmltree($string);
if ($tree-root-name != 'foo') {
...
}
It appears that the DomDocument object doesn't have the -root property
anymore. Am I right?
Do I need to use $tree-children-0-name now, or will you add $tree-root
back in?
--
Colin Viebrock
Co-Founder, easyDNS Technologies Inc.
http://www.easyDNS.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: What have you done to your website!!! ???
But the h2 / h3 / h1 elements look like lego-blocks for me. :) This must be caused by the fact that I don't have Arial font in my system..using the defaults fonts (overriding the document specified) 'fixes' this. Why not use 'Verdana' ? It's more readable font, IMO. If you don't have Arial, shouldn't your browser go to the next font in the list (i.e. Helvetica)? I can't find your first email ... did you mention what browser/platform this is on? - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Session-based authentication and Netscape 6 problems
Apologies in advance for the cross posting, but I imagine this issue affects
several users here. I'm not on the general PHP mailing list, so please cc
me off-list if you have any comments.
So ...
I just spent the last 2 days tracking down a bug in my own authentication
class. Since my class was kinda based on PHPLIB, this may affect PHPLIB
users too.
What happens is that when I go to one of my protected pages, the server
sends a "Location:" header to redirect to the login form. The login form
then POSTS to the protected page again ... which includes the auth code, and
either redirects to the login form again (for failed user/pass combos) or
continues on for successful authentication. Basically, your standard
session-based auth process.
What seemed to be happening if I visited the site using Netscape 6, was that
all the pages were being served by the server (logs verify this), but the
browser wasn't "refreshing" with the new location. I say "refreshing",
because if I did a view source, I could actually see the source to the
protected page, and I was logged in (looking at the session files verified
this). However, the browser still showed the login page.
Unfortunately, I tried to condense my code into something very simple that
reproduced the problem consistantly. Simple code, however, seemed to work.
Anyway, to make a long story a bit shorter, a lot of searching on the web
revealed a few similar bugs, so I tried adding the following to my Apache
conf file, and all seems to be fixed:
BrowserMatch "Mozilla/5" nokeepalive
This seemed to have been a problem with Netscape 2.x browsers too. I can
only guess that when doing a 302 redirect, i.e. Header("Location: ..."), if
the page to which you are redirecting is too big, then Netscape 6.x seems to
receive all the data but not refresh the browser window to display the new
data.
This is more of a NS6/Mozilla bug than anything else. Just thought it might
affect anyone here using session-based authentication.
--
Colin Viebrock
Co-Founder, easyDNS Technologies Inc.
http://www.easyDNS.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] DOMXML documentation
Is there any way to convince someone to write more extensive documentation on the DOMXML functions? -- Colin Viebrock Co-Founder, easyDNS Technologies http://www.easyDNS.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] DOMXML documentation
Two specific questions that maybe you or someone can answer: When building an XML document: a) how do I set the encoding and standalone attributes of the document? b) how can I specify the DOCTYPE? i.e., how do I add this line to the resulting XML: !DOCTYPE my_root SYSTEM "my.dtd" Thanks -- Colin Viebrock Co-Founder, easyDNS Technologies http://www.easyDNS.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
