Serendipity Forums

To clear that up:

my blog is running 1.7 (at least it says so), the "URL to blog" field is empty in the admin-interface and in the db I find only baseURL (no defaultBaseURL)

That is perfectly normal. You upgraded the blog to 1.7, it is not a fresh installation, correct?

The option "URL to blog" previously was baseURL. Now it is called defaultBaseURL and baseURL is either that option or getting autodetected. My patch will add a task to the upgorader to move baseURL ot defaultBaseURL, if only the first is present.

Findings:

I can only tell you that all links were working with RC3, but they did not with the release version.

In Blog coming via RC the variable defaultBaseURL did not exist. In Blogs updated from 1.6.2 the variable exists but empty.

What I find as well is that the variable autodetect_baseURL is set to false for blogs coming from RC and true for the others.

Hi Dirk

In Blogs updated from 1.6.2 the variable exists but empty.

You probably saved the configuration in this blog, correct? I was able to reproduce the bug (install 1.6, upgrade to 1.7, save the configuration there). The config-option defaultBlogURL wouldn't exist in 1.7 if the configuration is never manually saved, which explains why the bug wasn't always triggered after an update.

After saving the configuration, blogURL is set in the database. defaultBlogURL is set as well but empty. Because of a bug in serendipity_load_configuration(), that empty value is used to overwrite blogURL in the serendipity-array read by the templates. The bug won't occur in most PHP-environments if the HTTP-Path auto-detection is enabled.

To give an update on the situation: I just commited a second patch which will also fix this issue on blogs who currently experience the bug, the patch from yesterday will prevent the bug from occuring after an upgrade from 1.6.

onli wrote:Hi Dirk

In Blogs updated from 1.6.2 the variable exists but empty.

You probably saved the configuration in this blog, correct? I was able to reproduce the bug (install 1.6, upgrade to 1.7, save the configuration there).

Yes, I did.

onli wrote:To give an update on the situation: I just commited a second patch which will also fix this issue on blogs who currently experience the bug, the patch from yesterday will prevent the bug from occuring after an upgrade from 1.6.

Perfect!

Cheers

Dirk

onli wrote:I was able to reproduce the bug (install 1.6, upgrade to 1.7, save the configuration there). The config-option defaultBlogURL wouldn't exist in 1.7 if the configuration is never manually saved, which explains why the bug wasn't always triggered after an update.

Perfect, Malte!!! That sounds reasonable!
Does that mean, everybody who hasn't updated yet, has to trigger the manual configuration submit once, to be not affected by this?

The other way around. After the upgrade to 1.7, don't touch the configuration or if you do, remember to enter the "URL to blog" manually. The upgrade to 1.7.1 will take care of that issue without the user having to use the configuration.

Ah, I see ... Well, I did this a lot of times since upgraded and the baseURL value never changed (and that was confusing me). And that - by your mean - was because I did not upgrade from 1.6x, right?

And the ones trying the RC version without having this issue, were those, who haven't submitted config yet, also right?

Right. Only an upgrade from 1.6 or an earlier version, were that option was called baseURL and not defaultBaseURL, will cause the bug.

Timbalu wrote:And the ones trying the RC version without having this issue, were those, who haven't submitted config yet, also right?

Or autodetection was on or the RC-Version was a fresh install, not an upgrade, or they filled in defaultBaseURL in the configuration.

Ok THAT one is a match. Well done!

one last question...:
Wouldn't it be better to delete databased set old baseURL var, to avoid future "conficts", after all this is done in 1.7.1, to only presume with defautBaseURL?

Maybe. I didn't want to delete it in case the upgrade fails, so it at least remains in the database. As it normally gets overwritten anyway, having it there shouldn't hurt.

As far as I'm concerned, I am not satisfied with having these sort of cadaverous leftovers. We can never forget this, as being fixed and cleared in total. And every new developer will not see it as (understandable) documented...

Well, are we talking about the same thing?

The value in the database hurts no one, a new developer won't even notice that. I agree that the code respecting serendipity['baseURL'] right now is not good in that regard. The next release (1.8/2.0) should remove that, with the upgrade-taks of 1.7.1 there will be a valid defaultBaseURL in every installation.

Yes, we are!
And if you remember to correct this for 2.0, this is definitely fine for me!