alanft

Anyone having issues with WL and WP3 and has the time to help troubleshoot – let me know.

http://wordpress.org/extend/plugins/widget-logic/faq/

Try switching to the WP default theme – does that change things?

By basic logic, I mean some simple things like !is_home() or !is_category()

I think the problem is that $post->post_parent can only be an integer – that is the ID of the page. You can find the numeric ID of a page in the ‘edit page’ screen, hover over the ‘edit’ link on a particular page and look at the URL of that link – it will have post=xxxx in it, that’s the ID

I’m afraid I’ve not put in enough time to check how thoroughly compatible it is. I tried the last RC before the official release (just out) and it LOOKED good – no complaints, it did what it was meant to in the quickest of tests. But it was not what I’d call thorough.

If more user ratings pile up YES, I’ll mark it as officially compatible in a couple of weeks — why not, that’s beta testing for you!

I have a small backlog of requested tweaks (strict mode, permission changes) that I’ve been meaning to implement and just not had the time either 🙁 and ideally I’d do that with a minor update release and official 3.0 compatibility.

Now to see about upgrading our live site to 3.0…

I had a quick look in the code and there’s a file

buddypress/bp-core/bp-core-templatetags.php

full of what looks like usable conditional tags starting around line 1362 with the comment:

/* Template is_() functions to determine the current page */

here they are:
bp_is_blog_page()
bp_is_my_profile()
bp_is_home()
bp_is_front_page()
bp_is_activity_front_page()
bp_is_directory()
bp_is_page($page)
bp_is_active( $component )
bp_is_profile_component()
bp_is_activity_component()
bp_is_blogs_component()
bp_is_messages_component()
bp_is_friends_component()
bp_is_groups_component()
bp_is_settings_component()
bp_is_member()
bp_is_user_activity()
bp_is_user_friends_activity()
bp_is_activity_permalink()
bp_is_user_profile()
bp_is_profile_edit()
bp_is_change_avatar()
bp_is_user_groups()
bp_is_group()
bp_is_group_home()
bp_is_group_create()
bp_is_group_admin_page()
bp_is_group_forum()
bp_is_group_activity()
bp_is_group_forum_topic()
bp_is_group_forum_topic_edit()
bp_is_group_members()
bp_is_group_invites()
bp_is_group_membership_request()
bp_is_group_leave()
bp_is_group_single()
bp_is_user_blogs()
bp_is_user_recent_posts()
bp_is_user_recent_commments()
bp_is_create_blog()
bp_is_user_friends()
bp_is_friend_requests()
bp_is_user_messages()
bp_is_messages_inbox()
bp_is_messages_sentbox()
bp_is_notices()
bp_is_messages_compose_screen()
bp_is_single_item()
bp_is_activation_page()
bp_is_register_page()

try them out. check out the buddypress code for more detail

if i read you right, you could use my plugin

http://wordpress.org/extend/plugins/widget-logic/other_notes/

with the code using a variation on current_user_can(‘read’) for every logged in user

To get to Widget editing you need the switch_themes capability which is, by default, only available to the administrator role. At least this is my understanding looking at the code in v2.9 and v3beta. (The wp-admin/includes/schema.php indicates this, as does http://codex.wordpress.org/Roles_and_Capabilities )

However even though that is the case, you have a totally valid point – I can see the case that many (if not most) admins (me included) would want site editors to have access to widget content but NOT widget logic. (I think this means you will have explicitly added the switch_themes capability to the editorial role on your site.)

So like I said, you’ve definitely sold me on restricting access to editing the WL code some more. I’ll add an (admin only!) accessible option that will allow you to spec the capability needed, either ‘switch_themes’ (the current default) ‘edit_themes’ (which seems like the functionally closest existing capability, and is also admin only by default) or a new capability ‘edit_themes_WL’ (or something like that – i’m not clear on adding capabilities, but will look into it).

However I am re-assured that, despite what you say, normally, Widget Logic does NOT allow non-admin users to write/exec PHP code.

It could still be that the code is lax enough that changing the WL PHP code could be hacked/faked – I’m not 100% sure of that. The data can be changed if ‘sidebar_admin_setup’ action is executed, but in every case in the WP code that action is only reached after a test for the switch_themes capability.