Re: [PHP] Connect to LDAP
Yes. Correct
On Mon, Nov 9, 2009 at 7:30 AM, Ashley M. Kirchner wrote:
>
> Hi folks,
>
> I've never done any PHP->LDAP code writing (nor have I ever dealt with an
> LDAP server to begin with.) However I'm writing an app which requires
> verifying a user's credentials against an LDAP server. The admin of the
> server sent me the following snippet, however also made it clear that he is
> not 100% whether it's accurate (he's not a PHP coder). And I don't have
> remote access to the server (the app is going to sit on the internal network
> and the LDAP server doesn't accept outside connections.)
>
> So, asking the wise folks on here, does the following piece look
> semantically correct?
>
>/* Check against LDAP server */
>$adServer = "server.address.hidden";
>$ldapconn = ldap_connect($adServer) or die("Connection to the AD
> server failed.");
>$ldapuser = $_POST["uname"];
>$ldappass = $_POST["pword"];
>$ldapbind = ldap_bind($ldapconn, $ldapuser, $ldappass);
>
>if ($ldapbind) {
> $msg = "User Authenticated Successfully!";
> $_SESSION['username'] = $ldapuser;
> $_SESSION['password'] = $ldappass;
> return true;
>} else {
> $msg = "Invalid username / password";
> return false;
>}
>
> Thanks.
>
> -- A
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Devendra Jadhav
देवेंद्र जाधव
[PHP] Multilingual website, texts in external JavaScript problem
I need to create a multilingual website and my framework already gives me that facility. However, I also use JavaScript quite extensively and since XHTML 1.0 Strict doesn't allow inline script, I must use external .js file. The problem is in these scripts, there are strings that needs to be translated as well. How can I make PHP parse these scripts as well? Or are there alternative approaches? -- View this message in context: http://old.nabble.com/Multilingual-website%2C-texts-in-external-JavaScript-problem-tp26261666p26261666.html Sent from the PHP - General mailing list archive at Nabble.com. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Checkbox in PHP form
value="PFDs" name=f_sequipment1>PFDs -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
On Sun, Nov 08, 2009 at 06:30:37PM -0500, Robert Cummings wrote: > Also, why support > two libraries for which one is obviously inferior in speed and > functionality? > Because Tony's Radicore framework has a bunch of ereg* calls in it. ;-} Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Connect to LDAP
Hi folks,
I've never done any PHP->LDAP code writing (nor have I ever dealt
with an LDAP server to begin with.) However I'm writing an app which
requires verifying a user's credentials against an LDAP server. The
admin of the server sent me the following snippet, however also made it
clear that he is not 100% whether it's accurate (he's not a PHP coder).
And I don't have remote access to the server (the app is going to sit on
the internal network and the LDAP server doesn't accept outside
connections.)
So, asking the wise folks on here, does the following piece look
semantically correct?
/* Check against LDAP server */
$adServer = "server.address.hidden";
$ldapconn = ldap_connect($adServer) or die("Connection to the
AD server failed.");
$ldapuser = $_POST["uname"];
$ldappass = $_POST["pword"];
$ldapbind = ldap_bind($ldapconn, $ldapuser, $ldappass);
if ($ldapbind) {
$msg = "User Authenticated Successfully!";
$_SESSION['username'] = $ldapuser;
$_SESSION['password'] = $ldappass;
return true;
} else {
$msg = "Invalid username / password";
return false;
}
Thanks.
-- A
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Checkbox in PHP form
Hello,
on 11/08/2009 11:39 PM Ernie Kemp said the following:
> Need some help here with checkboxes in an html form.
>
>
>
> My issue is I have a form that needs to be viewed with checkboxes filled
> in depending on the values in the table.
>
>
>
> I tried:
>
> 'no') { echo "checked=yes"; } else { echo ''; } ?> value="PFDs"
> name=f_sequipment1>PFDs
>
> but the checkbox field is always checked.
It should be $row[33] == 'no'
--
Regards,
Manuel Lemos
Find and post PHP jobs
http://www.phpclasses.org/jobs/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Checkbox in PHP form
Need some help here with checkboxes in an html form. My issue is I have a form that needs to be viewed with checkboxes filled in depending on the values in the table. I tried: value="PFDs" name=f_sequipment1>PFDs but the checkbox field is always checked. I thought of JavaScript also but it would have to be a "if $row[33] then run a JavaScript function" . This is not working for me neither. Sorry if this seems trivial but I need your help. Thanks in advance.
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
Tony Marston wrote: "Robert Cummings" wrote in message 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. Not quite true... major version moves are an opportunity to make a break for freedom. All there needs to be is an upgrade path... and that is clearly in play right now with the warning indicating that POSIX regex functions are being deprecated. 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? They most certainly are cruft... hence the reason they are being removed. The people who decide what is, and is not, cruft are the very same people who are writing the code. If you are not happy with this then there's the age old saying in open source... "put up or shut up". 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. This would probably be worse than removing the POSIX functions. POSIX and PCRE I daresay are not completely compatible. At least when you remove the POSIX functions then the problem space is well defined. Suddenly having POSIX regex functions that are really wrappers around PCRE functions may introduce subtle differences in output for the same horde of users but without the same explicability. 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. This isn't a mathematical problem. It's a question of correctness. I wasn't happy to hear POSIX regex functions were going either, but when I heard the reasoning I did the best thing I could... I fixed my code to prepare for the inevitable. There's no way I'd trust my code to "just work" with POSIX functions redirected through PCRE and so I'd still need to do the same legwork. Wrapping the POSIX regex functions around PCRE will lead to more problems than it solves IMHO. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
"Robert Cummings" wrote in message news:4af7549d.1060...@interjinn.com... > Tony Marston wrote: >> "Eddie Drapkin" wrote in message >> news:68de37340911081330v799803f3he6ed60ecc6e67...@mail.gmail.com... >> On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston >> 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" wrote in message >>> news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com... On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston 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" 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 ht
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
Tony Marston wrote: "Eddie Drapkin" wrote in message news:68de37340911081330v799803f3he6ed60ecc6e67...@mail.gmail.com... On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston 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" wrote in message news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com... On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston 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" 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
"Eddie Drapkin" wrote in message news:68de37340911081330v799803f3he6ed60ecc6e67...@mail.gmail.com... On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston 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" wrote in message > news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com... >> On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston >> 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" 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston 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" wrote in message > news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com... >> On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston >> 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" 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
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" wrote in message news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com... > On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston > 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" 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
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston 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" 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
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
"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" 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
Re: [PHP] Re: Die Page, Die! (Was: Preview button to show PDF without submittingpost data?)
On Nov 8, 2009, at 1:20 PM, Dave M G 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Die Page, Die! (Was: Preview button to show PDF without submittingpost data?)
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
Re: [PHP] Carriage Returns
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,
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
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
[PHP] Re: Die Page, Die! (Was: Preview button to show PDF without submittingpost data?)
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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Carriage Returns
On Sun, Nov 8, 2009 at 11:40 AM, John List wrote:
> Dan Shirah wrote:
>>
>> Hello all,
>>
>> Basically I have a form with a . 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 but rather puts a before the newline
character(s). Try str_replace("\r", '', $post_field).
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Carriage Returns
Dan Shirah wrote:
Hello all,
Basically I have a form with a . 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_textCHAR(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
[PHP] Re: Die Page, Die! (Was: Preview button to show PDF without submitting post data?)
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Die Page, Die! (Was: Preview button to show PDF without submitting post data?)
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 'javascript:self.close();';
> }
>
> 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
[PHP] Die Page, Die! (Was: Preview button to show PDF without submitting post data?)
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 'javascript:self.close();';
}
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.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Preview button to show PDF without submitting post data?
Dave M G schrieb: PHP Users, I have a page that generates a PDF document using PHP. It takes form data filled in by the user to fill out the PDF When the user clicks "submit", it emails that PDF document to the intended recipient. However, I would like to add a "preview" function as well. But for a variety of reasons, instead of submitting the form data through post and re-filling all the fields with the selected data, I'd like to be able to open a new window with an example PDF without actually submitting the form. I think this might need JavaScript, but I'm not sure. Is this possible? Thank you for any advice. Hallo Dave, to get the PDF you use a create PDF Engine writing on PHP right?. The Only Way to generate the PDF is, to get the Information from user (with the POST or GET method) using the PDF Engine writing on PHP right? I think you can generate the PDF and show it like a "preview" Page, but the User must be able to regenerate the PDF to send it as email (where the same Data will be used or not, please think about, if you want to do this) I think, you must to think more about the usability at this point Regards Carlos -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
