Opened 8 years ago
Last modified 20 months ago
#44977 new defect (bug)
Transient fill fail delete to itself if it's timeout option is missing
| Reported by: | nlozovan | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Awaiting Review |
| Component: | Options, Meta APIs | Version: | |
| Severity: | normal | Keywords: | needs-patch |
| Cc: | Focuses: |
Description (last modified by )
Just faced this issue - for some reason, the transient was not deleting itself. While checking the DB, the option with the transient was there, while the timeout option was missing (probably a glitch while saving to DB).
Now, if you check get_transient() in option.php (quick link https://core.trac.wordpress.org/browser/tags/4.9.8/src/wp-includes/option.php#L0 ) you can see that these are deleted only if both exist and both pass the test:
[...]
if ( false !== $timeout && $timeout < time() ) { DELETING TRANSIENT}
[...]
Otherwise transient will hang... forever. This should be tuned up so it also checks that these options exist, and delete transient if timeout is absolete.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
How should we handle transients that are saved without a timeout due to a glitch? Should we add a check for this wherever we delete the transient?
if ( false === $timeout || ( false !== $timeout && $timeout < time() ) ) {