TolstoyDotCom

Your older posts can quickly become out-of-date and require editing to provide up-to-date information. 
For instance, posts at medical sites might require regular reviews to make sure they’re keeping up with the latest research. 
Spritz keeps track of when each post needs to be reviewed. 
When the time arrives, the post is marked as needing review and an optional email is sent to the admin user. 
You can adjust the timing on a per-post basis if you want: some posts might require monthly reviews, others might only need them yearly. 
A listing page shows the current state of each post. 
You can even subject the review to a further approval step if you want.
To read more about ‘Spritz’ visit <a href="https://wisdomtree.dev/spritz-wordpress-plugin/" rel="nofollow ugc">this page</a>.
<h3>Configuration</h3>
A post can be in one of the following states: NEUTRAL, AWAITING_REVIEW, REVIEWED, NEEDS_WORK, APPROVED, or DISAPPROVED. 
Each post has a “Next action date”. 
If the post is in REVIEWED or APPROVED state, it’s moved into AWAITING_REVIEW state on the “Next action date”. 
Then, it’s expected that an admin will put the post into the REVIEWED or APPROVED state. After an admin does that, the timer starts over again. 
Of course, an admin could also put the post into the NEEDS_WORK or DISAPPROVED state, 
but what happens in that case is beyond the scope of this plugin.
<h3>Details</h3>
Screenshot 1 shows the sidebar where you set the state of your posts. 
At the top it shows the current state, the next action date, and the note on the current state. 
Below that, you can set the new state and provide notes. 
To add the new state, you have to check the confirm checkbox and save the post. 
At the bottom you can override the settings just for this post, see below.
Screenshot 2 shows the settings screen. 
If you check ‘Automatically approve posts’, any time a post is put into the REVIEWED state, 
it will automatically be moved into the APPROVED state. If you don’t check that, an admin 
will need to move it into the APPROVED state manually. 
‘Number of days’ controls the timer. 
The other settings are for the email that’s sent out when a post is moved into the AWAITING_REVIEW state. 
If you don’t fill out all three email fields, no email will be sent out.
Referring back to Screenshot 1, you can override settings on a per-post basis. 
For instance, you might want some posts to be reviewed more frequently than others. 
You can also change the auto-approval settings. 
As with setting the new state, you have to check the confirm checkbox to have the overrides saved.
<h3>Shortcodes</h3>
Three shortcodes are provided: [spritz_post_status], [spritz_post_note], and [spritz_post_nextreviewdate]. 
If used on a post, those show the current status of the post, the last note, and the next review date. 
If used on something other than a post, nothing is shown.
<h3>Multiple Roles</h3>
If you have multiple roles that will review posts, you’ll need to install one of the many 
member plugins that are available. 
Screenshot 4 is from one of those plugins. 
Only roles with the ‘spritz_edit_settings’ permission can change the global settings. 
Only roles with the ‘spritz_override_post_settings’ permission can override those global settings on a per-post basis. 
The other permissions are of the form ‘spritz_transition_from_X_to_Y’. 
You may decide that users of a certain role can move a post from REVIEWED to NEEDS_WORK but not vice versa, and so on.
<h3>Customizations</h3>
If you’d like a customization for a reasonable fee, please contact us with the details: 
https://wisdomtree.dev/contact/feedback
<h3>Support future development</h3>
Your generous support will help support new versions: 
https://www.paypal.com/donate/?hosted_button_id=4U3VYC5LNWRM4
<h3>Additional Documentation</h3>

Spritz

Spritz reminds you to review or refresh your WordPress posts on a regular basis.

10up

Jeffrey Paul

Josh Levinson

observerteam

brs14ku

Eight Day Week provides a set of tools to manage your print workflow directly in your WordPress dashboard–right where your posts are!
Primarily, it offers an interface to group, label, and manage the workflow status of posts in a printed “Issue”.
Features:
Create “Print Issues”
<ul>
<li>Add and order sections, and articles within sections</li>
<li>Assign article statuses specific to your print workflow</li>
</ul>
Limit access to Print Roles
Two custom roles are added by this plugin to best model a real-world print team.
<ul>
<li>The Print Editor role offers full access to the creation interfaces, such as Print Issue, Article Status, Print Publication, etc.</li>
<li>The Print Production role offers read-only access to a Print Issues. The XML export tool is also available to Production users.</li>
</ul>
View a Print Issue in “Read Only” mode
<ul>
<li>Circumvents the post locking feature by offering a read-only view of a print issue</li>
</ul>
XML Export to InDesign: Classic Editor vs. Gutenberg Exports
When exporting content from WordPress for use in InDesign, there are key differences between Classic Editor and Gutenberg (Block Editor) exports. This section highlights how each type of export behaves in InDesign and offers guidance on how to handle these differences.
<ul>
<li>Classic Editor exports use basic HTML tags like <code></code>, <code></code>, and <code></code>, making them straightforward for import into InDesign.</li>
<li>Gutenberg exports include additional metadata such as HTML comments (<code></code>) that define block-level structures, which may require manual adjustments after importing into InDesign.</li>
</ul>
Import Differences:
<ul>
<li>Classic Editor: Imports cleanly into InDesign without extra metadata.</li>
<li>Gutenberg: May include block-related metadata, requiring users to clean up the imported content or manually adjust formatting.</li>
</ul>
Recommendations:
<ul>
<li>Classic Editor: Best for simple imports with minimal manual work.</li>
<li>Gutenberg: Recommended for users comfortable with removing metadata or adjusting block-based settings after the import.</li>
</ul>
<h3>Filters & Hooks</h3>
Eight Day Week provides a number of filters and hooks for customizing and extending the plugin.
Modules
Eight Day Week follows a module-style approach to many of its features. These can be turned on or off via filters, and all work independently. 
These are: 
Article Byline 
Article Count 
Article Export 
Article Status 
Issue Publication 
Issue Status 
Any of these can be disabled by returning a false value from the following filter format:
<pre><code>add_filter( 'Eight_Day_Week\Plugins\load_$plugin', '__return_false' );
</code></pre>
The <code>$plugin</code> value is a slug version of the plugin name, i.e. article-byline.
Article Table
The information displayed in the list of articles within a Print Issue is filterable. Custom columns can be added via the following filters: <code>Eight_Day_Week\Articles\article_columns</code> and <code>Eight_Day_Week\Articles\article_meta_$column_name</code>.
Sample usage:
<pre><code>add_filter( 'Eight_Day_Week\Articles\article_columns', function( $columns ) {
 $columns['byline'] = _x( 'Byline', 'Label for multiple, comma separated authors', 'your-text-domain' );
 return $columns;
} );
add_filter( 'Eight_Day_Week\Articles\article_meta_byline', function( $incoming_value, $post ) {
 return implode( ', ', wp_list_pluck( my_get_post_authors_function( $post ), 'display_name' ) );
}
</code></pre>
Print Issue Table
The information displayed in the list of Print Issues is filterable. Custom columns can be added via the following filter: 
 Eight_Day_Week\Print_Issue_Columns\pi_columns. Note that this is a convenience filter, the base filter is <code>manage_edit-print-issue_columns</code>. See <code>includes/functions/print-issue-columns.php</code> for sample usage.
Article Export
The export of posts in a Print Issue is highly customizable, from the file name of the zip, to the file name of the individual files, to the contents of the files themselves. The best reference would be to read through <code>includes/functions/plugins/article-export.php</code>. <a href="https://github.com/10up/eight-day-week/wiki/Sample-Eight-Day-Week-filters-for-the-Observer" rel="nofollow ugc">Here’s</a> a few examples used on the Observer.
Sample Eight Day Week filters for the Observer
Examples from Observer’s eight-day-week-filters.php:
<pre><code><?php

add_filter( 'Eight_Day_Week\Plugins\Article_Export\xml_outer_elements', function( $elements, $article ) {
 $elements['subHeadline'] = get_post_meta( $article->ID, 'nyo_dek', true );
 return $elements;
}, 10, 2 );

add_filter( 'Eight_Day_Week\Plugins\Article_Export\xml_outer_elements', function( $elements, $article ) {
 if( function_exists( '\Eight_Day_Week\Plugins\Article_Byline\get_article_byline' ) ) {
 $elements['byline'] = \Eight_Day_Week\Plugins\Article_Byline\get_article_byline( $article );
 }
 return $elements;
}, 10, 2 );

add_filter( 'Eight_Day_Week\Plugins\Article_Export\xpath_extract', function( $extract ) {
 $extract[] = [
 'tag_name' => 'pullQuote',
 'container' => 'pullQuotes',
 'query' => '//p[contains(@class, "pullquote")]'
 ];
 return $extract;
} );

add_filter( 'Eight_Day_Week\Plugins\Article_Export\dom', function ( $dom ) {
 $swap_tag_name = 'emphasized';

 $extract_map = [
 'strong' => [
 'solo' => 'bold',
 'inner' => 'em'
 ],
 'em' => [
 'solo' => 'italics',
 'inner' => 'strong'
 ],
 ];

 foreach ( $extract_map as $tag_name => $map ) {
 $nodes = $dom->getElementsByTagName( $tag_name );
 $length = $nodes->length;

 for ( $i = $length; -- $i >= 0; ) {
 $el = $nodes->item( $i );
 $emphasized = $el->getElementsByTagName( $map['inner'] );
 if ( $emphasized->length ) {
 $em = $dom->createElement( $swap_tag_name );
 $em->nodeValue = $el->nodeValue;
 try {
 $el->parentNode->replaceChild( $em, $el );
 } catch ( \Exception $e ) {

 }
 continue;
 }

 $new = $dom->createElement( $map['solo'] );
 $new->nodeValue = $el->nodeValue;
 try {
 $el->parentNode->replaceChild( $new, $el );
 } catch ( \Exception $e ) {

 }

 }

 }

 return $dom;

} );
</code></pre>
<h3>Known Caveats/Issues</h3>
Gutenberg exports 
Gutenberg-based exports include some additional metadata/details that a Classic Editor-based export does not. <a href="https://developer.wordpress.org/block-editor/key-concepts/#delimiters-and-parsing-expression-grammar" rel="nofollow ugc">Gutenberg stores block data in HTML comments</a>, so you’ll notice those comments (in the form of <code></code>) appearing in the Eight Day Week XML export. Note that the XML is still valid–you can test and confirm that yourself using an <a href="https://www.xmlvalidation.com/" rel="nofollow ugc">XML validator</a>–though depending on your version of InDesign you may get different results upon importing a Gutenberg export compared to a Classic Editor export. Our testing showed that those HTML comments in a Gutenberg export did not affect the import into InDesign however. You can test how this works in your version of InDesign with these sample XML files: <a href="https://raw.githubusercontent.com/wiki/10up/eight-day-week/BlockEditor-sample.xml" rel="nofollow ugc">Gutenberg XML</a>, <a href="https://raw.githubusercontent.com/wiki/10up/eight-day-week/ClassicEditor-sample.xml" rel="nofollow ugc">Classic Editor XML</a>. You can also test how this works with full ZIP exports of Print Issues containing a <a href="https://raw.githubusercontent.com/wiki/10up/eight-day-week/BlockEditor-SampleExport.zip" rel="nofollow ugc">Block Editor sample</a> or a <a href="https://raw.githubusercontent.com/wiki/10up/eight-day-week/ClassicEditor-SampleExport.zip" rel="nofollow ugc">Classic Editor sample</a>.

Eight Day Week Print Workflow

Optimize publication workflows by using WordPress as your print CMS

Spritz vs Eight Day Week Print Workflow