Visiting Layout page introduces invalid setting in config.php

francosolerio

On a fresh install of Vanilla 2.6, opening the Layout panel of the Settings page (even before making any change or committing with save) a wrong setting is introduced in conf/config.php that makes the root of the forum unavailable with a big custom Page Not Found message.

The original config file has:
$Configuration['Routes']['DefaultController'] = 'discussions';

After visiting Layout the same line becomes:
$Configuration['Routes']['DefaultController'] = array('', 'Internal');

If I manually edit the line and restore the original line, the homepage is accessible again. But as soon as I go to the Layout panel, the file gets messed up again.

System info:
Ubuntu 16.04.4 LTS
PHP 7.2.7

Steps to reproduce:

1) Download and unzip the Vanilla package
2) Compile the form with the database settings etc
3) Access the homepage (everything works)
4) Access Dashboard
5) Click on Settings and select the Layout page on the left
6) Access the homepage of the forum -> PAGE NOT FOUND

Thanks in advance for any hint or suggestion

donovanb

Interesting. The Page Not Found is common as far as I can tell, and I doubt the Routes entry is invalid... but interesting that you've isolated steps to reproduce.

I required a custom .htaccess to fix the PAGE NOT FOUND issue, which I've shared in a few recent posts here.

x00

open an issue on github

https://github.com/vanilla/vanilla/issues

francosolerio

I opened an issue here: Visiting Layout page introduces invalid setting in config.php #7392

Could you please send me a link to the discussion with the custom .htaccess to fix the issue?

Thanks

R_J

Whatever happens there is surely no htaccess problem. Only by visiting a page there shouldn't be any changes written to the config. Try making that line $Configuration['Routes']['DefaultController'] = array('discussions', 'Internal');

francosolerio

I tried to put
$Configuration['Routes']['DefaultController'] = array('discussions', 'Internal');
but the result is the same: everything works until I visit the Layout page, then config.php is changed.

donovanb

# Modified
# If you modify this file then change the above line to: # Modified

DirectoryIndex index.php

<IfModule mod_rewrite.c>
    RewriteEngine On
    # Certain hosts may require the following line.
    # If vanilla is in a subfolder then you need to specify it after the /.
    # (ex. You put Vanilla in /forum so change the next line to: RewriteBase /forum)
    # RewriteBase /

    DirectoryIndex disabled

    RewriteRule (^|/)\.git - [L,R=403]
    RewriteRule ^cache/ - [L,R=403]
    RewriteRule ^cgi-bin/ - [L,R=403]
    RewriteRule ^uploads/import/ - [L,R=403]
    RewriteRule ^vendor/ - [L,R=403]

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.*)$ index.php\?p=$1 [QSA,L]
</IfModule>

<IfModule mod_headers.c>
   <FilesMatch "(?<!embed)\.(css|js|woff|ttf|eot|svg|png|gif|jpeg|jpg|ico|swf)$">
      Header set Cache-Control "max-age=315360000"
      Header set Expires "31 December 2037 23:59:59 GMT"
   </FilesMatch>
</IfModule>

francosolerio

The modified .htaccess doesn't solve the issue.

donovanb

There are a few possibilities. I guess I'm more focusing on the Page Not Found, rather than the odd setting change. Usual suspects for the PNF (that I found) are .htaccess config and permissions. We'd have to know more about your setup to help with those things.. permissions / environment / if the forum is installed in a directory, etc...

Ultimately, just know that this can be figured out.

Donovan

R_J

@donovanb said:
There are a few possibilities. I guess I'm more focusing on the Page Not Found, rather than the odd setting change.

"Page Not Found" is a result of a wrong entry in the config setting, so there is no need to fix this.

@francosolerio said:
On a fresh install of Vanilla 2.6, opening the Layout panel of the Settings page (even before making any change or committing with save) a wrong setting is introduced in conf/config.php

The code that is run on this page follows below (taken from class.settingscontroller.php):

    public function layout() {
        ...
        if (!$this->Form->authenticatedPostBack()) {
            ...
        } else {
            $newRoute = val('Target', $this->Form->formValues(), '');
            Gdn::router()->deleteRoute('DefaultController');
            Gdn::router()->setRoute('DefaultController', $newRoute, 'Internal');
            ...
            $this->informMessage(t("Your changes were saved successfully."));
        }
        ...

What happens is the following: only if the page has been posted, that means after you have clicked "Save", the current home page ("DefaultController") is deleted and afterwards saved again with a value that is taken from the POST information.
Additionally, after that has been done, an informational message is displayed in the lower left corner.

Normally you open a page with a http GET method. I really do not know how this could happen, but if the layout page is "opened" with a POST request, the new value for the DefaultController would be empty and the result would be the entry in the config that is causing the problems.

That is the only theoretical way that I could imagine how your problem may arise, but I wouldn't know how this could happen in real life...

francosolerio

Thank you R_J, the only thing that comes to my mind that can change the browser's http request is a browser plugin, and indeed it was! As soon as I disabled uBlock Origin Safari extension, the issue disappeared.

I really don't know why that happens, I think I'll drop a note to the extension's developer. For the time being, a little change helps avoid modifying config.php if the new route is empty (aka the POST is not a real POST with valid parameters).

public function layout() {
        ...
        if (!$this->Form->authenticatedPostBack()) {
            ...
        } else {

        $newRoute = val('Target', $this->Form->formValues(), '');
            if (!empty($newRoute)) {
                Gdn::router()->deleteRoute('DefaultController');
                Gdn::router()->setRoute('DefaultController', $newRoute, 'Internal');
                $this->setData('CurrentTarget', $newRoute);
             }
             // Save the preferred layout setting
             ...
        }
}

I don't know if a pull request for fixing a behavior introduced by the bug in another software would be accepted. What do you think about that?

R_J

Normally there should be no need for that, but preventing even absurd errors doesn't hurt either. But I would suggest a more subtil way euch doesn't have the same effect, but is less invasive: Vanillas val function takes a default value

$newRoute = val('Target', $this->Form->formValues(), 'discussions');

So if there is no value provided, the discussions controller will be set which in fact might result in a change, but at least not in a broken setting

francosolerio

That's great.

x00

edge case for an issue beyond the control of Vanilla. I think browser pluigns that submit forms in the background to be gratuitous especially from an adblocker.

On the other hand having a sensible default is no harm either.

donovanb

@R_J said:

@donovanb said:
There are a few possibilities. I guess I'm more focusing on the Page Not Found, rather than the odd setting change.

"Page Not Found" is a result of a wrong entry in the config setting, so there is no need to fix this.

"Thumbs Up"