Andrey "Rarst" Savchenko

Sorry for late reply, my feed reader is missing your last answer for some reason. :\

Looking at your snippet your path for log might be off, starting it with / means look for it relative to the very root of file system. I doubt you have public_html folder right in root?..

If there aren’t any errors in that file then everything is ok. ??

If there are errors, but widget isn’t showing them – then not ok.

When I run phpinfo.php, it tells me that ‘error_log’ has a value of ‘error_log’ … no other path info is included.

My guess would be that makes log relative to active PHP entry script file and since WP has several of them (admin is different from front end, etc) you probably have several logs all over from it.

If you enable WP_DEBUG_LOG (see https://codex.www.ads-software.com/Debugging_in_WordPress#WP_DEBUG_LOG ) it will point logging to WP_CONTENT_DIR . '/debug.log' and widget will pick that up.

But since that is public location and not really recommended to keep on you can just set different path via ini_set('error_log','path'); or filter error_log_widget_logs.

Not sure what happens. If I feed your logs as is to it I seem to get correct most recent entries in newer to later order:

22-Jun-2013 19:45:41 UTC	WordPress database error  [...]
22-Jun-2013 12:03:06 UTC	PHP Warning: Cannot modif [...]
22-Jun-2013 12:03:06 UTC	PHP Warning: Cannot modif [...]
22-Jun-2013 12:03:06 UTC	PHP Warning: Cannot modif [...]
22-Jun-2013 12:03:06 UTC	PHP Warning: date() expec [...]
18-Jun-2013 20:11:49 UTC	PHP Fatal error: Call to  [...]
18-Jun-2013 09:49:03 UTC	PHP Fatal error: Call to  [...]
18-Jun-2013 09:48:01 UTC	PHP Fatal error: Call to  [...]
17-Jun-2013 09:42:40 UTC	PHP Fatal error: Call to  [...]

There is no caching in plugin that could make it stuck.

Are you sure you are looking at same log file in filesystem that widget is looking at? By default it gets file to display from ini_get( 'error_log' ).

This is odd, since it’s whole point of it to display fresh ones.

Could you provide example of log that exhibits the behavior?

Had been running dev version for a while so released that as version 1.2. Seems to work robustly with everything that I have tried.

@m4olivei

Thanks for feedback! Please let me know if you experience any issues with dev version. I want to do couple more things and then will release update.

Ouch, that is not meant to replace anything and you almost never need to edit [properly coded] WordPress stuff, unless that is explicitly said. Among other things because version updates overwrite such changes.

Small tweaks tend to go into functions.php file of theme, but since we are switching between themes here appropriate location would be to create small plugin for it.

Or even more easily – use it as must use plugin – save in file with .php extension and put into wp-content/mu-plugins folder.

Hi, I’m wondering why my users cant change/see the feature? specially the ‘editors’

As you see in code default capability required is switch_themes, which by default only Admins and Super Admins can do.

You can use something like following code to filter capability and allow editors (and above so it will still include admins) access:

add_filter( 'tts_capability', 'tts_editor_capability' );

function tts_editor_capability() {

	return 'editor';
}

I pushed bunch of changes to the development repository https://bitbucket.org/Rarst/toolbar-theme-switcher/raw/tip/toolbar-theme-switcher.php

Reaaally dislike option filtering, but so far it seems to work properly with customizer. I will poke it some more before releasing new version, let me know if you test and have any issues with this one.

Ugh… I really didn’t want to filter options, but it seems there are leftover places that don’t use wrapper and no decision which way should it be adjusted, see https://core.trac.www.ads-software.com/ticket/20027

The issue is I can’t quickly fix this simply by switching to filtering options, since there are some naaaasty edge cases – like craziness with multiple theme directories registered which I recently hit and really not happy with temporary solution.

Since the ticket probably won’t produce results till WP 3.6, what I will probably work on throwing out some code that makes things complicated (theme list and fields retrieval) and switch to filtering options when I can toggle it to either more easily.

Also note that you don’t need to modify plugin’s code to achieve this! Just use class name explicitly instead of __CLASS__ and you can add it as any hook from your own code:

add_action( ‘wp_ajax_nopriv_tts_set_theme’, array( ‘Toolbar_Theme_Switcher’, ‘set_theme’ ) );

The initial use case for this plugin was for-developer and with solid security to be used on live sites.

While it is flexible enough to be used as public switcher (as you discovered), it’s been left in current “mild challenge” state so far.

I am considering implementing public mode natively, but not without interface to go with it – so that non-developers are comfortable using it and have clear feedback. Which in turn means more code (and localization) to be written.

So this is likely getting implemented as version 2 or something, when I have mood and chunk of time I feel like spending on such improvements.

Thank you for the review! This was exactly my assessment of the niche and I am aiming to provide precisely that – robust, up to date and flexible switcher.

Plugin version 1.1.3 released with this fix.