Suggested change to settings.php

[fade2gray]

Wouldn't this avoid having to use repair_settings php? Works for me on localhost (running Virualmin on Ubuntu server) and domain server.

What you are getting is exactly what you will get when the forum is set up to localhost and then copied to an actual domain server without  changing all of the paths and urls.

Change $boardurl...

From:

Code Select Expand

$boardurl = 'http://127.0.0.1/smf';

To:

Code Select Expand

$boardurl = 'http://'.$_SERVER['HTTP_HOST'].dirname($_SERVER['PHP_SELF']);

[Arantor]

No, would not recommend. I already fixed issues in the installer in the past relating to the suggestion you've made where it was insecure.

HTTP_HOST is not guaranteed to be set (it's not mandatory in HTTP/1.0, is in 1.1) but in any case it is inherently *supplied by the user* and should be assumed to be tainted until proven otherwise.

In any case it is just *rife* with SEO penalties. Consider that this would on most sites suddenly make the entire site be visible to both domain.com and www.domain.com and they would effectively mirror each other's content which is a duplicate content penalty.

I am willing to bet you are using PHP 5.5 with Zend OpCache, or APC, which can under some circumstances cause the value you set during installation to not be used when updating Settings.php during installation.

[Kindred]

Besides, why do you feel it is necessary to avoid running repair_settings.php?  They took was designed specifically for adjusting the settings needed to move a forum.

[Arantor]

Actually, the bug he encountered can affect fresh installations where 127.0.0.1/smf is the default in Settings.php, it's loaded from cache and saved to cache again without the proper value being saved.

I know it's fixed in 2.1 but I don't know if it was backported to the 2.0 installer script.

[fade2gray]

Excuse my ignorance, but why doesn't the correct url get used for the avatar and theme directories when the "Forum URL:" is displayed correctly at step #2 during installation? This doesn't seem a problem for an other popular board's installation.

[Kindred]

It has always been set correctly for me."

[Arantor]

For exactly the same reason as I alluded to above. When the installer performs the write, a cached version (i.e. with the old/incorrect data) is used instead to repopulate Settings.php and subsequently for all generation into the database.

@Kindred: you would need to be running PHP 5.5 with Zend OpCache or APC.

For more information:

https://github.com/SimpleMachines/SMF2.1/issues/868
https://github.com/SimpleMachines/SMF2.1/commit/fcb4952ed220d37c15a1f13d8643113504db261e

Possibly related:
https://github.com/SimpleMachines/SMF2.1/issues/2207

[Kindred]

Ah. I see.

[fade2gray]

@Arantor: Applying the 2.1.0 opcache patch to 2.0.9 worked for me. Thanks

[Arantor]

I thought it probably would

@Kindred, this probably indicates that the mainstream branch of 2.0.x should get it in SVN ready for the next build run (for building 2.0.10 packages as and when that happens, unless someone wants to rebuild the 2.0.9 packages too)

[Kindred]

Yah, we are not going down that road again (multiple versions of a version)

So, I'll suggest that it gets included into 2.0.10, along with the mod_security category patch...  Whenever that happens.