[RESOLVED] Need to evaluate all PHP found in string

ppowell

I need to find all occurrences of any PHP-related code found in a string of text. If PHP is found it must be evaluated.

This is what I have so far:

		// NEW 8/4/2005: IF PHP CODE WAS EMBEDDED, DO AN EVALUATION
		foreach (array('string_1', 'string_2') as $string) if (preg_match('/^.*<\?(php)?.+\?' . '>.*$/i', preg_replace('/[\n\r]+/i', "\s", ${$string}))) ${$string} = eval(${$string});

The string text could be pure PHP, HTML with embedded PHP, pure HTML, or even plain text. It will be ASCII of some kind but you have no way of knowing if PHP is found inside the strings or not.

The following lines of code produce this error:

Parse error: parse error in /page.php(69) : eval()'d code on line 1

Has anyone ever had to do something like this before, if so, what have you done?

Thanx
Phil

lucasrd

What is in the $string variable...seems to me there is a PHP parse error...your code could be working...

ppowell

$string could contain literally anything at all, PHP, HTML, both, neither.. it's content that you entered using a Content Management tool.. it's to eventually display within an HTML template.

Phil

Weedpacket

So how are you (I should say, how is the script) expected to determine whether a given string is PHP or ASCII text? (Especially since a string of PHP is a string of ASCII text.)

ppowell

Very simple. It will look for '<' followed by '?' and a possible instance of 'php' after the '?', some text and then '?' followed by '>'. In short, it will look for a PHP command block; if it finds one, it will assume everything inside is PHP, comments and all.

Phil

toplay

I understand that you want to look for the PHP tags, however, the string containg the code you pass to eval() must not have the PHP tags. So, not only do you have to look for the PHP tags, but you need to strip them out before calling eval().

leatherback

Couldn't you do a preg_match on <?php ... ?>

toplay

leatherback wrote:
Couldn't you do a preg_match on <?php ... ?>

He is, but he's not stripping them out.

leatherback

OK, missed that in the first post. I see now.

Why don't you just echo out the string, and see what it contains, and for now leave out the eval() function? I mean... First make sure you grab what you think you are grabbing!

lucasrd

leatherback...that's what I was trying to say earlier...echo out the $string variable to see what's in it since the eval is returning a parse error....if the php tags are causing the problem, they can be easily removed with [man] ereg_replace [/man]...

ppowell

toplay wrote:
I understand that you want to look for the PHP tags, however, the string containg the code you pass to eval() must not have the PHP tags. So, not only do you have to look for the PHP tags, but you need to strip them out before calling eval().

So bascially what I have to do is to remove the PHP tags before doing eval? That's doable with some clever working of preg_replace()

Phil

leatherback

You can use pregmatch with subsections, and only retrieve the sections you need. I think each section is deliniated between backets, lik ei do for finding required files in code:

preg_match("#require\((.{0,})(\))(.{0,})#", $line, $matches); 
$result = $matches[1];

Weedpacket

Since PHP is signalled by opening PHP tags, you can ensure that eval() starts out scanning in non-PHP mode by adding a closing tag.

eval("?>".$string);

Subsequent opening PHP tags will kick the parser back in again, closing tags will kick it out, and so on.

Anything non-PHP in this would be sent to output, so you'd probably want to use output buffering to capture it into a variable instead.

leatherback

Weedpacket wrote:
Since PHP is signalled by opening PHP tags, you can ensure that eval() starts out scanning in non-PHP mode by adding a closing tag.
eval("?>".$string);

Hey nice! Didn't realize that would work! But.. hm..
🙂

execute

doesnt strip_tags() function strip away <?php tags anyway?
Sorry im not an expert at this... 😮

ppowell

Weedpacket wrote:
Since PHP is signalled by opening PHP tags, you can ensure that eval() starts out scanning in non-PHP mode by adding a closing tag.
eval("?>".$string);
Subsequent opening PHP tags will kick the parser back in again, closing tags will kick it out, and so on.

Anything non-PHP in this would be sent to output, so you'd probably want to use output buffering to capture it into a variable instead.

I thought that any occurrence of '?' followed by '>' triggers an end of a PHP command block, regardless of its placement, thus, your statement would break PHP. Wouldn't it be safer instead to do:

eval('?'. '>', $string);

Turns out it's no longer a requirement, but a nice "to know" basis at this point anyway. The client changed its mind

Phil

Weedpacket

Nope; PHP's smart enough to know that a string containing "?>" is just a string. Just like a pipe is sometimes just a pipe. (Suddenly switching to generating output in the middle of declaring a string literal would be a parse error anyway).

At least, it works for me when I use it.