Log into the backoffice, go to the Blogs tab, choose your blog, then uncheck "Allow skin switching" and save. You can still show the print skin by adding ?skin=printskinname onto the end of the url.

yes, I did it, but if "Allow skin switching" is unchecked, adding ?skin=print or any other sikinname onto the end of the url doesn´t change anything, still works with the default skin...

any other way???
thanks!

Actually I think that's not true. If the URL forces a skin it'll over-ride the back office setting. When the visitor clicks any other link they get the back office rule instead. That means not having skin switching turned on doesn't matter if your URL has ?skin=print (or &skin=print).

Make sense?

Excuse me, I will insist:

I don`t know if the URL forces a skin or not, but you can see this problem in my blogs:

In this one, "Allow skin switching" is checked on, and the "Para imprimir (print) link works right, but if you press Go Back button (IN THE NAVIGATOR SIDEBAR), the other post you whant to read more, will look at print mode:

http://www.prensadefrente.org/pdfb2/index.php?blog=6

In this other, "Allow skin switching" is unchecked, and you can`t go to print skin, no even wrihting ?skin=print onto url...

http://www.prensadefrente.org/pdfb2/index.php?blog=7

then, what is the true problem?

iTHINK PERHAPS there is a code to reset skin to default in each page

I tray with
<?
$skin='default'
?>

in head or in body, but It doesn`t work, all links continue in print skin.

How can I restore to default skin inmediately after select print mode?

thanks

That's odd. You're right. But that's not the way it usually works. Did you do some kind of modification to get the print functionality? I noticed that the url also had printme=1. I've never seen that before. The way skin switching works is that there's a cookie set when a reader switches skins, and then all the pages on all the blogs are show to that user with that skin until they change skins again or delete the cookie. I don't like that, so I usually just turn skin switching off. I can still view my blog with another skin by adding it into the url. But, as you pointed out, yours doesn't work that way anymore.

Interesting!

You can see in the following links that skin switching CAN be forced with the URL, but I also see where it is NOT working in your skin.
http://wonderwinds.com/flightblog.php is a blog without skin switching, and http://wonderwinds.com/flightblog.php?skin=junk_test shows the skin is changed. http://wonderwinds.com/flightblog.php/2005/08/31/i_m_going_flying is a single post in that blog, and http://wonderwinds.com/flightblog.php/2005/08/31/i_m_going_flying?skin=junk_test shows that single post with the skin changed.

That doesn't help you because I see where yours will not switch. By the way I had no problem using my "back" button to return to the proper skin. What browser do you have the problem in? I use Firefox 1.0.6.

I see where you are using version 0.9.0.10 and wonder if that is part of the issue? Probably not since the "print pretty pages" thread was posted when that was the latest and greatest version.

As personman noticed, there are some 'non-standard' things in your printing URL. Your url is "....&pb=11printme=1&skin=print", which I think contains an error. "&pb=1&printme=1" is probably what you want, but that does not allow skin switching in the blog 7. Do you have other hacks that may have interfered with the printing hack? Can you undo the hacks to try to find what is causing your blog to act that way?

EDIT: if you look at the blog I linked in the "junk_test" skin you'll see why I don't do skin switching. I use a horrible hack to make my categories list only show certain cats, but a normal skin shows cats I've set aside for future uses. Ugly hack, nice end result, TERRIBLE in different skins!

Mine doesn't work that way, either. If skin switching is turned off in the backoffice, adding a "skin" parameter to the URL does nothing. I thought that was just the way it worked. I'm using the latest version, and I haven't done much hacking to my blog.

Possibly server-related?

I'm reaching - I really don't know what the cause is.

Anyone have any idea? Skin selection is set in a cookie. On first selecting a new skin the URL contains the skin name, and the information is placed or updated in the cookie. Ever after, if no skin information is in the URL then the cookie is used. If, after allowing skin switching, you stop allowing it then the cookie is not supposed to count anymore. Clearly something is happening differently for at least 2 users. Thus I have to wonder if it is somehow server related.

Funny... I don't have a cookie from the prensadefrente site...???????

I will leave a test comment and tell it to remember me. That should give me your cookies. BRB.....

If I turn skin switching on, then it works just fine, and remembers my skin choice (even if I hand-type it in the URL). So, as far as I'm concerned, there is no problem, and it behaves as I would expect.

It is strange, though, that it works that way for some and not for others.

Do any of you use stub files? I don't, but I thought maybe that was a possible difference.

I got the expected cookies after commenting, but never got a cookie for selecting the print skin from either blog #.

The issue has to be due to one of the following:
1. server (no clue how it could be though)
2. hacks (although Kweb has the same issue and little hackage)
3. settings (maybe something about your baseurl in conf/_config.php?)

Oh and by the way, here is a way to get back to the real skin:

<?php if( ! $Blog->get('force_skin') ) { // IF SKIN SWITCHING IS ENABLED {
	$def_skin = $Blog->get( 'default_skin' );
	$def_skin_link = url_add_param( get_bloginfo('blogurl'), 'skin='.$def_skin ); ?>
	<ul>
	<li><a href="<?php echo $def_skin_link; ?>">Switch to the Default Skin</a></li>
	</ul>
	<?php } ?>

Placing that in the _main in your print skin *should* let people see the blog in the real skin again.

A test can help determine a few things, if you're willing and have the time.

Make a brand new completely different installation with no hacks. Turn off skin switching, then change skins in the URL. Does it switch skins? If not then we know it's got nothing to do with any hacks - it's got to be your server.

If you can switch skins in a 'clean' installation go ahead and add the "print skin hack" and see what happens when you try to use it. Again we'll learn something to tell us why your real installation won't behave like 'normal'.

After that try adding your real skin to the test installation and see what happens. Maybe (for some reason) the issue comes from your skin, so this test will tell us that.

I do have a clean instalation, for this kind of test:
www.prensadefrente.org/baulazul
absolutely no hacks.

Turning off skin switching: the same problem...

you think it's got to be my server, but see:

If you press print option ("Para imprimir") yo see the post in the print skin, OK. "Allow skin switching" is checked on:

http://www.prensadefrente.org/pdfb2/index.php?blog=6

This is the link code
<a href="<?php echo url_add_param( $Item->gen_permalink(), 'printme=1&amp;skin=print', '1'); ?>" >Para imprimir</a>

And if you get back clicking the link in the banner, it works, you can continue viewing all other post in default skin!
this is the code link to come back and restore default link:

<a href=" <?php echo url_add_param( $Item->gen_permalink(), 'skin=default'); ?>" title="Volver al sitio">

THE PROBLEM BECOME WHEN, INSTEAD OF CLICKING THE LINK IN THE BANNER, YOU CLICK GO BACK BUTTON IN THE NAVIGATOR BAR (IE6 or Firefox). Any other post to read more you choose (or cattegory), you will see in print mode... The cookie seems to mantain the print skin...

That's what I thought there could be a code to reset skin to default in each page

I tray with
<?
$skin='default'
?>

in head or in body, but It doesn`t work, all links continue in print skin.

well, as we say in the pampas: "¡cosa´e mandinga"! (daemon`s matter!)

Pablo wrote:

I do have a clean instalation, for this kind of test:
www.prensadefrente.org/baulazul
absolutely no hacks.

Turning off skin switching: the same problem...

Near as I can tell then it *must be* something about your server. Every time I've ever had an installation I've been able to change skins in the URL. Sometimes to troubleshoot for people I find out if they have other skins by just adding it to the URL, then can maybe show them something about their problem. So if it doesn't work for you what else could it be?

Pablo wrote:

This is the link code
<a href="<?php echo url_add_param( $Item->gen_permalink(), 'printme=1&amp;skin=print', '1'); ?>" >Para imprimir</a>

Okay - that helps me understand one problem. Try changing that to

<a href="<?php echo url_add_param( $Item->gen_permalink(), 'printme=1&amp;skin=print'); ?>">Para imprimir</a>

The final parameter is for "glue", or the thing that sticks all the params onto the end of your URL. When you have it be '1' you get

pb=11printme=1&skin=print

. The default is for "&", so with the way I show here you will get

pb=1&printme=1&skin=print

. I do not know if that is the problem or not, but it can't hurt to have it be better!

Pablo wrote:

Any other post to read more you choose (or cattegory), you will see in print mode... The cookie seems to mantain the print skin...

Oh now I understand. BACK gets you back, but any clicks after that get the print skin. I went BACK, but didn't go anywhere after that, so I didn't see that happen. I don't know how to code it, so let's hope for some extra help here. I think what you need is for your blog to read the URL and decide what to do. Something like this:

if( URL does not have "skin=print" in it ) {
$skin=$default_skin;
OR MAYBE
$skin='YOUR_SKIN_NAME';
}

That would have to happen immediately so that the request is processed with the correct skin name. conf/hacks.php would be a good place for that because _main.php reads hacks.php as part of initializing b2evolution. Plus you won't lose the hack when you upgrade.

So what unless someone knows how to write something that can read the URL!!!

Oh by the way is your skin named "default"? Inside the code b2evolution uses a variable $default_skin, so I'm guessing your skin is called default because "&skin=default" in your banner works.

I think the difference may be "register_globals" being on or off. It's off on my server, and from what I can tell, the code that detects the skin from the URL assumes this is on.

I guess this could be called a bug report or a feature request, depending on how you look at it.

look at this!

whith a little help of destiny, I foud it, and everything works right!

in b2evocore/_blog_main.php, when refeer to skin settings, it says:

else
{ // Get the saved skin in cookie or default:
param( $cookie_state, 'string', $default_skin );
// Get skin by params or default to cookie
// (if cookie was not set, the $$cookie_state contains default skin!)
param( 'skin', 'string', $$cookie_state );

I change $$cookie_state by $default_skin, so then the print skin only works when i click for pretty print mode, but everything else continues working with the default skin selected...

I don,t know if you understand this explanation, my english is not good, but you can see my print mode here:

http://www.prensadefrente.org/pdfb2/index.php?blog=7&skin=quienessomos

thanks everybody!