| 开发者 |
urkekg
techwebux |
|---|---|
| 更新时间 | 2026年9月20日 05:36 |
| 捐献地址: | 去捐款 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv3 |
| 版权网址: | 版权信息 |
N published articles from database (posts and/or pages) published on current day and/or offset of time in past years, and list them in widget or block.
User can set widget title, number of displayed articles and message shown when there is no public articles in past.
Features
no articles message)time-machine folder to the /wp-content/plugins/ directory.Plugins menu in WordPress.Time Machine widget on Appearance → Widgets.Time Machine options.Plugins → Add New and search for time machine.Install Now link bellow Time Machine search result and aswer Yes on popup question.Proceed.Plugins menu in WordPress.Time Machine widget on Appearance → Widgets.Time Machine options.I like effect that produce Time Machine - traveling trough time. This plugin does exactly that, but with fixed month and day constant.
Revire and rate plugin, submit suggestions, contribute on WordPress forum.
Yes. Time Machine's list is refetched from a small REST endpoint right after the page finishes loading, so the visible content stays current even when the whole page has been cached for longer than a day. The cached markup already on the page stays visible until (and unless) that request succeeds, so nothing is ever blank while it refreshes, and the page cache itself is never touched or purged. If you prefer to disable this and rely only on the page cache's own expiry, add define( 'TIME_MACHINE_DISABLE_REFRESH', true ); to wp-config.php.
Add this to wp-config.php:
define( 'TIME_MACHINE_DISABLE_REFRESH', true );
No data-time-machine-* attributes are printed after that, the refresh script is never enqueued, and no REST request is ever made. Lists render once, on the server. On a page held in a full page cache for longer than a day, the list can then be a day or more behind.
/wp-json/time-machine/v1/list. What is wrong?A security plugin or snippet on your site closes the whole REST API to signed out visitors, through the rest_authentication_errors filter. That filter runs before any route can state that it is public, so Time Machine cannot exempt its own route from it, however read only that route is.
Nothing is broken for your visitors. The list is rendered on the server and stays on screen; only the refresh described above is skipped, and the failed request is logged in the console. Time Machine checks this once a day and tells you in Tools -> Site Health, which spells out the two options below.
Option 1: switch the refresh off. Add this to wp-config.php:
define( 'TIME_MACHINE_DISABLE_REFRESH', true );
No request is made after that, so the console stays clean. Lists render once, on the server, exactly as they did before this feature existed. On a page held in a full page cache for longer than a day, the list can then be a day or more behind.
Option 2: let this one route through. It is read only and returns the same published titles, excerpts and links the page already shows to the same visitor, so letting it through gives nothing away. Add this to a must-use plugin or to your theme's functions.php:
```
add_filter(
'rest_authentication_errors',
function ( $result ) {
if ( ! is_wp_error( $result ) ) {
return $result;
}
$route = isset( $GLOBALS['wp']->query_vars['rest_route'] )
? ltrim( $GLOBALS['wp']->query_vars['rest_route'], '/' )
: '';
if ( 0 === strpos( $route, 'time-machine/v1/' ) ) {
return null;
}
return $result;
},
99
);
```
It runs after the restriction and before the core cookie check, and clears the error for the time-machine/v1 namespace only. Every other route keeps the restriction exactly as it is.
the_excerpt()TIME_MACHINE_DISABLE_REFRESH constant to switch the front-end refresh off site wide from wp-config.phphours offsetSCRIPT_DEBUG is on