php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #51864 preg_replace returns NULL on error
Submitted: 2010-05-20 00:45 UTC Modified: 2010-06-08 15:01 UTC
From: dscotese at litmocracy dot com Assigned: salathe (profile)
Status: Closed Package: PCRE related
PHP Version: Irrelevant OS: NA
Private report: No CVE-ID: None
View Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
2 + 26 = ?
Subscribe to this entry?

 
 [2010-05-20 00:45 UTC] dscotese at litmocracy dot com 
Description:
------------
Sometimes preg_replace([Array],[Array],$subject) returns null, but the error cannot be reproduced using preg_replace($problem_regex,$repl,$subject).  My attempt to reproduce it showed that $problem_regex was not a problem - the replacement worked as designed.  I actually removed it from the arrays and did it separately under the assumption that the regex engine might have been biting off more than it could chew.

If I shortened $repl, I was able to get the array version to work, but since my $repl was longer, I moved it to a separate call.

The docs for preg_replace do not mention preg_last_error.  That should be mentioned right where it says it returns NULL on error.

Test script:
---------------
// You may need to create several more patterns and replacements to get an error
// Just make sure they're all legitimate

$contents = file_get_contents("textfile.txt");
$find = array('<td><'.'?php readfile("/var/www/www.domain1.com/html/templates/leftmenu2_lfl.txt"); ?'.'></td><td width="663"',
    '#(?:<table .{450,500})?<\?php\s+readfile[^<>]*?templates/footer(?:lamps)?.txt[\'";) ]*\s*\?'.'>.*#s');

$replace = array('<td>file_get_contents('whatever').'</td><td width="601"',
    file_get_contents('newFooter.txt'));

echo preg_replace($find, $replace, $contents);


Expected result:
----------------
When the arrays are large enough and/or the patterns are complicated enough, The output will be empty.  The "bug" is that there's no documentation on how to find out why it's empty.  Is there a way?

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-05-20 14:31 UTC] mike@php.net
-Status: Open +Status: Feedback -Package: Regexps related +Package: PCRE related
 [2010-05-20 14:31 UTC] mike@php.net 
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.
 [2010-05-20 16:04 UTC] dscotese at litmocracy dot com
-Status: Feedback +Status: Open
 [2010-05-20 16:04 UTC] dscotese at litmocracy dot com 
Sorry I was not clear in my last post.  This is a documentation problem.  No test script is necessary.  Simply add a reference to preg_last_error to the preg_replacement documentation.

However, when you call preg_replace with an array of patterns and replacements, it can fail even though calling it with the corresponding pairs of pattern/replacement one at a time does not fail.  I'd consider that a weakness, but not a bug.

If it's possible, preg_replace could be rewritten so that when it takes arrays and fails in a way that doesn't indicate any bad patterns, it tries to do the replacements one at a time.  But that is not what this bug report is about.  I leave it to you to decide if preg_replace should be made more robust in that way.
 [2010-06-08 14:30 UTC] felipe@php.net
-Status: Open +Status: Bogus
 [2010-06-08 14:30 UTC] felipe@php.net 
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
 [2010-06-08 14:32 UTC] felipe@php.net
-Status: Bogus +Status: Open
 [2010-06-08 14:32 UTC] felipe@php.net 
Re-open... Surely it must be documented.
 [2010-06-08 14:51 UTC] salathe@php.net 
Automatic comment from SVN on behalf of salathe
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=300271
Log: see also preg_last_error, doc bug #51864
    - added preg_last_error see also link for preg_* functions
    - also added other useful see-also links for preg funcs
 [2010-06-08 15:01 UTC] salathe@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: salathe
 [2010-06-08 15:01 UTC] salathe@php.net 
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

I've added preg_last_error() to the "See Also" section of the following functions: 
preg_match, preg_match_all, preg_replace, preg_replace_all, and preg_split. Is 
that sufficient, or is there anything else that you were wanting?
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sun Oct 26 08:00:02 2025 UTC