BoldMinded

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 does not recognise that there’s a newer draft when submitting an update via Channel Form

Status Resolved
Add-on / Version Publisher 1.4.2
Severity Critical
EE Version 2.8.1

Pete Heaney

Jul 24, 2014

Sorry, me again!

This may or may not be related to my other ticket (#936) so I thought it would be best to create a new ticket.

When submitting a new entry draft (i.e. not an update to an existing entry) via a Channel Form, everything works as expected.  When viewing the Published version of the entry in the CP, I see the message “A more recent draft is available”.  Also, the {has_newer_draft} tag returns true.  All good.

However, when I submit an update draft via Channel Form, Publisher does not recognise that a newer draft exists.  I do not see the “A more recent draft is available” message in the CP and the {has_newer_draft} tag returns false.

Like my other ticket, I believe this is an issue that has arisen since upgrading from v1.4.0 to v1.4.2.

Thanks,
Pete

#1

BoldMinded (Brian)

But the draft via Channel Form is saving and updating data correctly, right? And there is still no Open/Published version of the entry?

#2

Pete Heaney

Sorry, yes, I meant to mention that. The draft data is saved correctly.

There is however an open/published version of the entry, as the initial draft would have been previously approved/published. So it looks something like this:

1) User submits first draft (no published version exists at this stage and Publisher correctly identifies that a draft exists) 2) Admin approves/publishes draft (Publisher correctly identifies that there is currently no newer draft) 3) User submits an update (a draft that is newer than the published version exists but Publisher fails to recognise that fact)

#3

BoldMinded (Brian)

Did you add the hidden fields noted at the very bottom of this page? https://boldminded.com/add-ons/publisher/template-tags

#4

Pete Heaney

Yes, I have the following fields:

<input name=”lang_id” value=”{publisher:current_language_id}” type=”hidden”> <input name=”publisher_view_status” value=”draft” type=”hidden”> <input name=”publisher_save_status” value=”draft” type=”hidden”>

#5

BoldMinded (Brian)

Ok, I’ll try to replicate it this weekend and see if I can figure out what the issue is. Thanks for the detailed steps to replicate.

#6

Pete Heaney

No probs, thanks for your help.

#7

Pete Heaney

fyi, as per my other ticket (#936), I have downgraded Publisher back to v1.4.0 to resolve another bug.

However, the problem described in this ticket still exists in v1.4.0.

#8

BoldMinded (Brian)

Pete, I’m unable to replicate this locally. I have 2 templates, one for creating and one for editing. This is what the opening tag looks like for both:

channel-create.html

{exp:channel:form channel="pages" return="forms/channel-create"}
    <input name="lang_id" value="{publisher:current_language_id}" type="hidden">
    <input name="publisher_view_status" value="draft" type="hidden">
    <input name="publisher_save_status" value="draft" type="hidden">
    .... rest of form fields ....

channel-edit.html

{exp:channel:form channel="pages" return="forms/channel/ENTRY_ID" entry_id="{segment_3}" publisher_status="draft"}
    <input name="lang_id" value="{publisher:current_language_id}" type="hidden">
    <input name="publisher_view_status" value="draft" type="hidden">
    <input name="publisher_save_status" value="draft" type="hidden">
    .... rest of form fields ....

With these templates I can create a draft entry, then edit the entry and it never creates an open version of the entry. The draft is updated correctly when editing too.

#9

Pete Heaney

Found the problem/solution:

It’s a timezone / daylight saving issue. I’ll try to explain…

In member preferences, I had “Allow members to set their own localization preferences?” set to “yes”, but I wasn’t actually asking members to set their timezone. That resulted in members defaulting to GMT (not adjusted for daylight saving, i.e. an hour behind).

Being a Super Admin, my account is not affected by this problem because Super Admin accounts default to the timezone specified during EE installation (which automatically takes care of daylight saving).

So what all this means is that normal members essentially have a timezone that is one hour behind that of the Super Admins.

This causes a problem because when a normal member submits a draft via the frontend, Publisher assigns a timestamp in exp_publisher_titles using the member’s timezone (1 hour behind), but when the Super Admin comes along and approves the draft, it uses the Super Admin’s timezone (1 hour ahead of the normal member’s timezone). So when Publisher compares the open and draft edit dates (in the _has_draft_multi method in models/publisher_entry.php), it sees that the draft date is older than the open date and thinks that there’s no new draft.

I’ve fixed the problem by setting “Allow members to set their own localization preferences?” to “no”. I guess it may be something you could make allowances for in the add-on when setting the edit dates in the db.

#10

BoldMinded (Brian)

Ahhhhh. That makes sense and I didn’t even think to look at that. I should be able to account for this, but not sure if I want to do it on submission or in the logic that determines if a draft is newer. The later seems like the most logical place to put this check.

Thanks for figuring this out, and sorry for the back and forth. At least its working now 😊

#11

Pete Heaney

No worries, not exactly an easy one to spot. I sat there staring at a list of timestamps for about half an hour before it hit me!

Thanks for looking into it anyway, much appreciated!

#12

BoldMinded (Brian)

Pete, sending you a new build. Try reverting that user preference and the build I’m sending to see if the behavior is fixed.

#13

Pete Heaney

I updated to the new build. Unfortunately I’m now getting an error:

Fatal error: Call to private method Publisher_helper::is_draft_newer() from context ‘Publisher_entry’ in /home/grs/public_html/system/expressionengine/third_party/publisher/models/publisher_entry.php on line 687

The page I’m trying to view when getting this error uses the {has_newer_draft} tag so I’m guessing it’s something to do with that.

#14

BoldMinded (Brian)

Oops. Go to that line of code and change it to public from private.

#15

Pete Heaney

Ok, done that, error fixed. However, I’m afraid the original problem is still there. It’s still not recognizing that there’s a draft.

#16

BoldMinded (Brian)

Ok, I’ll look at it again tonight.

#17

Pete Heaney

No probs, thanks.

#18

BoldMinded (Brian)

Sent 1.4.3 build that I think fixes the issue.

#19

Pete Heaney

That fixed the problem. But unfortunately caused another problem. Now my channel form on another channel (that doesn’t use Publisher) is failing to load (i.e. the form just doesn’t load). I don’t really have time to work out why. I’ve reverted back to 1.4.2. Turning off localization fixes the problem, so that’s good enough for me.

#20

BoldMinded (Brian)

Did you reapply the patch you sent me earlier?

#21

Pete Heaney

Yep

#22

BoldMinded (Brian)

The entire form does not load or the field tags are not parsed like before? Did you try different entries? Did you try adding show expired or show future to the tag?

#23

Pete Heaney

Weirdly, the form tag itself is there, and the hiddenFields div containing all the hidden Channel Form fields is there, but nothing after that is loaded. No empty fields, no unparsed tags, nothing.

Switching to a different user, with a different associated entry makes no difference.

Adding show_expired=”yes” and show_future_entries=”yes” to the channel form tag makes no difference either.

#24

BoldMinded (Brian)

Sent another build. Taking a shot in the dark to see if it makes a difference.

#25

Pete Heaney

Ok, sorry, I think I caused this problem - I didn’t apply the patch properly. Now that I’ve done that, all is fine. So actually, your most recent build wasn’t necessary. Sorry about that!

And the timestamp fix is still good.

So I think that’s it!

#26

Brian Litzinger

Ah. Ok. Good to hear 😊

Going to mark this closed and keep an eye out for other people reporting the original issue since I can’t replicate it.

Login to reply