[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c

[Colin Viebrock]

> 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 é and Ä (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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard info.c

[Colin Viebrock]

> And I wonder why do you think it is so important to show the characters 
> like é or ä 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 é or ä.
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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Plan for PHP 5.0

[Colin Viebrock]

> 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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard css.c

[Colin Viebrock]

> 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 Thé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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard css.c

[Colin Viebrock]

>> 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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard css.c

[Colin Viebrock]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard css.c

[Colin Viebrock]

>>   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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: phpinfo() problems

[Colin Viebrock]

Would this problem be solved if the META tag that defines the character
set is hard-coded to use US-ASCII or ISO-8859-1, instead of going
through the process it does now to try and determine a charset?

- Colin

Yasuo Ohgaki wrote:
> 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.
> 
> Second problem, phpinfo() output should not automatically
> converted to html entity unless correct charset is used
> when chars are converted to entity. Otherwise, characters
> may be broken. Please do not try to use UTF-8 always to fix
> since UTF-8 does not support everything.
> 
> Due to these two problems, phpinfo() output is much less
> useful for me than used to be.
> 
> I hope someone responsible will fix it.
> 
> --
> Yasuo Ohgaki
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] auto_prepend/append: does the PHP engine cache the

[Colin Viebrock]

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:



  

  

  


  

  

  ... etc ...
  


Is this possible in PWEE right now?  If not, would you consider adding
support for it?

- Colin


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: phpinfo() output

[Colin Viebrock]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] autoconf version

[Colin Viebrock]

I run buildconf and get:

...
buildconf: autoconf version 2.53 (ok)
buildconf: Your version of autoconf likely contains buggy cache code.
   Running cvsclean for you.
   To avoid this, install autoconf-2.13 and automake-1.5.
...

I'm just wondering if that's a mistake.  Does 2.53 contain buggy cache
code and is downgrading my version of autoconf really the appropriate
solution?  Or was the cache issue solved in a later version, and the
buildconf message needs to be updated?

- Colin


-- 
PHP Development Mailing List 
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

[Colin Viebrock]

> 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 
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

[Colin Viebrock]

> 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 
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

[Colin Viebrock]

> 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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: ICAP/MCAL

[Colin Viebrock]

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 
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

[Colin Viebrock]

> 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 
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

[Colin Viebrock]

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 
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

[Colin Viebrock]

I can't get to it either through the web, or through NNTP.

- Colin



-- 
PHP Development Mailing List 
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

[Colin Viebrock]

> > 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 
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

[Colin Viebrock]

"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]

[PHP-DEV] xmlrpc extension in 4.1.0

[Colin Viebrock]

Any docs on using this extension?

- Colin


-- 
PHP Development Mailing List 
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

[Colin Viebrock]

> 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 
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/

[Colin Viebrock]

I suppose the text here needs to be revamped in light of the Zend license
change.

- Colin



-- 
PHP Development Mailing List 
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

[Colin Viebrock]

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]

[PHP-DEV] Re: configure error in PHP3

[Colin Viebrock]

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 
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

[Colin Viebrock]

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-general&m=97498417629870&w=2

Any help would be appreciated.

- Colin




-- 
PHP Development Mailing List 
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

[Colin Viebrock]

> > 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 
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

[Colin Viebrock]

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:

d');
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 
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

[Colin Viebrock]

Nevermind ... I just saw the bug report and notice that it's fixed in CVS.

- Colin



-- 
PHP Development Mailing List 
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

[Colin Viebrock]

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 
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 ... ?

[Colin Viebrock]

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 
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

[Colin Viebrock]

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 
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

[Colin Viebrock]

> 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 
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

[Colin Viebrock]

> 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 
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

[Colin Viebrock]

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 
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

[Colin Viebrock]

> 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 
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.

[Colin Viebrock]

> (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 
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

[Colin Viebrock]

> 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 
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)

[Colin Viebrock]

> 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 
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)

[Colin Viebrock]

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 

[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


Parse error:  parse error in x.php on line 4
[cmv@sunniva Reg]$ 


- Colin



-- 
PHP Development Mailing List 
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.

[Colin Viebrock]

> > 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


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 
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

[Colin Viebrock]

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 
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

[Colin Viebrock]

> >>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 
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

[Colin Viebrock]

> 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):

...
curl.c: In function `php_minit_curl':
curl.c:175: `CURLOPT_FILETIME' undeclared (first use in this function)
curl.c:175: (Each undeclared identifier is reported only once
curl.c:175: for each function it appears in.)
curl.c:179: `CURLOPT_HEADERFUNCTION' undeclared (first use in this function)
curl.c:180: `CURLOPT_MAXREDIRS' undeclared (first use in this function)
curl.c:181: `CURLOPT_MAXCONNECTS' undeclared (first use in this function)
curl.c:182: `CURLOPT_CLOSEPOLICY' undeclared (first use in this function)
curl.c:183: `CURLOPT_FRESH_CONNECT' undeclared (first use in this function)
curl.c:184: `CURLOPT_FORBID_REUSE' undeclared (first use in this function)
curl.c:185: `CURLOPT_RANDOM_FILE' undeclared (first use in this function)
curl.c:186: `CURLOPT_EGDSOCKET' undeclared (first use in this function)
curl.c:187: `CURLOPT_CONNECTTIMEOUT' undeclared (first use in this function)
curl.c:192: `CURLCLOSEPOLICY_LEAST_RECENTLY_USED' undeclared (first use in
this function)
curl.c:193: `CURLCLOSEPOLICY_OLDEST' undeclared (first use in this function)
curl.c:208: `CURLINFO_FILETIME' undeclared (first use in this function)
curl.c:258: `CURLE_TOO_MANY_REDIRECTS' undeclared (first use in this
function)
curl.c:259: `CURLE_UNKNOWN_TELNET_OPTION' undeclared (first use in this
function)
curl.c:260: `CURLE_TELNET_OPTION_SYNTAX' undeclared (first use in this
function)
curl.c:261: `CURLE_ALREADY_COMPLETE' undeclared (first use in this function)
curl.c: At top level:
curl.c:283: conflicting types for `curl_write'
/usr/local/include/curl/curl.h:569: previous declaration of `curl_write'
curl.c:333: conflicting types for `curl_read'
/usr/local/include/curl/curl.h:567: previous declaration of `curl_read'
curl.c: In function `php_if_curl_setopt':
curl.c:589: `CURLOPT_FILETIME' undeclared (first use in this function)
curl.c:590: `CURLOPT_MAXREDIRS' undeclared (first use in this function)
curl.c:591: `CURLOPT_MAXCONNECTS' undeclared (first use in this function)
curl.c:592: `CURLOPT_CLOSEPOLICY' undeclared (first use in this function)
curl.c:593: `CURLOPT_FRESH_CONNECT' undeclared (first use in this function)
curl.c:594: `CURLOPT_FORBID_REUSE' undeclared (first use in this function)
curl.c:595: `CURLOPT_CONNECTTIMEOUT' undeclared (first use in this function)
curl.c:615: `CURLOPT_RANDOM_FILE' undeclared (first use in this function)
curl.c:616: `CURLOPT_EGDSOCKET' undeclared (first use in this function)
curl.c:667: `CURLOPT_HEADERFUNCTION' undeclared (first use in this function)
curl.c: In function `php_if_curl_getinfo':
curl.c:844: `CURLINFO_FILETIME' undeclared (first use in this function)
make[3]: *** [curl.lo] Error 1
make[3]: Leaving directory `/usr/local/sources/php-4.0.6RC1/ext/curl'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/sources/php-4.0.6RC1/ext/curl'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/sources/php-4.0.6RC1/ext'
make: *** [all-recursive] Error 1
[root@sunniva php-4.0.6RC1]#


-- 
PHP Development Mailing List 
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

[Colin Viebrock]

> 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 
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

[Colin Viebrock]

> > Do you know what to revert to? Apparently it didn't work in 4.0.5
either.
>
> Huh? Revision 1.29 says "complete rewrite of domxml module", and 1.28 is
> where 4.0.5 was branched so that's what you'd revert back to.

I'm sorry but I'll be a wee bit annoyed if all the code I rewrote for the
4.0.5 "version" of the DOMXML functions needs to be rewritten to go back to
the 4.0.4 version.  :(

FWIW, I've been using the 4.0.5 and CVS version flawlessly" no core dumps,
segfaults or other weirdness.

- Colin


-- 
PHP Development Mailing List 
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

[Colin Viebrock]

> 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 
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

[Colin Viebrock]

What I do when I need multidimensional arrays from forms, is name my
variables:



i.e., I delimit the dimensions with "::".  Then, on the page they are posted
to, I do:



And here is the code for that function, which looks for all the variables
that start with 'i::' and creates the multidimensional array needed.

$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

[Colin Viebrock]

> 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 
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

[Colin Viebrock]

> 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 
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

[Colin Viebrock]

> 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 
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?

[Colin Viebrock]

> 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 
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

[Colin Viebrock]

> Full name: Virsago Vahniir
> Email: [EMAIL PROTECTED]
> ID: Taros
> Purpose: Personal Webpage

Hehehe ...

- Colin


-- 
PHP Development Mailing List 
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?

[Colin Viebrock]

> 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 
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

[Colin Viebrock]

> 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 
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?

[Colin Viebrock]

> I added an error of level E_NOTICE for this.

Thanks.

- Colin


-- 
PHP Development Mailing List 
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

[Colin Viebrock]

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 
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?

[Colin Viebrock]

Parse error: parse error, expecting `T_PAAMAYIM_NEKUDOTAYIM' or `'('' in
/path/to/file.php on line 246

Zeev/Andi ... ?  :)

- Colin


-- 
PHP Development Mailing List 
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

[Colin Viebrock]

> > 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 
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

[Colin Viebrock]

> 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 
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

[Colin Viebrock]

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] always building cgi...

[Colin Viebrock]

> 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 
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?

[Colin Viebrock]

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

[Colin Viebrock]

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!!! ???

[Colin Viebrock]

> But the  /  /  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 
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!!! ???

[Colin Viebrock]

> Oh? Have you installed some truetype support? As for me the fonts
> are way too small and some look like lego-blocks. :)

Can you too look again?  At least look at http://ca.php.net (which I
can update instantly).

I changed the style sheet to use percentages instead of absolute pixel or
point sizes.  Does that make things look better for Jani, and still look ok
for Andrei?

- Colin


-- 
PHP Development Mailing List 
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

[Colin Viebrock]

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]

RE: [PHP-DEV] DOMXML documentation

[Colin Viebrock]

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:



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]

RE: [PHP-DEV] DOMXML documentation

[Colin Viebrock]

> On Wed, Jan 24, 2001 at 01:00:02PM -0500, Colin Viebrock wrote:
> > Is there any way to convince someone to write more extensive 
> documentation
> > on the DOMXML functions?
> Try to convince me :-)
> 
> I'll see what I can do.

Well, I'm not asking much :)

a) List all the functions and their syntax.
   (e.g., domxml_new_xmldoc(), domxml_add_root() , aren't listed now)

b) List all the methods and properties for each of the DOM object types,
   and their syntax.  (e.g. the DomNode object has a setattr() method ...
   how do you use it?  the DomDocument object has a "standalone" property
   ... how do you set it?)

Right now, it's takes a bit of work to try and figure out how to parse 
XML documents.  But it takes a *lot* of work to try and figure out how
to *generate* XML documents.


-- 
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

[Colin Viebrock]

> have you already tried these?
> http://www.zugeschaut-und-mitgebaut.de/php/extension.domxml.html

This one is helpful, but it doesn't expose some of the methods
for the DOM-type objects (i.e., DomDocument, DomNode, etc.).
Knowing these methods and their syntax is important when using 
the DOMXML functions to generate XML documents.

> http://www.dynamicwebpages.de/05.tutorials.php?tutorialID=222

Wish I spoke German ... :)

> http://www.circle.ch/projects/?cat_id=2&art_id=5

Very handy, thank you!

-- 
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]

[PHP-DEV] DOMXML documentation

[Colin Viebrock]

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]