angoo

I’m using the php mail method.
It turned out that my webhosting provider silently blocked emails before sending them because of the body, even if empty.
SMTP method works ok.

I think the error resides in inc/phpmailer/class.phpmailer.php.
CreateBody function creates a somewhat malformed body which is silently rejected by mail() function or after.

Only a new plugin update can solve this. I even attempted a plugin downgrade which resulted in a real database nightmare.

I’m investigating the code and I think there’s a problem with email body, even the default one or an empty one. Changing theme doesn’t work as well.

If i replace line 455 in controllers/ajax/campaigns.php:
if($mailer->sendSimple($receiver, stripslashes($email_object->subject),$email_object->body,$params)) {

with

if($mailer->sendSimple($receiver, stripslashes($email_object->subject),"--",$params)) {

test emails are sent correctly without the body

This is the updated code for the child theme:

in functions.php

add_action( 'wp_enqueue_scripts', function() {
		wp_enqueue_script( 'js', get_stylesheet_directory_uri() . '/functions.js', array('jquery'), null, true );
}, 100 );

in functions.js

(function($){
	$( document ).ready( function() {
		$( window )
			.off( )
		$( '#sidebar' ).first()
			.css("position", "relative")
			.off( );
	});
})( jQuery )

I’m working on a child theme and I hadn’t success with the css approach.
I had it by turning off twentyfifteen’s sidebar event listeners with this code:

(function($){
	$( document ).ready( function() {
		$sidebar = $( '#sidebar' ).first();
		$window
			.off( 'scroll.twentyfifteen')
			.off( 'resize.twentyfifteen');
		$sidebar.off( 'click keydown', 'button' );
	});
})( jQuery )

The problem with sidebar background in twentyfifteen resides in body:before that has the width of the sidebar and a white background.
This should do it:

body:before {
   background-color: transparent;
}

Same problem for me (and same settings, Polylang 1.2 beta)

I followed Chouby’s hints and some readings (https://shibashake.com/wordpress-theme/custom-post-type-permalinks-part-2) and ended up with this code that seems to work fine. Anyway it’s not perfect, the same page can be reached both from en/books and en/libri.
Wish this was handled by polylang itself ??

...
		'has_archive'         => true,
		'publicly_queryable'  => true,
		'rewrite'			  => array(),
		'query_var'			  => true
	);
	register_post_type( 'libri', $args );
}

add_action( 'init', 'my_custom_post_types', 0 );

// translation of CPT slugs
add_action( 'init', function(){
	global $wp_rewrite;
	$wp_rewrite->add_permastruct('libri', '/%customslug%/%postname%', false);
	add_rewrite_rule('en/books(/[^/]+)?(/[0-9]+)?/?$',
		'index.php?post_type=libri&name=$matches[1]&page=$matches[2]','top');
	add_rewrite_rule('libri(/[^/]+)?(/[0-9]+)?/?$',
		'index.php?post_type=libri&name=$matches[1]&page=$matches[2]','top');
}, 0);

add_filter('post_type_link', function ($permalink, $post) {
	global $polylang;
	$t = $post->post_type;
	if(empty($lang))
		switch ($polylang->model->get_post_language($post->ID)->slug . $t) :
			case "enlibri": $t = 'books'; break;
			endswitch;
	return str_replace(	array('%customslug%', '%postname%'),
				array($t, $post->post_name), $permalink );
}, 10, 2);

add_filter('post_type_archive_link', function ($permalink) {
	return = str_replace('/libri/', '/' . __('libri') . '/', $permalink );
});

I think this is a limit of the plugin so you just can’t.
It isn’t even well translated: some things keep showing up in English even with a it_IT language file.

i.e “Add Film” instead of “Aggiungi Film”.

In the code I found this line:

$cpt_labels['add_new'] = ( $cpt_post_type[2]["add_new"] ) ? $cpt_post_type[2]["add_new"] : 'Add' .$cpt_singular;

instead of

$cpt_labels['add_new'] = ( $cpt_post_type[2]["add_new"] ) ? $cpt_post_type[2]["add_new"] : __('Add') . " " .$cpt_singular;

that would take advantage of wordpress default translation.

So you should ask the developer to update the plugin or modify it by yourself.