Our client has blog posts categorized as “Events” (with a slug of /events/). However, these are regular blog entries, not events managed by The Events Calendar plugin.

For instance, a post like this one: https://example.com/events/hello-world/ gets unpublished (reverted to draft) automatically after about 20 hours. This suggests a conflict with the plugin, which might be expecting actual event listings in the “Events” category.

Can you confirm if The Events Calendar plugin might be causing this automatic draft reversion because of the “Events” category being used for blog posts?

My broken link checker also filled up with links from posts I archived, Im guessing because the scanner doesn’t have access to read private posts? Google bot will have the same problem I guess? I’m talking to the plugin devs to help me add code as a workaround, I’m just curious about search engine bots.

Thank you!

To replicate this issue, do the following:

1. Register a custom post type without support for title nor the editor.
2. Add a meta box to the custom post type with one or more custom fields.
3. Create a new post with the registered CPT.
4. Click publish.

The environment I’m working on is:

• WP version 6.4.3
• OS: Windows 10 Home Edition
• WP is run on Local by Flywheel version 8.2.1

These are the troubleshoot steps that I’ve taken so far:

• Created a new site on Local with zero plugins besides the one I’m developing, restricting the behavior of the plugin to that of only registering the CPT with no support for title nor the editor. The theme that was used for testing is Twenty-twenty-four.
• Erased browser cookies (Brave) and cleared the cache.
• Turned off and on the computer (just in case).
• I installed the previous version of WordPress in which I am 100% sure that my plugin used to work, which is 6.3.1. I did this in Local.
• I installed the previous version of Local in which I am 100% sure that my plugin used to work, which is 7.1.2.
• I setup a testing server with XAMPP, I manually downloaded the WP version 6.3.1 and installed it there.
• I tried with Chrome, Firefox, and Edge (besides Brave).

The behavior in all the different environments was the same, the CPT Post with no support for title no editor is saved as “draft” when I click “Publish” and it’s impossible to change the status to “publish” by clicking “Publish”.

I currently don’t have access to a different Computer or OS.

There are some things that I found out though:

1. When I click “Publish”, the parameter post_status is sent as “draft”.
2. If I add title and editor support to the CPT, but set show_in_rest as false, once the post is saved as “draft”, and add a title and some text to the editor, the post isn’t published when I click “Publish”, the status “draft” remains.
3. If I set show_in_rest as true, once the post is saved as “draft”, then the post can be published, changing its status to “publish” once I click “Publish” (with title and editor support).

The only way in which I can change the status to “publish” once the post is saved as “draft” without adding support for the editor and not showing in rest is by doing this:

1. Set the status to “Pending Review” from the dropdown in the submit box in the post editing screen.
2. On the list of posts, click “Quick Edit” and choose the status of “Scheduled” from the dropdown menu.
3. Click “Update”.

I’m doing all of this using the Admin user.

I guess it may have to do with some recent update in Gutenberg that I’m not aware of, given that I tried an old version of WP (6.3.1) and the most recent one (6.4.3) that comes bundled with Local, and in both cases, the result is the same.

https://www.ads-software.com/plugins/publishpress-statuses/
https://www.ads-software.com/plugins/edit-flow/

This plugin is conflicting with them by registering an action handler to the filter “edit_post_status”

The offending code is in lib\ShortPixel\CriticalCSS\Admin\UI\Term.php, line 33:

<span style="color: #dcdcaa;">add_action</span><span style="color: #d4d4d4;">( </span><span style="color: #ce9178;">"edit_{</span><span style="color: #9cdcfe;">$tax</span><span style="color: #ce9178;">}"</span><span style="color: #d4d4d4;">, [? ? </span><span style="color: #569cd6;">$this</span><span style="color: #d4d4d4;">,? ? </span><span style="color: #ce9178;">'save_manual_css'</span><span style="color: #d4d4d4;">,] );</span>

This should be preceded by a safeguard like this:

$post_fields = ['post_author', 'post_date', 'post_date_gmt', 'post_content', 'post_title', 'post_excerpt', 'post_status', 'comment_status', 'ping_status', 'post_name', 'to_ping', 'pinged', 'post_modified', 'post_modified_gmt', 'post_content_filtered', 'post_parent', 'guid', 'menu_order', 'post_type', 'post_mime_type', 'comment_count'];

if (in_array($tax, $post_fields)) {
   continue;
}

Another way you could avoid this conflict is by hooking to the “edit_term” action instead of “edit_{$taxonomy}”.

Without one of these changes, the only alternative for affected plugins is to bypass this code block completely by filtering your “shortpixel_critical_css_manual_term_css” to false.

After further investigations, I found 2 more orders (out of 500+) with a similar issue.

What could have caused the DB entry to be written incorrectly?

I’m using your Notification plugin to manage the editorial workflow for our online sports media website, Detroit Sports Nation. We have a team of writers and editors, and we’re trying to streamline our process by sending notifications at various stages of article development.

We’re using custom post statuses provided by the PublishPress Planner Pro plugin. The statuses we use are: Pitch, Assigned, In Progress, Draft, Pending Review, Scheduled, and Published.

I’ve tried adding these custom statuses to the Notification plugin by modifying our theme’s functions.php file, using the notification/trigger/wordpress/post/updated/statuses filter as per your documentation. Here’s the code snippet I used:

add_filter( 'notification/trigger/wordpress/post/updated/statuses', function( $statuses, $post_type ) { $statuses[] = 'Pitch'; $statuses[] = 'Assigned'; $statuses[] = 'In Progress'; $statuses[] = 'Draft'; $statuses[] = 'Pending Review'; $statuses[] = 'Scheduled'; $statuses[] = 'Published'; return $statuses; }, 10, 2 );

However, I’m unable to trigger notifications when the post status changes. Could you please guide me on how to correctly set up the plugin to send notifications based on these custom post statuses?

Thank you for your time and assistance.

Switching to draft from the page or post editor does work. Very strange.

get_post_status ( ID );
get_post_status ( $Post );

Even the post has a Draft status, get_post_status() return publish.

I downgrade to the V6.1.1 and get_post_status() return the right status.

I Google around for answers and I find threads where moderators says that WooCommerce doesn’t create auto-draft orders. But it does. And no, it’s not created by any plugin. I have tried deactivating plugins and it still creates auto-draft orders. And no it’s not checkout-draft orders. These are ‘auto’draft’ orders, I have looked in the database.

Most annoying is that it’s not possible to list all the drafts and delete them.

The best would be if the auto-draft is created when a order row or item is created, anything with connection to the order. But not just by visiting the Add Order page. And then I would of course like to be able to list all the drafts to be able to delete them.