[wp-trac] [WordPress Trac] #20746: Accessing non-existing theme folder in Network install gives 500 error

[WordPress Trac]

#20746: Accessing non-existing theme folder in Network install gives 500 error
-------------------------------------------------+-------------------------
 Reporter:  arkimedia                            |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Rewrite Rules                        |     Version:  3.3.2
 Severity:  normal                               |  Resolution:
 Keywords:  needs-testing has-patch dev-         |     Focuses:  multisite
  feedback 2nd-opinion                           |
-------------------------------------------------+-------------------------

Comment (by mausmalone):

 I'm reviving this **ancient** thread because I think I figured out what
 this bug is and - more importantly - where it comes from. I get the
 impression that nobody's willing to fix it because they're afraid that
 it's like this for a reason and, as far as I can tell, it isn't.

 Basically the long and short of it is this. This line:

 {{{
 RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
 }}}

 ''can result'' in a circular redirect in some rare circumstances because
 **([_0-9a-zA-Z-]+/)?** will just keep matching itself over and over again
 after redirect. Removing the **?** fixes it, but why is it there in the
 first place?

 Here's the part of /wp-admin/network.php that outputs a .htaccess file in
 WordPress 3.4.


 {{{#!php
 <?php
                 $htaccess_file = 'RewriteEngine On
 RewriteBase ' . $base . '
 RewriteRule ^index\.php$ - [L]

 # uploaded files
 RewriteRule ^' . ( $subdomain_install ? '' : '([_0-9a-zA-Z-]+/)?' ) .
 'files/(.+) wp-includes/ms-files.php?file=$' . ( $subdomain_install ? 1 :
 2 ) . ' [L]' . "\n";

                 if ( ! $subdomain_install )
                         $htaccess_file .= "\n# add a trailing slash to
 /wp-admin\n" . 'RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/
 [R=301,L]' . "\n";

                 $htaccess_file .= "\n" . 'RewriteCond %{REQUEST_FILENAME}
 -f [OR]
 RewriteCond %{REQUEST_FILENAME} -d
 RewriteRule ^ - [L]';

                 // @todo custom content dir.
                 if ( ! $subdomain_install )
                         $htaccess_file .= "\nRewriteRule  ^[_0-9a-
 zA-Z-]+/(wp-(content|admin|includes).*) $1 [L]\nRewriteRule  ^[_0-9a-
 zA-Z-]+/(.*\.php)$ $1 [L]";

                 $htaccess_file .= "\nRewriteRule . index.php [L]";
 }}}

 It's clearly a bit messy, so somebody decided that they would clean it up
 in version 3.5. And while they were at it, they would take that gnarly
 RegEx and turn it into a variable so it would be easier to read and
 understand. And it is much **much** cleaner in WordPress 3.5:

 {{{#!php
 <?php
         $subdir_match          = $subdomain_install ? '' : '([_0-9a-
 zA-Z-]+/)?';
         $subdir_replacement_01 = $subdomain_install ? '' : '$1';
         $subdir_replacement_12 = $subdomain_install ? '$1' : '$2';


 }}}


 {{{#!php
 <?php
                 $htaccess_file = <<<EOF
 RewriteEngine On
 RewriteBase {$base}
 RewriteRule ^index\.php$ - [L]
 {$ms_files_rewriting}
 # add a trailing slash to /wp-admin
 RewriteRule ^{$subdir_match}wp-admin$ {$subdir_replacement_01}wp-admin/
 [R=301,L]

 RewriteCond %{REQUEST_FILENAME} -f [OR]
 RewriteCond %{REQUEST_FILENAME} -d
 RewriteRule ^ - [L]
 RewriteRule ^{$subdir_match}(wp-(content|admin|includes).*)
 {$rewrite_base}{$subdir_replacement_12} [L]
 RewriteRule ^{$subdir_match}(.*\.php)$
 {$rewrite_base}$subdir_replacement_12 [L]
 RewriteRule . index.php [L]
 EOF;

 }}}

 Have you all spotted the error yet? Whoever made these changes started by
 changing this

 {{{
  $htaccess_file .= "\n# add a trailing slash to /wp-admin\n" .
 'RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]' . "\n";
 }}}

 to this

 {{{
 # add a trailing slash to /wp-admin
 RewriteRule ^{$subdir_match}wp-admin$ {$subdir_replacement_01}wp-admin/
 [R=301,L]
 }}}

 And that's totally valid. It outputs the same exact string as the original
 but it's easier to read. But then they changed this:
 {{{
 if ( ! $subdomain_install )
                         $htaccess_file .= "\nRewriteRule  ^[_0-9a-
 zA-Z-]+/(wp-(content|admin|includes).*) $1 [L]\nRewriteRule  ^[_0-9a-
 zA-Z-]+/(.*\.php)$ $1 [L]";
 }}}

 to this:

 {{{
 RewriteRule ^{$subdir_match}(wp-(content|admin|includes).*)
 {$rewrite_base}{$subdir_replacement_12} [L]
 }}}

 And those do not match ... they're very similar but they don't match.

 So that's where the error was introduced and unless someone can find a
 really good explanation for it I think it's pretty clear that someone was
 refactoring /wp-admin/networking.php and, though they did make it **a
 lot** cleaner, they made a tiny typo that introduced a very rare bug.

 The 3.5 version of this code is character-for-character what's in 5.8,
 btw, except it's been moved to **/wp-admin/includes/network.php**.

 So does that make sense? Do any of the more experienced WP developers have
 any info that might show that this is incorrect? There's still a lot about
 the WP code base I don't understand so I'm totally receptive to the idea
 that I've jumped to the wrong conclusion.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/20746#comment:57>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform