Be sure to checkout our newest add-on Speedy!

EE compatibility updates:

  • Publisher is EE5 compatible, but it does not currently support the Fluid field.

ExpressionEngine.com licenses:

  • If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.

Ticket: Some fields, sometimes, not showing correct translated content.

Status Client Wait
Add-on / Version Publisher 3.1.5
Severity
EE Version 5.3.2

Gregory Maher

May 13, 2020

Hi Brian,
I hope all is well. We’re working on updating a site you’ve helped with in the past to ExpressionEngine 5 and Publisher 3.1.5. Everything *seems* to be working correctly, but for some of the regional (MSM) sites, some fields are not showing the correct content, but rather English content. These are primarily RTE fields. The incorrectly displaying fields happen across multiple templates (ex: titles in both the navigation and detail pages).

The translations are correct in the control panel.

For the MSM site in question, we’re using the following in the index.php file:
$assign_to_config[‘publisher_lang_override’] = ‘jp’;

And, this looks to be set correctly on the exp_publisher_site_language cookie.

I can provide additional screenshots and/or URLs as followup so you can see what I am referring to.

Thanks in advance!

Greg

#1

BoldMinded (Brian)

May 13, 2020

Hi, Gregory. It looks like you added the same image twice.

What you described is very vague, and not really enough information to go off of or to start debugging anything. Have you focused on a specific entry id, and then scanned the exp_publisher_data and publisher_data_field_X tables for that id to see if there are duplicate data rows?

#2

BoldMinded (Brian)

May 15, 2020

I see you updated the image, but it still doesn’t really describe the issue to me enough to look into it. This is most likely a database issue, maybe something happened when upgrading to Publisher 3.x. You’ll need to isolate and simplify the issue before I can look into this… focus on a single field that is displaying the incorrect data, then look at the exp_publisher_data_field_X table for the corresponding field, then find all rows matching the entry_id that is displaying incorrectly, then see if there are any duplicate rows. It uses composite keys, so lang_id, status, and entry_id. The values in those columns per row should be unique.

Next step is to create a test template with just a single channel:entries tag in it querying a single entry and displaying a single field that is having the issue, no extra fields, markup, or other EE tags. Again, simplify and isolate.

#3

Gregory Maher

May 15, 2020

Hi Brian,
Thanks for the followup. We’re doing exactly what you’re describing. And, we believe it to be a db issue also.

We’ve actually started digging through the database for all tables/rows containing the Entry ID for one of the entries displaying incorrectly, and for the Entry ID of one displaying correctly in the same channel and using the same template.

Can you tell us how many rows a correct Entry should have in each of the Publisher tables?

We’ll follow your advice to create a test template and see if that shows anything. It’s odd as Grid fields are working, but the Wygwam fields are not, again, for some entries.

We’ll keep you posted as we make progress, and we’ll update you once we have more detail. No need for any support on your end at the moment, but can you keep the ticket open so we can followup?

Publisher has been a workhorse for us over the years and the fact that upgrades from EE 3->5 worked at all is testimate to the quality of the Add-on.

Thanks again for the followup and we’ll be back in touch!

Greg

#4

BoldMinded (Brian)

May 15, 2020

Thanks for the kind words!

Think of Wygwam fields as just basic textarea fields, b/c that really is all they are when it comes to Publisher. As for the rows, if you have 1 entry saved in 2 languages you’ll have 2 rows, if that entry also has a draft for 2 languages,  you’ll have 4 rows.

#5

Gregory Maher

6 days ago

Hi Brian,
Thanks for your patience here. We’ve done quite a bit of digging and are seeing where we might have some issues.

It looks like on our current live site (where things are working correctly), the language for one of our regional sites is “forced” somehow to display only a specific (Japanese) language. The Entries don’t appear to have Published versions of the default language (English). And, in other cases have Japanese content in the English entry, it seems as a “hack”.

On our new site, it looks like the Entries that are working actually don’t appear to have a published version of the default language.

For the site in question is there a way to force a specific language? We have

$assign_to_config[‘publisher_lang_override’] = ‘jp’;

set in the index.php file but it might be depreciated?

Let me know and we’ll continue to research accordingly.

Thanks!

Greg

#6

BoldMinded (Brian)

6 days ago

Can you clarify what version of publisher the production site is using?

I haven’t deprecated any config values like that , so it should still work, but I’ll double check it tomorrow when I’m back on a computer.

#7

Gregory Maher

6 days ago

Hi Brian,
We’re using 3.1.5 which looks to be current.

Keep us posted and talk soon!

Greg

#8

BoldMinded (Brian)

6 days ago

So that config value, publisher_lang_override, is still in the same spot in the code it’s been in since 2015.

What other add-ons do you have installed?

#9

Gregory Maher

5 days ago

Comment has been marked private.

#10

BoldMinded (Brian)

5 days ago

Did you check the settings in Publisher - Language Control? It modifies the publisher_lang_override config value.

#11

BoldMinded (Brian)

5 days ago

I’m not sure what you mean by “Is there a way to set that just for this MSM site?”

#12

Gregory Maher

5 days ago

Comment has been marked private.

#13

BoldMinded (Brian)

5 days ago

You’re going to have to add a var_dump b/c I don’t have FTP access. Before line 78 of that file add this:

var_dump($languages, $lang_id);
#14

Gregory Maher

5 days ago

Comment has been marked private.

#15

BoldMinded (Brian)

5 days ago

You don’t have any languages with the ID of 4. Japanese is #10. Sounds like something is hard-coded or something that is setting the ID to 4 instead of 10.

#16

Gregory Maher

5 days ago

Comment has been marked private.

#17

BoldMinded (Brian)

4 days ago

No, the settings table isn’t where language information is stored. I would dig into the site and find out why it thinks Japanese language ID is set to 4, when it’s actually 10.

#18

Gregory Maher

8 hours ago

Hi Brian,
I hope you had a great holiday weekend. We’re continuing to look into this. I have a specific question.

Where does Publisher Language Control store its settings? I need to revert the control for the JP site “What language for new visitors…” setting.

Thanks!

#19

BoldMinded (Brian)

8 hours ago

It actually saves it in the exp_extensions table as a serialized array. There should be 4 rows for with the class value of “Publisher_language_control_ext” - be careful making changes manually to that b/c if you change a 10 to a 4 and don’t change the accompanying string length value from s:2 to s:1 it’ll corrupt the array.

#20

BoldMinded (Brian)

8 hours ago

If you make the change in 1 of the 4 rows, then just copy/paste the whole settings column value to the other rows too.

#21

Gregory Maher

8 hours ago

OK, great. Thanks, Brian. I deleted the rows as I hadn’t set anything else. The CP is now working and the Add-on is showing as not installed.

So, getting back into the language setting, do you have anywhere I should immediately be looking? Any specific tables? I see nothing in our index.php or admin.php files.

Thanks again for continuing to take a look!

Greg

#22

BoldMinded (Brian)

7 hours ago

I would assume it was incorrectly saved in the exp_extensions table. Try re-enabling the extension and configuring it again and see what happens.

#23

Gregory Maher

7 hours ago

Comment has been marked private.

#24

BoldMinded (Brian)

7 hours ago

That is coming from Publisher. I have no idea where the value of “10” was coming from, but that was probably the source of the issue.

#25

Gregory Maher

7 hours ago

In exp_publisher_languages, jp has an id of 10.

It’s the same on the current production site that’s working correctly.

Any idea where the 4 is coming from?

#26

BoldMinded (Brian)

7 hours ago

It might be cached, I don’t know. Uninstall the language control extension again, clear ALL caches (EE’s, Redis, or whatever you have), then re-install it. It’s fetching the languages from Publisher, which are cached, so it could be returning an old cache.

#27

Gregory Maher

7 hours ago

I’m getting the same thing for that specific setting:
<input type=“radio” name=“default_language[11]” value=“4”>

When the Japanese setting is used as a checkbox, the value is correctly set as “10”.
<input type=“checkbox” data-group-toggle=”[]” value=“10”>

Actually, when looking at the Language Override and Default Language radio button groups, the language values are incorrect throughout. The values appear to be consecutive, when our values skip 4 and 5.

These settings are correct in exp_publisher_languages.

Any thoughts there?

#28

BoldMinded (Brian)

6 hours ago

Comment has been marked private.

#29

BoldMinded (Brian)

6 hours ago

An array merge was resetting the language ids to the wrong values, which is why Japanese, the 5th one in the list, had the id of 4 :(

Login to reply

Contact

For add-on support, please use the Support section. General inquries and pre-sale questions can be sent to support@boldminded.com.