Re: [PHP-DEV] php.exe - php-cgi.exe
On Sunday 08 December 2002 01:02, John Coggeshall wrote: I think a big ole' message at the end of ./configure will drastically reduce the number of problems. With php.exe? *g* Also, perhaps a check could be put in the CLI version of PHP that would throw an error message if it is being used as a CGI... A _meaningful_ error-message in the right place would be the right thing (tm). Too many people don't read release-notes. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Monday 25 November 2002 21:55, Sascha Schumann wrote: Whereas assuming that PHP users are too stupid to understand english is not at all arrogant? :) Wrong, Sterling. Beginning PHP users might neither have formal education in computer science _nor_ foreign languages. Perfectly true. Some people just lack education, or are too young or too old. The average newbie: - uses M$ Windows - with a WAMP-all-in-one package, or, failing to know such things exist, uploads to some free webspace for testing - thinks PHP-Nuke is the high art of programming - doesn't even know that there is such a thing as a manual I happen to help these people rather often... there are a lot of them. If you just put a translation online... believe me, they're never going to find it. The people who will find it probably won't need it. If you want these people to find this translation, you'd have to put the url into every error-message. And provide a way to change the root-url, so it can be downloaded The strength of PHP is that, for some reason, it's so easy to use that even people with no programming background at all use it, very often with a complete lack of skill and a minimum of effort. From the perspective of newbies, translated error-messages are definately the right thing (tm). If you want them to find the translation, you have to present it in a way that they cannot possibly miss it. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Monday 25 November 2002 23:08, Daniel Lorch wrote: I would prefer to have the developers getting used (yes, meaning educate them) to english being a universal language, for both the language constructs, error messages, documentation. Don't. You shouldn't think of PHP-users as developers in this sense. Read my other mail. I mean the don't even want to program and least amount of effort-part. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Monday 25 November 2002 22:43, Daniel Lorch wrote: Developers don't have to be spoon-fed. Really. Some do. Especially among PHP-developers. Imagine your neighbour to be a PHP-developer. Maybe he has a hobby, like fishing. Maybe he has a website about this. With PHP, he might even make that website dynamic, create an online-community or something. I met a hobby-photographer who built a photographer community. When he began, he didn't know shit about programming, after a while, he had to make a pay-service (more features for paying people) because the traffic became too expensive. I met a sociologist who who had done rather complex web-surveys, and didn't even know what switch() does. I regularly help people like some gamer who wants to make a clan-page, or people who try to reinvent the guestbook-wheel. You wouldn't believe how many of these people exist. They don't even want to program. They don't want do dig documentation, sharpen their devlopment-skills or anything, all they want is a working webpage. With the least amount of effort possible. Right now, PHP is the tool of choise for these people, because it's rather easy to learn, and webspace with PHP is cheap. Localized error-messages would definately make these people's lifes easier, PHP would be even easier to use for them. You'd gain even more users. If you don't think it's worth the effort, don't do it, but don't think developers don't need this. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Monday 25 November 2002 23:29, Daniel Lorch wrote: You're right. We should think about writing a colorful GUI for PHP, so scripts just can be clicked together. Oh, and it definitively should support skins.. I don't think this would work. But if it did, it's place wouldn't be inside the language. Either in an IDE or in a PHP-application. PHP often is used for skinning a website, btw. But if there were a good idiot-proof IDE, it would definately help these people. It would have to be free (beer), of course. People who spend 2,50€ a month on webspace won't spend a fortune on an IDE. On the other hand, you lose a lot of flexibility this way. At some point, people will have to touch the code. And there should be as few obstacles as possible. I can absolutely understand your argumentation (which you forgot to CC to the list, by the way) and being a regular to PHP-DE (german PHP users mailinglist), I am also in touch with people you described. But what's wrong about just HREF'ing to the manual, which is localized anyway? You'd have to put a href in every single error-message. Ugly. Either this, or people won't find it. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Monday 25 November 2002 23:49, Jani Taskinen wrote: If you want these people to find this translation, you'd have to put the url into every error-message. And provide a way to change the root-url, so it can be downloaded I thought we already have these both..? By default? Does it lead to a translation of the error-message, or some other description of what the error-message means? Remember. I'm talking about the people that have to be spoon-fed. Anyway, I'm just dreaming. All those newbies who ask questions like what does this error mean or My code doesn't work. Why? might be able to answer some of these questions themselves. But sometimes, dreams come true :-) regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tuesday 26 November 2002 00:07, Jani Taskinen wrote: Remember. I'm talking about the people that have to be spoon-fed. Well..to be quite honest: I don't care about such people. To be honest, they tend to piss me off a little (at least some do). Getting rid of these stupid questions... ah... dreaming again... They're not working with PHP, they just use it for fun. Every _serious_ developer definately knows enough english.. Not necessarily. There are still those that are too young, and those that are too old. PHP has a very wide userbase. But you're not that wrong... anybody who is serious will find a way to understand it. But PHP is very popular among people who are _not_ serious. Some become serious. After the got in touch with programming. After they got their first site to work. Removing obstacles is mostly a good thing. PHP is very easy to use already. This is just one point where it still can improve. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.2.3 mbstring patch?
On Thursday 14 November 2002 07:10, lowbwtom wrote: Will there be a patch to fix the mbstring bug in 4.2.3? Any idea when? (specifically to fix the missing 4 characters in array posts) This bug is definitely a show-stopper. There are _many_ PHP-applications out there that use arrays in forms, and many of these are screwed up. For those who can choose their PHP-Version, it means sticking to 4.2.2 For those who can't, it means either doing ugly workarounds or (if they can't chance the source), being out of business until 4.3 is out, which won't be tomorrow. Bad. Some of us have been totally screwed by this bug - since our isp's have updated to 4.2.3 and left everyone's sites totally broken. They refuse to drop back to old version and are leaving everyone up the creek until php 4.3.0 is in final release or a 4.2.3 patch is released. Time for a 4.2.3pl1, I think. regards Wagner -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch-tastic!
Sebastian Bergmann wre: Andrei Zmievski wrote: The latest one changes some operators. Nice, but why not overload + for strings to do the concatenation? No way. Many people don't know (think newbies here) what types their variables have, and don't care. This feature would quickly introduce more bugs into PHP-programs than register_globals did in its entire lifespan. Operators should be as type-independent as possible. Only objects might be an exception. regards Wagner -- When did ignorance become a point of view? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Patch-tastic!
Rasmus Lerdorf wrote: Not very useful. But certainly very cool. Somehow. Where are the people begging for complexity in the language? ;-) regards Wagner -- When did ignorance become a point of view? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
brad lafountain wrote: Ok, But take ext/domxml it requires a newerversion of libxml2. I didn't have it installed on my machine when i installed php. If we bundle say a specfic version of libxml2 that domxml depends on, then it won't matter how fast pased the development is, ext/domxml won't use it. We can obvisouly peridocially upgrade the version that is bundled and you can have an override if you want to use a different version that is installed on a system. As xml gets more and more popular i feel that domxml will be more and more popular. I'd make it an optional download, because there are always people like me who have all the libraries already installed with their distro. People with non-deb distros or who are lacking skills with Linux but want to do it anyway would definately benefit from this. It would be for pure convinience, like all the precompiled libraries bundled with the Windows-download, gdlib is an entirely different matter. regards Wagner -- When did ignorance become a point of view? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Computer Science and PHP
Manuel Lemos wrote: There is no doubt about that, but the original poster was asking why PHP is not part of college curriculum and I was explaining that unlike other languages that are marketed by companies with big brands, there is no big brand behind PHP to push it at any comparable level. While I agree that better marketing would greatly benefit PHP, and might even get it into some universities, I don't think it is the main obstacle. IMHO PHP does not have much of a place in university. Languages like Haskell, Scheme and Gopher, have always been quite successful in university although there has rarely been anything useful done with them in the world outside and marketing behind them has always been near zero. Universities care a lot about concepts, or how to do it right. PHP's focus is on people who are new to programming and on do it right now. The latter, aka Worse is better, while being successful and important in the free world, is not very suitable for universities. PHP's design is not very clean, that never was the goal and it's probably better this way., because what PHP wanted to achieve it did achieve (I think). I can't think of very much actual facts (as opposed to marketing) that would make universities interested in PHP. One of those I can think of is MetaL, btw. To illustrate what I am say, althought it was not a language but a Open Source OS, Linux did not start taking much credit until Red Hat started distributing it and entered to NASDAQ. From then on, Red Had become a big brand (at least a noticeable one) and Linux was not necessarily the best free Unix like OS. Red Hat made it a big deal as we all know. Linux was successful in universities before it was successful outside. PHP is very successful outside, and I fear that conquering universities from where PHP is successful now is simply neither very probable nor, at the current state of PHP, very desirable. regards Wagner -- Never attribute to malice what can as easily be the result of incompetence. -- 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: Moving extensions to PECL
Jim Winstead wrote: no objections, but one thing that should be considered is what happens to the documentation for these extensions when they are no longer a part of the core distribution. QA too. I suppose removing some of these less frequently used extensions will also help make the QA team's job a little easier, too. sounds dangerous to me. regards Wagner -- When did ignorance become a point of view? -- 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: [2]: [PHP-DEV] Re: Shootout
Daniel Lorch wrote: it would be nice to see PHP w and w/o ZEND competing against each other. Zend what? I'd like to see it with/without ZendAccelerator. absolutely *no* reasonable programmer will ever use PHP to calculate prime numbers or fractals (maybe with mathematical extensions, but not with raw PHP code). Perl and the like are used a lot in bio-informatics, and they are scripting-languages. Even in CPU-intensive areas, ease of development can be important. face it: PHP is just a layouting engine. it collects data from different sources, gives it the final polish (formatting) and outputs it. nothing more. and YES it's a very feature-rich layouting engine and an excellent one, too. PHP is a general-purpose language aimed at web-applications. That's more than just layout. A lot more. regards Wagner -- Cynic, n.: A blackguard whose faulty vision sees things as they are, not as they ought to be. -- Ambrose Bierce, The Devil's Dictionary -- 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: [3]: [PHP-DEV] Re: Shootout
Daniel Lorch wrote: just wanted to add something: java is quite successful in commercial applications. not because it's fast, but because you have an excellent ability for code reusage. you can compile java beans into both applets and servlets. people are ready to pay the loss of performance because development time is cut down drastically. PHP allows you to produce perfectly reusable code, but it doesn't force you to do that. It doesn't force you to use paradigms that often are just in the way. development time and code maintenance are much more important than raw performance power nowadays - at least for commercial applications. PHP is very good for rapid worse is better style of coding, while being scalable enough to allow somewhat bigger applications. It's a lot prettier than Perl ;-) General purpose may strech it a bit too far, but PHP is suitable for far more than layout. regards Wagner -- Cynic, n.: A blackguard whose faulty vision sees things as they are, not as they ought to be. -- Ambrose Bierce, The Devil's Dictionary -- 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] unsubscibe
Oleg Nazarevych wrote: unsubscibe try unsubscribe with r regards Wagner -- Cynic, n.: A blackguard whose faulty vision sees things as they are, not as they ought to be. -- Ambrose Bierce, The Devil's Dictionary -- 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] exit()
Andi Gutmans wrote: As Derick pointed out, it still prints... Huh? What do you mean? exit(,0) wouldn't print anything. Wouldn't break BC either, would it? regards Wagner -- Cynic, n.: A blackguard whose faulty vision sees things as they are, not as they ought to be. -- Ambrose Bierce, The Devil's Dictionary -- 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] exit()
Yasuo Ohgaki wrote: exit(,0) wouldn't print anything. Wouldn't break BC either, would it? No, I don't think it prints any of course. It just seems strange to me ;) Sure, it looks arkward, but it should be fine for 4.x. IMHO it should be nuked for PHP 5, though. Sometimes BC has to be broken. regards Wagner -- Cynic, n.: A blackguard whose faulty vision sees things as they are, not as they ought to be. -- Ambrose Bierce, The Devil's Dictionary -- 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] exit()
Yasuo Ohgaki wrote: exit(,0) wouldn't print anything. It works, but question is Is this really good fix? or good change to have? I don't expect 100% compatibility for any language if there is major version up. I suppose many people want/keep clean syntax, instead of keeping compatibility for this. There are many BC changes in many languages including PHP, aren't there? Sure, but three things: a) BC changes can be made, when necessary. I don't see why breaking BC is necessary here. People actually using PHP for shell-scripts and such should be able to cope with strange look of their exit-call. b) Changing exit()'s behaviour would break a lot of code and would introduce those really nasty bugs that are hard to find and you end up with an annoyed customers on the phone who doesn't know what happened because an error-message wasn't printed. c) I don't see another major version before PHP 5. But then I'd clean it up. regards Wagner -- Cynic, n.: A blackguard whose faulty vision sees things as they are, not as they ought to be. -- Ambrose Bierce, The Devil's Dictionary -- 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: Re[2]: [PHP-DEV] sendmail_from in linux installation
Javier Crespo wrote: if you omit the 4th argument, it's your MAIL TRANSFER AGENT (i.e. qmail, sendmail, exim, ...) which puts in the [EMAIL PROTECTED] and not PHP. have a look at your MTA's manual for this problem. I know, And that's my problem. All mail is sent by nobody (this is ok) or whatever is passed in 4th to mail function (this also is ok). Perhaps forget to comment. I'm hosting multiuser virtual server domains in my apache server. All of them php enabled, and not all users are well known. You're using PHP as APXS/Module? Try CGI with suexec instead, this is what mass-hosters usually do, AFAIK. Safe-mode isn't very popular. I've never configured sendmail myself, but it should be possible to block access for certain users, I guess, so this might helf you out. regards Wagner -- Cynic, n.: A blackguard whose faulty vision sees things as they are, not as they ought to be. -- Ambrose Bierce, The Devil's Dictionary -- 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 #14381: xlst_error causes error with valid XSLT processor instance
Am Freitag 07 Dezember 2001 18:33 schrieb Rasmus Lerdorf: AFAIK (and according to the manual) the first argument to xslt_process() should be a string containing the XSL data ($xslData) and not the XSLT processor handle. Please advise. Then the manual is wrong. The code is clearly expecting arguments in this order: ext/sablot or ext/xslt ? The manual seems to be right for old ext/sablot. Are you two talking about the same extension? regards Wagner -- He's dead Jim No I'm not! I'm feeling much bet- ZZZAP! -- 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] [NEW EXTENSTION]: templates
Björn Schotte wrote: - anything else? you tell me Feature set from PHPLIB's Template class. IT[X]-Style interface for blocks. regards Wagner -- Never attribute to malice what can as easily be the result of incompetence. -- 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] [NEW EXTENSTION]: templates
Björn Schotte wrote: Political reasons[2]. Template engine? No problem, it is integrated into PHP - cravatti[1]: Oh, that's nice, let's choose PHP [1]: anyone has a nice English expression for the german Schlipsträger? Pointy haired boss? regards Wagner -- Never attribute to malice what can as easily be the result of incompetence. -- 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] [NEW EXTENSTION]: templates
Björn Schotte wrote: * Sebastian Bergmann wrote: I don't see the need for the 23042th template solution in or for PHP, the future belongs to XML and XSL(T) anyhow. Web designers and pixel movers are yet too dumb to check how XSL(T) works. Ack. So they prefer template solutions like PHPLIB/IT[X], as Smarty is only usable for programmers (and as Kris said, a template engine should not be a full fledged turing engine). You have a point here, but you're not necessarily right. Smarty templates are more complex than IT[X]/PHPlib-style templates, but still easier than XSL, and not all designers are that dumb. I think IT[X]-style templates are more important, but I wouldn't object to having both. regards Wagner -- Never attribute to malice what can as easily be the result of incompetence. -- 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] Feature Request: add HTML 4.01 support into DOMXML extension?
Andrei Zmievski wrote: there's no point in using a home-brewn scripting language to do those tasks, is there? all the constructs are already part of the php language... Are you aware of the concept of domain-specific languages? There is a point. Are you done? I'm definately with you here, Andrei. Templates are simple but they aren't brain dead. *Plonk*. But, even if we don't agree with his opinion on templates, what about the features that libxml provides which are currently unused by PHP, including HTML 4.01-support (I don't know exactly what libxml can do)? Are there any plans to make them accessible from PHP? It definately would be nice. regards Wagner -- Never attribute to malice what can as easily be the result of incompetence. -- 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] Current CVS + Apache2 on Linux
Andrei Zmievski wrote: On Thu, 25 Oct 2001, Hartmut Holzgraefe wrote: diff -u2 -b -w -B Uh, what do these options do? They aren't documented in my version of CVS (1.11). man diff -b Ignore changes in amount of white space. -B Ignore changes that just insert or delete blank lines. -w Ignore white space when comparing lines. -u Use the unified output format. --unified[=lines] Use the unified output format, showing lines (an integer) lines of context, or three if lines is not given. For proper operation, patch typically needs at least two lines of context. regards Wagner -- Ein Mathematiker ist eine Maschine, die Kaffee in Theoreme verwandelt. Paul Erdös, Mathematiker, 1913-1996 -- 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: Security e-mail address
Jani Taskinen wrote: So what's wrong in keeping them public? If they are false alarms, why not keep them public and show all other people who think they found serious security related bugs that they are wrong? If it's opensource KEEP it open. There can't be any closed 'groups' which get some info in this kind of projects. If there are, it's no longer opensource..IMO. Even for open source projects, it is good practice to keep security issues closed until a fix has been released. As long as there is no fix, making it public won't help anyone except the black hats. IMO. And possible security issues shouldn't be considered bogus by default. regards Wagner -- Ein Mathematiker ist eine Maschine, die Kaffee in Theoreme verwandelt. Paul Erdös, Mathematiker, 1913-1996 -- 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] A php's patch for support xhtml
Stig Sæther Bakken wrote: Will newbies really use XHTML? Right now? Probably not. Or at least it's rare. But I hope this will change, and IMHO PHP shouldn't be standing in XHMTL's way. Anyway, people have been embedding PHP in WML and other XML formats without visible problems for a while now. So far people embedding PHP in XML-documents were people who knew what they were doing. Ever seen someone do his private homepage in WML? IF we are to add another Apache type mapping for this, it should be application/x-httpd-php-xml. Ack. IMHO it adds complexity to PHP without really solving any problems that could not be configured around. You got a point here, but I see two issues. First, configuring around is more difficult. Even if it's documented, it woud always be custom configuration. The additional Apache type might be part of the default config. If using PHP inside XML makes an httpd.conf or .htaccess modification necessary, it is sure to scare of some newbies, who might have used XHMTL otherwise. Making it easier to use PHP embedded in XML is not going to save the world, but scaring less newsbies off using XHMTL should be good enough for some warm fuzzy feeling, shouldn't it? ;-) Anyway, some day in the future, when using XHTML is more common, it will be a problem that php in default config is not embeddable in XHTML. Solving the problem before it actually occurs might be a good idea. Second, many ISPs use CGI-sandboxes, neither php_value nor the alternative Apache type will work there, will they? What about this? What about non-APXS server-APIs? Maybe the Apache-Type approach is bullshit, but the problem is there, and IMHO now (or after 4.07 is final) might be just the right time to solve it. regards Wagner -- Ein Mathematiker ist eine Maschine, die Kaffee in Theoreme verwandelt. Paul Erdös, Mathematiker, 1913-1996 -- 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] A php's patch for support xhtml
Stig Sæther Bakken wrote: 1.Add a mime/type application/x-httpd-php-xhtml to mark xhtml mode. 2.disable short-tags and asp-tags in xhtml mode. 3.add php ... /php instead ? ... ? and php-v eval=/ instead ?= ? 4.ignore '![CDATA[' and ']]' in script block. Since XHTML is XML, ?php ... ? is the proper way of embedding PHP in XHTML files. +1 But this resolves only points 3 and 4. What about the first two? IIRC there was nothing done about PHP producing parse errors on ?xml and other PIs with short-tags enabled? XHTML is spreading and newbies might soon run into problems with short-tags, since these are activated on most ISPs I know of. Deactivating them via .htaccess is a little too difficult for most newbies. How about an instruction like good old ?php_track_vars?, which, when placed at the top of the script, would deactivate short-tags? Or is this possible via ini_set()? regards Wagner -- Ein Mathematiker ist eine Maschine, die Kaffee in Theoreme verwandelt. Paul Erdös, Mathematiker, 1913-1996 -- 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: Bug #13388 Updated: Could not connect to server
Gossi, Dean wrote: What information are you looking for..I just told you how to reproduce it. What me to fix it for you... The information you provided boils down to that on Win2k SP2, IIS, mail() works for you when PHP runs as CGI, but not as a module. Since only mail() doesn't work for the module, and does for cgi, I (and probably you, too) assume that PHP is installed correctly. Module = CGI is the only difference, so this might be the problem. (side note: regarding how few information you provided, your report was a little too long) This is why you'd prefer this bug to be reproduced by someone of the qa-team rather than being bogusified. But a developer who knows PHP (and Derick sure does, far better than I do, anyway, he is in the php-dev team, not me) will notice that the change in the (server-API) should not affect the mail function, they are not related (I assume). This is either a pretty strange side-effect, or a configuration issue. IIS might be a little strange sometimes. And although IIS is not the most common webserver used with PHP, there is quite a userbase for this combination, many of them using PHP as a module. If mail() didn't work for all of them, it is quite strange nobody noticed. This makes it more probable that this is a configuration issue. This is why Derick bogusified the bug. I hope both sides see each others points now. Anyway, configuration issues are not bugs within PHP. Basically, what Derick and Jeroen ask you to do is to go ahead and ask on php-general and php-windows, two public mailinglists about php, if somebody knows this problem. If you don't find a solution, somebody else can reproduce this problem or you find out what the configuration problem was, feel free to ask for re-opening the bug-report (using the web-interface, not answering to the mail), request a change in the manual noting the config-problem or just add it yourself to the annotated manual. PHP is a community effort. You'd be part of this community then :-) If neither php-general nor php-windows can help you or you can prove that this bug can be reproduced on other systems, I'm sure the php-qa and dev teams will try to resolve this. You'd have to provide more information then. Like does PHP even try to connect to the SMTP-server or does it fail after the connect? Otherwise, it's hard to do remote diagnostics. I guess I should just use asp. With this type of developer support (2-5 word responses to your emails) I don't think php will cause any stir in the marketplace A response that basically says not enough input isn't required to be wordy, is it? Mind you, these people are volunteers. Also, for many of them english is not their native language, english is just the common ground they meet on. When you get something for free, please remember that you're not in a corporate environment. This is a community. If all parts (core-team and users in this case) are nice to each other, it makes the world a better place. Didn't Gartner just recommend not using IIS? Either having to install a patch every week or reinstalling the whole machine every few months? Is that a stir? When Microsoft tells you that with their software, you can do complicated things easily, you might not end up with what you wanted. I would recommend to try using Apache, it tends to be more reliable (this is just my opinion) and is more common (= tested) in combination with PHP. I heard a few really bad stories from people having used ASP who ended up with PHP and were happy. On the other hand, what else would you expect from the PHP-community? regards Wagner -- 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] Simple wildcard matching
Hartmut Holzgraefe wrote: First i wondered why there is no [p|e]reg function for encoding all the special chars available in regular expressions (which i still do) RTM ;-) http://php.net/preg_quote regards Wagner -- Madness takes its toll. Please have exact change. -- 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] Syntax error
Zeev Suraski wrote:
for ($sz=1; $sz 6; sz++) {
You're missing a $ on the last sz in this line
He knows that. He want a better error-message.
regards
Wagner
--
Never attribute to malice what can as easily be the result of
incompetence.
--
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] big memory problem with 4.0.6
fx wrote: with version 4.0.6 I had no problem with my sites moreover I had memory_limit = 8M with php = 4.0.5 with no problem and now I have memory_limit = 16M with 4.0.6 and that even doesn't solve the problem Wasn't there a patch for 4.06's memory limit on http://php.net/downloads.php ? regards Wagner -- Never attribute to malice what can as easily be the result of incompetence. -- 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] Satellite (Was: Re: [PHP-DEV] PHP 4.0.7)
Rasmus Lerdorf wrote: demo server at http://satellite.2good.nu I get a no data from that URL. Works fine for me. regards Wagner -- Madness takes its toll. Please have exact change. -- 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] Security Issues
Peter Petermann wrote: I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even knows what and how to do nowadays. I don't think turning register_globals to off will evangelize people to develop more secure scripts/applications. thats it. I see your point, but I disagree. Register_globals is a lanugage-feature which can result in security-gaps when people don't initialize their variables. It's a common mistake, a pitfall, especially for beginners, that could be resolved by turning register_globals off. There's a lot of beginners using PHP, and this wouldn't only make their applications a little more secure (just a little, but better than nothing), it will also teach them manners. Using $HTTP_*_VARS ist cleaner, IMO. what we could do to make people to write more secure script is: - telling them to do so, - telling them what is insecure - telling them why something is insecure - writing a special type of documentation, about how to write secure scripts Please, can you say beginner? Once people read that kind of stuff, they are not beginners any more. They aren't the problem. You can't force people to write secure applications, but you can make it easier. regards Wagner -- Madness takes its toll. Please have exact change. -- 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] Security Issues
Peter Petermann wrote: i dont think it is easier to write more secure applications with turning a feature of. In this particular case, it would. There are several reported cases of security-holes caused by this feature. Without it, there would be fewer insecure PHP-applications out there. Thats a fact. Thats the past. Now let's talk about the future. Turning register_globals off won't fix old code. If code relies on register_globals, people will fix it with foreach (Rasmus' example), or by turning register_globals on. But that's not the point. The point is that people who don't care about security or coding style (beginners or professionals, doesn't really matter) are less likely to write insecure code, because there's one mistake less that they can make. As long as they stick to the defaults, anyway. regards Wagner -- Madness takes its toll. Please have exact change. -- 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] trans-sid and Location: Header
Björn Schotte wrote: I had a talk with somebody whom I said that --enable-trans-sid would save time in his project. He implemented it but dropped me a note that he had to manually rewrite Header(Location: http://$HTTP_HOST/foobar.php;); URIs with the SID. So would it be able to implement trans-sid for the Location: HTTP Header? Trans-sid doesn't work with complete URL beginning with http://;, does it? Aren't these regarded as external links? BTW: I don't find it that difficult to rewrite the Headers manually. You don't have that many of them, usually. regards Wagner -- Madness takes its toll. Please have exact change. -- 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]
