magdor

Is this the only way to provide the configuration? This head.js setting provides a considerable performance boost.

You might be suffering from this:

https://www.ads-software.com/support/topic/flare-not-compatible-with-jetpack-any-fix

This indeed turns out to be the problem. I found the same behaviour. Flare shows up on the posts, but not on the pages when Jetpack is activated.

The functionality of Jetpack can be had by installing separate plugins for each functionality that you are using from Jetpack but I don’t think that is the way to go.

I would imagine Jetpack to be one of the most used plugins coming from WordPress and installed by default.

Hopefully the developer of Flare will address this issue soon, as there not been an answer on this forum for a couple of weeks now.

Royho,

My bad. This strange behaviour was a result of a missing } in one of the previously defined functions. So all is well again. Thank you for your support and patience.

Minor progress. Now the field is removed from the checkout page but when going for placing the order, the error message shows up that this is a required field even though it is not visible anymore.

Did as advised but still the same result.

Sorry about that:

/* WooCommerce: Remove phone number on checkout page. */
add_filter( 'woocommerce_checkout_fields' , 'custom_override_checkout_fields' );

and

function custom_override_checkout_fields( $fields ) {
     unset($fields['billing']['billing_phone']);
     return $fields;
}

I followed the instructions per the given link and removed the billing_phone field from the checkout page. But when click the checkout button I am greeted with the following message:

Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, ‘custom_override_checkout_fields’ was given in /home/content/xxxxxxxxx/sitenamehere/wp-includes/plugin.php on line 170

Warning: Invalid argument supplied for foreach() in /home/content/xxxxxxxxx/sitenamehere/wp-content/plugins/woocommerce/classes/class-wc-checkout.php on line 157

This error does not show up with the phone field back in. What do the error messages mean? And how to fix it?

Here the test page with the buy button at the end of the page:

(Site in dutch, but you can safely ignore that)

Remove the /template/ from your structure. So it becomes:

wp-content -> themes -> whitelight-dalluva-child -> woocommerce -> myaccount -> form-login.php

Disclaimer: I am not a plugin developer.

This is what workes for me and how I understand it: The code above needs to be part of a function. This function needs to be placed in your themes function.php. This function needs to be tied to a wordpress hook.

In my case, the theme that I use has a theme set-up function. Within this set-up function you add the call to your new function, like so:

/* Remove digg digg buttons/floating bar from certain pages. */
   add_filter( 'body_class', 'your-theme-name_remove_dd_buttons' );

The hook I use here is body_class. I am not sure if that is the best one to use. Caution.

Next, outside the theme setup function, I’ve added the new function definition:

function your-theme-name_remove_dd_buttons() {
if(is_page( array( 'page-slug-1', 'page-slug-2', 'page-slug-3' ) ) ) {
    remove_filter('the_excerpt', 'dd_hook_wp_content');
    remove_filter('the_content', 'dd_hook_wp_content');
}
}

I have replaced the OR with an array.

This is an ugly solution for several reasons:
• For every page that needs to be excluded you have remember to update the functions.php file
• The same goes for an occasional slug name change
• Also, it scores very low on user friendliness
• And this was just for pages. A user might have a good reason to exclude the buttons from a post as well…

A more elegant solution might be to have a tick box on the post/page edit page, like e.g. the addthis plugin does. It is way more flexible and keeps us, who know just enough to shoot ourselves in the foot, from messing with a functions.php file.

Resolved

Ok, that last minor issue is resolved as well. It turned out to be a wrong setting by me in the YMLP form settings, in the YMLP dashboard. So all is working well now.

My advice thus is to NOT use YMLP api (contrary to the recommendation in the plugin) but to fill in the correct form action in the plugin List settings.

I solved some of the problems by NOT using the YMLP api. The results are now:

– Subcribers are added via the extra tick box when commenting
– The subscribers receive a confirmation mail with a link to click
– I do receive a notification mail that there is a new subscriber
– The autoresponder coupled with the list does get triggered.

The only minor issue now is that a subscriber is now redirected, after confirmation, to the page where he gets informed that he needs to confirm via the link in the mail. This message is out of sync. In stead the Thank You for registering page should be shown.

My host was less responsive, so I switched hosts and all is well now.

Installed java plugin and testpage shows up correctly.

I did a completely new fresh install (3.1.3) without any plugins activated and still no show. I am starting to suspect that a server change on the hosting side might be the reason.