Appearance
Future Actions
Unpublish, trash or recategorise posts and pages at a date; reads PublishPress Future's data.
kitloom/future-actions · admins: kitloom/future-actions-filament, kitloom/future-actions-nova
Video lessons
Recorded in the Filament admin; the Nova admin works the same way.
Lets a post, a page or a record of any other type change by itself at a date you choose: go back to draft, become private or pending review, move to the trash, be stuck to the top of the blog or unstuck, gain or lose categories and tags. It is what PublishPress Future (formerly Post Expirator) does on a WordPress site — an offer that ends on Sunday night, an event page that leaves the site the day after, a "new" category that comes off a product after a month — and it reads that plugin's data: a site moved from WordPress keeps the actions it had scheduled, with nothing to import.
The screens are in the admin under Future Actions (kitloom/future-actions-filament or kitloom/future-actions-nova); the action itself is set on the record's own form.
Scheduling an action
Open a post or a page. Its form has a Future action box (a tab in Nova).
Turn on Enable future action.
When: the date and time, in the site's time zone (Settings → General).
Action: what happens then —
Action What it does Change status to draft The record leaves the site and waits as a draft. Change status to pending The same, marked for review. Change status to private Only signed-in users who may read private records see it. Move to the trash Into the trash, where it can be restored. Stick / Unstick On or off the top of the blog's first page. Replace the terms The record's terms of a taxonomy become the ones you pick. Add terms / Remove terms Those terms are added or taken off; the others stay. Remove all terms Every term of that taxonomy comes off (a post with no category gets the default one, as in WordPress). For the term actions, pick the Taxonomy and the Terms.
Save the record. The Future action column of the list shows what waits and when.
Turning Enable future action off and saving cancels it. A date already passed runs within a minute.
Several at once: tick records in a list and choose Schedule future action in the bulk menu — every chosen record gets the same action, replacing what waited on it. Cancel future action there takes it off. The list's Future action filter shows the records that have one, or none.
Who may schedule what
Scheduling an action asks what doing it by hand would ask: editing the record, and
- publishing rights of its type for private;
- deleting the record for the trash;
- editing others' posts for stick and unstick, as WordPress asks for sticky posts;
- assigning terms of the taxonomy for the term actions.
On a screen a module guards with one permission for its whole section (a contact form, a slider), that permission is the editing and the deleting — as it opens the form and the Delete button — and the rest is asked as above. A term action names terms the taxonomy has; an id it has not is refused rather than dropped, so "add these terms" never quietly becomes nothing.
When the time comes the action is done by the site itself, as PublishPress Future does it: the plugin keeps no user with the action, so a person whose role changed later does not stop it. The change is still announced as any edit is — the activity log, webhooks, the page cache and the term counts follow.
The list of what is scheduled
Future Actions → Scheduled lists every record with an action waiting, of every type, the nearest first: the title (a link to its form), the type, its status now, the action and when. Cancel takes an action off; tick several to cancel them together. Administrators and editors see it (view_future_actions).
Settings
Future Actions → Settings (administrators, manage_future_actions):
- One section per post type. Future actions on this type puts the box on its form and the column, filter and bulk actions on its list — posts and pages are on, other types off until you turn them on. Then what a new action of the type starts with: the Default action, the Default taxonomy, whether the box is On for new records, the Default date (the site's, or Its own — How far ahead, as
+3 days), and addresses to Also email for this type. - Emails. Email when an action was done sends a short note — which record, what was done, when, and its address — to More addresses (comma-separated), to the type's own addresses and, when Email the administration address too is on, to the address of Settings → General. Nothing is sent when no address is set.
- Dates. Default date of a new action — how far ahead, as
+1 week(the plugin's default),+3 days,+1 month. Date format and Time format of the shortcode, as WordPress writes them (l F jS, Y,g:ia). - Shortcode. The tag and class put around the date it shows.
The date in a text
[futureaction] in a post or page shows the date of its waiting action: "This offer ends [futureaction type=date]." It shows nothing when no action waits, so the sentence can go with the offer.
| Attribute | |
|---|---|
type | full (date and time), date or time |
dateformat, timeformat | a PHP date format; empty — the settings page's |
wrapper, class | span, div, p, strong, em or time around it, and its class |
post_id | another record's date; empty — the page's own |
The plugin's older [postexpirator] works the same, so moved content shows its dates.
Notifications and AI agents
With kitloom/notifications, a channel can tick Future action failed (on by default — a record meant to leave the site is still on it) and Future action done. With kitloom/ai, an agent lists, schedules and cancels actions (future_actions_list, future_actions_schedule, future_actions_cancel) with its user's rights, and describe_site tells it which types have actions and their defaults.
Running the actions
The actions are done by future-actions:run, every minute through Laravel's scheduler — the server needs the usual cron line:
* * * * * cd /path/to/site && php artisan schedule:run >> /dev/null 2>&1The same line publishes scheduled posts at their time (wordpress:publish-scheduled, from the core). An action that fails — a record someone deleted meanwhile, a database error — is turned off and reported, not tried again every minute.
Data
Everything is where PublishPress Future keeps it, so a site that ran the plugin needs no import:
| What | Where |
|---|---|
| A record's action | post meta _expiration-date (UTC time), _expiration-date-status (saved while it waits, 0 when cancelled or done), _expiration-date-type, _expiration-date-post-status, _expiration-date-taxonomy, _expiration-date-categories, _expiration-date-options |
| A type's defaults | option expirationdateDefaults<Type> (expirationdateDefaultsPost, …) |
| Site-wide settings | options expirationdateEmailNotification, expirationdateEmailNotificationAdmins, expirationdateEmailNotificationList, expirationdateDefaultDateCustom, expirationdateDefaultDateFormat, expirationdateDefaultTimeFormat, shortcodeWrapper, shortcodeWrapperClass |
The plugin's action "delete" (for good) is done as Move to the trash: nothing leaves the site for good on a timer. Not carried over: the plugin's line under the content ("Post expires at…"), its action log, and Pro's workflows — PublishPress Future Pro keeps those in tables of its own.
For developers
php
use Carbon\CarbonImmutable;
use Kitloom\FutureActions\FutureAction;
use Kitloom\FutureActions\FutureActions;
app(FutureActions::class)->schedule($post, FutureAction::choose('draft', CarbonImmutable::parse('2030-05-01 09:00', 'UTC')), $user);
app(FutureActions::class)->waiting($post); // ?FutureAction
app(FutureActions::class)->cancel($post, $user);Events Kitloom\FutureActions\Events\ActionRan and ActionFailed carry the record and the action. The configuration (config/kitloom-future-actions.php) turns off the schedule, the shortcodes, the agent tools, the notifications and each admin.