Goal: let a team operate schedules without sending them into the WordPress admin.
Before you start: both shortcodes are administrative views. They render only for users holding recurring_form_submissions_manage_resubmissions, and output nothing at all for anyone else.
Option 1 — A Read-Only Dashboard #
One page, one shortcode:
[rfsfgf_overview]Columns: Entry, Form, Feed Name, Feed Label, Next Submission, Progress, Status.
Narrow it with the status attribute:
[rfsfgf_overview status="failed"]
[rfsfgf_overview status="paused"]
[rfsfgf_overview status="all"]active (the default) lists everything except completed and canceled. Because completed and canceled series are retained for the history window, all lists more than it used to — ask for the status you actually want.
This table requires the Premium plan or higher.
Option 2 — Controls for One Entry #
[rfsfgf_entry_widget form_id="12" entry_id="345"]This renders the same cards as the entry page, with:
- Run Next Submission Now
- Retry Failed Submission
- Start Series From Now
- Cancel Series (Premium plan)
Pause, Resume, Change next submission, attempt history and diagnostics deliberately stay in Queue.
Option 3 — A List-and-Detail Pattern #
The useful combination: one page that lists series, and one that operates a chosen entry.
The list page #
Add [rfsfgf_overview], or build your own list (a GravityView view works well), and link each row to your detail page with the entry ID:
https://example.com/schedules/detail/?rfsfgf_entry=345The detail page #
[rfsfgf_entry_widget entry_id="current"]current reads the entry from the request, checking rfsfgf_entry first, then lid, then entry_id.
rfsfgf_entry is the unambiguous choice for your own pages; lid is supported because that’s what Gravity Forms uses on its entry screens.
Behaviour on the Front End #
| Aspect | Behaviour |
|---|---|
| Actions | Use AJAX and refresh the cards in place, on the page they were performed on. |
| Without JavaScript | The ordinary form submission returns to the same page with its result notice — never a redirect into the dashboard. |
| Security | Operational requests go through the same capability-checked and nonce-checked handler as the dashboard. No new endpoint is added. |
Mismatched form_id |
Renders nothing, rather than another form’s feeds. |
Access Control #
The default #
No management capability → nothing renders. That’s the whole widget, not just the buttons.
Granting access to a team #
Give the role the recurring_form_submissions_manage_resubmissions capability with your role editor. Those users then get both the view and the actions.
Letting someone view only their own #
Use rfsfgf_shortcode_can_view to widen the read without widening the write:
add_filter( 'rfsfgf_shortcode_can_view', function ( $can_view, $context, $args ) {
if ( 'entry_widget' === $context && ! $can_view ) {
return get_current_user_id() && (int) rgar( $args['entry'], 'created_by' ) === get_current_user_id();
}
return $can_view;
}, 10, 3 );The buttons and the handler behind them still require the management capability, so a user you let see a card cannot submit from it.
Scope any widening tightly. Returning a bare
trueshows every user every series’ entry, form, feed and failure state.
Page-level protection #
Still worth applying — a members-only page, a password, a restricted menu. It is no longer the only thing protecting the data, but it’s a sensible second layer.
A Sensible Setup #
| Page | Who can reach it | Contents |
|---|---|---|
| Schedules | Operations team | [rfsfgf_overview] |
| Schedule detail | Operations team | [rfsfgf_entry_widget entry_id="current"] |
| Needs attention | Operations team | [rfsfgf_overview status="failed"] |
Keep Queue as the place for schedule editing and forensics. The front-end pages are for the routine day-to-day.
