mklusak

Yes, the single post problem is solved in GitHub version!

But the “term archive” has still this error. Well, maybe it’s a “feature” now, because my scenario is somewhat unusual (not so much), but I think it’s easy to fix it.

As I said, on single post (with some taxonomy term) the breadcrumbs are now “Home page > CPT archive > Term archive > Post title”. Clicking Term archive link takes me to page, where the breadcrumbs are “Home page > CPT archive > Term title” … but the CPT archive is still same, even for the second post type registered with the taxonomy. My scenario is that I am moreover adding “post_type” parameter to URL to show only posts with the term only from one custom post type. For example example.com/some-taxonomy/some-term/?post_type=cpt1 (or more exactly example.com/cpt1-slug/some-taxonomy/some-term/ with simple rewrite rule, the result is identical).

As I wrote earlier, function type_archive (in its “taxonomy” branch) does not check what/if post type is set, it only takes the first one of those registered with taxonomy, and use it. My common sense tells me it should be easy to check query var “post_type” first (and maybe check if it is really registered with taxonomy?), and if not set, then take the first one from registered with the taxonomy.

Both CPTS are registered like this, no special settings:


$args = array(
'labels' => $labels,
'supports' => array('title', 'editor', 'revisions'),
'hierarchical' => true,
'public' => true,
'show_ui' => true,
'show_in_menu' => true,
'menu_position' => 2,
'show_in_nav_menus' => false,
'show_in_admin_bar' => true,
'can_export' => true,
'has_archive' => true,
'exclude_from_search' => true,
'publicly_queryable' => true,
'capability_type' => 'page',
);
register_post_type('cpt1', $args);


And taxonomy:


$args = array(
'labels' => $labels,
'hierarchical' => true,
'public' => true,
'show_ui' => true,
'show_admin_column' => true,
'show_in_nav_menus' => false,
'show_tagcloud' => false,
'rewrite' => array('hierarchical' => true ),
);
register_taxonomy( 'tax1', array( 'cpt1', 'cpt2' ), $args )


Well, the problem occurs when I am displaying single post with some term added, and BCN is trying to add this taxonomy term to breadcrumbs hierarchy. Term archive link is OK, but “parental” CPT archive link is then wrong. The $type variable passed to bcn_breadcrumb_trail::type_archive() function is a term object, and $type->post_type is null. So the second IF branch is followed, and first CPT registered with this term’s taxonomy is used, no matter what CPT single post is really displayed.

I was thinking if some other part of my plugin is causing it. So I set up clean WP install, created two CPTs and one shared taxonomy. Result is the same – post of second CPT has archive part of breadcrumbs same as post of first CPT (if both post has any term selected from custom taxonomy).

The problem I see is in class.bcn_breadcrumb_trail.php in function type_archive(). Archive link post type is get from $wp_taxonomies[$type->taxonomy]->object_type[0] … no matter how many “object types” is taxonomy registered to, and what CPT post is displayed, it will use the first one. And that is bad.

I think it is possible to get current post type from some enviroment variable, as $wp_query->query_vars['post_type'] … and than choose correct “object type”, if available in that array, or the first one otherwise.

Ha! You’re right, now I see tons of “POST /xmlrpc.php HTTP/1.0” requests …

So another line to .htaccess ??

Redirect 403 /xmlrpc.php

Upgrade solved everything! Thank you very much! ??

1. Yay! Thank you ??

2. Yes! It’s my default choice everytime (language by directory), and I know I was setting it this time too. But now I see the “language by content” is set. Setting language from directory (and those changes in source code) solved my issue.

Can I ask when the change in source code will by public?

Yes, it works, but … I don’t want to hardcode those changes to your plugin and disable its later updates ?? Have those is_string() checks any special meaning? Will it “break” when removed?

But there is another issue – the other plugin loads settings on ‘init’ action, and this code

$this->settings = get_option( 'quitenicebooking' );
echo "Step 1: " . $this->settings['step_1_page_id'];

… echoes “Step 1: 5” … but translated value is 213. But this is echoed on the top of the page, before any HTML … plugin has one widget, it is placed in sidebar, and it loads plugins settings again, via $quitenicebooking_settings = get_option('quitenicebooking'); … and now the 5 value is correctly translated to 213!

I checked that wpml-compat.php translate_strings() function is called even before the first settings load, but returns untranslated values. So I think that when booking plugins loads, Polylang functions works (after is_string() removal), but the setting translation is not available at the moment. But it is available later when the page renders (booking widget loading same settings).

Do you have any idea what can be wrong now?

Yes, removing is_string() from this conditions did the job – those strings appeared on String translation tab. But there are probably some front-end issues, because even when it was correctly translated in WP admin, nothing changed on front-end … and I gave up searching ??

It looks promising! Thank you!

Well, I mean those numerical “strings” are not displayed on that tab. So I can’t even to try to translate them.

XML content: https://imgur.com/OswWzzZ
String translation tab: https://imgur.com/RaW74GV

There should be seven another strings between fax_number and currency_unit.

I searched Polylang source codes and found for example register_string_recursive() (wpml-compat.php).

protected function register_string_recursive($context, $strings, $options) {
		foreach ($options as $name => $value) {
			if (isset($strings[$name])) {
				if (is_string($value) && $strings[$name] == 1) // !!! -----> is_string($value) ... and $value is number/ID ...
					pll_register_string($name, $value, $context);
				elseif (is_array($value) && is_array($strings[$name]))
					$this->register_string_recursive($context, $strings[$name], $value);
			}
		}
	}

Those is_string() conditions creates this problem I suppose.

Hi! Maybe the problem is that those strings are loaded from wpml-config.xml … then it is automatic process I suppose, and I can’t affect those parameter. Or can I?

Hi, thank for replying! Well, yes. There is approx. 20 “admin-texts” items in XML, but in Polylang admin / String translation tab are listed only some of them – those with any string value. Those with only numerical value are missing.

I am referring to this tutorial for WPML – https://themes.quitenicestuff.com/docs/sohohotelwp/translate-plugin-booking-other.html … I hoped it will be possible with Polylang too.

Ah, now I see textareas in plugin source code … but my strings has only INPUT fields. They are loaded from wpml-config.xml admin-texts list … could this be the issue?

jabdulla: Well, I registered here just to have a possibility to let know about my findings ?? Anyway, you’re welcome!

mlkary: I think your problem is ONLY in image dimensions, and not failing Imagick library. Problem described above was not affected by image dimensions, I have tried many of them. You are just dealing with too big images and too low RAM memory limit your script can allocate (PHP directive “memory_limit”).

Hi, I’m glad it’s useful. I knew I couldn’t be the only one who is experiencing this issue ?? Well, there is a simple method using add_filter() function, so you can add this code to your theme’s functions.php file:

add_filter( 'wp_image_editors', 'change_graphic_lib' );
function change_graphic_lib($array) {
  return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
}

It changes order of checking for available graphic libraries, so GD is checked first and if it is present, it is used.