Because you do not want the users skin switching to a feed, instead of a proper skin... Which would happen if ?skin=_rss is used... With ?tempskin=_rss the skin preference is not saved.

At least this is why i think it is (pretty sure it is).

Well thats ok if you want to give users Skin choices...
I don't :)

John are you saying someone who subscribes to a b2evolution blog that gets upgraded will suddenly have a dead feed in their aggregator?

Nope, the rss.php etc files are still in the same location (although, funnily enough, they set $skin and not $tempskin).

AFAIK the reason for tempskins is purely aesthetic as a feed is just another skin (view) of your blog.

¥

@EdB
Mine died in Bloglines (feed script error).

It was easily fixed though some subscribers did email me about it as well.

Hi John,

Can I ask you to stop lying? I just visited your blog and they're definatley not powered by sparkes :roll:

¥

Hell, caught out again..

Though I do still have a full Sparkle backup :)

Your a bit offtrack EdB, he was just asking why feeds use 'tempskin' instead of 'skin' ;)

EDIT: Yeeks where did those last 4 posts come from 8|

now that's a much better sig ;)

If you change $skin= to $tempskin= in all the feed pages in xmlsrv then things will work again. I'll try and remember to raise this on the dev list.

¥

Wait so whats the problem here?

feeds should use 'tempskin', skins should use 'skin'....

Thanks, will do so when I end up getting enough enthusiasm to start twiddling again :)

The problem with the feed (in xmlsrv folder) using $skin='_feed' is that if skin switching is disabled then the feed will get the (forced) blog skin. If $tempskin is used then it'll bypass that restriction.

¥

Anyway you should not do $skin='_feed', you should do $tempskin='_feed'.

But your saying that if skin switching is disabled, the user can still change their skin by using $tempskin='skin' instead of $skin='skin' ?

Is that the only problem?

My misunderstanding then. I was aware of how the feeds now use a folder located in the skins folder, but briefly feared that the actual feed URL (there I go capitalizing again :roll: ) included it - and did not look for myself.

Anyway twas a brief fear that aggregators might choke when a blog owner upgrades. Seems we have a case of an issue. Is it fair to say in general it's not an issue?

(better check my own blog...)

Hm! The actual URL has changed!!! I think this needs further investigation. After I take care of a plugin I've been wanting to make I'll subscribe (via Sage in Firefox) to a 0.9.2 test installation I have, then upgrade it to 1.8 beta carotene and see what happens.

So theres two issues?

1) using tempskin bypasses the do not allow skin switching setting.

2) existing subscribers (via feeds) are booted because of the change in url.

Correct?

Urm, sort of, but you have it a tad arse backwards (must be your hemisphere :p).

Although a user "could" change your (blog) skin with $tempskin= (in url) that isn't the problem. The problem is that the (old) default feed files use $skin which can be overidden by the blog settings (allow skin switching == no). Which means that feeds will fail for any blog that dissallows skin switching.

Lol EdB, you'll be fretting about capitalisation and brackets right up to the sun going over the yardarm ;)
¥

You mean existing subscribers feeds will fail for blogs that do not allow skin switching? If so then i'm totally up to speed.

Well using tempskin has it's purpose.

The only 'fix' i can think of would be to make it so skins which directories start with '_' should bypass the 'no skin switching' option. Agree?

You mean existing subscribers feeds will fail for blogs that do not allow skin switching? If so then i'm totally up to speed.

You're almost up to speed, using _skin stops it showing in the skin list, but you need to change $skin to $tempskin in the (old location) feed files.

btw John, my mind stayed with me long enough to raise this on the dev list, hopefully it'll be sorted by the next release (about april 2947 from what I hear :roll:)

¥

So where is the problem? And how do you plan on fixing it?

The answer is 42 wrote:

The problem is that the (old) default feed files use $skin which can be overidden by the blog settings (allow skin switching == no).

ish :p

¥

Oh no, you're not one of these 42 nuts are you?

Yeh but the feeds shouldn't use 'skin', they should use 'tempskin'.
And that's the way it should be as using 'skin' may cause the feed to become the actual skin for the blog, instead of a proper blog skin like 'custom'...

So if skin switching is no, then 'skin' would no longer work for feeds.
If it is yes, then 'skin' would work for feeds.

So if the old subscribers are subscribed to a blog where skin switching is disabled, then they have a problem...

So it should be made that skins witch directories start with a underscore bypass the no skin switching restriction.

Now if thats not it, i'll try again after sleep.

I need a number? :O damn, I always thought I was a nut no matter the number

The simplest solution (since this only involves backwards compatibility) is to change the variable name in the affected files ;)

¥

So your suggesting not using 'tempskin' at all?

And which files are infected, it's behaving exactly like it should...

No, what I'm saying is that the files (old feed locations [== xmlsrv/]) use $skin='<new feed skin>'; what they need to do is use $tempskin = '<new feed skin''; otherwise they can be overriden if a blog forces a skin.

¥

Ohhhhhhhhhh.

Couldn't they just do a http_redirect to the correct page or whatever...

probably, but why force another pageload?

¥

Good point.

I'm happy.

yay :D sleep well in hell .... urm, I mean perth (complete with cheap party happy women ....... damn you have a hard life :|)

¥

You wouldn't believe.

I'll just take hell as a compliment from now on...

Does this mean I just paid you one hell of a compliment? ..... bugger

and I'll believe anything, that's part of what makes being blonde fun ;)

¥

ps.
Urm, so, John, does all this answer your question?

Just to add. Yes the users of the 0.9.x feed URLs do not receive feeds anymore, although if visited "directly" via a browser it works fine. I was informed by blogburst on this matter.

However, feedburner seems doing fine using the old URLs.

I updated all my feed URLs to the new one. In light with this, maybe there should be a feedburner support built-in? Or a plugin maybe...

^^