geertvanderheide

Thank you LogoLogics for pointing towards WPML. That is indeed the biggest difference between the two sites and this cookie plugin isn’t officially compatible with WPML. On the other hand, I have been able to translate the cookie notice through WPML, and other users here are also using the plugin with WPML. Even still, it may be the cause of the acceptance state not being properly set somehow.

I have another WPML site that will need a cookie notice, so I’ll probably try another cookie plugin for that and see how it goes.

I did notice that the plugin also sets css body classes (“cookies_not_set”, “cookies_set”, “cookies_accepted”, “cookies_refused”, whichever apply). I can use that to hide the notice through the theme’s stylesheet, practically solving the problem… but it’s more of a workaround.

If anyone has any more suggestions regarding this problem, please let me know.

• This reply was modified 6 years, 5 months ago by geertvanderheide.

Found an answer to my own question. To anyone who needs the category page ID that a form was sent from, inside the wpcf7_mail_components filter, this could be useful. It requires that you’ve set a category base in the permalinks. In this example, the category base is “category”.

$url = wpcf7_special_mail_tag('', '_url');
$cat_base = '/category/';
  
if (strpos($url, $cat_base) !== false) :
  $cat_slug = substr($url, strpos($url, $cat_base) + strlen($cat_base));
  if ($cat_slug) :
    $cat = get_term_by('slug', $cat_slug, 'category');
    $cat_id = $cat->term_id;
  endif;
endif;

Ah, that explains it. In that case, I’ll just wait and see how it goes. Thank you for the information.

Thanks for the suggestion. I’ve set up the IP block and it’s working for now.

This doesn’t solve the problem though – only this specific bot is now blocked, but there’s no protection from other bots. The Easy Sign Up plugin supposedly works with Akismet so I expected spam to be blocked by that. Maybe this feature isn’t where it needs to be yet?

I just found one small bug: the text “Directions”, inside the Google Maps popup, is not being translated. It shows the “[:]” symbols in the output. I’ll work around this, but maybe it’s something to fix in a future release.

Using the latest WP and Store Locator btw.

Exactly what I needed! It’s working. Thank you for the speedy support!

That’s exactly what I was missing. Thank you very much for the support!

The complete code example for anyone who finds this:

function set_question_form_recipient($components, $form, $object) {
  if ($form->id() == 102) :
    // Get the ID of the post the form was sent from
    $post_id = wpcf7_special_mail_tag('', '_post_id');
  
    // Get the recipient e-mail address from an Advanced Custom Field
    $recipient_email = get_field( 'name_of_acf_field', $post_id );

    // If you use a regular (non-ACF) custom field, use:
    // $recipient_email = get_post_meta( $post_id, 'name_of_custom_field', true );

    if ($recipient_email) :
      // Set the recipient
      $components['recipient'] = $recipient_email;
    endif;
  endif;
  
  // Return the modified array (not sure if needed)
  return $components;
}
add_filter('wpcf7_mail_components', 'set_question_form_recipient', 10, 3);

In this example, the ID of the CF7 form (102 in the example), and the field names, need to be replaced with the ones you’re using.

Thank you for your reply. Using the filter you mentioned, and the method for getting the post ID you gave here, I was able to get it working.

One more question: Is there a way to get the form ID with this filter? I’d like to make sure this code runs only for one specific CF7 form. The function’s second and third parameter ($form and $object) are both NULL for me. Any ideas there?

Here’s a code example for others looking to change the recipient using a custom field:

function set_question_form_recipient($components, $form, $object) {
  // Get the post ID
  $post_id = wpcf7_special_mail_tag('', '_post_id');
  
  // Get the recipient e-mail address from an Advanced Custom Field
  $recipient_email = get_field( 'name_of_acf_field', $post_id );

  // If you use a regular (non-ACF) custom field, use:
  // $recipient_email = get_post_meta( $post_id, 'name_of_custom_field', true );

  if ($recipient_email) :
    // Set the recipient
    $components['recipient'] = $recipient_email;
  endif;
  
  // Return the modified array
  return $components;
}
add_filter('wpcf7_mail_components', 'set_question_form_recipient');

• This reply was modified 8 years, 1 month ago by geertvanderheide.

Hi Greenweb. Thank you so much for addressing my request! I’ve installed the update and it works like a charm. My client will be very happy with this. Glad I’ve been able to support you by purchasing the Data Extra extention – it’s well worth it and I’ll definitely consider using your plugins again in the future.

Thank you for your reply.

Adding editor level access could be done by creating a new capability specific to the ESU plugin. By default, this capability could be assigned only to administrators, but theme builders like me could then assign it to another role, like the editor role, through functions.php or otherwise. It might be useful to have several capabilities, like “view ESU data” and “change ESU settings”.

There’s other solutions as well, like having a dropdown box in the admin for specifying the required role, but using a capability seems to make the most sense to me. Either way, good luck and I hope you find the time to include this soon.

Thank you for clearing that up! If my client ends up agreeing to the planned expansion of her site, this is the plugin I’ll use.

Thank you for your reply. I was already on version 1.5.2 when I posted this, so I’m doubtful the problem is actually solved to be honest. But: The problem only occurs when WP_DEBUG is set to true, since they’re only warnings and notices. They’re not fatal errors, and this could just be some rare conflict with my own code or other plugins. So I’ve taken care to disable debug mode on projects that my clients have access to. This avoids them seeing errors.

I would recommend you use debug mode some time to see if there are any warnings or notices on your end. It might improve the plugin. Other than that, this issue can be considered resolved.

Small update: The error is occurring whenever I make a new post or update an existing post from the WordPress admin. It happens regardless of whether I add images.

Ah of course, I did not think of that. Thank you very much for pointing me to a solution and including an example. Adding one or more shortcodes should work well for me here. Solved!

Thanks for putting me on the right track! After reading the article you linked to, I checked the code to find where WooCommerce was creating the widgets. I found a bunch of calls to “register_widget” all nicely listed together. That gave me the class names I needed, and so this is the code required to remove them:

function remove_woo_widgets() {
  unregister_widget( 'WC_Widget_Recent_Products' );
  unregister_widget( 'WC_Widget_Featured_Products' );
  unregister_widget( 'WC_Widget_Product_Categories' );
  unregister_widget( 'WC_Widget_Product_Tag_Cloud' );
  unregister_widget( 'WC_Widget_Cart' );
  unregister_widget( 'WC_Widget_Layered_Nav' );
  unregister_widget( 'WC_Widget_Layered_Nav_Filters' );
  unregister_widget( 'WC_Widget_Price_Filter' );
  unregister_widget( 'WC_Widget_Product_Search' );
  unregister_widget( 'WC_Widget_Top_Rated_Products' );
  unregister_widget( 'WC_Widget_Recent_Reviews' );
  unregister_widget( 'WC_Widget_Recently_Viewed' );
  unregister_widget( 'WC_Widget_Best_Sellers' );
  unregister_widget( 'WC_Widget_Onsale' );
  unregister_widget( 'WC_Widget_Random_Products' );
}
add_action( 'widgets_init', 'remove_woo_widgets' );

Yay! The widget screen is nice and clean once more. I always try to limit administrative complexity for my clients, and this definitely helps.

To anyone else looking for this: Put the above code in your functions.php, or inside a plugin.