php-general Digest 9 Nov 2009 00:23:29 -0000 Issue 6433

[php-general-digest-help]

php-general Digest 9 Nov 2009 00:23:29 -0000 Issue 6433

Topics (messages 299695 through 299712):

Die Page, Die! (Was: Preview button to show PDF without submitting post data?)
        299695 by: Dave M G
        299696 by: Ashley Sheridan
        299697 by: Dave M G
        299701 by: Nathan Rixham
        299704 by: Dave M G
        299705 by: Phpster

Re: Carriage Returns
        299698 by: John List
        299699 by: Eddie Drapkin
        299703 by: Nathan Rixham

Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
        299700 by: Tony Marston
        299702 by: John Black
        299706 by: Tony Marston
        299707 by: Eddie Drapkin
        299708 by: Tony Marston
        299709 by: Eddie Drapkin
        299710 by: Tony Marston
        299711 by: Robert Cummings
        299712 by: Tony Marston

Administrivia:

To subscribe to the digest, e-mail:
        php-general-digest-subscr...@lists.php.net

To unsubscribe from the digest, e-mail:
        php-general-digest-unsubscr...@lists.php.net

To post to the list, e-mail:
        php-gene...@lists.php.net


----------------------------------------------------------------------

--- Begin Message ---

PHP List,

Okay, so I've got a nice situation where a form has a preview button as
well as a submit button. When the user presses "Submit", the page
reloads, and it emails a PDF.

If the user presses "Preview", it launches a new page in a new window,
and also outputs a PDF directly to the user so they can review it.

All good, but I don't need that second window open once the PDF has been
shown to the user.

For some reason I can't kill that second window. I've tried two methods.
Killing it with PHP, and killing it with JavaScript.

Here's the PHP version:

if (isset($_POST['preview']))
{
  $pdf->Output("preview.pdf", "D");
  die("PDF　プレビュー出しました / PDF Preview Displayed");
}

Here's the JavaScript version:

if (isset($_POST['preview']))
{
  $pdf->Output("preview.pdf", "D");
  echo '<script type="text/javascript">javascript:self.close();</script>';
}

But in either case, I keep getting that second page coming out, with the
whole form rendered all over again.

How can I kill a page? Once the PDF is rendered, I don't need it. I'd be
okay if it came down to the browser then closed, but it would be better
if the server sent the PDF and didn't send the page.

Any advice would be much appreciated.

--- End Message ---

--- Begin Message ---

On Sun, 2009-11-08 at 21:38 +0900, Dave M G wrote:

> PHP List,
> 
> Okay, so I've got a nice situation where a form has a preview button as
> well as a submit button. When the user presses "Submit", the page
> reloads, and it emails a PDF.
> 
> If the user presses "Preview", it launches a new page in a new window,
> and also outputs a PDF directly to the user so they can review it.
> 
> All good, but I don't need that second window open once the PDF has been
> shown to the user.
> 
> For some reason I can't kill that second window. I've tried two methods.
> Killing it with PHP, and killing it with JavaScript.
> 
> Here's the PHP version:
> 
> if (isset($_POST['preview']))
> {
>   $pdf->Output("preview.pdf", "D");
>   die("PDF　プレビュー出しました / PDF Preview Displayed");
> }
> 
> Here's the JavaScript version:
> 
> if (isset($_POST['preview']))
> {
>   $pdf->Output("preview.pdf", "D");
>   echo '<script type="text/javascript">javascript:self.close();</script>';
> }
> 
> But in either case, I keep getting that second page coming out, with the
> whole form rendered all over again.
> 
> How can I kill a page? Once the PDF is rendered, I don't need it. I'd be
> okay if it came down to the browser then closed, but it would be better
> if the server sent the PDF and didn't send the page.
> 
> Any advice would be much appreciated.


I think you do, or where else would you show the PDF? Unless you force
the PDF to download when the user clicks the preview button, you are
left with the default option of the users browser, which will most
usually be to display the PDF in the browser window. 

Thanks,
Ash
http://www.ashleysheridan.co.uk

--- End Message ---

--- Begin Message ---

Ashley,

Thank you for responding.

> I think you do, or where else would you show the PDF? Unless you force
> the PDF to download when the user clicks the preview button, you are
> left with the default option of the users browser, which will most
> usually be to display the PDF in the browser window.

No, that's not what's happening. I'm not showing the PDF in a browser
window. It's being given to the user with the option to download or view
in a separate application.

So I am fine with the download option. That's what I'm doing now, I
suppose. So since the user is downloading the PDF, they don't need an
in-browser window to view it.

Once the PDF is downloaded/viewed, I want the new window to die by any
means necessary.

Surely there's a way.

-- 
Dave M G

--- End Message ---

--- Begin Message ---

Dave M G wrote:
> Ashley,
> 
> Thank you for responding.
> 
>> I think you do, or where else would you show the PDF? Unless you force
>> the PDF to download when the user clicks the preview button, you are
>> left with the default option of the users browser, which will most
>> usually be to display the PDF in the browser window.
> 
> No, that's not what's happening. I'm not showing the PDF in a browser
> window. It's being given to the user with the option to download or view
> in a separate application.
> 
> So I am fine with the download option. That's what I'm doing now, I
> suppose. So since the user is downloading the PDF, they don't need an
> in-browser window to view it.
> 
> Once the PDF is downloaded/viewed, I want the new window to die by any
> means necessary.
> 
> Surely there's a way.
> 

yup.. forget the new window all together, if you have it set to download
as an attachment then the user won't be taken away from the page; so no
need for a new window at all.

--- End Message ---

--- Begin Message ---

Nathan,

Thank you for responding.

> yup.. forget the new window all together, if you have it set to download
> as an attachment then the user won't be taken away from the page; so no
> need for a new window at all.

Right... so, we're all on board with the goals.

Now... how do I do that?

The whole problem here is that I keep getting a new window even though I
don't want it.

I would have thought if I told PHP to die immediately after outputting
the PDF, it would give up on making the new window.

I've also tried JavaScript to kill the window after it's made.

*How* do I get the page to die?

-- 
Dave M G

--- End Message ---

--- Begin Message ---

On Nov 8, 2009, at 1:20 PM, Dave M G <mar...@autotelic.com> wrote:

Nathan,

Thank you for responding.

yup.. forget the new window all together, if you have it set to download as an attachment then the user won't be taken away from the page; so no

need for a new window at all.

Right... so, we're all on board with the goals.

Now... how do I do that?

The whole problem here is that I keep getting a new window even though I

don't want it.

I would have thought if I told PHP to die immediately after outputting
the PDF, it would give up on making the new window.

I've also tried JavaScript to kill the window after it's made.

*How* do I get the page to die?

--
Dave M G

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

If you are popping up a new window just to handle the download, what about using a small iframe or hidden frame to handle that instead?

Bastien

--- End Message ---

--- Begin Message ---

Dan Shirah wrote:

Hello all,

Basically I have a form with a <textarea>.  The user can enter up to 5,000
characters in this text area.

If the user just types text like: This is a test.

And saves it, there's no problem.

However if the user types:

This

Is

A

Test

And saves it, the insert bombs.

I've tried using nl2br($text) and str_replace("\r","#CR",$text) to convert
the carriage returns, but it still crashes.

I'm using an informix database and the column is: my_text    CHAR(5000)

Any ideas why it crashes any time there is a carriage return in the text
area?

Thanks,
Dan

João Cândido de Souza Neto wrote:

Are you using nl2br to convert before recording or after?

This is probably an Informix problem or a problem with your interface to Informix. (I say that because I store textarea data with embedded newlines all the time in MySQL using the PHP mysql_ functions.)

What interface are you using? ODBC?

What errors do you get from Informix when it bombs?

I'm guessing an embedded CR or LF character is breaking something as it's being passed to Informix. As João implies, if you really are changing these to break tags, you shouldn't have a problem. So you might try outputting the results of your conversion to your PHP error log before you pass it to Informix.

You may find more help on an Informix list.

John

--- End Message ---

--- Begin Message ---

On Sun, Nov 8, 2009 at 11:40 AM, John List <johnl...@gulfbridge.net> wrote:
> Dan Shirah wrote:
>>
>> Hello all,
>>
>> Basically I have a form with a <textarea>.  The user can enter up to 5,000
>> characters in this text area.
>>
>> If the user just types text like: This is a test.
>>
>> And saves it, there's no problem.
>>
>> However if the user types:
>>
>> This
>>
>> Is
>>
>> A
>>
>> Test
>>
>> And saves it, the insert bombs.
>>
>> I've tried using nl2br($text) and str_replace("\r","#CR",$text) to convert
>> the carriage returns, but it still crashes.
>>
>> I'm using an informix database and the column is: my_text    CHAR(5000)
>>
>> Any ideas why it crashes any time there is a carriage return in the text
>> area?
>>
>> Thanks,
>> Dan
>
> João Cândido de Souza Neto wrote:
>>
>> Are you using nl2br to convert before recording or after?
>>
>>
>
> This is probably an Informix problem or a problem with your interface to
> Informix. (I say that because I store textarea data with embedded newlines
> all the time in MySQL using the PHP mysql_ functions.)
>
> What interface are you using? ODBC?
>
> What errors do you get from Informix when it bombs?
>
> I'm guessing an embedded CR or LF character is breaking something as it's
> being passed to Informix. As João implies, if you really are changing these
> to break tags, you shouldn't have a problem. So you might try outputting the
> results of your conversion to your PHP error log before you pass it to
> Informix.
>
> You may find more help on an Informix list.
>
> John
>
>
>
>
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
It's probably worthwhile to note that nl2br does NOT replace \n and/or
\r with <br /> but rather puts a <br /> before the newline
character(s).  Try str_replace("\r", '', $post_field).

--- End Message ---

--- Begin Message ---

Dan Shirah wrote:
>> My guess is that you are getting an SQL error returned to you.  What does
>> that
>> say?  Is it talking about a broken SQL statement?
>>
>> Also, an example of the actual insert statement with example data would be
>> helpful.
>>
>>
>>
> 
> I'm getting the generic error message: Prepare fails (E [SQLSTATE=IX 000
> SQLCODE=-282])
> 
> My insert statement when echo'd out using print_r($insert) is nothing
> complex.
> 
> INSERT INTO my_table VALUES (0, 'This is my text. When I use carriage
> returns it breaks. I am not sure why.')
> 

informix doesn't allow new lines in sql strings; unless you enable the
"ALLOW_NEWLINE" setting on the server.

to remove newlines I'd suggest stripping all vertical space and
replacing it with spaces, then stripping down the excess horizontal
space.. something like

function strip_newlines( $string ) {
  $string = preg_replace( '/\v/' , ' ' , $string );
  $string = preg_replace( '/\h\h+/' , ' ' , $string );
  return $string;
}

$sql = strip_newlines( $sql );

regards,

--- End Message ---

--- Begin Message ---

The POSIX regex functions are currently marked as DEPRECATED in 5.3.0 and 
are due to be removed completely in PHP 6. I propose that instead of being 
dropped they be converted into wrappers for the equivalent PCRE functions.



It does not matter how long various people have been preaching in various 
unofficial channels that users should switch to using the PCRE functions 
(preg_*) instead of the POSIX ones (ereg_*) as many users simply do not 
access those channels. The first time that a significant number of users 
will become aware of this is when they switch to 5.3.0 or later, and they 
will be very, very upset. Some users do not test their applications against 
each new PHP version as it comes out, they just use whatever version their 
hosting company provides them with.



It does not matter that the PHP developers cannot find someone to upgrade 
the POSIX functions, it does not matter that the same functionality can be 
provided with the PCRE functions, all the users will know is that their 
scripts, some of which have been running for many years, will suddenly not 
work and will need serious programming effort before they can run again.



You know how long it took for sites to upgrade from PHP 4 to 5 because of 
the backward compatibility issues, so imagine even more resistance and a 
slower uptake for PHP 6. The POSIX functions have been a core part of the 
language since the early days of PHP, so to suddenly dump them for no good 
reason will alienate and upset a large number of people. When I say "no good 
reason" I mean from the user's point of view. The fact that it is taking 
(has taken?) considerable effort to get the PCRE functions working with 
Unicode for PHP 6, and no-one is prepared to spend similar effort on the 
POSIX functions, may make it seem in the users eyes that the PHP developers 
are either lazy or incompetent.



It does not matter that the PHP developers are unpaid volunteers - that is 
no reason for shoddy workmanship. If they can't do the job properly they 
shouldn't do it at all. BC breaks, especially on a range of functions which 
have been a core part of the language for many, many years, do not go down 
well with the users, and remember that it is the incredibly large number of 
people who use PHP, not the efforts of the developers, that has made it such 
a popular language. So annoying large numbers of users will create a PR 
disaster.



If the PCRE functions have been made to work with Unicode, and each of the 
POSIX functions has a PCRE equivalent, then surely an intelligent move would 
be to convert all the POSIX functions into simple wrappers for their PCRE 
equivalents. So instead of spending huge amounts of effort in making the 
POSIX functions work with Unicode you simply cut out the code behind each 
POSIX function and replace it to a call to the relevant PCRE function.



This should only require a relatively small amount of developer effort which 
should be balanced against the huge amount that would otherwise be required 
in userland. If the PHP developers are not prepared to undertake this small 
amount of effort then they should be prepared for considerable amounts of 
fallout from lots of unhappy users.



I would strongly suggest that a start be made on this as soon as possible so 
that the changeover to PCRE wrappers can be fully tested and debugged before 
PHP 6 goes live. This will make the changeover from POSIX to PCRE totally 
transparent, and will be greatly appreciated in userland.


-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org 

--- End Message ---

--- Begin Message --- The same can be said about the removal of magic_quotes(), it will break A LOT of old scripts. I am in the same boat, I did not keep up to date with the PHP developer plans and just found out about ereg when I installed PHP 5.3.

I think it was handled properly by displaying warning messages before actually removing it. It will give people enough time to update their scripts or weed out the old and insecure scripts.

Yes, it will create some headache but, AFAIK, it is for the better.

--
John
Intelligent Life
http://xkcd.com/638/

--- End Message ---

--- Begin Message ---

"It is for the better"? How can you justify that? It is a problem that will 
cause a lot of headaches for a lot of users, yet the solution which I have 
proposed will remove that problem with only very little effort, yet still 
leave only one regex engine which has to be supported in PHP 6.

You have to balance out the small bit of effort required in implementing 
this solution against the huge amount of effort required in changing 
thousands, if not millions of scripts.

For the PHP developers to say "we can't be bothered to update the POSIX 
functions to deal with unicode, so we've decided to drop them from PHP 
entirely even though it will break lots of scripts" will not go down well in 
userland.


-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

"John Black" <s...@network-technologies.org> wrote in message 
news:4af70120.1040...@network-technologies.org...
> The same can be said about the removal of magic_quotes(), it will break A 
> LOT of old scripts.
> I am in the same boat, I did not keep up to date with the PHP developer 
> plans and just found out about ereg when I installed PHP 5.3.
>
> I think it was handled properly by displaying warning messages before 
> actually removing it. It will give people enough time to update their 
> scripts or weed out the old and insecure scripts.
>
> Yes, it will create some headache but, AFAIK, it is for the better.
>
> -- 
> John
> Intelligent Life
> http://xkcd.com/638/ 

--- End Message ---

--- Begin Message ---

On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
<t...@marston-home.demon.co.uk> wrote:
> "It is for the better"? How can you justify that? It is a problem that will
> cause a lot of headaches for a lot of users, yet the solution which I have
> proposed will remove that problem with only very little effort, yet still
> leave only one regex engine which has to be supported in PHP 6.
>
> You have to balance out the small bit of effort required in implementing
> this solution against the huge amount of effort required in changing
> thousands, if not millions of scripts.
>
> For the PHP developers to say "we can't be bothered to update the POSIX
> functions to deal with unicode, so we've decided to drop them from PHP
> entirely even though it will break lots of scripts" will not go down well in
> userland.
>
>
> --
> Tony Marston
> http://www.tonymarston.net
> http://www.radicore.org
>
> "John Black" <s...@network-technologies.org> wrote in message
> news:4af70120.1040...@network-technologies.org...
>> The same can be said about the removal of magic_quotes(), it will break A
>> LOT of old scripts.
>> I am in the same boat, I did not keep up to date with the PHP developer
>> plans and just found out about ereg when I installed PHP 5.3.
>>
>> I think it was handled properly by displaying warning messages before
>> actually removing it. It will give people enough time to update their
>> scripts or weed out the old and insecure scripts.
>>
>> Yes, it will create some headache but, AFAIK, it is for the better.
>>
>> --
>> John
>> Intelligent Life
>> http://xkcd.com/638/
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

The plan, as far as I am aware, is to move POSIX regular expressions
into PECL as of PHP6.  If you can fix your scripts by simply running
"pecl install ereg" what's all the hee-hawing about?

--- End Message ---

--- Begin Message ---

That's an amateur fudge, not a professional fix. Besides, what happens if 
your hosting company won't let you install PECL extensions?

-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

"Eddie Drapkin" <oorza...@gmail.com> wrote in message 
news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com...
> On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
> <t...@marston-home.demon.co.uk> wrote:
>> "It is for the better"? How can you justify that? It is a problem that 
>> will
>> cause a lot of headaches for a lot of users, yet the solution which I 
>> have
>> proposed will remove that problem with only very little effort, yet still
>> leave only one regex engine which has to be supported in PHP 6.
>>
>> You have to balance out the small bit of effort required in implementing
>> this solution against the huge amount of effort required in changing
>> thousands, if not millions of scripts.
>>
>> For the PHP developers to say "we can't be bothered to update the POSIX
>> functions to deal with unicode, so we've decided to drop them from PHP
>> entirely even though it will break lots of scripts" will not go down well 
>> in
>> userland.
>>
>>
>> --
>> Tony Marston
>> http://www.tonymarston.net
>> http://www.radicore.org
>>
>> "John Black" <s...@network-technologies.org> wrote in message
>> news:4af70120.1040...@network-technologies.org...
>>> The same can be said about the removal of magic_quotes(), it will break 
>>> A
>>> LOT of old scripts.
>>> I am in the same boat, I did not keep up to date with the PHP developer
>>> plans and just found out about ereg when I installed PHP 5.3.
>>>
>>> I think it was handled properly by displaying warning messages before
>>> actually removing it. It will give people enough time to update their
>>> scripts or weed out the old and insecure scripts.
>>>
>>> Yes, it will create some headache but, AFAIK, it is for the better.
>>>
>>> --
>>> John
>>> Intelligent Life
>>> http://xkcd.com/638/
>>
>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
> The plan, as far as I am aware, is to move POSIX regular expressions
> into PECL as of PHP6.  If you can fix your scripts by simply running
> "pecl install ereg" what's all the hee-hawing about? 

--- End Message ---

--- Begin Message ---

On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston
<t...@marston-home.demon.co.uk> wrote:
> That's an amateur fudge, not a professional fix. Besides, what happens if
> your hosting company won't let you install PECL extensions?
>
> --
> Tony Marston
> http://www.tonymarston.net
> http://www.radicore.org
>
> "Eddie Drapkin" <oorza...@gmail.com> wrote in message
> news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com...
>> On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
>> <t...@marston-home.demon.co.uk> wrote:
>>> "It is for the better"? How can you justify that? It is a problem that
>>> will
>>> cause a lot of headaches for a lot of users, yet the solution which I
>>> have
>>> proposed will remove that problem with only very little effort, yet still
>>> leave only one regex engine which has to be supported in PHP 6.
>>>
>>> You have to balance out the small bit of effort required in implementing
>>> this solution against the huge amount of effort required in changing
>>> thousands, if not millions of scripts.
>>>
>>> For the PHP developers to say "we can't be bothered to update the POSIX
>>> functions to deal with unicode, so we've decided to drop them from PHP
>>> entirely even though it will break lots of scripts" will not go down well
>>> in
>>> userland.
>>>
>>>
>>> --
>>> Tony Marston
>>> http://www.tonymarston.net
>>> http://www.radicore.org
>>>
>>> "John Black" <s...@network-technologies.org> wrote in message
>>> news:4af70120.1040...@network-technologies.org...
>>>> The same can be said about the removal of magic_quotes(), it will break
>>>> A
>>>> LOT of old scripts.
>>>> I am in the same boat, I did not keep up to date with the PHP developer
>>>> plans and just found out about ereg when I installed PHP 5.3.
>>>>
>>>> I think it was handled properly by displaying warning messages before
>>>> actually removing it. It will give people enough time to update their
>>>> scripts or weed out the old and insecure scripts.
>>>>
>>>> Yes, it will create some headache but, AFAIK, it is for the better.
>>>>
>>>> --
>>>> John
>>>> Intelligent Life
>>>> http://xkcd.com/638/
>>>
>>>
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>> The plan, as far as I am aware, is to move POSIX regular expressions
>> into PECL as of PHP6.  If you can fix your scripts by simply running
>> "pecl install ereg" what's all the hee-hawing about?
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Then you've got several options:
1) Don't upgrade PHP.
2) Pick a different hosting provider.
3) Fix your scripts.

You talk about a "professional" fix.  The right fix is to remove the
depracated elements from your scripts before upgrading PHP, which
realistically shouldn't be that big of a deal for the vast majority of
expressions.  Rather than accept the change and just fix your scripts,
you propose a problem that breaks a lot of other things and introduces
way more problems than it solves.

You're not the first person to post this exact same tantrum on this
list and the response has always been: fix your scripts or don't
upgrade.  Seeing as PHP 6 is a long ways away you've got plenty of
time to fix your scripts and it's not like this is being sprung
overnight, so do the real professional thing and upgrade your scripts,
if you want to upgrade (when 6 is released).  Breaking BC happens.

--- End Message ---

--- Begin Message ---

"Eddie Drapkin" <oorza...@gmail.com> wrote in message 
news:68de37340911081330v799803f3he6ed60ecc6e67...@mail.gmail.com...
On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston
<t...@marston-home.demon.co.uk> wrote:
> That's an amateur fudge, not a professional fix. Besides, what happens if
> your hosting company won't let you install PECL extensions?
>
> --
> Tony Marston
> http://www.tonymarston.net
> http://www.radicore.org
>
> "Eddie Drapkin" <oorza...@gmail.com> wrote in message
> news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com...
>> On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
>> <t...@marston-home.demon.co.uk> wrote:
>>> "It is for the better"? How can you justify that? It is a problem that
>>> will
>>> cause a lot of headaches for a lot of users, yet the solution which I
>>> have
>>> proposed will remove that problem with only very little effort, yet 
>>> still
>>> leave only one regex engine which has to be supported in PHP 6.
>>>
>>> You have to balance out the small bit of effort required in implementing
>>> this solution against the huge amount of effort required in changing
>>> thousands, if not millions of scripts.
>>>
>>> For the PHP developers to say "we can't be bothered to update the POSIX
>>> functions to deal with unicode, so we've decided to drop them from PHP
>>> entirely even though it will break lots of scripts" will not go down 
>>> well
>>> in
>>> userland.
>>>
>>>
>>> --
>>> Tony Marston
>>> http://www.tonymarston.net
>>> http://www.radicore.org
>>>
>>> "John Black" <s...@network-technologies.org> wrote in message
>>> news:4af70120.1040...@network-technologies.org...
>>>> The same can be said about the removal of magic_quotes(), it will break
>>>> A
>>>> LOT of old scripts.
>>>> I am in the same boat, I did not keep up to date with the PHP developer
>>>> plans and just found out about ereg when I installed PHP 5.3.
>>>>
>>>> I think it was handled properly by displaying warning messages before
>>>> actually removing it. It will give people enough time to update their
>>>> scripts or weed out the old and insecure scripts.
>>>>
>>>> Yes, it will create some headache but, AFAIK, it is for the better.
>>>>
>>>> --
>>>> John
>>>> Intelligent Life
>>>> http://xkcd.com/638/
>>>
>>>
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>> The plan, as far as I am aware, is to move POSIX regular expressions
>> into PECL as of PHP6. If you can fix your scripts by simply running
>> "pecl install ereg" what's all the hee-hawing about?
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

> Then you've got several options:
> 1) Don't upgrade PHP.

Not an acceptable option.

> 2) Pick a different hosting provider.

Not an acceptable optional.

> 3) Fix your scripts.

The scripts aren't broken. It's PHP 6 that's going to be broken.

> You talk about a "professional" fix.  The right fix is to remove the
> depracated elements

My whole argument is that they shouldn't have been deprecated in the first 
place.

> from your scripts before upgrading PHP, which
> realistically shouldn't be that big of a deal for the vast majority of
> expressions.

It is going to be a VERY big deal for all hose users who suddenly finf that 
their scripts won't run in PHP 6.

> Rather than accept the change and just fix your scripts,

It's not a change, it's a removal of core functions that have worked 
flawlessly for years. Both the POSIX and the PCRE functions needed to be 
updated to work with unicode, but the developers couldn't be bothered to 
update both. The only reason that the POSIX have been deprecated is because 
the PHP developers are either too lazy or too incompetent to provide a 
proper fix.

> you propose a problem that breaks a lot of other things and introduces
> way more problems than it solves.

> You're not the first person to post this exact same tantrum on this
l> list and the response has always been: fix your scripts

The scripts aren't broken, it's PHP 6 that's broken.

> or don't upgrade.

Not an acceptable option.

> Seeing as PHP 6 is a long ways away you've got plenty of
> time to fix your scripts

Just as the PHP developers have plenty of time to do a proper job.

> and it's not like this is being sprung overnight,

To a lot of peope it will appear to be sprung overnight as the first time 
they will know that the POSIX functions have been removed is when their 
scripts don't work.

> so do the real professional thing

The professional thing would be to fix PHP 6 so that is doesn't  break 
existing scripts needlessly.

> and upgrade your scripts,
> if you want to upgrade (when 6 is released).  Breaking BC happens.

There is a difference between breaking BC because of genuinely 
insurmountable reasons, and breaking it because of pure laziness.

-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org 

--- End Message ---

--- Begin Message ---

Tony Marston wrote:

"Eddie Drapkin" <oorza...@gmail.com> wrote in message news:68de37340911081330v799803f3he6ed60ecc6e67...@mail.gmail.com...

On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston
<t...@marston-home.demon.co.uk> wrote:

That's an amateur fudge, not a professional fix. Besides, what happens if
your hosting company won't let you install PECL extensions?

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

"Eddie Drapkin" <oorza...@gmail.com> wrote in message
news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com...

On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
<t...@marston-home.demon.co.uk> wrote:

"It is for the better"? How can you justify that? It is a problem that
will
cause a lot of headaches for a lot of users, yet the solution which I
have

proposed will remove that problem with only very little effort, yet still

leave only one regex engine which has to be supported in PHP 6.

You have to balance out the small bit of effort required in implementing
this solution against the huge amount of effort required in changing
thousands, if not millions of scripts.

For the PHP developers to say "we can't be bothered to update the POSIX
functions to deal with unicode, so we've decided to drop them from PHP

entirely even though it will break lots of scripts" will not go down well

in
userland.


--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

"John Black" <s...@network-technologies.org> wrote in message
news:4af70120.1040...@network-technologies.org...

The same can be said about the removal of magic_quotes(), it will break
A
LOT of old scripts.
I am in the same boat, I did not keep up to date with the PHP developer
plans and just found out about ereg when I installed PHP 5.3.

I think it was handled properly by displaying warning messages before
actually removing it. It will give people enough time to update their
scripts or weed out the old and insecure scripts.

Yes, it will create some headache but, AFAIK, it is for the better.

--
John
Intelligent Life
http://xkcd.com/638/

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

The plan, as far as I am aware, is to move POSIX regular expressions
into PECL as of PHP6. If you can fix your scripts by simply running
"pecl install ereg" what's all the hee-hawing about?

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

Then you've got several options:
1) Don't upgrade PHP.

Not an acceptable option.

2) Pick a different hosting provider.

Not an acceptable optional.

3) Fix your scripts.

The scripts aren't broken. It's PHP 6 that's going to be broken.

I think you're missing the point of a full version increase. This is not a minor or micro version change... script breakage is *expected*. You don't think PHP should support legacy cruft in the core forever do you? If unicode support is slopped onto the current POSIX regex functions won't that then make them non-POSIX? Food for thought. Also, why support two libraries for which one is obviously inferior in speed and functionality?

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--- End Message ---

--- Begin Message ---

"Robert Cummings" <rob...@interjinn.com> wrote in message 
news:4af7549d.1060...@interjinn.com...
> Tony Marston wrote:
>> "Eddie Drapkin" <oorza...@gmail.com> wrote in message 
>> news:68de37340911081330v799803f3he6ed60ecc6e67...@mail.gmail.com...
>> On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston
>> <t...@marston-home.demon.co.uk> wrote:
>>> That's an amateur fudge, not a professional fix. Besides, what happens 
>>> if
>>> your hosting company won't let you install PECL extensions?
>>>
>>> --
>>> Tony Marston
>>> http://www.tonymarston.net
>>> http://www.radicore.org
>>>
>>> "Eddie Drapkin" <oorza...@gmail.com> wrote in message
>>> news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com...
>>>> On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston
>>>> <t...@marston-home.demon.co.uk> wrote:
>>>>> "It is for the better"? How can you justify that? It is a problem that
>>>>> will
>>>>> cause a lot of headaches for a lot of users, yet the solution which I
>>>>> have
>>>>> proposed will remove that problem with only very little effort, yet 
>>>>> still
>>>>> leave only one regex engine which has to be supported in PHP 6.
>>>>>
>>>>> You have to balance out the small bit of effort required in 
>>>>> implementing
>>>>> this solution against the huge amount of effort required in changing
>>>>> thousands, if not millions of scripts.
>>>>>
>>>>> For the PHP developers to say "we can't be bothered to update the 
>>>>> POSIX
>>>>> functions to deal with unicode, so we've decided to drop them from PHP
>>>>> entirely even though it will break lots of scripts" will not go down 
>>>>> well
>>>>> in
>>>>> userland.
>>>>>
>>>>>
>>>>> --
>>>>> Tony Marston
>>>>> http://www.tonymarston.net
>>>>> http://www.radicore.org
>>>>>
>>>>> "John Black" <s...@network-technologies.org> wrote in message
>>>>> news:4af70120.1040...@network-technologies.org...
>>>>>> The same can be said about the removal of magic_quotes(), it will 
>>>>>> break
>>>>>> A
>>>>>> LOT of old scripts.
>>>>>> I am in the same boat, I did not keep up to date with the PHP 
>>>>>> developer
>>>>>> plans and just found out about ereg when I installed PHP 5.3.
>>>>>>
>>>>>> I think it was handled properly by displaying warning messages before
>>>>>> actually removing it. It will give people enough time to update their
>>>>>> scripts or weed out the old and insecure scripts.
>>>>>>
>>>>>> Yes, it will create some headache but, AFAIK, it is for the better.
>>>>>>
>>>>>> --
>>>>>> John
>>>>>> Intelligent Life
>>>>>> http://xkcd.com/638/
>>>>>
>>>>>
>>>>> --
>>>>> PHP General Mailing List (http://www.php.net/)
>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>
>>>>>
>>>> The plan, as far as I am aware, is to move POSIX regular expressions
>>>> into PECL as of PHP6. If you can fix your scripts by simply running
>>>> "pecl install ereg" what's all the hee-hawing about?
>>>
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>>> Then you've got several options:
>>> 1) Don't upgrade PHP.
>>
>> Not an acceptable option.
>>
>>> 2) Pick a different hosting provider.
>>
>> Not an acceptable optional.
>>
>>> 3) Fix your scripts.
>>
>> The scripts aren't broken. It's PHP 6 that's going to be broken.
>
> I think you're missing the point of a full version increase. This is not a 
> minor or micro version change... script breakage is *expected*.

But breakage should be kept to an absolute minimum, and developer laziness 
or incompetence is not an acceptable excuse.

> You don't think PHP should support legacy cruft in the core forever do 
> you?

Widely use regex functions are not "legacy cruft". Besides, who decides what 
is "cruft" and should be removed from the language?

> If unicode support is slopped onto the current POSIX regex functions won't 
> that then make them non-POSIX? Food for thought. Also, why support two 
> libraries for which one is obviously inferior in speed and functionality?

That is why I suggested that instead of dropping the POSIX functions 
entirely and seriously annoying lots of users, that they should simply be 
rewritten as wrappers for the PCRE functions. In that way all the calls to 
ereg_* would still work, but all they would do is immediately call the 
relevant preg_* function. The small amount of effort that tghis would take 
would kill two birds with one stone:

(1) There would be only one regex engine to support, which would be PCRE.
(2) Lots of developers would be spared the hassle of modifying their code as 
all the calls to POSIX functions would still work as expected because the 
language would redirect to the PCRE function automatically.

I am not suggesting that the POSIX functions be rewritten to deal with 
unicode as that would require a huge amount of effort, but by redirecting al 
POSIX calls to the equivalent PCRE function would have the same effect for 
far less effort.

The choice is simple - either a small amount of effort from a small number 
of developers, or a large amount of effort from a large number of seriously 
pissed-off users. Do the maths. It's not rocket science.

-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

> Cheers,
> Rob.
> -- 
> http://www.interjinn.com
> Application and Templating Framework for PHP 

--- End Message ---