[resolved] Submit admin settings change for subdirectory multisite redirects to root site (2 posts)

  1. andre.langer
    Posted 3 years ago #


    I have done a clean install of WordPress 3.5.1 with multisite feature enabled on a Windows server 2008 R2. Multisite is configured to use a separate subdirectory for each site. The redirection rules in .htaccess/web.config are updated and work as expected.

    Beside the main network side (Path: /, Frontend: http://mydomain.com/blog/) I have created a second site, let's call it "test" (Path: /test/, Frontend: http://mydomain.com/test/)

    Now, I want to change some settings for my site "test". So I login to the admin backend and select the "test" Dashboard" and the Settings->General menu item (http://mydomain.com/test/wp-admin/options-general.php ). However, when I submit the form, the loaded target url is http://mydomain.com/wp-admin/options-general.php?settings-updated=true , that means the General settings form of the Root Page. And as a consequence, the settings were not updated for the subsite "test".

    As far as I can see, the issue occurs for the General settings, the Write settings, the Read settings, the Discussion settings and the Media settings. Interestingly, everything works fine for the Permalink settings form, so I assume it is related to the individual form action.
    options-permalink.php works fine whereas the other options-*.php target URLs ignore the admin subdomain of the seccond page.

    Can anybody tell me if this is an irregular behavior and if it is likely to be a misconfiguration issue or if I am missing some important point? Could it be a plugin problem or a table metadata problem (I renamed the wp_* database tables to wpcms_* afterhand).

    Thanks for every idea...


  2. andre.langer
    Posted 3 years ago #

    I found the solution.

    The reason for this behavior was an incompatible plugin (http://wordpress.org/plugins/permalink-fix-disable-canonical-redirects-pack/ ) which was strangely already installed on this server and which had a side effect on the WordPress backend.

    After a night of sleep I followed the general recommendation and disabled all plugins, then enabled one by one and finally found the culprit.

Topic Closed

This topic has been closed to new replies.

About this Topic