[5.x] Avoid querying status

[jasonvarga]

Closes#2217

The issue

When you have a collection with date behaviors like a typical blog with scheduled posts (past dates are visible, future dates are not) whenever the current time ticks over the scheduled date, the entry would not be displayed.

This is because we were filtering by "status" in order to prevent drafts from being displayed by default.
The future dated entries have a status of "scheduled", and they get stored in the Stache index (or even in the database table if using the Eloquent driver). When the time ticks over the publish date, there's nothing that would update the indexed status, so the entry would continue to be filtered out.

The solution

This PR reworks logic so that we don't ever query status, as it would never automatically update. We would only query by date logic plus whether the entries are published.

Thinking of it more like a traditional database, you're currently querying status as if it were a column.
With this PR, consider the column gone, and to query by "status" it would really be a more complex query scope.

Breaking changes

In this PR, there should be none. However there will be some for v6 in a separate PR.

At the moment, you can still use all the condition types in your tag or API requests, e.g. status:in="draft|published" or status:not="whatever". It'll query against the stored value like it always did, but you may continue to run into the scheduling bug.

In v6, those will cause exceptions. Similar to if you were to query a missing column in a database you'd get Column [status] not found. In v6 you'll need to use whereStatus.

In v6, you'll only be able to query single statuses. I believe you only ever used the more complex operators to get around issues. I could be wrong! If that's the case and people really need them, we can add them back by making whereStatus smarter, or adding whereStatusIn, etc.

Todo

• Replace any instances of querying by status
• In REST API
• In GraphQL
• Possibly add some sort of deprecation warning when querying by status
  For this PR, it logs a deprecation message. In v6, it'll throw an exception.
• Possibly add backwards compatibility for querying by status.
  It's backwards compatible for now because the existing (sometimes broken) behavior will remain unchanged.
• In a breaking release of eloquent driver, remove the status column. (Drop status on entries eloquent-driver#228)

By the way

This doesn't address the issue where a listing should get updated while using static caching.

That's solvable using https://statamic.com/addons/mity-digital/scheduled-cache-invalidator

[jasonvarga]

Closes#2217

The issue

When you have a collection with date behaviors like a typical blog with scheduled posts (past dates are visible, future dates are not) whenever the current time ticks over the scheduled date, the entry would not be displayed.

This is because we were filtering by "status" in order to prevent drafts from being displayed by default.
The future dated entries have a status of "scheduled", and they get stored in the Stache index (or even in the database table if using the Eloquent driver). When the time ticks over the publish date, there's nothing that would update the indexed status, so the entry would continue to be filtered out.

The solution

This PR reworks logic so that we don't ever query status, as it would never automatically update. We would only query by date logic plus whether the entries are published.

Thinking of it more like a traditional database, you're currently querying status as if it were a column.
With this PR, consider the column gone, and to query by "status" it would really be a more complex query scope.

Breaking changes

In this PR, there should be none. However there will be some for v6 in a separate PR.

At the moment, you can still use all the condition types in your tag or API requests, e.g. status:in="draft|published" or status:not="whatever". It'll query against the stored value like it always did, but you may continue to run into the scheduling bug.

In v6, those will cause exceptions. Similar to if you were to query a missing column in a database you'd get Column [status] not found. In v6 you'll need to use whereStatus.

In v6, you'll only be able to query single statuses. I believe you only ever used the more complex operators to get around issues. I could be wrong! If that's the case and people really need them, we can add them back by making whereStatus smarter, or adding whereStatusIn, etc.

Todo

• Replace any instances of querying by status
• In REST API
• In GraphQL
• Possibly add some sort of deprecation warning when querying by status
  For this PR, it logs a deprecation message. In v6, it'll throw an exception.
• Possibly add backwards compatibility for querying by status.
  It's backwards compatible for now because the existing (sometimes broken) behavior will remain unchanged.
• In a breaking release of eloquent driver, remove the status column. (Drop status on entries eloquent-driver#228)

By the way

This doesn't address the issue where a listing should get updated while using static caching.

That's solvable using https://statamic.com/addons/mity-digital/scheduled-cache-invalidator

[jasonvarga]

Closes#2217

The issue

When you have a collection with date behaviors like a typical blog with scheduled posts (past dates are visible, future dates are not) whenever the current time ticks over the scheduled date, the entry would not be displayed.

This is because we were filtering by "status" in order to prevent drafts from being displayed by default.
The future dated entries have a status of "scheduled", and they get stored in the Stache index (or even in the database table if using the Eloquent driver). When the time ticks over the publish date, there's nothing that would update the indexed status, so the entry would continue to be filtered out.

The solution

This PR reworks logic so that we don't ever query status, as it would never automatically update. We would only query by date logic plus whether the entries are published.

Thinking of it more like a traditional database, you're currently querying status as if it were a column.
With this PR, consider the column gone, and to query by "status" it would really be a more complex query scope.

Breaking changes

In this PR, there should be none. However there will be some for v6 in a separate PR.

At the moment, you can still use all the condition types in your tag or API requests, e.g. status:in="draft|published" or status:not="whatever". It'll query against the stored value like it always did, but you may continue to run into the scheduling bug.

In v6, those will cause exceptions. Similar to if you were to query a missing column in a database you'd get Column [status] not found. In v6 you'll need to use whereStatus.

In v6, you'll only be able to query single statuses. I believe you only ever used the more complex operators to get around issues. I could be wrong! If that's the case and people really need them, we can add them back by making whereStatus smarter, or adding whereStatusIn, etc.

Todo

• Replace any instances of querying by status
• In REST API
• In GraphQL
• Possibly add some sort of deprecation warning when querying by status
  For this PR, it logs a deprecation message. In v6, it'll throw an exception.
• Possibly add backwards compatibility for querying by status.
  It's backwards compatible for now because the existing (sometimes broken) behavior will remain unchanged.
• In a breaking release of eloquent driver, remove the status column. (Drop status on entries eloquent-driver#228)

By the way

This doesn't address the issue where a listing should get updated while using static caching.

That's solvable using https://statamic.com/addons/mity-digital/scheduled-cache-invalidator

[jasonvarga]

Closes#2217

The issue

When you have a collection with date behaviors like a typical blog with scheduled posts (past dates are visible, future dates are not) whenever the current time ticks over the scheduled date, the entry would not be displayed.

This is because we were filtering by "status" in order to prevent drafts from being displayed by default.
The future dated entries have a status of "scheduled", and they get stored in the Stache index (or even in the database table if using the Eloquent driver). When the time ticks over the publish date, there's nothing that would update the indexed status, so the entry would continue to be filtered out.

The solution

This PR reworks logic so that we don't ever query status, as it would never automatically update. We would only query by date logic plus whether the entries are published.

Thinking of it more like a traditional database, you're currently querying status as if it were a column.
With this PR, consider the column gone, and to query by "status" it would really be a more complex query scope.

Breaking changes

In this PR, there should be none. However there will be some for v6 in a separate PR.

At the moment, you can still use all the condition types in your tag or API requests, e.g. status:in="draft|published" or status:not="whatever". It'll query against the stored value like it always did, but you may continue to run into the scheduling bug.

In v6, those will cause exceptions. Similar to if you were to query a missing column in a database you'd get Column [status] not found. In v6 you'll need to use whereStatus.

In v6, you'll only be able to query single statuses. I believe you only ever used the more complex operators to get around issues. I could be wrong! If that's the case and people really need them, we can add them back by making whereStatus smarter, or adding whereStatusIn, etc.

Todo

• Replace any instances of querying by status
• In REST API
• In GraphQL
• Possibly add some sort of deprecation warning when querying by status
  For this PR, it logs a deprecation message. In v6, it'll throw an exception.
• Possibly add backwards compatibility for querying by status.
  It's backwards compatible for now because the existing (sometimes broken) behavior will remain unchanged.
• In a breaking release of eloquent driver, remove the status column. (Drop status on entries eloquent-driver#228)

By the way

This doesn't address the issue where a listing should get updated while using static caching.

That's solvable using https://statamic.com/addons/mity-digital/scheduled-cache-invalidator

[jasonvarga]

Closes#2217

The issue

When you have a collection with date behaviors like a typical blog with scheduled posts (past dates are visible, future dates are not) whenever the current time ticks over the scheduled date, the entry would not be displayed.

This is because we were filtering by "status" in order to prevent drafts from being displayed by default.
The future dated entries have a status of "scheduled", and they get stored in the Stache index (or even in the database table if using the Eloquent driver). When the time ticks over the publish date, there's nothing that would update the indexed status, so the entry would continue to be filtered out.

The solution

This PR reworks logic so that we don't ever query status, as it would never automatically update. We would only query by date logic plus whether the entries are published.

Thinking of it more like a traditional database, you're currently querying status as if it were a column.
With this PR, consider the column gone, and to query by "status" it would really be a more complex query scope.

Breaking changes

In this PR, there should be none. However there will be some for v6 in a separate PR.

At the moment, you can still use all the condition types in your tag or API requests, e.g. status:in="draft|published" or status:not="whatever". It'll query against the stored value like it always did, but you may continue to run into the scheduling bug.

In v6, those will cause exceptions. Similar to if you were to query a missing column in a database you'd get Column [status] not found. In v6 you'll need to use whereStatus.

In v6, you'll only be able to query single statuses. I believe you only ever used the more complex operators to get around issues. I could be wrong! If that's the case and people really need them, we can add them back by making whereStatus smarter, or adding whereStatusIn, etc.

Todo

• Replace any instances of querying by status
• In REST API
• In GraphQL
• Possibly add some sort of deprecation warning when querying by status
  For this PR, it logs a deprecation message. In v6, it'll throw an exception.
• Possibly add backwards compatibility for querying by status.
  It's backwards compatible for now because the existing (sometimes broken) behavior will remain unchanged.
• In a breaking release of eloquent driver, remove the status column. (Drop status on entries eloquent-driver#228)

By the way

This doesn't address the issue where a listing should get updated while using static caching.

That's solvable using https://statamic.com/addons/mity-digital/scheduled-cache-invalidator

[jasonvarga]

Closes#2217

The issue

When you have a collection with date behaviors like a typical blog with scheduled posts (past dates are visible, future dates are not) whenever the current time ticks over the scheduled date, the entry would not be displayed.

This is because we were filtering by "status" in order to prevent drafts from being displayed by default.
The future dated entries have a status of "scheduled", and they get stored in the Stache index (or even in the database table if using the Eloquent driver). When the time ticks over the publish date, there's nothing that would update the indexed status, so the entry would continue to be filtered out.

The solution

This PR reworks logic so that we don't ever query status, as it would never automatically update. We would only query by date logic plus whether the entries are published.

Thinking of it more like a traditional database, you're currently querying status as if it were a column.
With this PR, consider the column gone, and to query by "status" it would really be a more complex query scope.

Breaking changes

In this PR, there should be none. However there will be some for v6 in a separate PR.

At the moment, you can still use all the condition types in your tag or API requests, e.g. status:in="draft|published" or status:not="whatever". It'll query against the stored value like it always did, but you may continue to run into the scheduling bug.

In v6, those will cause exceptions. Similar to if you were to query a missing column in a database you'd get Column [status] not found. In v6 you'll need to use whereStatus.

In v6, you'll only be able to query single statuses. I believe you only ever used the more complex operators to get around issues. I could be wrong! If that's the case and people really need them, we can add them back by making whereStatus smarter, or adding whereStatusIn, etc.

Todo

• Replace any instances of querying by status
• In REST API
• In GraphQL
• Possibly add some sort of deprecation warning when querying by status
  For this PR, it logs a deprecation message. In v6, it'll throw an exception.
• Possibly add backwards compatibility for querying by status.
  It's backwards compatible for now because the existing (sometimes broken) behavior will remain unchanged.
• In a breaking release of eloquent driver, remove the status column. (Drop status on entries eloquent-driver#228)

By the way

This doesn't address the issue where a listing should get updated while using static caching.

That's solvable using https://statamic.com/addons/mity-digital/scheduled-cache-invalidator

[jasonvarga]

Closes#2217

The issue

When you have a collection with date behaviors like a typical blog with scheduled posts (past dates are visible, future dates are not) whenever the current time ticks over the scheduled date, the entry would not be displayed.

This is because we were filtering by "status" in order to prevent drafts from being displayed by default.
The future dated entries have a status of "scheduled", and they get stored in the Stache index (or even in the database table if using the Eloquent driver). When the time ticks over the publish date, there's nothing that would update the indexed status, so the entry would continue to be filtered out.

The solution

This PR reworks logic so that we don't ever query status, as it would never automatically update. We would only query by date logic plus whether the entries are published.

Thinking of it more like a traditional database, you're currently querying status as if it were a column.
With this PR, consider the column gone, and to query by "status" it would really be a more complex query scope.

Breaking changes

In this PR, there should be none. However there will be some for v6 in a separate PR.

At the moment, you can still use all the condition types in your tag or API requests, e.g. status:in="draft|published" or status:not="whatever". It'll query against the stored value like it always did, but you may continue to run into the scheduling bug.

In v6, those will cause exceptions. Similar to if you were to query a missing column in a database you'd get Column [status] not found. In v6 you'll need to use whereStatus.

In v6, you'll only be able to query single statuses. I believe you only ever used the more complex operators to get around issues. I could be wrong! If that's the case and people really need them, we can add them back by making whereStatus smarter, or adding whereStatusIn, etc.

Todo

• Replace any instances of querying by status
• In REST API
• In GraphQL
• Possibly add some sort of deprecation warning when querying by status
  For this PR, it logs a deprecation message. In v6, it'll throw an exception.
• Possibly add backwards compatibility for querying by status.
  It's backwards compatible for now because the existing (sometimes broken) behavior will remain unchanged.
• In a breaking release of eloquent driver, remove the status column. (Drop status on entries eloquent-driver#228)

By the way

This doesn't address the issue where a listing should get updated while using static caching.

That's solvable using https://statamic.com/addons/mity-digital/scheduled-cache-invalidator

[jasonvarga]

Closes#2217

The issue

When you have a collection with date behaviors like a typical blog with scheduled posts (past dates are visible, future dates are not) whenever the current time ticks over the scheduled date, the entry would not be displayed.

This is because we were filtering by "status" in order to prevent drafts from being displayed by default.
The future dated entries have a status of "scheduled", and they get stored in the Stache index (or even in the database table if using the Eloquent driver). When the time ticks over the publish date, there's nothing that would update the indexed status, so the entry would continue to be filtered out.

The solution

This PR reworks logic so that we don't ever query status, as it would never automatically update. We would only query by date logic plus whether the entries are published.

Thinking of it more like a traditional database, you're currently querying status as if it were a column.
With this PR, consider the column gone, and to query by "status" it would really be a more complex query scope.

Breaking changes

In this PR, there should be none. However there will be some for v6 in a separate PR.

At the moment, you can still use all the condition types in your tag or API requests, e.g. status:in="draft|published" or status:not="whatever". It'll query against the stored value like it always did, but you may continue to run into the scheduling bug.

In v6, those will cause exceptions. Similar to if you were to query a missing column in a database you'd get Column [status] not found. In v6 you'll need to use whereStatus.

In v6, you'll only be able to query single statuses. I believe you only ever used the more complex operators to get around issues. I could be wrong! If that's the case and people really need them, we can add them back by making whereStatus smarter, or adding whereStatusIn, etc.

Todo

• Replace any instances of querying by status
• In REST API
• In GraphQL
• Possibly add some sort of deprecation warning when querying by status
  For this PR, it logs a deprecation message. In v6, it'll throw an exception.
• Possibly add backwards compatibility for querying by status.
  It's backwards compatible for now because the existing (sometimes broken) behavior will remain unchanged.
• In a breaking release of eloquent driver, remove the status column. (Drop status on entries eloquent-driver#228)

By the way

This doesn't address the issue where a listing should get updated while using static caching.

That's solvable using https://statamic.com/addons/mity-digital/scheduled-cache-invalidator