View Categories

Shortcodes

Table of Contents

Two shortcodes place recurring-submission surfaces on a front-end page.

Shortcode Renders
[rfsfgf_overview] A read-only table of series.
[rfsfgf_entry_widget] The entry cards, with a subset of their controls.

Read This First: They Are Administrative Views #

Both shortcodes render only for a user holding recurring_form_submissions_manage_resubmissions.

For anyone else — signed out, or signed in without the capability — they output nothing at all. Not a stripped-down version, not a table without buttons. Nothing.

That means a series’ entry, form, feed and failure state are never exposed by the page’s own access controls alone.

Page-level access control is still worth applying on top. It is simply no longer the only thing standing between a visitor and your series data.

Neither shortcode adds a new schedule-management endpoint: operational requests go through the same capability-checked and nonce-checked handler as the dashboard.

[rfsfgf_overview] #

A summary table of series.

[rfsfgf_overview]
[rfsfgf_overview status="failed"]

Columns #

Column Contents
Entry The parent entry.
Form The form it belongs to.
Feed Name The feed’s name.
Feed Label The feed’s label, with merge tags resolved.
Next Submission Date, time and timezone of the next target.
Progress 3 of 12 against a counted limit, or 3 successful submissions without one.
Status The lifecycle state.

Attributes #

Attribute Default Notes
status active active lists everything except completed and canceled. all lists every series still inside the retention window. Or name one exact status: scheduled, processing, paused, failed, completed, canceled.

Because completed and canceled series are retained for the history window, status="all" lists more than you might expect. Ask for the status you actually want.

This is a read-only summary, not the Queue editor. It offers no actions.

Plan requirement #

The overview table requires the Premium plan or higher. On a lower plan it renders an upgrade message in place of the table.

[rfsfgf_entry_widget] #

Renders the recurring cards for one parent entry, with working controls.

[rfsfgf_entry_widget form_id="12" entry_id="345"]
[rfsfgf_entry_widget entry_id="current"]

Attributes #

Attribute Default Notes
entry_id (required) The parent entry to show. entry_id="current" reads it from the request — rfsfgf_entry first, then lid, then entry_id.
form_id The entry’s own form Optional. A value that disagrees with the entry’s form renders nothing, rather than another form’s feeds.

Available actions #

In the widget Stays in Queue
Run Next Submission Now Pause
Retry Failed Submission Resume
Cancel Series (Premium plan) Change next submission
Start Series From Now Attempt history
Copy Diagnostics

The split is deliberate: routine per-entry operations belong wherever your team works, while schedule editing and forensics belong on the operations screen.

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 that same page with its result notice rather than redirecting into the dashboard.

A List-and-Detail Pattern #

entry_id="current" exists so one page can serve a whole list.

  1. Build a list of parent entries — a GravityView view, a loop, whatever you prefer.
  2. Link each row to a detail page with ?rfsfgf_entry=123.
  3. Put [rfsfgf_entry_widget entry_id="current"] on that detail page.

rfsfgf_entry is the unambiguous argument; lid is supported because that’s what Gravity Forms uses on its own entry screens.

Widening or Narrowing Access #

rfsfgf_shortcode_can_view filters the decision before anything is rendered.

It receives:

  1. the capability check’s result,
  2. the context — overview or entry_widget,
  3. for the entry widget, an array holding the entry and form.

Returning true for a user without the management capability shows them series state, so scope any widening to the entries that user should actually see:

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 );

Widening the read does not widen the write. The action buttons, and the request handler behind them, still require the management capability. A user you let see a card cannot use it to submit anything.

What are your Feelings