Theme and Plugin Editor unable to edit PHP files for Active theme/plugin of Main Site in a Multisite system

[Otto42]

Originally reported here: ​https://wordpress.org/support/topic/theme-editor-cannot-edit-php-files/

Was able to reproduce on my own multisite instance.

Editing any PHP file of the theme which is active on the "main" site of the multisite instance will result in a "Something went wrong" message.

Narrowed it down to the wp_remote_get calls (either the one to wp-admin/theme-editor.php or the one to home_url) timing out, in the $is_active section of the function wp_edit_theme_plugin_file().

This does not happen on any other theme, nor any other plugin as far as I can determine. Those edits go through fine, however you would expect them to, as other themes are not the "active" one, although I cannot account for why plugins would not register as "active" in this case. Perhaps network activated plugins are not detected as active here and thus do not trigger this code.

While the /wp-admin/theme-editor.php call does redirect to /wp-admin/network/theme-editor.php, I'm not sure of the underlying problem here. I think it may have something to do with the difference between the transients and the site_transient, but I'm been unable to narrow it down further. Reporting as a bug in case anybody else has better ideas.

[andrea.r]

Changes references to admin_url into network_admin_url in function wp_edit_theme_plugin_file

[andrea.r]

Hello,
Same issue here on WP 4.9.4, and it also applies to the Plugin Editor when trying to edit plugins active on the main site.

I tracked down the issue to the fact that the URL called by the loopback test to verify that no errors were introduced in the PHP theme/plugin code is referring to the non-multisite theme/plugin editor (see lines 525..537 of wp-admin/includes/file.php), which triggers a redirect to the multisite editor without passing along the query string (line 13 of wp-admin/plugin-editor.php and wp-admin/theme-editor.php) which contains the scrape_key and transient needed to correctly handle the request (see functions wp_start_scraping_edited_file_errors and wp_finalize_scraping_edited_file_errors in wp-includes/load.php).

I suggest changing the references to admin_url in lines 525..537 of file wp-admin/includes/file.php into network_admin_url, which falls back to admin_url if the installation is not multisite.

[jergerb]

Has this been solved? I'm having the same issue trying to update a includes PHP file on a multisite set up.

[mjdewitt]

Hi,

I recently ran into the issue of Multisite Network Admin unable to edit PHP files for themes and plugins on a development server under WP 5.0.3. I too found that the fundamental issue is that the loopback requests don't use the network admin url (see ​https://wordpress.org/support/topic/does-multisite-run-properly-under-php-fpm-cgi/).

What I believe also would great is commenting in the code the fact that a working "Basic Authorization" is not a requirement of the loopback request. Getting "Basic Authorization" working under CGI is difficult, if not impossible, depending on the host's configuration. It took me a while to chase this down as a "red herring" as underlying request/response errors are masked in the UI by the setting of $loopback_request_failure with a generic failure message.

I am still exploring, but haven't been able yet to figure out yet why the loopback is needed twice (the check to see if the site is working makes sense to me) and I think this is an important question because of the hurdles (auth, needle, http, ssl, etc.) the loopback request has to pass in order to confirm a change in the filesystem that was already successfully made.

As a concrete example, on my development server, which has a self-signed certificate, I have to figure out how I can best manage sslverify as the loopback request is insisting on verifying my snake-oil certificate.

Mike

[ocean90]

Duplicate of #45755.