Publisher does not support the Fluid field type. Please do not contact asking when support will be available.

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: Publisher only serves default language on most entries, until they are manually saved and have data

Status Resolved
Add-on / Version Publisher 2.8.3
Severity
EE Version 4.3.1

Aaron Jay

Aug 20, 2018

Description:

Following an update of an EE2 site to EE4.3.1, publisher entries for one specific channel at least, will only serve the default language. We’ve managed to track this issue down to exp_entry_versioning.

The update completed successfully, and translations appear to be working correctly across most of the site.

There are over 2700 entries in the “Diary” channel. If I switch from English (default) to Irish, on the front end, in a diary entry, or the diary landing page, some entries will function correctly, but most won’t.

The ones that will work correctly if they are manually set to published, and we hit “Save”. The issue really concerns the bulk of entries or else we would just manually resolve the issue by saving them and hence creating the entries in the db in the exp_entry_versioning table.

Also just to note, Versioning was turned off for this channel, we’ve since enabled it locally, but it doesn’t make a difference, possibly will for future entries.

Detailed steps to reproduce the issue:
1. Update old Publisher EE2 site to EE4
2. Attempt to change language on the front end, and observe that some work. while the majority do not.
3. Check the db, notice that while exp_publisher_data is affected somewhat, the only fix seems to be the entry in the exp_entry_versioning table.

Is there any way for us to safely bulk update all 2700 entries, bearing in mind some of this data is in possibly 6 tables or so, and this may not be the only occurrence of this happening?

#1

BoldMinded (Brian)

Publisher doesn’t do anything with the native versioning. Did the EE2 site have Publisher installed or is this a new install of Publisher? It sounds like either the channel is set to ignored or the migration during the install didn’t complete properly, in which case, the publisher_titles and publisher_data tables not don’t have the correct data, which is why the manual saves are correcting it.

#2

Aaron Jay

The EE2 site had Publisher installed. All of the entries were published, and have both English & Irish versions of the entries. The update appeared to complete successfully.

#3

BoldMinded (Brian)

Find another entry that isn’t showing correctly, and before you re-save it to fix it, take a look at those tables I mentioned, and compare them to the native corresponding channel_titles/data tables for any discrepancies. A year or so ago there was a bug where the incorrect author_id was in the publisher_titles table, which meant the join query didn’t work, thus it didn’t display the entries on the front-end. Don’t know if that is what you’re seeing, just providing ideas on what to look for.

#4

BoldMinded (Brian)

You can also dig into the Service/Entry/EntryResult.php file around line 354 inside the getAll() and getAllQuery() methods to see where it might be breaking down.

#5

Aaron Jay

Hi Brian,

I’ve had a good look and I don’t see anything in the tables you mentioned that could be causing the initial issue.

We’ll need to find a solution for this, or we’ll end up needing to manually update 2700+ entries. In attempting to find a solution for some of the issues, we’ve come across 2 more serious issues that appear to be caused by Publisher.

  1. If Persistent Entries is switched on, it breaks pagination for non-default languages (eg. Irish). Instead of the standard /page/P10, it just keeps appending /page/P10/P20/P20/P20 and so on. If I turn off Persistent Entries then pagination will work, but in some areas where 90% of content isn’t translated, it then appears to paginate through multiple blank pages, and also we’d only see the other 10% of the content.
  2. If we attempt to use bulk edit (which was a possible option to speed up the manual task of saving these entries), it wipes the language content for non-default languages. So in this case, no matter how many entries we select for bulk edit, and then attempt to update the status to published, it will wipe the Irish content from the entry, replacing it with the default. This happens regardless of Persistence settings.

Is there a query we could run to update all of our entries in a given channel, and update the correct tables it should be joined to? I’m not aware of the full db structure of publisher and how many tables I’d need to adjust to do so correctly, even if I could force them all to be published, that would resolve our first issue.

#6

BoldMinded (Brian)

Is there a query we could run to update all of our entries in a given channel, and update the correct tables it should be joined to?

I don’t know what is wrong, so I can’t provide a query, sorry.

Please open two new tickets for those new issues you found. I don’t want this ticket to be referencing multiple issues, it’ll get confusing real fast. In the mean time I’ll try to replicate them in a local environment.

#7

BoldMinded (Brian)

Comment has been marked private.

#8

Aaron Jay

Comment has been marked private.

#9

BoldMinded (Brian)

I don’t have a query to send b/c I don’t know what the query needs to do. I’d have to spend some time looking at the database before I could come to a possible conclusion on what it may be IF it is a data issue. The base of the query would be similar to this one found in the Entry service, which is a basic join to get data from the publisher_titles and publisher_data table, you can start there. If there are certain entries that are not being found, use those entry_ids to see if the join works to find the query, if it doesn’t, then it means something simple is wrong, like the language_id or statuses are not matching up, but doubt that is the case.

$query = $db->select('t.*, d.*')
            ->from('exp_publisher_titles AS t')
            ->join('exp_publisher_data AS d', 't.entry_id = d.entry_id')
            ->where([
                't.entry_id' => $entryId,
                'd.entry_id' => $entryId,
                't.status' => $status,
                'd.status' => $status,
                't.lang_id' => $language,
                'd.lang_id' => $language
            ])
            ->get();

Publisher does not fully instantiate if its a ACT request, so depending on what Gmaps is trying to do, then yeah it may not work correctly. ACT requests aren’t meant to be full page requests, thus Publisher doesn’t need to act on it. For example I think its the DevDemon Forms module that submits to an ACT request, and the same ACT requests instantiates the template parser and handles the HTML output of the entire page for the error message, which is not what an ACT request should be doing. Its circumventing half of EE’s boot process. So, if Gmaps is doing something like that, then yeah it won’t work with Publisher.

#10

BoldMinded (Brian)

By not fully instantiating I mean that Publisher doesn’t create its global template variables, Structure specific template variables, or try to do anything with the URL (like auto-switch languages).

#11

BoldMinded (Brian)

For reference, this is the Forms related ticket. Maybe Rein can determine if its a similar behavior that is happening? https://boldminded.com/support/ticket/1670

#12

Aaron Jay

Thanks, that could explain some of the other issues we were having re: the ACT requests.

For the original issue, I’ll try to query some of the entries that are missing translations and find where the break is.

I’ll add anything I find upon querying for the dud entries.

Also, I’ve done some more testing on the bulk edit and can repeatedly trigger the same behaviour. I’ve set up a new ticket here: https://boldminded.com/support/ticket/1812

Login to reply