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?

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

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);

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.

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.

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.

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 :(

So you deleted a translation but the content in that translation still shows up? Did you check the exp_publisher_titles table to make sure it is gone? Was there a duplicate row and you only deleted one of them? I’d go back to focusing on that lang_id, status, entry_id combination of columns in the exp_publisher_titles table, and the corresponding exp_publisher_field_data_X tables, and focus in on a custom field or two instead of the entire entry (e.g. is it a relationship or grid field, or a textarea/wygwam? b/c those fieldtypes behave very differently and store data in different places. Just focusing on the entire entry as a whole is too much noise.

I think the issue is with the publisher_status=”draft|open” parameter. Publisher isn’t forming the query correctly when the statuses are piped like that. It’s executing the following query, which returns no results b/c the status is either “open” or “draft”, not “open|draft”.

Removing the publisher_status parameter, or just setting it to “open” returns what I think is the proper row. I don’t see any Japanese text though, so I don’t know if you’re expecting that or not. Since the original query was returning 0 rows, I think Publisher was falling back to display the English content, which is what you were seeing on the test page.

Does this sound right to you?

SELECT `ct`.*, `t`.*, `channel_title`, `c`.`channel_name`, `c`.`channel_url`, `c`.`comment_url`, `c`.`comment_moderate`, `c`.`channel_html_formatting`, `c`.`channel_allow_img_urls`, `c`.`channel_auto_link_urls`, `c`.`comment_system_enabled`, `username`, `m`.`email`, `m`.`screen_name`, `m`.`signature`, `m`.`sig_img_filename`, `m`.`sig_img_width`, `m`.`sig_img_height`, `m`.`avatar_filename`, `m`.`avatar_width`, `m`.`avatar_height`, `m`.`photo_filename`, `m`.`photo_width`, `m`.`photo_height`, `m`.`group_id`, `m`.`member_id`, `ct`.`url_title` AS default_url_title, `ct`.`status` AS status, `t`.`title` AS title, `t`.`site_id` AS entry_site_id
FROM (`exp_publisher_titles` AS t)
JOIN `exp_channel_titles` AS ct ON `ct`.`entry_id` = `t`.`entry_id`
JOIN `exp_channels` AS c ON `c`.`channel_id` = `t`.`channel_id`
JOIN `exp_members` AS m ON `m`.`member_id` = `t`.`author_id`
WHERE `t`.`entry_id` IN (12159) 
AND `t`.`status` =  'draft|open'
AND `t`.`lang_id` =  10

Note to self, this fixes the issue (mostly)

public function setChannelFilter($channelFilter)
    {
        if (!$channelFilter) {
            return $this;
        }

        $channels = explode('|', $channelFilter);
  
  //$this->channelFilter

        $cf = array_map(function($channel) {
            if (!is_numeric($channel)) {
                /** @var \CI_DB_result $qry */
                $qry = ee('db')->select('channel_id')->get_where('channels', ['channel_name' => $channel, 'site_id' => 10]);

                if ($qry->num_rows() == 1) {
                    return trim($qry->row('channel_id'));
                }
            }

            return trim($channel);
        }, $channels);
  
  //var_dump($cf); die;

  
        return $this;
    }

You might need to comment out the next conditional too. Basically check those tables to see if those columns exist in your EE 2 install, then if it does comment out both conditionals.

Well, heck, that explains it. I must have added the conditionals more recently. Wrap those 2 query statements in conditionals:

if (!ee('db')->field_exists('expiration_date', 'publisher_titles')) {
            $db->query("ALTER TABLE `" . $db->dbprefix . "publisher_titles` ADD `expiration_date` int(10) DEFAULT 0 AFTER `edit_date`");
        }

        if (!ee('db')->field_exists('comment_expiration_date', 'publisher_titles')) {
            $db->query("ALTER TABLE `" . $db->dbprefix . "publisher_titles` ADD `comment_expiration_date` int(10) DEFAULT 0 AFTER `expiration_date`");
        }

Is this a fresh update from EE 2? It seems like the DB has been partially upgraded already. Did you get a pristine EE2 version of the site db and start the upgrade from the beginning?

yeah, the fresh upgrade from EE3 should do it. I meant Publisher 2 instead of EE2 in the previous comment. That unique key error says the key already exists, so it was created at some point already, perhaps in a previous upgrade attempt. So starting from the pristine EE3 db version again, if you can, should do it, otherwise you might keep running into errors like this.

Greg, I’m having a hard time following where you’re at in the installation process. This error happens when you have Publisher 3.x installed and are running the upgrade? Based on all these errors it just feels to me like the DB is in a half upgraded state and/or the wrong versions of files are being used. If you haven’t started the upgrade from EE3’s fresh DB to EE5 and Publisher 2 to Publisher 3 from scratch each time, it may leave the DB in a half upgraded state. That error specifically is happening b/c there is already a row in the exp_publisher_data_field_21 table with the same entry_id, lang_id, and status, which should never be the case. One of the first things Publisher does when upgrading to 3.x is de-duplicate potentially stray rows in the exp_publisher_titles and exp_publisher_data tables before it tries to migrate anything to the exp_publisher_data_field_X tables.

Is this the process you’re following?

1. Fresh, pristine copy of the site in EE3, straight from the production server.
2. Upgrade EE3 to EE5.
3. Upgrade Publisher from 2 to 3.