Save draft disappears

same here.

It doesn’t disappear, you just don’t have a separate button to save draft anymore.

But you can still save as a draft just by selecting the draft status in the dropdown (it should default to draft initially anyway) and saving it. This is simply how the plugin works

I am resolving this for good order, but will still monitor the thread

I have 6.1.1 and both the Save Draft button AND the Draft Status Dropdown disappeared.

I deactivated the plugin and only the Save Draft button returned.

(Posting this in an attempt to help. I really enjoy / appreciate the plugin!)

I’m confused. There is no such thing as a save draft dropdown. Once the plugin is active there should be both a:

1. A status drop-down that should contain all the potential statuses e.g. publish, private, draft, pending, archive
2. A save button with which you can save whatever changes you’ve made (including a change of post status.

The above is the expected behaviour. If this is not the case I’m happy to investigate (noting I’m not seeing any problem ms on my own sites).
if this is the behaviour though there is no issue.

Hi there, I just installed this plugin and archived a ton of posts which is great however I am having this same issue. There is not option to save as a draft inside a post. There is a drop-down when using quick edit in the list view but no option inside the actual post. Current workaround is I have to “update” the post which publises it then change it to draft from the quick edit list view. This is obviously not ideal and creates broken links.

Are you able to assist? I can send screen shot if it helps. Im hoping there is a quick fix other wise I have to undo all the work I did to archive the posts and then uninstall the plugin.

More to this. I see the status option with some posts however the issue seems to be if scheduling is used. Even if schedule is removed, the status drop down is gone and replaced with Next status will be “Publicly published” once the scheduled date will be reached.

This appears even if the date is in the past and there is no way to clear that thus the work around mentioned above.

are you talking about the message:

Next status will be “Publicly published” once the scheduled date will be reached.

?

That appears when a future date is used and removes the post status dropdown

Hi! This is a great plugin, but I’m having the same issue. To answer your last question from my perspective: yes, there is a “Next status…” message even though I never opted to use scheduling. When I create a new page or post, an Auto Draft is immediately created, the page or post is titled “Auto Draft”, next to “Publish” in the summary, it puts the time at which the page or post was initially created, and the status dropdown is not visible.

Let me echo @mkonji’s worries (and of the others as well). Aye, I have experienced the same behaviour as them — and, frankly, I don’t like it at all.

In your documentation (both formal and informal) you always state that “this plugin does only X; use something else if you wish more” — a minimalist approach to WP plugins which I personally like a lot.

Nevertheless, this plugin introduces a new workflow for starting to write a new post and classifying it properly for publishing. Pages and Posts now start with a default article title — which may be confusing if two authors are both creating a new article at the same time (it happens… especially when it takes some time writing them, and one author may just have the page for their new post open for hours — while doing other chores — and the other has just starting to edit what they believe is a new, unique page).

And there is this slightly misleading message “Next status will be “Publicly published” once the scheduled date will be reached.”, when the status of the post/page is either Draft and the author doesn’t intend to publish it on a future date, but rather do it now (sometimes, after publishing, the message persists, at least for a few times — it could be just an issue with the object cache — until it finally disappears; but by then it’s not obvious how to revert the status to Draft). And, of course, now there is no way to publish the post privately (or use any of the other possible status), since the dropdown allowing that is gone (at least until the post gets saved — and thus publicly published — which can then be immediately reverted to ‘private’ — and, with luck, nobody will have noticed it).

Here is a snapshot with comments. I’m well aware that I have tons of plugins running on this particular instance of WP; but rest assured, I did experiment it on a ‘blank’ installation (done from scratch), I just forgot to take a snapshot then.

In other words — it’s irrelevant if the actual mechanism is “not much different than it was before”, or even “the new mechanism is actually better than the default one”. The point here is that this new mechanism is included in an otherwise unrelated functionality, and there is no way to override it easily, and revert to the old, standard way of dealing with new posts/articles. In other words, I’m sure that you had the best intentions in changing something because, for you, the defaults are not ok (for some reason only known to you).

This is the kind of thing that should be best delegated to a separate plugin altogether. It doesn’t make any sense to do it otherwise — especially if there is no way of turning it off!

Granted, I’m also fully aware that it might take a lot of work to ‘disable’ that bit of code, while keeping the plugin as fully operational as before. I admit I haven’t looked at your code (yet!) so I have no idea how hard that is to do.

Mostly my point here is that you’re very consistent in your overall approach to the plugin design and have clearly stated that several times. It’s just in this specific case that you have departed from your usual standard, and I guess that’s the reason why we feel compelled to comment here ??

To simplify plugin is actually three parts

1. My original plugin which only supported the classic editor
2. a library I have integrated called wp statuses that enables the gui for custom post statuses in the block editor (Gutenberg). Written by @imath
3. Some other functionality I’ve added

The issues you’ve raised both relate to to the library (2). And I’ve raised both with the author

His response on the first was:

Unfortunately this is a downside of the lack of extensibility of the Block Editor, to be sure to get the update button, I need to use another field to save the status to use and force the WordPress status to be private. Otherwise you get the Publish button and you cannot customize the post status.

So basically the first issue can’t be fixed for now until core improves the the block editor (classic should work fine). I agree it’s annoying

Ive followed my previous post up on the second issue (ie the inability to set any other status than scheduled for publish dates in the future) on GitHub with the library author and see what he comes up with.

Well, that is annoying: by saying that the “issue can’t be fixed for now until core improves the block editor”, you mean that this requires Automattic to change their code on the Gutenberg block editor so that your plugin (and @imath’s library) work again?

I’m sorry — but I don’t believe that is going to happen. Unless there is a serious bug in the WP core code — and I haven’t checked — why should Automattic change their code just for @imath’s sake? I cannot understand that.

I understand that you’re more familiar with the classic editor. So am I; I gave up trying to get a setup to work with the block editor, but, then again, I’m not a professional programmer. I fully understand that there are now new levels of complexity just to get anything to work with the block editor. Unfortunately (for all of us), our own users couldn’t care less. For them, adding the Archive functionality (which they need) means having a broken workflow (which is unacceptable).

A workaround is required. Again, I do understand that you cannot do anything except rely on @imath to fix the library. And I also understand that @imath is waiting for Automattic to change their code. That’s all very fine, but it’s the kind of answer that I cannot give to my users. They want to know when their workflow is restored to ‘normal’, i.e. back to what it was before.

It’s really a pity — as said, I love your minimalist approach to do one thing, and do one thing right — but it really seems that I will need to find an alternative. Anything is better than having a broken workflow from the perspective of the end users — even if that means forgetting all about the Archive (at least for now).

Again, as said, I wish I were an expert in WP plugin development, but I’m not. Nevertheless, I will take a look at both your code and @imath’s, and try to understand if there is anything I can do with it — salvage the best parts, get rid of the things that break everything — but possibly this means searching for an alternative, or creating my own: I don’t really need anything fancy, just guarantee that nothing breaks the user’s posting workflow.

Which is truly a pity. As said — and I’m happy to repeat it — your plugin comes as highly recommended by many authors. It implements functionality that WP should have had at its core. It strictly adheres to WP’s coding standards. It does one thing, and does one thing well. It’s well maintained, and the support forum is helpful. Few plugins can claim the same. But breaking the posting workflow is, unfortunately, a non-starter.

There are two issues

The first issue with ie “auto draft” is (according to imath) an unavoidable issue with the current state of the block editor.

The second is the lack of any other status than scheduled when a future post date is set on the block editor . I’m yet to hear back from imath on that one

Imath wp-status library is used for all UI in the block editor for my plugin. I don’t know enough react to look at the issue myself and so best for both of us to follow the issues on github (search wp-statuses Imath) but if you can find workarounds let me know and I’ll look at incorporating them

Sorry for just reporting now.

Like you, I’m afraid I’m not a React expert (not even a PHP expert, at that), so all I could do was to take a look at the information I could find on this subject.

Needless to say, when I saw that the ticket regarding the WP statuses is… 13… thirteen… years old, well… it’s absolutely obvious to me that it won’t. Ever. Be. Fixed.

In fact, one the developers even hinted at that, commenting on someone else’s comment regarding the time that took to fix a CMS to do something all CMS must do, namely, deal with publishing workflows. The answer was simple — this requires updating things at the core, because, well, nobody ever thought that it would be ‘important’ to deal with custom post status, and formally define an API for it, and then, when that was ready, they could change the Gutenberg editor to use that to figure out what the post/page status currently is and display things properly — without the need of using @imath’s ‘fix’.

But after reading all of those threads — or, well, at least the main ones — it’s quite clear to me that this is going to be one of those ‘developer stubbornnesses’. They don’t want to touch the post statuses, because that will take them a lot of work, just to get a handful of people happy. And they have supervisors, team managers, and ultimately, Matt sitting at the top and asking: ‘why are you wasting so much time and effort on that?’ And so… they prefer to get a handful people angry, but, after a decade or two, they know that those people will go away, change CMS, change the company they work for, lose the client they had who needed post statuses, well, one of the above, or even all together, and with a bit of patience and stubbornness, they will just close the ticket due to ‘lack of interest’ and nobody will bother them any longer with this issue (in fact, on the WP GitHub mirror, they already attempted to do just that, a few years ago).

So, it’s a pity, and I appreciate both your effort and @imath’s workaround, but clearly this approach, for all its elegance, will never have any chance of success, not in the foreseeable future at least. In fact, this is the kind of thing that is more likely to be deprecated in WordPress than worked upon: i.e. they will just suggest that people implement workflows using either new taxonomies, specifically designed for that purpose, or to use meta tags to flag posts as being archived, and just manually update all queries to look up the meta tag first before including a post in the loop…

I believe this is the current approach being used by those plugins which provide workflow functionality — they simply sidestep the issue and build a ‘post_status replacement’ ecosystem.

So, it seems that this the only option I have right now. I wish you and @imath the best of luck, but it seems that this is going to take a long, long time to get implemented by Automattic. And obviously it’s not acceptable to have a change of workflow during the time we wait for a solution from Automattic — one that might never happen, after all. In other words: if it were something simple to fix, it would have been fixed 13 years ago. As it stands, and this is by admission of the developers themselves, there is a lot of new functionality that has been added to Gutenberg and the REST API, and, the more time passes, the more things need to be changed, the harder it gets, and the more time (and human resources) will be required to change anything.

In short: it’s hopeless. I’ll have to find a completely different alternative, then. I’m sorry for the time you spent answering my questions. I wish you the best of luck to the LocalHero project.

Gwyneth,

you are conflating a few different but related problems

firstly WordPress support for registering custom post statuses. Yes this has been outstanding for 13 years. But it’s quite easy to work around this on the classic editor. My plugin did and still does this using vanilla JavaScript and jquery.

However the block editor is uses react. My plugin did not support the block editor at all until I integrated imaths wp-status library. However as you pointed out there are two issues which do not currently work on the block editor

The auto draft problem. According to imath this is an issue with the block editor itself (which is now part of core). There is no fix via the library atm until block editor specific changes are made in core.

The inability to set draft, pending etc statuses on posts with future publish dates. The only post status available being scheduled. Imath has yet to respond on whether there is a library specific fix possible for that. I first raised that issue in February and followed up last week. I suspect that issue is library specific but I’m only guessing.

I suggest you look annd/or follow up the issues I raised on GitHub for the wp-status library. You’ll see it all there and additional follow might help clarify the second issue further. I know imath is busy atm with buddypress (as I am). But “The squeaky wheel gets the grease” as they say!

I will immediately incorporate any library updates into the plugin but as Im a php and vanilla is guy so I’m not going to spend days pondering react as this plugin currently works for my purposes.