Bug #7831

Router interprets negative integer values of a match result as "matched"

Added by Robert Lemke about 10 years ago. Updated over 9 years ago.

Should have
Start date:
Due date:
% Done:


PHP Version:
Has patch:


The DynamicRoutPart::match() method doesn't do strict comparison of the route's return value and therefore wrongly interprets integer values such as "-1" as TRUE. This leads to the route part handlers to match although they don't.

Associated revisions

Revision 6bcc0e8b (diff)
Added by Robert Lemke about 10 years ago

[+BUGFIX] FLOW3 (Configuration): The ConfigurationManager now checks if the option "uriPattern" has been set. Fixes #7820
[~TASK] FLOW3 (Error): The var_dump debugger now displays more information about objects implementing ArrayAccess
[+BUGFIX] FLOW3 (MVC): The Router now uses strong comparison for checking the match results of routes. Fixes #7831
[~TASK][!!!] Fluid (View): The TemplateView now expects all template files to be UpperCamelCase as this is the general convention for filenames in FLOW3. Make sure to update the case of your template filenames! Resolves #7243


#1 Updated by Robert Lemke about 10 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 0 to 100

Applied in changeset r4321.

#2 Updated by Bastian Waidelich about 10 years ago

Robert Lemke wrote:

Hi, I have a little remark here:

The DynamicRoutPart::match() [...] wrongly interprets integer values such as "-1" as TRUE.

RoutePartHandler must implement F3\FLOW3\MVC\Web\Routing\RoutePartInterface. It's match() method should always return a boolean (and the default DynamicRoutPart does).
So if DynamicRoutPart::match() returns "-1", that is actually a mistake in the respective route part handler. The same thing for Route:matches(). But I guess, we still want to "fix" this in the calling code, right?

BTW: the fix isn't covered by a unit test ;) should I provide one?

Also available in: Atom PDF