frafor

Allora a me non compaiono… già visto in Impostazioni Schermata e non ci sono spunte da mettere a riguardo.

Ordine da creare: https://ibb.co/HrWQn3H
Ordine creato: https://ibb.co/QpGQnp1

• This reply was modified 6 years, 4 months ago by frafor.

Perdonami daniele ma io non ci riesco. Quando carico i dati dell’utente, non compaiono proprio i dati di CF e PIVA, salvo l’ordine e al refresh comunque mancano. Se invece faccio l’ordine da frontend sono presenti senza problemi.

Screen dell’ordine da backend:

1. Cerco l’utente: https://ibb.co/dmJH94Z
2. Selezionato, carica i dati: https://ibb.co/xfv9JTx
3. Dopo aver aggiunto un prodotto, creo l’ordine: https://ibb.co/y5FBVKY

Come vedi mancano i dati di PIVA e CF (che sono invece presenti nel profilo di Luca Mario).

Se luca mario effettua l’ordine da frontend, invece, eccoli qui: https://ibb.co/g6Z6YkG

In functions.php of your theme, add:

/**
 * Woocommerce / Shield compatibility on login - reset password
 * 
 */
 
function woo_lostpassword_shield() {
	do_action('lostpassword_form');
}
add_action('woocommerce_lostpassword_form', 'woo_lostpassword_shield', 9);

function woo_login_shield() {
	do_action('login_form');
}
add_action('woocommerce_login_form', 'woo_login_shield', 9);

Fixed.

angelleye-paypal-for-divi-companies_operations.php

row 29 and row 44, where $account_id is defined, change both to:

$account_id = isset($_POST[‘paypal_for_divi_account_id’]) ? esc_html($_POST[‘paypal_for_divi_account_id’]) : ”;

Those rows were deliberately uppercasing and removing special characters from the paypal address.

Moreover, I noticed that I cannot save any Paypal Account Name (it remains blank). Not a big deal for now.

Hi, I am having exactly the same issue. Any account I add, all the special chars are stripped out, and it’s being saved all uppercase. No dots, no @, no hyphens. Obviously it doesn’t work.

Hi asrto! It’s been a while since I don’t have this issue. I cannot say if the solution was plugin or server side, as the hosting (Namecheap in my case) have rolled out at least one server update/maintenance schedule.

• This reply was modified 6 years, 9 months ago by frafor.

FIY, just tried another package with Shield disabled, and got the same result.

There always Shield working on the main domain, but it shouldn’t affect other directories, as far as i know. I’m trying again disabling it from there too.

Another thing worth to mention: the same hostings that results in 500 errors, display a Host Build Interrupt message during package creation. Anyway, the package continues building in the background and after few seconds it’s ready.

The host in question is Namecheap. I have the problem on other local hostings, but they aren’t worth to mention as they’re very small.

EDIT: same results after disabling shield on the whole domain

• This reply was modified 7 years, 3 months ago by frafor.

Yes, I’ve been on chat support with the hosting for 3 hours at least, they didn’t find anything strange from their side, just make sure suhosin was disabled and made several test with output buffering on or off.

The extraction process seems to end fine according to the duplicator log, and the fact that I can actually follow step 2 by checking the ‘manual package extraction’ after the error.

Within the package, there’s the Shield plugin for security purpose. Anyway I can install it without issues on other shared servers.

Latest Update. The previous one could led to confusion, as the same term can be associate with more than one taxonomy. Now you have to specify the taxonomy as argument:

function get_user_protected_terms($taxonomy = '') {
	$protected_terms = array();
	
	if ( $taxonomy ) {
		um_fetch_user( get_current_user_id() );
 		$user_role = um_user('role');
 		
		$terms = get_terms(array(
    				'taxonomy' => $taxonomy
				));
		foreach ( $terms  as $term ) {
			$term_id = $term->term_id;
			$term_meta = get_option( "category_$term_id" );
			if($term_meta && !in_array($user_role, $term_meta[_um_roles])) {
				array_push($protected_terms, $term->slug);
			}
		}
	}
	return $protected_terms;
}

Updated version. Now get_protected_terms() checks for user role, and returns the terms the user shouldn’t see. pre_get_posts function instead runs when ‘product’ post type is set.

function get_protected_terms() {
	$protected_terms = array();
	
	$tax_args = array(
  		'public'   => true,
  		'_builtin' => false
	);
	$tax_output = 'names';
	$taxonomies = get_taxonomies($tax_args,$tax_output);
	
	if ( $taxonomies ) {
		um_fetch_user( get_current_user_id() );
 		$user_role = um_user('role');
 		
		$terms = get_terms(array(
    				'taxonomy' => $taxonomies
				));
		foreach ( $terms  as $term ) {
			$term_id = $term->term_id;
			$term_meta = get_option( "category_$term_id" );
			if($term_meta && !in_array($user_role, $term_meta[_um_roles])) {
				array_push($protected_terms, $term->slug);
			}
		}
	}
	return $protected_terms;
}

pre_get_posts action

add_action( 'pre_get_posts', 'custom_pre_get_posts_query' );
function custom_pre_get_posts_query( $q ) {

	if ( ! is_admin() && $q->query[post_type] == 'product' ) {

		$q->set( 'tax_query', array(array(
			'taxonomy' => 'product_cat',
			'field' => 'slug',
			'terms' => get_protected_terms(),
			'operator' => 'NOT IN'
		)));
	}
}

• This reply was modified 7 years, 8 months ago by frafor.
• This reply was modified 7 years, 8 months ago by frafor.

I come up with this solution:

function get_protected_terms() {
	$protected_terms = array();
	
	$tax_args = array(
  		'public'   => true,
  		'_builtin' => false
	);
	$tax_output = 'names';
	$taxonomies = get_taxonomies($tax_args,$tax_output);
	
	if ( $taxonomies ) {
		$terms = get_terms(array(
    				'taxonomy' => $taxonomies
				));
		foreach ( $terms  as $term ) {
			$term_id = $term->term_id;
			$term_meta = get_option( "category_$term_id" );
			if($term_meta) {
				array_push($protected_terms, $term->slug);
			}
		}
	}
	return $protected_terms;
}

The function returns an array of protected terms that can be passed later to pre_get_posts:

add_action( 'pre_get_posts', 'custom_pre_get_posts_query' );
function custom_pre_get_posts_query( $q ) {

	if ( ! $q->is_main_query() ) return;
	if ( ! $q->is_post_type_archive() ) return;
	
	if ( ! is_admin() && !is_user_logged_in() ) {

		$q->set( 'tax_query', array(array(
			'taxonomy' => 'product_cat',
			'field' => 'slug',
			'terms' => get_protected_terms(), // Don't display products in protected categories
			'operator' => 'NOT IN'
		)));
	
	}
}

I would like to improve get_protected_terms() as it should check for user’s role against the current post. Maybe tomorrow will do ??

Hi Ashok, ver 1.1.6 still has issues.

woo-min-max-quantity.php line 101 & 102 for function wc_mmax_custom_add_to_cart

even rows 86 & 87 have same problem

• This reply was modified 7 years, 8 months ago by frafor.

Thanks for the additional info Malcolm and sorry if it was OT.

I’m working with a theater and most of their show title goes beyond 80 chars, so they’ve been shortening them and it wasn’t nice on the front-end.

It was just annoying for me to change the field lenght via the Database at every update, but with the constant setting it should be fine now ??

Hi Malcom,

I’d like to suggest another possible improvement for future releases.

In my opinion, showName field in _sshow_shows table should be longer, as titles can easily go beyond 80 chars.

For example I had to manually set it as VARCHAR 256, because I’ve set up a custom post type that automatically adds a show in _sshow_shows when creating a new post in a specific taxonomy.

The template then calls the shortcode using do_shortcode(), and takes the post title as reference.

Shows’ title can often be longer than 80 chars, so having them trimmed down didn’t always display the boxoffice.

FF

Hi Malcolm, thanks for the fixes. It seems to work fine for now, today I’ll make a real payment to check if even the Paypal checkout is fine.

I’ve just sent you an e-mail for the translation files ??