I've read through numerous posts on preg_match and can't find the answer. How to fail the whole preg_match when only one part of the haystack fails? I simply need to fail the whole preg_match, when the haystack ends with dot-anything (e.g., .html).
The groupings in here, before the problem area, are needed for other purposes and can't be changed. The portion I want to fail, when it contains a dot, is: ([^\.])* If that fails, the entire preg_match needs to fail. Note: the dot is only a "failing dot" if it occurs after the hyphen. There are dots before the hyphen that are not failing dots.
Everything on the right-hand side of the OR operator is fine. Nothing needs to be changed there.
preg_match('#^(.*)\/([0-9]+)\-([^\.])*|(.*)id_category=([0-9]+)(.*)$#', $haystack, $return_array)
Since I'm not evaluating the entire string for the dot, I have not been successful with negative lookahead. It only fails the one part, without failing the whole preg_match.
You can add any such condition as a (negative) lookhead at the start of the regex.
preg_match('#^(?!.*\..+$)((.*)\/([0-9]+)\-([^\.])*|(.*)id_category=([0-9]+)(.*)$)#', $haystack, $return_array)
Here it would fail when there is a '.' with at least one character afterwards. But if you are looking for fileendings, you can e.g. limit the amount of following characters:
(?!.*\..{1,4}$)
See a simple example here in regex101
Does anyone know off the top of their head if this is valid (start and end caret and dollar within each side of the OR)? It appears to be valid in my prelim tests:
'#^misc-stuff-and-reg-ex$|^other-stuff-and-reg-ex$#'
If it is actually valid, and not just appearing to work, then I can also solve my problem with an approach that seems less heavy on the processor, by simply doing this:
'#^(.*)\/([0-9]+)\-([^\.]*)$|^(.*)id_category=([0-9]+)(.*)$#'
It is appearing to test out as a solution. I don't want a match when a dot is after the hyphen, and it is appearing to satisfy that in tests so far, without fouling anything up because of splitting the carets/dollars apart.
What's interesting to me is that when the dollar symbol is not explicitly placed after the no-dot-here part, then the no-dot-here part is not implicitly seen as the end of the haystack (thus also giving us success in not matching if dot is present), even though it is snugged right up next to the OR operator. Or, maybe that's not very interesting, since the other side of the OR operator is simply seen as part of the string, even though it, like the left-hand side, is actually the whole string in a practical sense.