IstanbulMMV

Wonderful!! $form->get_campaign()->ID fixed the problem.
Many thanks Eric.

Hi Eric, I’ve added this code via my own little plugin.

Trying to eliminate any possible conflicts, I’ve now removed every piece of code from my custom plugin, including where I add my custom ‘receivers_email’ field.

What I’m now trying to do is simply exclude the core ‘first_name’ and ‘last_name’ fields on some, but not all, donation forms.

My plugin now contains just one function as shown below:

function wg_customize_donation_form( $fields, Charitable_Donation_Form $form ) {

        unset( $fields['address'] );
        unset( $fields['address_2'] );
        unset( $fields['city'] );
        unset( $fields['state'] );
        unset( $fields['postcode'] );
        unset( $fields['country'] );
        unset( $fields['phone'] );

        if ( ! has_term( 'groups', 'campaign_category', get_the_ID() ) ) {

                unset( $fields['first_name'] );
                unset( $fields['last_name'] );

        }

        return $fields;

}
add_filter( 'charitable_donation_form_user_fields', 'wg_customize_donation_form', 10, 2 );

Using the above code, all forms submit with no validation errors, but first_name and last_name are never saved to the database.

When I add the ! is_admin() condition as shown …

function wg_customize_donation_form( $fields, Charitable_Donation_Form $form ) {

        unset( $fields['address'] );
        unset( $fields['address_2'] );
        unset( $fields['city'] );
        unset( $fields['state'] );
        unset( $fields['postcode'] );
        unset( $fields['country'] );
        unset( $fields['phone'] );

        if ( ! is_admin() && ! has_term( 'groups', 'campaign_category', get_the_ID() ) ) {

                unset( $fields['first_name'] );
                unset( $fields['last_name'] );

        }

        return $fields;

}
add_filter( 'charitable_donation_form_user_fields', 'wg_customize_donation_form', 10, 2 );

… first_name and last_name are successfully saved to donor array when the first_name and last_name fields are present on the form.

I get a validation error however when trying to submit a form that has had the first_name and last_name fields removed.

Hope this helps in some way and thank you again for this amazing plugin.

• This reply was modified 5 years, 2 months ago by IstanbulMMV.

Hi Eric, sorry to bother you again. The above code works perfectly on the front end, but unfortunately doesn’t save my custom value to the database.

If I amend my code with the addition of a “! is_admin” condition, my custom value is successfully saved to the database, but I’m back to receiving a validation error on all other forms where the ‘receivers_email’ field has been excluded / is not required.

My code that saves to the database, but causes a validation error on forms that do not feature the ‘receivers_email’ field:

function wg_customize_donation_form( $fields, Charitable_Donation_Form $form ) {

        if ( ! is_admin() && ! has_term( 'groups', 'campaign_category', get_the_ID() ) ) {

		unset( $fields['receivers_email'] );

	}

        return $fields;

}
add_filter( 'charitable_donation_form_user_fields', 'wg_customize_donation_form', 10, 2 );

My code that produces no validation errors, but doesn’t save my custom value to the donation post_meta donor array:

function wg_customize_donation_form( $fields, Charitable_Donation_Form $form ) {

        if ( ! has_term( 'groups', 'campaign_category', get_the_ID() ) ) {

		unset( $fields['receivers_email'] );

	}

        return $fields;

}
add_filter( 'charitable_donation_form_user_fields', 'wg_customize_donation_form', 10, 2 );

The code I am using to generate my custom field is:

function wg_add_recipient_email_field_for_groups_only() {

                $field = new Charitable_Donation_Field( 'receivers_email', array(
                        'label'         => __( 'Receiver\'s email', 'wg' ),
                        'data_type'     => 'user',
                        'donation_form' => array(
                                'type'          => 'email',
                                'show_before'   => 'email',
                                'required'      => true,
                        ),
                        'admin_form' => array(
                                'type'          => 'email',
                                'show_after'    => 'email',
                                'required'      => false,
                        ),
                        'show_in_meta'  => true,
                        'show_in_export' => true,
                        'email_tag'     => array(
                                'description' => __( 'The receiver\'s email address' , 'wg' ),
                        ),
                ) );

                charitable()->donation_fields()->register_field( $field );

}
add_action( 'init', 'wg_add_recipient_email_field_for_groups_only' );

Any thoughts very much appreciated and apologies if I’m just doing something really silly/careless here!

• This reply was modified 5 years, 2 months ago by IstanbulMMV.

Please ignore the above question. The code, as shown above, does indeed work exactly as intended! Apologies.

Problem solved! Just add a priority number to the comment_post action…

add_action( ‘comment_post’, ‘save_comment_meta_data’ ); becomes…
add_action( ‘comment_post’, ‘save_comment_meta_data’, 5 );

• This reply was modified 6 years, 3 months ago by IstanbulMMV.

A wee note of warning regarding my original question of plugin-less domain mapping. Plugin-less domain mapping worked great until I had to conduct a network upgrade of all my sites (the standard wp process that updates all sites after a database change).

One of the sites on my network had an expired domain and this resulted in the network upgrade process stopping once it reached the site with the expired domain. To finish upgrading my network I had to revert back to a plugin-based domain mapping solution.

A very big thank you to all for their input on this question.

If you follow the Github link that Jeremy posted above a temporary fix is offered by Brandon Kraft (kraftbj). By uncommenting the piece of code referenced by kraftbj in “views > admin > network settings” all new sites created on my network are now automatically connected to wordpress.com via a single wp.com account.

Fingers crossed for a permanent solution sometime in the near future.

Many thanks again.

@nachoman42 & @wasanajones thank you both for your help/suggestions. Changing the sub-site override setting doesn’t solve my issue unfortunately. I actually already have this option set as I would like all sites to be associated with a single wordpress.com account so users don’t have to create their own wp.com profile. I’ll drop a note to the JetPack team and see how I get on. Thanks again.

Many thanks for the suggestion – I wasn’t aware of that particular feature of Protect. JetPack is network enabled on my install and active on my primary site. Unfortunately without connecting each individual site to wordpress.com I can’t unlock ShareDaddy, Stats and theming tools (Featured Content, Site Logo, Responsive Videos). Auto-enabling these features would smooth the deployment of my sites considerably. Thanks again for the heads up.

Many thanks David – just what I was looking for.

To ensure icons are also viewable in mobile/responsive view, add:

@media screen and (max-width: 782px) {
          #wpadminbar li#wp-admin-bar-charts {
                    display: block;
          }
}

Try adding the following to ‘content-product_cat.php’

echo $category->description;

If you want to pop something in your functions.php file, try this:

function remove_PlulzDashNews_dashboard_metabox() {
    remove_meta_box('PlulzDashNews', 'dashboard', 'core');
}
add_action('admin_init', 'remove_PlulzDashNews_dashboard_metabox');

Hi there, Mike Jolley’s code at https://gist.github.com/1600117 may help solve your problem.

Fantastic – thanks Joseph. The site we’re building is an internal tool, thus no need for an email address, just a phone (extension) number. We’re currently using Gravity Forms, but want to deply something a little more lightweight in this instance. The use case described above is the last thing we need to resolve. Thanks again.

Many thanks for the speedy response Donncha. Off now to do some Googling on cron jobs and local caching… Cheers