Palpatine1976

BUMP this bug is still present. Just set up a new site – no content, bug still exists.

It seems this bug is still present in the latest version (2.3) and the Development version. Even choosing “none” for both Above and Below Posts, the button still shows up in the RSS feeds.

I’m using WP 3.2.1, AddThis 2.3.0.

Any ideas?

Thanks!

@don – I think i ended up just modifying the built-in Editor role using Cap. Manager, and choosing that in the UAM settings (to avoid having to update plugin code every time there was an upgrade).

However I think that if you added your own custom Roles to the <select> option on line #486 of /tpl/adminSettings.php in the User-Access-Manager plugin, it should work. Remember that not only are the capabilities important, but the “level” of the Role is sometimes used to determine abilities. I’m still confused by this, but I suppose it depends how the plugin uses the Role info.

Looks like this is a bug in version 3.6 (probably part of the “WP3.0+” requirement change).

I downgraded to v3.5.1 of WP Title 2 (didn’t change my WP version – still running the latest 3.2.1) and now the bug is gone. I’m guessing there is a problem in the plugin integrating with wp_nav_menu() since that is the add_filter call that is causing the menu problem I described.

That’s great Chad! It really is a very useful & well written plugin.

I’ve had to make quite a lot of customizations to fit my need – I’d be happy to email you a few ideas on stuff I noticed as I was poking around (little things like the <label> tags in wpmem_login_form_NEW() have the wrong “for” attribute etc). Nothing crazy – your code is doing all the heavy lifting!

Keep up the good work. I just donated $50 toward the cause ??
[Twig Interactive]

Also I believe <legend> and <fieldset> should be inside the <form> tag, not outside (occurs in multiple wp-members-*.php files)

Plugin works ok, but seems to have some sloppy typos.. the mentioned by @moriakaice and for some reason the widget is registered as “easy-ategories-anagement” instead of “easy-categories-management” (lines 95/97)

Actually this plugin doesn’t play well with zigWidget class, so I switched to this category management plugin: https://www.ads-software.com/extend/plugins/extended-categories-widget/

@hallmarc – thanks for the tip! I’m using ZigWidgetClass now and no issues seen yet.

wow LAME – v6.3 released and this simple bugfix was NOT included.

@dglingren Great! Hopefully this fix will get rolled in to the next release. I am having the same “Sorry redirect not created” issue on a Windows-based box, but strangely not seeing the error on a *nix-host (same versions of WP and plugin). That is strange since the PHP/MYSQL stuff should cause same success/fail.

This is definitely a bug in the plugin – but I noticed from https://www.ads-software.com/support/topic/plugin-audit-trail-caution?replies=6 that a fix seems to be just terminating the “ignore users” string with a comma.

I entered “1,13,” and saved the options – seems to now exclude activity from users 1 and 13.

I ended up needing to refine this to work with multiple other Widget plugins (Widget Logic and Widget Cache specifically)

Code below I inserted at line#55 of the widget-classes.php plugin file.

[Code moderated as per the Forum Rules. Please use the pastebin]

@aizatto – I dug a little more into this, and I found a workaround but it’s not scalable ??

The issue is that other Widget plugins (like https://www.ads-software.com/extend/plugins/wp-widget-cache/ ) register their own callbacks, so that $widget[‘callback’][0] (the line that executes get_settings) is no longer a _Widget object – hence the fatal error.

By dumping out the whole $widget (after another Widget plugin is installed) I saw that what had been $widget[‘callback’] became [‘callback_wc_redirect’] – and so changing that in your plugin code allowed it to play happily with Widget Cache.

My concern is that other Widget plugins would alter the array key differently, and so a better parsing test is needed. Perhaps your plugin can scan the $widget object, look for the correct array key by property, then apply the get_settings() to it.

Hope this helps some people!

@aizatto – this is a really great plugin when it works and is very useful since there isn’t another easy way to add CSS to a specific plugin instance.

However the problem is the conflict with other Widget plugins or themes that use the sidebar hook. Widget Cache for example will conflict, as well as many others listed on the forums. It seems to be the get_settings() line (#64) is causing the problem – would be great to see a fix!

I agree w/ Erik – the Widget Classes plugin was fine for older versions of WP, or those that didn’t have other widget plugins installed. However if you are using anything new (like Widget Cache) then the Widget Classes plugin breaks.

I think it is because the Widget Classes plugin dev didn’t namespace his/her functions, so calling new Widget.whatever() causes conflicts. Shame because it did exactly the simple task I needed… adding a custom CSS class to a specific widget instance.