Warning: preg_replace(): Unknown modifier ']'

Other examples

The reference answer already explains the reason for "Unknown modifier" warnings. This is just a comparison of other typical variants.

• When forgetting to add regex /delimiters/, the first non-letter symbol will be assumed to be one. Therefore the warning is often about what follows a grouping (…), […] meta symbol:

  preg_match("[a-zA-Z]+:\s*.$"
              ↑      ↑⬆
  

• Sometimes your regex already uses a custom delimiter (: here), but still contains the same character as unescaped literal. It's then mistaken as premature delimiter. Which is why the very next symbol receives the "Unknown modifier ❌" trophy:

  preg_match(":\[[\d:/]+\]:"
              ↑     ⬆     ↑
  

• When using the classic / delimiter, take care to not have it within the regex literally. This most frequently happens when trying to match unescaped filenames:

  preg_match("/pathname/filename/i"
              ↑        ⬆         ↑
  

  Or when matching angle/square bracket style tags:

  preg_match("/<%tmpl:id>(.*)</%tmpl:id>/Ui"
              ↑               ⬆         ↑
  

• Templating-style (Smarty or BBCode) regex patterns often require {…} or […] brackets. Both should usually be escaped. (An outermost {} pair being the exception though).

  They also get misinterpreted as paired delimiters when no actual delimiter is used. If they're then also used as literal character within, then that's, of course … an error.

  preg_match("{bold[^}]+}"
              ↑      ⬆  ↑
  

• Whenever the warning says "Delimiter must not be alphanumeric or backslash" then you also entirely forgot delimiters:

  preg_match("ab?c*"
              ↑
  

• "Unkown modifier 'g'" often indicates a regex that was copied verbatimly from JavaScript or Perl.

  preg_match("/abc+/g"
                    ⬆
  

  PHP doesn't use the /g global flag. Instead the preg_replace function works on all occurences, and preg_match_all is the "global" searching pendant to the one-occurence preg_match.

  So, just remove the /g flag.

  See also:
  · Warning: preg_replace(): Unknown modifier 'g'
  · preg_replace: bad regex == 'Unknown Modifier'?

• A more peculiar case pertains the PCRE_EXTENDED /x flag. This is often (or should be) used for making regexps more lofty and readable.

  This allows to use inline # comments. PHP implements the regex delimiters atop PCRE. But it doesn't treat # in any special way. Which is how a literal delimiter in a # comment can become an error:

  preg_match("/
     ab?c+  # Comment with / slash in between
  /x"
  

  (Also noteworthy that using # as #abc+#x delimiter can be doubly inadvisable.)

• Interpolating variables into a regex requires them to be pre-escaped, or be valid regexps themselves. You can't tell beforehand if this is gonna work:

   preg_match("/id=$var;/"
               ↑    ↺   ↑
  

  It's best to apply $var = preg_quote($var, "/") in such cases.

  See also:
  · Unknown modifier '/' in ...? what is it?

  Another alternative is using \Q…\E escapes for unquoted literal strings:

   preg_match("/id=\Q{$var}\E;/mix");
  

  Note that this is merely a convenient shortcut, not dependable/safe. It would fall apart in case that $var contained a literal '\E' itself (however unlikely).

• Deprecated modifier /e is an entirely different problem. This has nothing to do with delimiters, but the implicit expression interpretation mode being phased out. See also: Replace deprecated preg_replace /e with preg_replace_callback

Alternative regex delimiters

As mentioned already, the quickest solution to this error is just picking a distinct delimiter. Any non-letter symbol can be used. Visually distinctive ones are often preferred:

• ~abc+~
• !abc+!
• @abc+@
• #abc+#
• =abc+=
• %abc+%

Technically you could use $abc$ or |abc| for delimiters. However, it's best to avoid symbols that serve as regex meta characters themselves.

The hash # as delimiter is rather popular too. But care should be taken in combination with the x/PCRE_EXTENDED readability modifier. You can't use # inline or (?#…) comments then, because those would be confused as delimiters.

Quote-only delimiters

Occassionally you see " and ' used as regex delimiters paired with their conterpart as PHP string enclosure:

  preg_match("'abc+'"
  preg_match('"abc+"'

Which is perfectly valid as far as PHP is concerned. It's sometimes convenient and unobtrusive, but not always legible in IDEs and editors.

Paired delimiters

An interesting variation are paired delimiters. Instead of using the same symbol on both ends of a regex, you can use any <...> (...) [...] {...} bracket/braces combination.

  preg_match("(abc+)"   # just delimiters here, not a capture group

While most of them also serve as regex meta characters, you can often use them without further effort. As long as those specific braces/parens within the regex are paired or escaped correctly, these variants are quite readable.

Fancy regex delimiters

A somewhat lazy trick (which is not endorsed hereby) is using non-printable ASCII characters as delimiters. This works easily in PHP by using double quotes for the regex string, and octal escapes for delimiters:

 preg_match("\001 abc+ \001mix"

The \001 is just a control character ␁ that's not usually needed. Therefore it's highly unlikely to appear within most regex patterns. Which makes it suitable here, even though not very legible.

Sadly you can't use Unicode glyps ❚ as delimiters. PHP only allows single-byte characters. And why is that? Well, glad you asked:

PHPs delimiters atop PCRE

The preg_* functions utilize the PCRE regex engine, which itself doesn't care or provide for delimiters. For resemblence with Perl the preg_* functions implement them. Which is also why you can use modifier letters /ism instead of just constants as parameter.

See ext/pcre/php_pcre.c on how the regex string is preprocessed:

• First all leading whitespace is ignored.

• Any non-alphanumeric symbol is taken as presumed delimiter. Note that PHP only honors single-byte characters:

  delimiter = *p++;
  if (isalnum((int)*(unsigned char *)&delimiter) || delimiter == '\\') {
          php_error_docref(NULL,E_WARNING, "Delimiter must not…");
          return NULL;
  }
  

• The rest of the regex string is traversed left-to-right. Only backslash \\-escaped symbols are ignored.

• Should the delimiter be found again, the remainder is verified to only contain modifier letters.

• If the delimiter is one of the ([{< )]}> )]}> pairable braces/brackets, then the processing logic is more elaborate.

  int brackets = 1;   /* brackets nesting level */
  while (*pp != 0) {
          if (*pp == '\\' && pp[1] != 0) pp++;
          else if (*pp == end_delimiter && --brackets <= 0)
                  break;
          else if (*pp == start_delimiter)
                  brackets++;
          pp++;
  }
  

  It looks for correctly paired left and right delimiter, but ignores other braces/bracket types when counting.

• The raw regex string is passed to the PCRE backend only after delimiter and modifier flags have been cut out.

Now this is all somewhat irrelevant. But explains where the delimiter warnings come from. And this whole procedure is all to have a minimum of Perl compatibility. There are a few minor deviations of course, like the […] character class context not receiving special treatment in PHP.

More references

• preg_match(); - Unknown modifier '+'
• Unknown modifier '/' error in PHP
• PHP RegExpr error Unkown modifier '('
• Unknown modifier '(' when using preg_match() with a REGEX expression
• PHP: Regex - Unknown modifier error
• Warning: preg_match() [function.preg-match]: Unknown modifier '('
• When does preg_match(): Unknown modifier error occur?
  ^{(Just a well-written question demonstrating prior research)}