Ken Young

Hi Julian, that worked great. Thanks for the quick response!

Hi Nelson, there aren’t any known conflicts that we’re aware of. Can you try disabling all plugins except Automator and running a simple recipe – User views a page > Send an email to see if that works? If not, please give us the details on your environment (WordPress version, host, PHP version, etc.) so we can investigate further.

Thanks, Denis; unfortunately, deactivating and reactivating the plugin didn’t work. I haven’t changed the site URL since installing the plugin. Is there somewhere in the database/options table that I could look to see if an incorrect domain name is stored? Or perhaps a line number in a file I could try modifying? This is actually our staging environment, so the URL is xxxxx.staging.wpengine.com. We’d like to be able to test on staging before deploying to the live site.

Unfortunately, disabling WPML doesn’t fix the issue.

I’ve also got another site that doesn’t have WPML installed where I’m trying to change text in a BuddyPress login widget. The the domain is “buddypress”. But it’s not working there either. Does it work for widgets? Same theme as the other site (The7), so maybe it’s the theme that’s the problem.

Thanks for the quick reply, Lee. I’ll try disabling the plugin and see if that helps.

I would also find this feature useful.

Just found this in the code (lines 162-167 in class-groups-post-access.php):

// The following is not correct in that it requires the user to have ALL capabilities:
// $where .= sprintf(
// ” AND {$wpdb->posts}.ID NOT IN (SELECT DISTINCT ID FROM $wpdb->posts LEFT JOIN $wpdb->postmeta on {$wpdb->posts}.ID = {$wpdb->postmeta}.post_id WHERE {$wpdb->postmeta}.meta_key = ‘%s’ AND {$wpdb->postmeta}.meta_value NOT IN (%s) ) “,
// self::POSTMETA_PREFIX . self::READ_POST_CAPABILITY,
// $caps
// );

Will uncommenting this and commenting out the following query work? I’m going to try it now!

bump?

I think I fixed it. There was an error in the logic. Lines 831-834 in gravity-forms-addons.php currently reads:

if(
  !empty($options['useredit']) && is_user_logged_in() && $current_user->ID === $lead['created_by'] || // Is user who created the entry
  !empty($options['adminedit']) && self::has_access("gravityforms_directory") // Or is an administrator
) {

should read:

if(
  (!empty($options['useredit']) && is_user_logged_in() && $current_user->ID == $lead['created_by']) || // Is user who created the entry
  (!empty($options['adminedit']) && self::has_access("gravityforms_directory")) // Or is an administrator
  ) {

The conditions needed to be grouped by brackets, and there was an extra “equals” sign in $current_user->ID === $lead[‘created_by’].

Sorry, false alarm. When I add the gravityforms_directory permission to the subscriber role, ANY user could edit ANY entry. So I disabled it, and now no users can edit entries. Hope a fix is in the works!

Vivojack’s solution worked for me. I used the User Role Editor plugin to help me add the permission to the subscriber role.

Hi Faison, no, no other menu plugins. Here’s what I have active:

AddThis Social Sign In
Gravity Forms
Nice Login Widget
Revolution Slider
Sabai
Say What?
Symple Shortcodes
Theme My Login

Unfortunately, no; I took the easy way out and just tweaked the content of the 404 page and added a login form (using a login widget). If a user logs in using the login widget they end up on the page they were looking for, so that worked okay for my purposes.

Sorry, just noticed you had some documentation on this on the main plugin page. I’ll try that out, thanks.