Entries sometimes won't publish

[tenmillionteeth]

Bug description

A client site has a collection of events. Since 4.58, sometimes when adding an event, then clicking save + publish, the entry doesn't publish. It seems to go into a draft state, despite not indicating that it's in a draft state. Clicking save + publish a second time then publishes the entry.

It was not an issue in 4.57.3, but every version since then it's a sometimes issue.

How to reproduce

Hard to recreate, because it doesn't happen every time. Nothing in the logs.

Logs

No response

Environment

Environment
Application Name:
Laravel Version: 10.48.12
PHP Version: 8.3.8
Composer Version: 2.7.6
Environment: production
Debug Mode:
URL: 
Maintenance Mode: OFF

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED

Drivers
Broadcasting: pusher
Cache: statamic
Database: mysql
Logs: stack / single
Mail: postmark
Queue: sync
Session: file

Statamic
Addons: 
Sites: 3 
Stache Watcher: Enabled
Static Caching: Disabled
Version: 5.7.2 PRO

Statamic Addons
4rn0/statamic-image-optimizer: 1.1.1
aerni/font-awesome: 2.1.0
anakadote/statamic-recaptcha: 1.0.14
aryehraber/statamic-color-extractor: 1.5.0
jacksleight/statamic-bard-texstyle: 3.2.2
mitydigital/feedamic: 2.3.3
rias/statamic-redirect: 3.7.1
statamic/collaboration: 1.0.0
statamic/seo-pro: 6.0.3
stillat/antlers-layouts: 2.1.0

Installation

Fresh statamic/statamic site via CLI

Additional details

No response

[duncanmcclean]

I can't see any changes in the v4.58.0 changelog that might be related to entries not publishing 🤔

Are you using revisions at all?

Hard to recreate, because it doesn't happen every time. Nothing in the logs.

Unfortunately, this doesn't give us much to go on. We haven't had reports of this issue from other users, could it be related to custom code in your project? Maybe a custom event listener?

[JesperFiltenborg]

I'm a very similar issue experiencing. Sporadically when I load the entry page and save a change it returns "unsaved changes" immediately but not every time. If i load the page without the issue a can save as many times as I want to without experiencing the issue, so it looks like a problem on the initial load of the entry.

I'm using the revisions. Statamic 4.58 and php 8.2 and laravel 10.

[tenmillionteeth]

This client isn't using revisions. The collection has no custom event listeners. Got some more info from client. The entry will appear in the listing on that initial save, but the route to the detail page doesn't render the template until they save it a second time.

Edit: It's an order-able collection, with dates. As far as we can tell, it's only happening in this one collection, but the other 26 collections aren't updated as frequently, so it could be happening there too.

[JesperFiltenborg]

@tenmillionteeth Are you using a multi-language site?

@duncanmcclean I've done a lot of testing, and i can disable revisions, which has no effect. I can reproduce the "draft state" concurrently when i switch between languages, so it looks like a localisation issue causing the "draft state" reappearing after save first time. If I save a second time the "draft state" does not appear. I've used the vue inspector on the "EntryPublishForm" and can see i hit the "draft state" due to the computed property isDirty being set to true after save. Note that the json data for the Entry does not change either between statamic version 3 and 4 (so that should not be the issue causing this).

Environment Application Name: Laravel Version: 10.48.12 PHP Version: 8.2.20 Composer Version: 2.7.7 Environment: local Debug Mode: ENABLED URL: .ddev.site Maintenance Mode: OFF

Cache Config: NOT CACHED Events: NOT CACHED Routes: NOT CACHED Views: CACHED

Drivers Broadcasting: log Cache: redis Database: mysql Logs: daily Mail: smtp Queue: redis Session: redis

Statamic Addons: 6 Antlers: runtime Sites: 2 (Danish, English) Stache Watcher: Disabled Static Caching: Disabled Version: 4.58.2 PRO

Statamic Addons doublethreedigital/duplicator: 4.0.1 jacksleight/statamic-bard-mutator: 2.3.0 pecotamic/sitemap: 1.4.6 statamic/eloquent-driver: 3.4.1

Statamic Eloquent Driver Asset Containers: file Assets: eloquent Blueprints: file Collection Trees: file Collections: eloquent Entries: eloquent Forms: eloquent Global Sets: eloquent Global Variables: file Navigation Trees: file Navigations: eloquent Revisions: eloquent Taxonomies: file Terms: eloquent

[tenmillionteeth]

@JesperFiltenborg We are using multi-site, yes.

[duncanmcclean]

Thanks all for the additional information, it sounds like it must be related to multisite.

However, I'm still not able to reproduce the issue on my end, on the latest version of Statamic. Is anyone able to replicate on a fresh site or share access to their project for us to take a look?

[tenmillionteeth]

@duncanmcclean Yes, would you prefer a user account created for you or a repository? I believe we're on 5.12. 5.13 yielded a different multisite issue where routing stopped working, so we downgraded.

[duncanmcclean]

Access to the repository would be great, thanks!

[tenmillionteeth]

Took some time off, and had another look at this. I was convinced it had to be something simple, as this is the only affected collection out of many across several sites.

If half-measure caching is enabled and the file watcher is disabled (as it is on production), the entry shows up in the listing of events, but the detail page either isn’t created or doesn’t exist. If file watcher was enabled, and caching is set to null, it works as expected. So I thought it was related to static caching invalidation not working correctly.

But no matter what I changed in those settings, nothing worked. And other collections behaved as expected.

So then I created a spreadsheet comparing the collection settings and route structures, etc. among all site collections. This one differs in two ways. One, it appended the date to the slug. Removing the appended date did not solve the issue.

Two, it's date-based but order-able. Disabling order-able in collection settings (which doesn’t seem to be necessary in this particular collection) actually fixes it. Unclear why that is the issue.

Happy to send over the repo if desired, but this seems to be fixed for me.