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: Several fields aren’t being saved when saving as draft.

Status	Resolved
Add-on / Version	Publisher 1.6.5
Severity
EE Version	2.10.1

Diederik v Hoorebeke

Sep 16, 2015

This happens with several fieldtypes, such as radio buttons and dropdowns.
Saving an entry as Draft, doesn’t save the state or content of those fieldtypes.

I’ve made a simple channel, with no third party fieldtypes. I’ve also disabled the de gzip compression, using php 5.5.
Saving the entry as Published, doesn’t cause it to fail. And going back from an error message when submitting an incomplete entry, also doesn’t cause any problems.

What could be the problem?

BoldMinded (Brian)

Can you upgrade to 1.6.6 first and try again?

BoldMinded (Brian)

Can you please take a screenshot of your publish form so I can see exactly what fieldtypes they are. You said “several” but only mention radio and dropdowns. Are those the only ones not working or does it not work with text fields too? And “doesn’t cause it to fail” what do you mean by that? What error message are you getting?

Diederik v Hoorebeke

Hi,

I’ve upgraded to version 1.6.6.

Content not being saved, only happens when saving as draft. Saving incomplete forms with required fields not filled out, don’t cause the content to be lost. Neither does publishing the entry.

Screenshot1: a test channel form with only one fieldtype added. In this case multiple checkboxes. https://infinit.io/_/34TadH4

Screenshot2: after saving the entry as draft, and going back to edit the entry, the checkbox that was previously checked, isn’t checked anymore. https://infinit.io/_/z4c5AXa

The problem only happens with radio buttons, dropdown fields and one custom made fieldtype. The custom fieldtype is a non-array fieldtype. (var $has_array_data = FALSE;)

I can add other fieldtypes to the test channel, if you want me to.

Thanks in advance! D.

Diederik v Hoorebeke

Hi Brian,

Any news on this matter? If there is anything more I could do to help resolving this issue, please do not hesitate to contact me.

Kind regards, Diederik.

Diederik v Hoorebeke

Hi Brian,

I noted that I forgot to answer your question regarding possible error messages. There are no error messages given.

Kind regards, Diederik.

BoldMinded (Brian)

I have not had a chance to look at this. It may be a couple days. Can you share the custom fieldtype with me?

BoldMinded (Brian)

Diederik, I just did a quick test and made a new select and radio field, and they both saved fine and retained their draft and open/published values. Are you able to replicate this in a new EE environment with only Publisher installed? Also, you should upgrade Publisher to the latest version.

Diederik v Hoorebeke

Hi Brian,

I’ve done some checks, and found something that could lead to a solution.

First of all, the draft fields are being saved. I’ve checked the database for the fields, and that looks like it should: https://infinit.io/_/NQ9JYSz (field 126 are radio buttons, field 127 is a textarea)

But when I try to view the entry as draft, only the draft-version of field 127 (textarea) is shown. Other fields, in this case the radio buttons, are the published version. All other non-custom fields work as supposed, except for the url_title field: https://infinit.io/_/SndTz2v

So I’ve enabled the output profiler. And sure enough, only the textarea field was being retrieved from the publisher_data table. Even though there is draft data for field 126 (radio buttons).

How come that published data is being displayed when viewing entries as draft? Any ideas?

Kind regards, Diederik.

Brian Litzinger

This is basically the opposite of what I’m seeing. My draft entry has the radio value set to “Yes” in the db, and it displays as “Yes” when loaded in the CP. The open version of the entry has the value set to “No”, it too properly shows “No” when viewing the entry.

Running the query also pulls the correct value.

SELECT `d`.`field_id_49`
FROM (`exp_publisher_titles` AS t)
JOIN `exp_publisher_data` AS d ON `d`.`entry_id` = `t`.`entry_id`
WHERE `t`.`publisher_status` =  'draft'
AND `d`.`publisher_status` =  'draft'
AND `t`.`publisher_lang_id` =  '1'
AND `d`.`publisher_lang_id` =  '1'
AND `t`.`entry_id` =  1408
AND `t`.`site_id` =  '1'

Did you replicate this in a new/clean EE environment with only Publisher installed?

#10

Diederik v Hoorebeke

Not yet. I will!

Except from that, when displaying the form using Channel Fields, the correct data is shown: https://infinit.io/_/35M7Vjx

In the backend itself, Publisher doesn’t even try to do the (modified) query you posted. It only gets one field, the textarea. And doesn’t execute the query to get the draft for the radio buttons.

I’ll keep you posted. If you have any suggestions, please let me know!

#11

Diederik v Hoorebeke

Is there a difference in the way Publisher gets its data between Channel Forms and the Edit Entry form in de CP?

#12

BoldMinded (Brian)

No, shouldn’t be any difference. There is no code in Publisher for Channel Forms. The only thing needed to support Channel Forms is to add some hidden inputs so it saves the status correctly, or add status and language to the form tag, but even then its just setting variables that everything else in Publisher uses to query the data… the same variables used in the CP.

Do you have the field ignored or something?

#13

Diederik v Hoorebeke

No, I don’t.

#14

BoldMinded (Brian)

Can you share the template code you are using to render the channel:form?

#15

BoldMinded (Brian)

Did you see the documentation at the very bottom of https://boldminded.com/add-ons/publisher/template-tags?

#16

BoldMinded (Brian)

Closing b/c I haven’t heard anything back in a month.