It's not exactly the plugin, it's the PCRE engine that processes the regular expression used by the plugin. Regular expressions are patterns that the preg_match() function uses to search for matches. They need a delimiter at both ends of the pattern string. For example, '/[Hh]ello/' will search for the string 'hello' or 'Hello'. The engine will get confused when the delimiter occurs inside the pattern. Regex expressions can have a modifier at the end (following the closing delimiter) like this '/hello/i'. This will do a case-insensitive search for Hello, hello, HElLo, etc.
This will work fine:
$pattern = '/[Hh]ello/';
$content = "<p>Hello</p>";
preg_match ($pattern, $content , $matches);
This code will *not* work fine:
$pattern = '/<p>Hello</p>/';
$content = "<p>Hello</p>";
preg_match ($pattern, $content , $matches);
When parsing the pattern, the engine will interpret the / in the middle as the end of the pattern and assume that the p following it is a modifier. Since there is no p modifier, it throws the error.
That's why it's critical to select a delimiter that you're sure won't be in the pattern. This is difficult with MODX because @, #, ~, %, `, +, &, and /, could all occur in a MODX page. Selecting the delimiter dynamically after searching for it in the page would solve this.
$delimiters = array(
'@', '#', '%', // etc.
}
$delimiter = null;
foreach ($delimiters as $d) {
if (strpos($content, $d) === false) {
$delimiter = $d;
break;
}
}
if ($delimiter !== null) {
preg_match($delimiter . '[hH]ello' . $delimiter, $content, $matches);
}
I filed a bug report at GitHub for this, but I don't know if Everett is still maintaining the plugin.
[update] The actual code uses preg_replace() not preg_match() but I used preg_match() (which throws the same error) in my examples for clarity.
[ed. note: BobRay last edited this post 6 years, 9 months ago.]
