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 Resolved
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

May 20, 2020

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)

May 20, 2020

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

May 20, 2020

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

Keep us posted and talk soon!

Greg

#8

BoldMinded (Brian)

May 20, 2020

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

May 21, 2020

Comment has been marked private.

#10

BoldMinded (Brian)

May 21, 2020

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

#11

BoldMinded (Brian)

May 21, 2020

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

#12

Gregory Maher

May 21, 2020

Comment has been marked private.

#13

BoldMinded (Brian)

May 21, 2020

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

May 21, 2020

Comment has been marked private.

#15

BoldMinded (Brian)

May 21, 2020

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

May 21, 2020

Comment has been marked private.

#17

BoldMinded (Brian)

May 22, 2020

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

May 26, 2020

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)

May 26, 2020

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)

May 26, 2020

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

May 26, 2020

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)

May 26, 2020

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

May 26, 2020

Comment has been marked private.

#24

BoldMinded (Brian)

May 26, 2020

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

May 26, 2020

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)

May 26, 2020

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

May 26, 2020

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)

May 26, 2020

Comment has been marked private.

#29

BoldMinded (Brian)

May 26, 2020

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

#30

Gregory Maher

May 27, 2020

Comment has been marked private.

#31

Gregory Maher

May 29, 2020

Comment has been marked private.

#32

Gregory Maher

May 29, 2020

Comment has been marked private.

#33

BoldMinded (Brian)

May 29, 2020

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.

#34

Gregory Maher

May 29, 2020

OK, I’ll go in and take a look at those tables/rows. However, the front-end template I was sharing above was only two Wygwam fields. That’s what we’re having issues with.

Again, I’ll take a look asap.

Greg

#35

Gregory Maher

May 29, 2020

As a followup, for the entry shared in the links above, there is only one row in the exp_publisher_titles, and the combination of site_id, channel_id, entry_id, lang_id and status are correct. Additionally, in the exp_publisher_data_field_439 (one of the corresponding Wygwam fields in the template mentioned above) there is a single row for this entry, with the correct lang_id and status.

#36

Gregory Maher

Jun 02, 2020

Comment has been marked private.

#37

BoldMinded (Brian)

Jun 02, 2020

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

 

#38

Gregory Maher

Jun 02, 2020

Comment has been marked private.

#39

BoldMinded (Brian)

Jun 03, 2020

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;
    }
#40

BoldMinded (Brian)

Jun 04, 2020

Comment has been marked private.

#41

Gregory Maher

Jun 04, 2020

NICE! Early tests are showing positive results - things display as expected!

Once again, Bold Minded for the win.

Let me dig a bit more, but I think we’re in very good shape.

Thank you, as always, for your persistence and continued support, Brian. I will follow up via email.

#42

BoldMinded (Brian)

Jun 05, 2020

Excellent news!

I’ll keep this ticket open for a bit before I close it.

#43

Gregory Maher

Jul 08, 2020

Hi Brian,
I re-opened this ticket as I wonder if the error we’re running into might be related to the latest release you shared with me.

While the latest develop version you shared does correct the language display issue on the front-end, when trying to upgrade our site from ExpressionEngine 3.x to ExpressionEngine 5.x and Publisher from 2.x to 3.1.5 (and 3.1.2) we’re often getting a 503 server error.

Then, when viewing the site we’re getting the following duplicate column error, across a few different columns, such as expiration_date, pub_key or comment_expiration_date.

SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name ‘expiration_date’:
ALTER TABLE `exp_publisher_titles` ADD `expiration_date` int(10) DEFAULT 0 AFTER `edit_date`

It seems like the 503 error is causing the update to not complete, and something isn’t getting finished when attempting to adjust the exp_publisher_titles table. Could it be there are too many entries (~18k)?

Would a longer script execution time or more memory help the effort?

Let me know what you think and we’ll try accordingly.

Thanks!

Greg

#44

BoldMinded (Brian)

Jul 08, 2020

Is there anymore to that error message? A call stack with file names line numbers perhaps?

#45

Gregory Maher

Jul 08, 2020

Sure thing, Brian! See here:

SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name ‘expiration_date’:
ALTER TABLE `exp_publisher_titles` ADD `expiration_date` int(10) DEFAULT 0 AFTER `edit_date`

ee/legacy/database/drivers/mysqli/mysqli_connection.php:117

Stack Trace: Please include when reporting this error

#0 ee/legacy/database/drivers/mysqli/mysqli_driver.php(112): CI_DB_mysqli_connection->query(‘ALTER TABLE `ex…’)
#1 ee/legacy/database/DB_driver.php(270): CI_DB_mysqli_driver->_execute(‘ALTER TABLE `ex…’)
#2 ee/legacy/database/DB_driver.php(180): CI_DB_driver->simple_query(‘ALTER TABLE `ex…’)
#3 user/addons/publisher/updates/up_2_10_06.php(10): CI_DB_driver->query(‘ALTER TABLE `ex…’)
#4 user/addons/publisher/vendor/litzinger/basee/src/Updater.php(95): Update_2_10_06->doUpdate()
#5 user/addons/publisher/upd.publisher.php(580): Basee\Updater->runUpdates()
#6 ee/EllisLab/ExpressionEngine/Controller/Addons/Addons.php(533): Publisher_upd->update(‘2.8.3’)
#7 [internal function]: EllisLab\ExpressionEngine\Controller\Addons\Addons->update(Array)
#8 ee/EllisLab/ExpressionEngine/Core/Core.php(241): call_user_func_array(Array, Array)
#9 ee/EllisLab/ExpressionEngine/Core/Core.php(110): EllisLab\ExpressionEngine\Core\Core->runController(Array)
#10 ee/EllisLab/ExpressionEngine/Boot/boot.php(151): EllisLab\ExpressionEngine\Core\Core->run(Object(EllisLab\ExpressionEngine\Core\Request))
#11 httpdocs/admin.php(156): require_once(’...’)
#11 httpdocs/admin.php(156): require_once(’...’)

#46

BoldMinded (Brian)

Jul 08, 2020

Actually it looks like that query only comes from 1 place. In the updates folder, file up_2_10_06.php, comment out lines 11-13.

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`");
        }

Not sure why that conditional thinks the column doesn’t exist when it does.

#47

BoldMinded (Brian)

Jul 08, 2020

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.

#48

Gregory Maher

Jul 08, 2020

Hi Brian,
That file looks a little different for me. See here:

<?php

use Basee\Update\AbstractUpdate;

class Update_2_10_06 extends AbstractUpdate
{
    public function doUpdate()
    {
        $db = ee('db');
        $db->query("ALTER TABLE `" . $db->dbprefix . "publisher_titles` ADD `expiration_date` int(10) DEFAULT 0 AFTER `edit_date`");
  $db->query("ALTER TABLE `" . $db->dbprefix . "publisher_titles` ADD `comment_expiration_date` int(10) DEFAULT 0 AFTER `expiration_date`");
 
      /** @var CI_DB_result $entries */
        $entries = ee('db')
            ->where('expiration_date', '> 0')
            ->or_where('comment_expiration_date', '> 0')
            ->get('channel_titles');

        foreach ($entries->result() as $entry) {
            ee('db')
                ->where('entry_id', $entry->entry_id)
                ->update('publisher_titles', [
                    'expiration_date' => $entry->expiration_date,
                    'comment_expiration_date' => $entry->comment_expiration_date
                ]);
        }
    }
}
#49

BoldMinded (Brian)

Jul 08, 2020

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`");
        }
#50

Gregory Maher

Jul 08, 2020

OK, that seemed to help, but now the same error on the next upgrade:

Exception Caught

SQLSTATE[42000]: Syntax error or access violation: 1061 Duplicate key name ‘pub_key’:
ALTER TABLE `exp_publisher_titles` ADD UNIQUE KEY `pub_key` (entry_id, lang_id, status)

ee/legacy/database/drivers/mysqli/mysqli_connection.php:117

Stack Trace: Please include when reporting this error

#0 ee/legacy/database/drivers/mysqli/mysqli_driver.php(112): CI_DB_mysqli_connection->query(‘ALTER TABLE `ex…’)
#1 ee/legacy/database/DB_driver.php(270): CI_DB_mysqli_driver->_execute(‘ALTER TABLE `ex…’)
#2 ee/legacy/database/DB_driver.php(180): CI_DB_driver->simple_query(‘ALTER TABLE `ex…’)
#3 user/addons/publisher/updates/up_3_00_00.php(63): CI_DB_driver->query(‘ALTER TABLE `ex…’)
#4 user/addons/publisher/vendor/litzinger/basee/src/Updater.php(95): Update_3_00_00->doUpdate()
#5 user/addons/publisher/upd.publisher.php(580): Basee\Updater->runUpdates()
#6 ee/EllisLab/ExpressionEngine/Controller/Addons/Addons.php(533): Publisher_upd->update(‘2.8.3’)
#7 [internal function]: EllisLab\ExpressionEngine\Controller\Addons\Addons->update(Array)
#8 ee/EllisLab/ExpressionEngine/Core/Core.php(241): call_user_func_array(Array, Array)
#9 ee/EllisLab/ExpressionEngine/Core/Core.php(110): EllisLab\ExpressionEngine\Core\Core->runController(Array)
#10 ee/EllisLab/ExpressionEngine/Boot/boot.php(151): EllisLab\ExpressionEngine\Core\Core->run(Object(EllisLab\ExpressionEngine\Core\Request))
#11 httpdocs/admin.php(156): require_once(’...’)
#11 httpdocs/admin.php(156): require_once(’...’)

Should i be doing the same on all remaining upgrade files?

#51

BoldMinded (Brian)

Jul 08, 2020

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?

#52

Gregory Maher

Jul 08, 2020

It’s actually an EE3 > 5 Upgrade. We started with a pristine EE3 db but got that 503 timeout error. So it seems like the upgrade is failing somewhere - just not sure where.

Do you think if we up our memory and PHP execution time we should try the upgrade again from a fresh db?

Thanks!

#53

BoldMinded (Brian)

Jul 08, 2020

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.

#54

Gregory Maher

Jul 08, 2020

Hi Brian,
OK, on a fresh Publisher 2 install (inside ExpressionEngine 5) we ran into the following issue:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '29-1-open' for key 'pub_key':
INSERT INTO `exp_publisher_data_field_21` (entry_id, lang_id, status, field_id_21) VALUES (29, 1, 'open', '1');INSERT INTO `exp_publisher_data_field_26` (entry_id, lang_id, status, field_id_26) VALUES (29, 1, 'open', '0');INSERT INTO `exp_publisher_data_field_29` (entry_id, lang_id, status, field_id_29) VALUES (29, 1, 'open', 'This is something new.\n\nThis is again something new.');INSERT INTO `exp_publisher_data_field_26` (entry_id, lang_id, status, field_id_26) VALUES (33, 1, 'open', '0');INSERT INTO `exp_publisher_data_field_26` (entry_id, lang_id, status, field_id_26) VALUES (34, 1, 'open', '0');INSERT INTO `exp_publisher_data_field_26` (entry_id, lang_id, status, field_id_26) VALUES (35, 1, 'open', '0');INSERT INTO `exp_publisher_data_field_26` (entry_id, lang_id, status, field_id_26) VALUES (36, 1, 'open', '0')

ee/legacy/database/drivers/mysqli/mysqli_connection.php:117

Stack Trace: Please include when reporting this error

#0 ee/legacy/database/drivers/mysqli/mysqli_driver.php(112): CI_DB_mysqli_connection->query('INSERT INTO `ex…')
#1 ee/legacy/database/DB_driver.php(270): CI_DB_mysqli_driver->_execute('INSERT INTO `ex…')
#2 ee/legacy/database/DB_driver.php(180): CI_DB_driver->simple_query('INSERT INTO `ex…')
#3 user/addons/publisher/Service/Migration.php(322): CI_DB_driver->query('INSERT INTO `ex…')
#4 user/addons/publisher/updates/up_3_00_00.php(73): BoldMinded\Publisher\Service\Migration->migrateEntryData()
#5 user/addons/publisher/vendor/litzinger/basee/src/Updater.php(95): Update_3_00_00->doUpdate()
#6 user/addons/publisher/upd.publisher.php(580): Basee\Updater->runUpdates()
#7 ee/EllisLab/ExpressionEngine/Controller/Addons/Addons.php(533): Publisher_upd->update('2.8.3')
#8 [internal function]: EllisLab\ExpressionEngine\Controller\Addons\Addons->update(Array)
#9 ee/EllisLab/ExpressionEngine/Core/Core.php(241): call_user_func_array(Array, Array)
#10 ee/EllisLab/ExpressionEngine/Core/Core.php(110): EllisLab\ExpressionEngine\Core\Core->runController(Array)
#11 ee/EllisLab/ExpressionEngine/Boot/boot.php(151): EllisLab\ExpressionEngine\Core\Core->run(Object(EllisLab\ExpressionEngine\Core\Request))
#12 httpdocs/admin.php(156): require_once('...')
#12 httpdocs/admin.php(156): require_once('...')

Any thoughts?

#55

BoldMinded (Brian)

Jul 08, 2020

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.

#56

Gregory Maher

Jul 08, 2020

Hi Brian,
Yes, what you’re describing is what we’re doing.

1. Replicate our production EE3 code and db on our dev server
2. Upgrade EE3 to EE5
3. Upgrade Publisher 2 to 3

I have a copy of the db that we’ve backed up after upgrading from EE3 to EE5 but before running the Publisher 3 upgrade. I’ve tried this multiple times and keep getting the same error.

Based on the above error, I’ve gone in and deleted the specific rows in the fields that looked to be duplicated. The update then finished and is now on step 2 with ~18k entries to update. I will report back asap!

Greg

#57

Gregory Maher

Jul 28, 2020

Comment has been marked private.

#58

BoldMinded (Brian)

Jul 29, 2020

Just to confirm, you’re 100% confident there are no tables in the database before you upgrade that start with the name exp_publisher_data_field_*?

#59

Gregory Maher

Jul 29, 2020

Ugh. That looks to have been the case. I think we left them in the db inadvertently during a previous failed upgrade. Things look to be working now. I will keep you posted with any other issues.

And, as always, thanks so much for the quick response!

Login to reply

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