Andrey "Rarst" Savchenko

Hm, I’ve revisited behavior in Appearance>Themes – but it is on best behavior right now. No issues I could see and/or reproduce. And I remember there were some before – but a lot of theme stuff changed in WP 3.4

If you are still experiencing any please let me know and with more details of what you are doing and what goes wring with it.

Thank you for reporting!

It seems that my local local stack is not setup for https development and testing right now, so not adding this immediately – noted to work on later.

CodexGen is in tricky place. It got very little traction by itself and by now its role was pretty much reduced to be prototype for https://queryposts.com

On other hand QueryPosts is not (and will not for a while) focusing on data export features.

I am hesitant to keep two in sync functionally, since that adds a lot of CodexGen maintenance effort for very little usage that it sees.

At moment I would recommend just to create your own code for output. Since CodexGen is very modular with ton of reusable code, something like Codex_Generator_Phpdoc_Parser::parse() will do all the heavy lifting for you and you only need to work a bit on template to present data.

These are kinda side-effects of plugin functionality. There is no concept in WP of such dynamic theme switching and different users looking at different themes. Plugin just “tricks” code into displaying theme, that is different from actual (and exclusive) theme that is chosen via native functionality.

It might make sense to just not do that on appearance screen, I will note down to look into that.

Would also suggest a bullet or other indicator of the default menu in the toolbar.

Makes sense, noting down to implement.

The plugin doesn’t currently have settings page and tinkering opportunities are bit involved and take some basic dev skills.

For example if you want to hide Twenty Ten from switcher you can add this snippet (to your theme’s functions.php file for example):

add_filter( 'tts_allowed_themes', 'hide_twenty_ten' );

function hide_twenty_ten( $themes ) {

	unset( $themes['Twenty Ten'] );

	return $themes;
}

So it seems we can’t use toolbar theme switcher to provide theme switching ability for anonymous and guest users. right?
Is there any way to provide a theme switching link for any user of site?

I’ve answered about tweaking permission to switch right above.

but how to add button for your theme switcher in somewhere other than toolbar?
like as a button in footer or …

The toolbar is kinda the point… ?? However it’s possible to have plugin do magic behind the scenes but control it in alternative manner.

Essentially the act of theme switching is following a simple URL (to WP Ajax endpoint) and coming back, having cookies adjusted with theme choice. Looking at plugin’s code to produce link to switch to specific theme you do:

add_query_arg( array( 'action' => 'tts_set_theme', 'theme' => urlencode( $theme['Name'] ) ), admin_url( 'admin-ajax.php' ) )

Even simpler way would be to copy link from toolbar menu and hardcode it.

Then you just put that link wherever. Note that by default it will not work for users who are not allowed to switch themes, so worth showing only to those who can without further customization.

Here is relevant trac ticket https://core.trac.www.ads-software.com/ticket/15317

Also note that if there are themes you don’t need/want to appear in list you can get rid of them by filtering tts_allowed_themes hook.

Hmmm… I am mostly making use of native toolbar functionality and try hard not to mess it up. ??

I will ask around if this is considered WP-level bug (which it seems to me) and if isn’t going away by itself will set up test and see what I can do about it in my code.

The code should be able to handle that, but it is not use case that I actively target and test for.

To completely remove restriction on who can see and use switcher:

add_filter( 'tts_can_switch_themes', '__return_true' );

However if you need this for non-logged-in users you will also need something to force toolbar itself to show. It’s not in scope for this plugin, but I am pretty sure there should be plugins and/or snippets for that around.

Yeah, I caught the order issue after I committed bugfix version for WP 3.4

Rearranged the checks and pushed 1.1.2 just now:
https://www.ads-software.com/extend/plugins/toolbar-theme-switcher/changelog/

Bugfix version 1.1.1 is live in repository
https://www.ads-software.com/extend/plugins/toolbar-theme-switcher/changelog/

I am aware of the issue. WP 3.4 deprecated multiple theme-related functions and something about the way they were reorganized causes plugin to crash with fatal error.

I will work on producing a fix and releasing new plugin version.

Version 1.1 released

https://www.ads-software.com/extend/plugins/toolbar-theme-switcher/changelog/

1. Theme name now shown in toolbar, as per your suggestion.
2. I think technical template details are not in scope for this plugin (I hate those bits all over different pieces of code, thinking about making comprehensive context plugin), but I’ve added tts_root_title filter so you can add that after title without having to fork or subclass.

The plugin works by declaring pluggable wp_mail() function, which is intended way WP provides to override mail sending process.

Unless BuddyPress tries to do same (which I don’t think it has reasons to) there should be no issue.