Pattern for user account page results in "404 Error - File not found!"

Please attach an export of the url_alias table and the system table.

I encountered a similar problem. In Firefox, I noticed <?> blocks after each segment in newly generated aliases after doing an upgrade to a newer version of pathauto. After clicking one of the aliases, I noticed the 404 and the status bar had had %00 where the <?> glyphs had been. I figured a null character had crept in somewhere, so after some testing I realized it wasn't Firefox doing it. I starting scanning the code and finally came across this block in pathauto.inc starting at line 182:

  if (function_exists('mb_eregi_replace')) {
    $output = mb_eregi_replace($ignore_re, '', $output);
  }
  else {
    $output = preg_replace("/$ignore_re/i", '', $output);
  }

After commenting out the if clause and the brackets, everything worked fine and I regenerated all my aliases and no <?>'s or %00 had cropped up. I'm pretty sure my host has mb_string, because the function didn't produce any errors, just odd output. I do know the php version is rather old, 4.3x or 4.4x.

So, here's the snippet with edits:

  //if (function_exists('mb_eregi_replace')) {
  //  $output = mb_eregi_replace($ignore_re, '', $output);
  //}
  //else {
    $output = preg_replace("/$ignore_re/i", '', $output);
  //}

Hope this helps save some people the gut wrenching half-hour it took me to find out what had happened.

-Seth

Another user affected by this bug, specifically:

warning: mb_eregi_replace() expects parameter 3 to be string, array given in
[sitehomedir]/sites/all/modules/pathauto/pathauto.inc on
line 182.

Yes, they have mbstring enabled, specifically:

Multibyte Support: enabled
Multibyte string engine: libmbfl
Multibyte (japanese) regex support: enabled
Multibyte regex (oniguruma) version: 4.4.4
Multibyte regex (oniguruma) backtrack check: On

@DamienMcKenna - it would be useful if you could figure out what the array is in mb_eregi_replace when this happens.

Something like drupal_set_message('<pre>'. print_r($output, TRUE) .'</pre>'); right before the call to mb_eregi_replace and then paste the output from that into this issue.

2+ weeks without specific details on how to repeat the bug. I imagine it is OS/PHP version/other module specific though I'm not entirely sure.

If this were a bug in the module on it's own then we'd have hundreds of reports of it... :/

I believe this is a duplicate of #341807: My Account/URL alias for user account returns 404.

At least that has a decent solution to the problem which none of the other similar issues have.