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: Draft preview not working for all fields
Status | Resolved |
Add-on / Version | Publisher |
Severity | Critical |
EE Version | 31 |
Timothy Kelty
May 23, 2013When I save a draft, changes show up correctly in the CP between my draft and published.
However, I have a simple “body” field (Wygwam, although I tried it as textarea just to test), and changes for that field do not show up in the draft preview (?publisher_status=draft).
All the other draft changes show up (Matrix fields, etc), but this one field won’t. Again, this is only on the preview, the draft content shows fine in the publish form.
The field is NOT in the ignored fields or fieldtypes in Publisher settings or anything.
Any ideas?
BoldMinded (Brian)
What else is going on in the template? I can create a page with a Wygwam field and it shows the proper draft content. https://www.evernote.com/shard/s9/sh/88b0b8c5-b15d-4121-a20c-a26fdfd2a671/69b8ec39b1ee5a7a943c5fe3791f9a22
Timothy Kelty
Yeah, like i said - I ended up trying it just as a textarea and it still didn’t work, so I don’t think it’s a fieldtype issue.
There was lots going on in the template, but I boiled it down to just an entries tag and the field, and it still loaded the published content:
Timothy Kelty
I was going to rule out any deleting all by my default language, but I wasn’t able to: http://boldminded.com/support/ticket/484
Brian Litzinger
Did you send me the site files for this project already for another ticket?
Timothy Kelty
I had the CP/FTP creds on another issue, but not a zip of the site (different projects)? Would you prefer that?
BoldMinded (Brian)
Yeah, if you can do that, a zip file with .sql file would help me debug it easier.
Timothy Kelty
I put the zip in the “site url” of the hidden info for this ticket.
Edit /config/environment.yml with your database and point host to /public and you should be good.
BoldMinded (Brian)
Thanks, I’ll try to look at it tonight.
Timothy Kelty
I was testing pages/default entries, but I saw the same thing other places.
Try editing the entry #30 “Rich Heritage” and saving some draft content in the body field.
Note - These are super old and thus hairy templates from an old EE1 site ported over. To rule out anything funky with that, I made the template have just the entries tag and the field, and I still saw the same thing.
BoldMinded (Brian)
The zip file isn’t opening for me, seems incomplete. I’ve downloaded it 3 times.
Timothy Kelty
Ok, give it another shot. I think it just hadn’t finished uploading.
BoldMinded (Brian)
Ok, I am getting really, really strange results. It looks like when when trying to view a draft the site_pages array has this value “/about-us/rich-heritage” but the open version is found at “/about/rich-heritage” - so adding ?publisher_status=draft to “/about/rich-heritage” doesn’t find any entry, b/c a draft does not exist, so things go haywire (its loading the includes/_header template recursively).
So you’re trying to view a draft of an entry that EE can’t find. If the draft is intended to have a different URL, then I’m not sure how to work around this issue. If a different URL was not the intention, then you might need to take a look at the parent page and this page in question to fix the URL.
If a different URL was intended, then I might have to do a little more work, and you might have to use the {exp:publisher:toolbar} to see the draft, instead of just adding the parameter to the URL.
Timothy Kelty
A different URL was not intended, no.
I think at some point the parent url was incorrectly /about-us, but got changed to /about
Timothy Kelty
Check out the walmart case study entry_id=741 (/work/walmart/).
I’m seeing the same thing with the body field there, but no urls have changed in that case.
BoldMinded (Brian)
Ok, it appears the embeds inside the entries tag is causing some recursion. I’ll look into this more this week.
Timothy Kelty
It doesn’t seem like that’s it to me:
If I reduce the work/detail template to merely:
… I see the draft content for the title, but cf_case_body is still showing the published data.
BoldMinded (Brian)
So if you leave in the header and footer include the page loads, but just doesn’t show the correct content? If I leave them in I get a PHP recursion error. I’m going to simulate the same setup in my sandbox to see if it does the same thing tonight.
Timothy Kelty
I’m not seeing any recursion error with the header and footer in, no.
My work/detail template:
Output of http://ee2.lippincott.loc/work/walmart?publisher_status=draft shows the draft content for {title}, but the published content for {cf_case_body}.
BoldMinded (Brian)
Yeah, I see that happening too.
Timothy Kelty
Just noticed the same thing is happening for different langauges for the same fields, I think.
I have a translation for: /offerings/ and when i view /zh/offerings/ I just get the english content.
However, for some fields, it is showing the zh content. If I put the {title} in the template, it’s showing the zh title.
BoldMinded (Brian)
Ok, I’ll dig into this tonight. I have another bug report of something similar.
BoldMinded (Brian)
can you do a test for me, on line 555 of ext.publisher.php add
return $results;
should be added just before this:
$lang_id = FALSE;
See if that does anything.
Timothy Kelty
It didn’t seem to have an effect.
HOWEVER - For the hell of it I switched the translation mode to production and things started working.
Drafts content started working with the fields it wasn’t working with! Translated content also started working for those fields too.
I want to leave it in development I think, though - as this site won’t be fully translated, I want it to fall back to english when zh not available.
BoldMinded (Brian)
That actually points me in the right direction, thanks for that report.
BoldMinded (Brian)
Turns out its an EE issue. https://support.ellislab.com/bugs/detail/19456
BoldMinded (Brian)
Tim, you may want to make these minor tweaks. Turns out the custom field save action was changed a bit in 2.6.
BoldMinded (Brian)
Ugh, that is messy. Try this instead: https://gist.github.com/litzinger/2dff8cbad4407648c65f
Timothy Kelty
That gist patch seems to do the trick.
BoldMinded (Brian)
Good to hear
BoldMinded (Brian)
Going to close things, sounds like its working for you, and I have this included in the next release.