All add-ons currently require PHP 7.4 or greater.
On July 4th 2024 PHP 8.2 will be the new minimum requirement for all add-ons. Expect any add-on released after that date to require 8.2 or greater. Some releases may not immediately take advantage of 8.x specific features in PHP, which means you might, be able to continue using new releases in PHP 7.4, however, if you experience an error the first thing you should do is update to PHP 8.2 then create a support ticket if the error persists.
Please read about the changes to BoldMinded add-on licensing.
Ticket: Creating a new entry as draft fails to save Entry Status field causing error on second save
| Status | Resolved |
| Add-on / Version | Publisher 3.3.1 build 4ab17f4b |
| Severity | |
| EE Version | 6.0.6 |
Paul Nash
Jul 07, 2021Steps to recreate:
1) Go to create new entry
2) Select save as draft
3) give the entry an Entry Status
4) click save draft and preview
5) after closing preview, edit something and try to click save
! validation error
After the entry is first saved as draft only, the Entry Status is not set to anything, it should be what was selected before the first save.
After setting the field to correct the validation error & saving, it remembers the Entry Status without needing a published state, so it’s related to the initial saving as draft.
No errors observed on channels that have the Entry Status hidden via the channel layouts.
Paul Nash
Comment has been marked private.
BoldMinded (Brian)
Thanks for the video. Will try to take a look at this tonight or tomorrow.
BoldMinded (Brian)
Comment has been marked private.
Paul Nash
This only partially fixes one area while breaking another, but also raises a question. (the break may have appeared on another build but only noticing now)
Bugs: 1) changing entry status on draft seems to change entry status on published? (and reverse is true) 2) not sure if this is a mix of EE bug and publisher bug, but I have an entry that won’t preview if I only enter numbers in the title/url_title fields … as soon as I prepend with a letter, the previews work (unlikely to happen but could do with fixing if it is Publisher related; i was spamming characters to test quickly). Additionally, the “save and preview” preview pop up doesn’t work until changing the url title and saving the published entry. I believe the second part at least is a publisher bug? 3) we appear to have at least one channel where previews will not work until saving a published state. Comparing against a working channel: preview templates both have publisher:entry_status in the channel entries tag. In fact on the channel where they’re not working correctly, i’ve tried ripping the template all the way back to a static empty page & the preview in the admin is still showing an unrelated page. I’ve checked the channel settings and the publisher preview settings to make sure nothing points to the unrelated page but I have no idea how it’s getting to that. 4) we have channels with the status field hidden via channel layouts: these never get set to open when saving as published? Changing channel layout to show the field and then viewing published version shows ‘Draft’ in the entry status. Ideally these would remain as open throughout? The channel in question are pages that arent automatically linked to and don’t really need a hidden/closed/preview state other than the draft/published states Publisher gives.
Question: If i’m creating a new entry and set my entry status to a custom one or closed and then save as draft, it overrides that and saves with a Draft status: is this correct? If i then publish that item, it ignores my initial choice and changes to Open: is that correct? Do I have to retrain users to always check that status before saving as published?
After initial save as draft, I seem free to go back in and change status to Closed and that will save as draft without changing the entry status field back to ‘Draft’? I’d assume if that’s allowed, it should also honor my setting on initial draft save?
I will follow up with a video or two to help.
Paul Nash
Comment has been marked private.
BoldMinded (Brian)
Thanks for the info. Based on everything you described this sounds like it’s going to take some time to look into… and it may be a few days or a couple weeks before I can find that amount of time :/
BoldMinded (Brian)
1) is not a bug. If you save an entry as Published, it sets the entry’s status to Open. That is working as expected. If you want to keep it in Draft status, you have to continue to save as Draft.
2) I don’t know of anything in Publisher that cares about integer value only url titles. Remove the rows in the exp_publisher_draft_previews table and try it again. See if that makes any difference.
3) You said “previews won’t work” - which preview? Publisher’s draft preview or EE’s native Live Preview? Clarify “won’t work” too, because I see content every time you do a preview. Is it showing the wrong content? If the content is wrong, what is wrong about it? Is it showing an entirely different entry? It’s also a little hard to diagnose this because I can’t see your control panel settings. In the 2nd video it looks like its not loading the correct entry (or correct template), which may or may not be a Publisher issue depending on your template code. Again, it’s hard to tell without seeing the Publisher and EE settings.
Is this an environment you can share CP, and potentially FTP access to so I can take a look? You’re describing several different issues and it’s getting a bit confusing. When you’re doing a Publisher Draft Preview, make sure EE’s output profiler and template debugger is enabled so you can see what template it is wanting to load.
Paul Nash
Comment has been marked private.
BoldMinded (Brian)
So for the Status field thing… if I’m understanding this correctly… it appears that in the scenario that Publisher is not installed (normal EE install), and you hide the Status field, you can never change the status when an entry is saved. So what is the purpose of hiding the field, and why should Publisher be responsible for counteracting/fixing the current behavior? To be honest this is the first time I’m aware of someone wanting to hide the Status field. It seems counterintuitive to me.
BoldMinded (Brian)
Comment has been marked private.
Paul Nash
On my temporary dev install, there was a Javascript error the first time I clicked “save draft & preview” which prevented the preview from showing and prevented the publisher tab from hiding, but it has not re-occured after that first time and only occured on that install. “Uncaught TypeError: Publisher.showRevisionTranslations is not a function” was the error in the console.
On both my local copy of the live site and the temporary dev install I am seeing a Javascript/JSON error in the console after “save draft & preview”, but the preview overlay still opens correctly …. I’m not seeing it on a staging site with previous build:
https://download.fifty50.co.uk/publisher/EE_Publisher_JS_error.png Uncaught SyntaxError: Unexpected token < in JSON at position 0 at JSON.parse (<a>) at Function.n.parseJSON (jquery.js?v=1624450091:4) at Object.success (publisher.js:213) at i (jquery.js?v=1624450091:2) at Object.fireWith [as resolveWith] (jquery.js?v=1624450091:2) at z (jquery.js?v=1624450091:4) at XMLHttpRequest.<a> (jquery.js?v=1624450091:4)
Is there any other information I can grab which would help debug remotely? I can package up this test install and send if needed.
Thank you for looking into this, it’s much appreciated, hopefully the below helps explain why we have hidden fields.
We use the channel layouts to ensure less technical users only see the parts of the entry we want them to edit. In this case we still want them to be able to publish a change without needing to even see the built in Status field (more steps to follow = more support required). Not relevant but worthing noting that if EE allowed it, we would also hide date and url title on channels where they aren’t output on the front end.
The view/save-as drop downs from publisher provide enough functionality to allow preview before publishing live without touching the Status field. Also, for less technical users it becomes confusing explaining the difference between the drop downs “published/draft” and entry status “open/draft/closed”
This is why I was also asking if there was a way to configure/disable the Entry Status field changing on save as published, since that happening means in some channels we have to train the editors of those channels into taking an extra step/change after save (more steps to follow = more chances to break something).
BoldMinded (Brian)
I’ll take a look at the JS error. I won’t be changing the behavior of how the entry status field works. There are hooks in the Publisher code to modify the display and behavior of those fields. You might be able to use those hooks to do what you’re looking to do.
BoldMinded (Brian)
Publisher.showRevisionTranslations is a newly added feature which I’ve tested in 2 different environments and it works as expected. Can you share more details on what you’re doing when you get the error? Another video perhaps? Are you 100% sure you installed all the theme files correctly and have cleared your browser cache?
Paul Nash
Comment has been marked private.
BoldMinded (Brian)
Comment has been marked private.
Paul Nash
This build fixes the javascript error seen in the console, thanks.
Question: when is 3.4.0 due for release? Is it safe to deploy this, or is there a chance of more update scripts being added between now and then (that would get missed when I upload 3.4.0 in the future)?
BoldMinded (Brian)
I”m probably going to release it (the version you have) very soon… just need to get around to doing it. Probably in the next few days.