Update scheduled status when it should

[aerni]

This PR takes another stab at updating the scheduled status of entries when the date is in the past. As discussed in this closed PR #4653.

Hope this is going in the right direction now. At least it feels better than before.

[jesseleite]

@jasonvarga, Does this status index conflict with the $entry->status() method available on entries?

[jasonvarga]

This index would be populated with exactly that - $entry->status() values.

[robdekort]

Oh my I wasn't aware of this issue since I use static caching mostly. But on this one site without, my scheduled entries wouldn't show. Pretty critical. Thanks for solving this Michael. I'd love to see it get merged :-).

[jasonvarga]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

[edalzell]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

If you're using eloquent, aren't all the queries done "live" so that the future posts would get captured by the usual query? i.e. this problem doesn't exist w the Eloquent driver?

[jasonvarga]

The status is still just sitting in a column. Something needs to update it.

I think the ideal solution would be to scrap the dedicated status value, and instead when you want to query for "published" entries, you would just do a more explicit query.

The status value takes into account all the scenarios - includes public/private future/past settings on the collection, etc.

Instead of doing ->where('status', 'published'), you'd do ->where('published', true)->whereDate('date', '<=', now()), etc. That way you're only ever querying values that wouldn't "become outdated".

This would be a much more far-reaching change though.

[aerni]

Are you saying that this can't be implemented without breaking changes?

[jasonvarga]

I think this PR will end getting merged and we'll have some alternate solution for Eloquent. But we want to have an idea before we push the button.

[jasonvarga]

Could you target 3.3 and merge 3.3 into this?

[buffalom]

This should include status 'published' so expirable items (as in they are hidden starting at the given date) get updated to status 'expired' as well. Something like this:

return ($value === 'scheduled' || $value === 'published') && $this->store->index('date')->get($id)->isPast();

[buffalom]

I've explained it in more detail in #2217 (comment).

[ryanmitchell]

Maybe this is the solution you already discounted, but we could drop the status column in eloquent-driver and if the column is status simply do the alternative query you mentioned (->where('published', true)->whereDate('date', '<=', now()))

[jesseleite]

This got mentioned again in Discord. Not sure @jasonvarga's current thoughts, but just a quick note that as this PR currently stands, it doesn't (yet) properly account for all four status possibilities as documented here...

[aerni]

I was just dealing with some caching invalidation questions regarding entry listings that kind of ties into this issue. I think it would be pretty nice if there was an EntryStatusChanged event that triggers whenever a status changes. This way, we can programmatically clear the cache when needed instead of relying on a scheduled command.

[jasonvarga]

That's what #5502 is essentially doing. You'd be able to see if the status is different.

[aerni]

As far as I understand, that PR is only useable in existing events like EntrySaved. I'm talking about an event that triggers when an entry status changes without the user's interaction to save an entry.

[jasonvarga]

If we could tell when an entry's status changes without user interaction, then we wouldn't have this issue to begin with.

[aerni]

Haha totally. What I'm trying to say. This PR here deals with stache invalidation. But there needs to be a way to ALSO invalidate the static cache when a status changes.

[jasonvarga]

I'm with ya

[jasonvarga]

Closing in favor of #8281. Give that a shot and see how it works for you.

[aerni]

This PR takes another stab at updating the scheduled status of entries when the date is in the past. As discussed in this closed PR #4653.

Hope this is going in the right direction now. At least it feels better than before.

[jesseleite]

@jasonvarga, Does this status index conflict with the $entry->status() method available on entries?

[jasonvarga]

This index would be populated with exactly that - $entry->status() values.

[robdekort]

Oh my I wasn't aware of this issue since I use static caching mostly. But on this one site without, my scheduled entries wouldn't show. Pretty critical. Thanks for solving this Michael. I'd love to see it get merged :-).

[jasonvarga]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

[edalzell]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

If you're using eloquent, aren't all the queries done "live" so that the future posts would get captured by the usual query? i.e. this problem doesn't exist w the Eloquent driver?

[jasonvarga]

The status is still just sitting in a column. Something needs to update it.

I think the ideal solution would be to scrap the dedicated status value, and instead when you want to query for "published" entries, you would just do a more explicit query.

The status value takes into account all the scenarios - includes public/private future/past settings on the collection, etc.

Instead of doing ->where('status', 'published'), you'd do ->where('published', true)->whereDate('date', '<=', now()), etc. That way you're only ever querying values that wouldn't "become outdated".

This would be a much more far-reaching change though.

[aerni]

Are you saying that this can't be implemented without breaking changes?

[jasonvarga]

I think this PR will end getting merged and we'll have some alternate solution for Eloquent. But we want to have an idea before we push the button.

[jasonvarga]

Could you target 3.3 and merge 3.3 into this?

[buffalom]

This should include status 'published' so expirable items (as in they are hidden starting at the given date) get updated to status 'expired' as well. Something like this:

return ($value === 'scheduled' || $value === 'published') && $this->store->index('date')->get($id)->isPast();

[buffalom]

I've explained it in more detail in #2217 (comment).

[ryanmitchell]

Maybe this is the solution you already discounted, but we could drop the status column in eloquent-driver and if the column is status simply do the alternative query you mentioned (->where('published', true)->whereDate('date', '<=', now()))

[jesseleite]

This got mentioned again in Discord. Not sure @jasonvarga's current thoughts, but just a quick note that as this PR currently stands, it doesn't (yet) properly account for all four status possibilities as documented here...

[aerni]

I was just dealing with some caching invalidation questions regarding entry listings that kind of ties into this issue. I think it would be pretty nice if there was an EntryStatusChanged event that triggers whenever a status changes. This way, we can programmatically clear the cache when needed instead of relying on a scheduled command.

[jasonvarga]

That's what #5502 is essentially doing. You'd be able to see if the status is different.

[aerni]

As far as I understand, that PR is only useable in existing events like EntrySaved. I'm talking about an event that triggers when an entry status changes without the user's interaction to save an entry.

[jasonvarga]

If we could tell when an entry's status changes without user interaction, then we wouldn't have this issue to begin with.

[aerni]

Haha totally. What I'm trying to say. This PR here deals with stache invalidation. But there needs to be a way to ALSO invalidate the static cache when a status changes.

[jasonvarga]

I'm with ya

[jasonvarga]

Closing in favor of #8281. Give that a shot and see how it works for you.

[aerni]

This PR takes another stab at updating the scheduled status of entries when the date is in the past. As discussed in this closed PR #4653.

Hope this is going in the right direction now. At least it feels better than before.

[jesseleite]

@jasonvarga, Does this status index conflict with the $entry->status() method available on entries?

[jasonvarga]

This index would be populated with exactly that - $entry->status() values.

[robdekort]

Oh my I wasn't aware of this issue since I use static caching mostly. But on this one site without, my scheduled entries wouldn't show. Pretty critical. Thanks for solving this Michael. I'd love to see it get merged :-).

[jasonvarga]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

[edalzell]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

If you're using eloquent, aren't all the queries done "live" so that the future posts would get captured by the usual query? i.e. this problem doesn't exist w the Eloquent driver?

[jasonvarga]

The status is still just sitting in a column. Something needs to update it.

I think the ideal solution would be to scrap the dedicated status value, and instead when you want to query for "published" entries, you would just do a more explicit query.

The status value takes into account all the scenarios - includes public/private future/past settings on the collection, etc.

Instead of doing ->where('status', 'published'), you'd do ->where('published', true)->whereDate('date', '<=', now()), etc. That way you're only ever querying values that wouldn't "become outdated".

This would be a much more far-reaching change though.

[aerni]

Are you saying that this can't be implemented without breaking changes?

[jasonvarga]

I think this PR will end getting merged and we'll have some alternate solution for Eloquent. But we want to have an idea before we push the button.

[jasonvarga]

Could you target 3.3 and merge 3.3 into this?

[buffalom]

This should include status 'published' so expirable items (as in they are hidden starting at the given date) get updated to status 'expired' as well. Something like this:

return ($value === 'scheduled' || $value === 'published') && $this->store->index('date')->get($id)->isPast();

[buffalom]

I've explained it in more detail in #2217 (comment).

[ryanmitchell]

Maybe this is the solution you already discounted, but we could drop the status column in eloquent-driver and if the column is status simply do the alternative query you mentioned (->where('published', true)->whereDate('date', '<=', now()))

[jesseleite]

This got mentioned again in Discord. Not sure @jasonvarga's current thoughts, but just a quick note that as this PR currently stands, it doesn't (yet) properly account for all four status possibilities as documented here...

[aerni]

I was just dealing with some caching invalidation questions regarding entry listings that kind of ties into this issue. I think it would be pretty nice if there was an EntryStatusChanged event that triggers whenever a status changes. This way, we can programmatically clear the cache when needed instead of relying on a scheduled command.

[jasonvarga]

That's what #5502 is essentially doing. You'd be able to see if the status is different.

[aerni]

As far as I understand, that PR is only useable in existing events like EntrySaved. I'm talking about an event that triggers when an entry status changes without the user's interaction to save an entry.

[jasonvarga]

If we could tell when an entry's status changes without user interaction, then we wouldn't have this issue to begin with.

[aerni]

Haha totally. What I'm trying to say. This PR here deals with stache invalidation. But there needs to be a way to ALSO invalidate the static cache when a status changes.

[jasonvarga]

I'm with ya

[jasonvarga]

Closing in favor of #8281. Give that a shot and see how it works for you.

[aerni]

This PR takes another stab at updating the scheduled status of entries when the date is in the past. As discussed in this closed PR #4653.

Hope this is going in the right direction now. At least it feels better than before.

[jesseleite]

@jasonvarga, Does this status index conflict with the $entry->status() method available on entries?

[jasonvarga]

This index would be populated with exactly that - $entry->status() values.

[robdekort]

Oh my I wasn't aware of this issue since I use static caching mostly. But on this one site without, my scheduled entries wouldn't show. Pretty critical. Thanks for solving this Michael. I'd love to see it get merged :-).

[jasonvarga]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

[edalzell]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

If you're using eloquent, aren't all the queries done "live" so that the future posts would get captured by the usual query? i.e. this problem doesn't exist w the Eloquent driver?

[jasonvarga]

The status is still just sitting in a column. Something needs to update it.

I think the ideal solution would be to scrap the dedicated status value, and instead when you want to query for "published" entries, you would just do a more explicit query.

The status value takes into account all the scenarios - includes public/private future/past settings on the collection, etc.

Instead of doing ->where('status', 'published'), you'd do ->where('published', true)->whereDate('date', '<=', now()), etc. That way you're only ever querying values that wouldn't "become outdated".

This would be a much more far-reaching change though.

[aerni]

Are you saying that this can't be implemented without breaking changes?

[jasonvarga]

I think this PR will end getting merged and we'll have some alternate solution for Eloquent. But we want to have an idea before we push the button.

[jasonvarga]

Could you target 3.3 and merge 3.3 into this?

[buffalom]

This should include status 'published' so expirable items (as in they are hidden starting at the given date) get updated to status 'expired' as well. Something like this:

return ($value === 'scheduled' || $value === 'published') && $this->store->index('date')->get($id)->isPast();

[buffalom]

I've explained it in more detail in #2217 (comment).

[ryanmitchell]

Maybe this is the solution you already discounted, but we could drop the status column in eloquent-driver and if the column is status simply do the alternative query you mentioned (->where('published', true)->whereDate('date', '<=', now()))

[jesseleite]

This got mentioned again in Discord. Not sure @jasonvarga's current thoughts, but just a quick note that as this PR currently stands, it doesn't (yet) properly account for all four status possibilities as documented here...

[aerni]

I was just dealing with some caching invalidation questions regarding entry listings that kind of ties into this issue. I think it would be pretty nice if there was an EntryStatusChanged event that triggers whenever a status changes. This way, we can programmatically clear the cache when needed instead of relying on a scheduled command.

[jasonvarga]

That's what #5502 is essentially doing. You'd be able to see if the status is different.

[aerni]

As far as I understand, that PR is only useable in existing events like EntrySaved. I'm talking about an event that triggers when an entry status changes without the user's interaction to save an entry.

[jasonvarga]

If we could tell when an entry's status changes without user interaction, then we wouldn't have this issue to begin with.

[aerni]

Haha totally. What I'm trying to say. This PR here deals with stache invalidation. But there needs to be a way to ALSO invalidate the static cache when a status changes.

[jasonvarga]

I'm with ya

[jasonvarga]

Closing in favor of #8281. Give that a shot and see how it works for you.

[aerni]

This PR takes another stab at updating the scheduled status of entries when the date is in the past. As discussed in this closed PR #4653.

Hope this is going in the right direction now. At least it feels better than before.

[jesseleite]

@jasonvarga, Does this status index conflict with the $entry->status() method available on entries?

[jasonvarga]

This index would be populated with exactly that - $entry->status() values.

[robdekort]

Oh my I wasn't aware of this issue since I use static caching mostly. But on this one site without, my scheduled entries wouldn't show. Pretty critical. Thanks for solving this Michael. I'd love to see it get merged :-).

[jasonvarga]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

[edalzell]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

If you're using eloquent, aren't all the queries done "live" so that the future posts would get captured by the usual query? i.e. this problem doesn't exist w the Eloquent driver?

[jasonvarga]

The status is still just sitting in a column. Something needs to update it.

I think the ideal solution would be to scrap the dedicated status value, and instead when you want to query for "published" entries, you would just do a more explicit query.

The status value takes into account all the scenarios - includes public/private future/past settings on the collection, etc.

Instead of doing ->where('status', 'published'), you'd do ->where('published', true)->whereDate('date', '<=', now()), etc. That way you're only ever querying values that wouldn't "become outdated".

This would be a much more far-reaching change though.

[aerni]

Are you saying that this can't be implemented without breaking changes?

[jasonvarga]

I think this PR will end getting merged and we'll have some alternate solution for Eloquent. But we want to have an idea before we push the button.

[jasonvarga]

Could you target 3.3 and merge 3.3 into this?

[buffalom]

This should include status 'published' so expirable items (as in they are hidden starting at the given date) get updated to status 'expired' as well. Something like this:

return ($value === 'scheduled' || $value === 'published') && $this->store->index('date')->get($id)->isPast();

[buffalom]

I've explained it in more detail in #2217 (comment).

[ryanmitchell]

Maybe this is the solution you already discounted, but we could drop the status column in eloquent-driver and if the column is status simply do the alternative query you mentioned (->where('published', true)->whereDate('date', '<=', now()))

[jesseleite]

This got mentioned again in Discord. Not sure @jasonvarga's current thoughts, but just a quick note that as this PR currently stands, it doesn't (yet) properly account for all four status possibilities as documented here...

[aerni]

I was just dealing with some caching invalidation questions regarding entry listings that kind of ties into this issue. I think it would be pretty nice if there was an EntryStatusChanged event that triggers whenever a status changes. This way, we can programmatically clear the cache when needed instead of relying on a scheduled command.

[jasonvarga]

That's what #5502 is essentially doing. You'd be able to see if the status is different.

[aerni]

As far as I understand, that PR is only useable in existing events like EntrySaved. I'm talking about an event that triggers when an entry status changes without the user's interaction to save an entry.

[jasonvarga]

If we could tell when an entry's status changes without user interaction, then we wouldn't have this issue to begin with.

[aerni]

Haha totally. What I'm trying to say. This PR here deals with stache invalidation. But there needs to be a way to ALSO invalidate the static cache when a status changes.

[jasonvarga]

I'm with ya

[jasonvarga]

Closing in favor of #8281. Give that a shot and see how it works for you.

[aerni]

This PR takes another stab at updating the scheduled status of entries when the date is in the past. As discussed in this closed PR #4653.

Hope this is going in the right direction now. At least it feels better than before.

[jesseleite]

@jasonvarga, Does this status index conflict with the $entry->status() method available on entries?

[jasonvarga]

This index would be populated with exactly that - $entry->status() values.

[robdekort]

Oh my I wasn't aware of this issue since I use static caching mostly. But on this one site without, my scheduled entries wouldn't show. Pretty critical. Thanks for solving this Michael. I'd love to see it get merged :-).

[jasonvarga]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

[edalzell]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

If you're using eloquent, aren't all the queries done "live" so that the future posts would get captured by the usual query? i.e. this problem doesn't exist w the Eloquent driver?

[jasonvarga]

The status is still just sitting in a column. Something needs to update it.

I think the ideal solution would be to scrap the dedicated status value, and instead when you want to query for "published" entries, you would just do a more explicit query.

The status value takes into account all the scenarios - includes public/private future/past settings on the collection, etc.

Instead of doing ->where('status', 'published'), you'd do ->where('published', true)->whereDate('date', '<=', now()), etc. That way you're only ever querying values that wouldn't "become outdated".

This would be a much more far-reaching change though.

[aerni]

Are you saying that this can't be implemented without breaking changes?

[jasonvarga]

I think this PR will end getting merged and we'll have some alternate solution for Eloquent. But we want to have an idea before we push the button.

[jasonvarga]

Could you target 3.3 and merge 3.3 into this?

[buffalom]

This should include status 'published' so expirable items (as in they are hidden starting at the given date) get updated to status 'expired' as well. Something like this:

return ($value === 'scheduled' || $value === 'published') && $this->store->index('date')->get($id)->isPast();

[buffalom]

I've explained it in more detail in #2217 (comment).

[ryanmitchell]

Maybe this is the solution you already discounted, but we could drop the status column in eloquent-driver and if the column is status simply do the alternative query you mentioned (->where('published', true)->whereDate('date', '<=', now()))

[jesseleite]

This got mentioned again in Discord. Not sure @jasonvarga's current thoughts, but just a quick note that as this PR currently stands, it doesn't (yet) properly account for all four status possibilities as documented here...

[aerni]

I was just dealing with some caching invalidation questions regarding entry listings that kind of ties into this issue. I think it would be pretty nice if there was an EntryStatusChanged event that triggers whenever a status changes. This way, we can programmatically clear the cache when needed instead of relying on a scheduled command.

[jasonvarga]

That's what #5502 is essentially doing. You'd be able to see if the status is different.

[aerni]

As far as I understand, that PR is only useable in existing events like EntrySaved. I'm talking about an event that triggers when an entry status changes without the user's interaction to save an entry.

[jasonvarga]

If we could tell when an entry's status changes without user interaction, then we wouldn't have this issue to begin with.

[aerni]

Haha totally. What I'm trying to say. This PR here deals with stache invalidation. But there needs to be a way to ALSO invalidate the static cache when a status changes.

[jasonvarga]

I'm with ya

[jasonvarga]

Closing in favor of #8281. Give that a shot and see how it works for you.

[aerni]

This PR takes another stab at updating the scheduled status of entries when the date is in the past. As discussed in this closed PR #4653.

Hope this is going in the right direction now. At least it feels better than before.

[jesseleite]

@jasonvarga, Does this status index conflict with the $entry->status() method available on entries?

[jasonvarga]

This index would be populated with exactly that - $entry->status() values.

[robdekort]

Oh my I wasn't aware of this issue since I use static caching mostly. But on this one site without, my scheduled entries wouldn't show. Pretty critical. Thanks for solving this Michael. I'd love to see it get merged :-).

[jasonvarga]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

[edalzell]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

If you're using eloquent, aren't all the queries done "live" so that the future posts would get captured by the usual query? i.e. this problem doesn't exist w the Eloquent driver?

[jasonvarga]

The status is still just sitting in a column. Something needs to update it.

I think the ideal solution would be to scrap the dedicated status value, and instead when you want to query for "published" entries, you would just do a more explicit query.

The status value takes into account all the scenarios - includes public/private future/past settings on the collection, etc.

Instead of doing ->where('status', 'published'), you'd do ->where('published', true)->whereDate('date', '<=', now()), etc. That way you're only ever querying values that wouldn't "become outdated".

This would be a much more far-reaching change though.

[aerni]

Are you saying that this can't be implemented without breaking changes?

[jasonvarga]

I think this PR will end getting merged and we'll have some alternate solution for Eloquent. But we want to have an idea before we push the button.

[jasonvarga]

Could you target 3.3 and merge 3.3 into this?

[buffalom]

This should include status 'published' so expirable items (as in they are hidden starting at the given date) get updated to status 'expired' as well. Something like this:

return ($value === 'scheduled' || $value === 'published') && $this->store->index('date')->get($id)->isPast();

[buffalom]

I've explained it in more detail in #2217 (comment).

[ryanmitchell]

Maybe this is the solution you already discounted, but we could drop the status column in eloquent-driver and if the column is status simply do the alternative query you mentioned (->where('published', true)->whereDate('date', '<=', now()))

[jesseleite]

This got mentioned again in Discord. Not sure @jasonvarga's current thoughts, but just a quick note that as this PR currently stands, it doesn't (yet) properly account for all four status possibilities as documented here...

[aerni]

I was just dealing with some caching invalidation questions regarding entry listings that kind of ties into this issue. I think it would be pretty nice if there was an EntryStatusChanged event that triggers whenever a status changes. This way, we can programmatically clear the cache when needed instead of relying on a scheduled command.

[jasonvarga]

That's what #5502 is essentially doing. You'd be able to see if the status is different.

[aerni]

As far as I understand, that PR is only useable in existing events like EntrySaved. I'm talking about an event that triggers when an entry status changes without the user's interaction to save an entry.

[jasonvarga]

If we could tell when an entry's status changes without user interaction, then we wouldn't have this issue to begin with.

[aerni]

Haha totally. What I'm trying to say. This PR here deals with stache invalidation. But there needs to be a way to ALSO invalidate the static cache when a status changes.

[jasonvarga]

I'm with ya

[jasonvarga]

Closing in favor of #8281. Give that a shot and see how it works for you.

[aerni]

This PR takes another stab at updating the scheduled status of entries when the date is in the past. As discussed in this closed PR #4653.

Hope this is going in the right direction now. At least it feels better than before.

[jesseleite]

@jasonvarga, Does this status index conflict with the $entry->status() method available on entries?

[jasonvarga]

This index would be populated with exactly that - $entry->status() values.

[robdekort]

Oh my I wasn't aware of this issue since I use static caching mostly. But on this one site without, my scheduled entries wouldn't show. Pretty critical. Thanks for solving this Michael. I'd love to see it get merged :-).

[jasonvarga]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

[edalzell]

FYI the delay on this is because it only solves the issue for the Stache. If you're using Eloquent for example, it won't have any effect. We wanted to think through it a little more.

But if you're wanting to use it, you can use a composer patch.

If you're using eloquent, aren't all the queries done "live" so that the future posts would get captured by the usual query? i.e. this problem doesn't exist w the Eloquent driver?

[jasonvarga]

The status is still just sitting in a column. Something needs to update it.

I think the ideal solution would be to scrap the dedicated status value, and instead when you want to query for "published" entries, you would just do a more explicit query.

The status value takes into account all the scenarios - includes public/private future/past settings on the collection, etc.

Instead of doing ->where('status', 'published'), you'd do ->where('published', true)->whereDate('date', '<=', now()), etc. That way you're only ever querying values that wouldn't "become outdated".

This would be a much more far-reaching change though.

[aerni]

Are you saying that this can't be implemented without breaking changes?

[jasonvarga]

I think this PR will end getting merged and we'll have some alternate solution for Eloquent. But we want to have an idea before we push the button.

[jasonvarga]

Could you target 3.3 and merge 3.3 into this?

[buffalom]

This should include status 'published' so expirable items (as in they are hidden starting at the given date) get updated to status 'expired' as well. Something like this:

return ($value === 'scheduled' || $value === 'published') && $this->store->index('date')->get($id)->isPast();

[buffalom]

I've explained it in more detail in #2217 (comment).

[ryanmitchell]

Maybe this is the solution you already discounted, but we could drop the status column in eloquent-driver and if the column is status simply do the alternative query you mentioned (->where('published', true)->whereDate('date', '<=', now()))

[jesseleite]

This got mentioned again in Discord. Not sure @jasonvarga's current thoughts, but just a quick note that as this PR currently stands, it doesn't (yet) properly account for all four status possibilities as documented here...

[aerni]

I was just dealing with some caching invalidation questions regarding entry listings that kind of ties into this issue. I think it would be pretty nice if there was an EntryStatusChanged event that triggers whenever a status changes. This way, we can programmatically clear the cache when needed instead of relying on a scheduled command.

[jasonvarga]

That's what #5502 is essentially doing. You'd be able to see if the status is different.

[aerni]

As far as I understand, that PR is only useable in existing events like EntrySaved. I'm talking about an event that triggers when an entry status changes without the user's interaction to save an entry.

[jasonvarga]

If we could tell when an entry's status changes without user interaction, then we wouldn't have this issue to begin with.

[aerni]

Haha totally. What I'm trying to say. This PR here deals with stache invalidation. But there needs to be a way to ALSO invalidate the static cache when a status changes.

[jasonvarga]

I'm with ya

[jasonvarga]

Closing in favor of #8281. Give that a shot and see how it works for you.