Giter Site home page Giter Site logo

10up / eight-day-week Goto Github PK

View Code? Open in Web Editor NEW
84.0 71.0 9.0 3.94 MB

Optimize print publication workflows by using WordPress as your print CMS.

Home Page: https://wordpress.org/plugins/eight-day-week-print-workflow

License: GNU General Public License v2.0

JavaScript 28.66% PHP 70.08% SCSS 1.19% Shell 0.07%
wordpress editorial print workflow

eight-day-week's Introduction

Eight Day Week Print Workflow

Optimize publication workflows by using WordPress as your print CMS.

Support Level E2E tests Release Version WordPress tested up to version GPLv2 License

Table of Contents

Overview

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".

The Print Issue list table.

Features

Create "Print Issues"

  • Add and order sections, and articles within sections
  • Assign article statuses specific to your print workflow

The Print Issue editor, showing the sections and contained articles, as well as several modules at play.

Limit access to Print Roles

Two custom roles are added by this plugin to best model a real-world print team.

  • The Print Editor role offers full access to the creation interfaces, such as Print Issue, Article Status, Print Publication, etc.
  • The Print Production role offers read-only access to a Print Issues. The XML export tool is also available to Production users.

The Users list table, showing the "Change print role to..." dropdown and "Print Role" column.

View a Print Issue in "Read Only" mode

  • Circumvents the post locking feature by offering a read-only view of a print issue

A Print Issue in "read only view". This view allows anyone with access to view a Print Issue without inducing a post lock, or being locked out by another editor. Note that the Export tools are still available in read only view.

XML Export to InDesign

  • Export XML files specifically formatted for import into InDesign

Sample article XML export.

Issue Statuses Publications Article Statuses
Editing of Issue Statuses Editing of Publications Editing of Article Statuses

Requirements

Installation

Eight Day Week has no settings or configurations to set up. It just works!

Filters & Hooks

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 falsey value from the following filter format: add_filter( 'Eight_Day_Week\Plugins\load_$plugin', '__return_false' ); The $plugin 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: Eight_Day_Week\Articles\article_columns and Eight_Day_Week\Articles\article_meta_$column_name.

Sample usage:

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

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 manage_edit-print-issue_columns. See includes/functions/print-issue-columns.php for sample usage.

Article Export

The export of posts in a Print Issue is highly customizeable, 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 includes/functions/plugins/article-export.php. Here's a few examples used on the Observer.

Sample Eight Day Week filters for the Observer

Examples from Observer's eight-day-week-filters.php:

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

} );

Known Caveats/Issues

Gutenberg exports

Gutenberg-based exports include some additional metadata/details that a Classic Editor-based export does not. Gutenberg stores block data in HTML comments, so you'll notice those comments (in the form of <!-- "Gutenberg block data" -->) appearing in the Eight Day Week XML export. Note that the XML is still valid--you can test and confirm that yourself using an XML validator--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: Gutenberg XML, Classic Editor XML. You can also test how this works with full ZIP exports of Print Issues containing a Block Editor sample or a Classic Editor sample.

Support Level

Stable: 10up is not planning to develop any new features for this, but will still respond to bug reports and security concerns. We welcome PRs, but any that include new features should be small and easy to integrate and should not include breaking changes. We otherwise intend to keep this tested up to the most recent version of WordPress.

Changelog

A complete listing of all notable changes to Eight Day Week are documented in CHANGELOG.md.

Contributing

Please read CODE_OF_CONDUCT.md for details on our code of conduct, CONTRIBUTING.md for details on the process for submitting pull requests to us, and CREDITS.md for a listing of contributors to Eight Day Week.

Like what you see?

Work with us at 10up

eight-day-week's People

Contributors

barneyjeffries avatar bmarshall511 avatar dependabot[bot] avatar dhanendran avatar dinhtungdu avatar dkotter avatar faisal-alvi avatar helen avatar iamdharmesh avatar jayedul avatar jeffpaul avatar joshlevinson avatar kmgalanakis avatar mnelson4 avatar peterwilsoncc avatar shelob9 avatar sidsector9 avatar sternb0t avatar zamanq avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

eight-day-week's Issues

Remove `BrentSchultz` as contributor in `readme.txt`

Describe the bug

The WordPress.org readme validator currently shows a warning for ignored contributors.

This is due to the user BrentSchultz not existing on WordPress.org.

An alternative may be to ask Brent to create a WordPress.org account.

Steps to Reproduce

  1. Validate readme.txt against WordPress markdown validator
  2. Visit https://profiles.wordpress.org/BrentSchultz/, observe page is not found

Screenshots, screen recording, code snippet

Screen Shot 2022-11-17 at 12 45 32 pm

Environment information

No response

WordPress information

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Sample output files

Is your enhancement related to a problem? Please describe.
A request came in via Twitter to provide a sample output file. This presumably will provide folks a sample that they can import into InDesign and see how the complete production process works (from WordPress to InDesign).

Describe the solution you'd like

  • sample output file with Classic Editor content
  • sample output file with Gutenberg content
    - [ ] sample output file with Classic Editor and Gutenberg content
  • link to the sample files from readme.md and readme.txt

Designs
n/a

Describe alternatives you've considered
none

Additional context
n/a

Add note to readme about Gutenberg support

Is your enhancement related to a problem? Please describe.
Gutenberg-based exports includes some additional metadata/details that a Classic Editor-based export does not.

Describe the solution you'd like

  • Update the readme to call out differences between exports from the Classic Editor and Gutenberg.
  • switch from using links to Adam Silverstein's personal Gists for XML samples to ones hosted either in-repo or on a 10up controlled web entity
  • test importing Classic Editor and Gutenberg exports into InDesign, capture differences, add to readme as examples

Designs
n/a

Describe alternatives you've considered
none

Additional context
Background details from 10up Slack.

Add hook doc generation

Is your enhancement related to a problem? Please describe.
There's a reference to sample filters for the Observer in the Article Export section (both in the readme.md and readme.txt files) that links out to a gist outside the repo. Let's add the hook doc generation GitHub Action to the repo and link to that resulting GitHub Pages site from our readme pages.

Describe the solution you'd like

  • add hookdoc action
  • update the link reference in the Article Export section of readme.md
  • update the link reference in the Article Export section of readme.txt

Designs
n/a

Describe alternatives you've considered
keep it as-is?

Additional context
none.

Release version 1.2.0

Describe your question

This issue is for tracking changes for the 1.2.0 release. Target release date: 13 December 2021

Release steps

  • Branch: Starting from develop, cut a release branch named release/1.2.0 for your changes.
  • Version bump: Bump the version number in eight-day-week.php, package.json, and readme.txt if it does not already reflect the version being released. Update both the plugin "Version:" property and the plugin EDW_VERSION constant in eight-day-week.php.
  • Changelog: Add/update the changelog in both readme.txt and CHANGELOG.md.
  • Props: update CREDITS.md file with any new contributors, confirm maintainers are accurate.
  • New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .gitattributes.
  • Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
  • Merge: Make a non-fast-forward merge from your release branch to develop, then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
  • Test: While still on the trunk branch, test for functionality locally. If all is well, push to GitHub.
  • Release: Create a new release, naming the tag and the release with the new version number. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone (e.g. https://github.com/10up/eight-day-week/milestone/3?closed=1). Close the milestone.
  • SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
  • Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/eight-day-week-print-workflow/. This may take a few minutes.
  • Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close 1.2.0 milestone.
  • Punt incomplete items: If any open issues or PRs which were milestoned for 1.2.0 do not make it into the release, update their milestone to 1.3.0 or Future Release.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Release version 1.1.2

This issue is for tracking changes for the 1.1.2 release. Target release date: TBD

Release steps

  • Branch: Starting from develop, cut a release branch named release/1.1.2 for your changes.
  • Version bump: Bump the version number in eight-day-week.php, package.json, and readme.txt if it does not already reflect the version being released. Update both the plugin "Version:" property and the plugin EDW_VERSION constant in eight-day-week.php.
  • Changelog: Add/update the changelog in both readme.txt and CHANGELOG.md.
  • New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .gitattributes.
  • Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
  • Merge: Make a non-fast-forward merge from your release branch to develop, then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
  • Test: While still on the trunk branch, test for functionality locally. If all is well, push to GitHub.
  • Release: Create a new release, naming the tag and the release with the new version number. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone (e.g. https://github.com/10up/eight-day-week/milestone/5?closed=1). Close the milestone.
  • SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
  • Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/eight-day-week-print-workflow/. This may take a few minutes.
  • Close milestone: Edit the 1.1.2 milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close 1.1.2 milestone.
  • Punt incomplete items: If any open issues or PRs which were milestoned for 1.1.2 do not make it into the release, update their milestone to 1.2.0 or Future Release.

Add develop branch

Is your enhancement related to a problem? Please describe.
Add a develop branch and set as default, to mimic 10up repo standards.

Describe the solution you'd like
See above.

Designs
n/a

Describe alternatives you've considered
n/a

Additional context
n/a

Setup GitHub Actions

Is your enhancement related to a problem? Please describe.
In order to automate our WordPress.ORG deploys, let's leverage the GitHub Actions that @helen built.

Describe the solution you'd like
Setup the GitHub Actions to handle dotorg-plugin-asset-update and dotorg-plugin-deploy from https://github.com/10up/actions-wordpress.

Designs
n/a

Describe alternatives you've considered
None.

Additional context
None.

Setup Cypress for E2E testing

Is your enhancement related to a problem? Please describe.

See overall concept in the OSBP guide and example setups on Simple Podcasting, Restricted Site Access, and 10up/ElasticPress#2446.

Describe the solution you'd like

  • add base GitHub Action
  • add .wp-env.json
  • add base docker files
  • update package.json / package lock files
  • add cypress tests
  • remove any WP Acceptance components

Designs

n/a

Describe alternatives you've considered

n/a

Additional context

https://github.com/10up/cypress-wp-setup/ && https://github.com/10up/cypress-wp-utils will be helpful in getting this spun up and some initial test commands to leverage.

Test against WordPress 6.0

Is your enhancement related to a problem? Please describe.
Once WordPress 6.0 is released, we'll want to test Eight Day Week to see if any incompatibility issues arise.

Describe the solution you'd like

  • test Eight Day Week on WordPress 6.0
  • open issues for any incompatibilities noted in testing
  • resolve issues identified in testing
  • bump "tested up to" version
  • if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
None

Additional context
Related: #77, #65, #54, #19

Test against WordPress 5.2

  • test core plugin functionalities against WP 5.2
  • check for core incompatibilities
  • check for Gutenberg incompatibilities
  • bump "tested up to" when tests are stable

Release version 1.1.3

This issue is for tracking changes for the 1.1.3 release. Target release date: 13 December 2021

Release steps

  • Branch: Starting from develop, cut a release branch named release/1.1.3 for your changes.
  • Version bump: Bump the version number in eight-day-week.php, package.json, and readme.txt if it does not already reflect the version being released. Update both the plugin "Version:" property and the plugin EDW_VERSION constant in eight-day-week.php.
  • Changelog: Add/update the changelog in both readme.txt and CHANGELOG.md.
  • New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .gitattributes.
  • Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
  • Merge: Make a non-fast-forward merge from your release branch to develop, then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
  • Test: While still on the trunk branch, test for functionality locally. If all is well, push to GitHub.
  • Release: Create a new release, naming the tag and the release with the new version number. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone (e.g. https://github.com/10up/eight-day-week/milestone/3?closed=1). Close the milestone.
  • SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
  • Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/eight-day-week-print-workflow/. This may take a few minutes.
  • Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close 1.1.2 milestone.
  • Punt incomplete items: If any open issues or PRs which were milestoned for 1.1.3 do not make it into the release, update their milestone to 1.2.0 or Future Release.

Add E2E Tests.

Is your enhancement related to a problem? Please describe.

Cypress setup for E2E testing is done on repo by @dhanendran via #92. Need to add additional E2E tests to cover the functionality of the plugin.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Readme updates

  • add support level section & badge
  • add released version badge
  • add WP tested up to badge
  • add license badge
  • move changelog to its own file

Allow Print CPT to function within Gutenberg

Is your enhancement related to a problem? Please describe.
As @adamsilverstein noted in #28:

Test Gutenberg compatibility: no changes are made to the post editor with this plugin so far. The "Print" custom post type added by the plugin opens in the classic edit environment because show_in_rest is not set (Gutenberg requires REST API access to use a CPT). Everything works as expected in my testing.

We'll want to build in support for Gutenberg-based editing in the Print CPT so that publishers who have converted to using Gutenberg for editing can utilize Eight Day Week.

Describe the solution you'd like

  • set show_in_rest to true for the Print CPT
  • test Gutenberg-based Print output exports correctly for InDesign
  • handle any inconsistencies in the Gutenberg-based output for the InDesign export

Designs
n/a

Describe alternatives you've considered
none.

Additional context
Child issue of #19, related to #28.

Add repository template files

Add a GH Actions summary

Is your enhancement related to a problem? Please describe.

Update the plugin to use the GH Actions Report summary used in 10up/cypress-wp-utils#63. It's a very nice presentation of the test results.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

"Publish" metabox toggle becomes disconnected

Describe the bug
See screenshot

Steps to Reproduce

  1. Go to add or edit an Issue
  2. Observe checkbox-looking thing floating off above the Issue Date box (it's a button and it's really the publish metabox)

Expected behavior
I honestly do not know what the original intent was, whether it was to disable expanding/collapsing the box or something else. Based on screenshots, it seems that the toggle arrow (the button) should be hidden, in any case.

Screenshots
image

Environment information
Not relevant

Additional context
PR incoming

There isn't Print section in admin console

I've tried to install plugin v.1.1.2 on WordPress v.5.7.1, v.5.6.2, 5.5.4, 5.5 and 5.4.2 and can't find the section 'Print'

Steps to Reproduce

  1. Install WordPress version 5.5 (I use PHP development environment from https://www.apachefriends.org/index.html)
  2. Open Admin console -> Plugins -> Add new -> find 'Eight Day Week' -> Install Now -> Activate.
  3. Reload Admin console.
  4. There isn't section 'Print' at left pane.

Expected behavior

Screenshots
image

Environment information

  • OS: Windows 7 64-bit
  • Browser and version: Firefox 88.0
  • Theme and version: Twenty Twenty
  • Other installed plugin(s) and version(s): none
  • PHP version: 7.3.27

Test against WordPress 5.5

Is your enhancement related to a problem? Please describe.
Once WordPress 5.5 is released, we'll want to test Eight Day Week to see if any incompatibility issues arise.

Describe the solution you'd like

  • test Eight Day Week on WordPress 5.5
  • open issues for any incompatibilities noted in testing
  • resolve issues identified in testing
  • bump "tested up to" version
  • if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
none

Additional context
none

Can't change print role in the User list screen

Describe the bug

If we use the upper "Change print role" dropdown, the print role of selected users will be removed regardless of which role is choosen.

Steps to Reproduce

  1. Go to Users.
  2. Select some users which have print role set.
  3. Choose a role from the upper print role dropdown.
  4. Click Change.
  5. See the role removed for selected users.
  6. Repeat the steps above but with the lower print role dropdown, don't see the issue.

Expected behavior

Both upper and lower print role dropdown should work flawlessly.

Refresh POT file

Is your enhancement related to a problem? Please describe.
After releasing v1.1.1 and checking the translations on .org, I noticed that some of the strings to be translated could be merged together given how similar they are or did not appear to need translations.

Describe the solution you'd like

Possibly remove?

I believe core removed this message in a recent release, we might update accordingly

Possibly merge?

Designs

n/a

Describe alternatives you've considered

none

Additional context

n/a

Create screencast showing plugin functionality

Is your enhancement related to a problem? Please describe.

A simple screencast (with audio and captions) showing how the plugin can be (configured) used to create print versions and exported to XML would be a nice addition to the readme (GitHub and WP.org) as well as added as a demo video on the marketing site (eightdayweekplugin.com).

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Include images/captions in InDesign export

Newspaper owners could benefit from a feature wherein the images and corresponding captions attached to posts would be sent over as part of the InDesign export as well.

Potential solution would be to create a new sub-folder in the existing export file structure called "ArticleName" and within that, both the article .xml file, as well as either (a) the caption embedded into the image as metadata or as a fallback, (b) the caption info conveyed in another .xml file with some type of association to the image file name.

  • Parse article to extract images and captions
  • Move articles to subfolder
  • Add images to zip file
  • Add captions to exports

We will benefit from an example of an XML with an Image file and a caption (otherwise that's another chunk of time to figure out the format).

Refactor interface with Backbone

There is currently a lot of jQuery/javascript for various browser-based actions–event handling, dom updating, dragging/dropping, autocompletion, ajax saving of data, etc. The use of a proper Backbone/Underscore app would remove a decent amount of duplicated effort and would provide good structure for a more cleanly architected JS codebase.

Test against WordPress 5.9

Is your enhancement related to a problem? Please describe.

Describe the solution you'd like

  • test WP New Relic on WordPress 5.9
  • open issues for any incompatibilities noted in testing
  • resolve issues identified in testing
  • bump "tested up to" version
  • if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
None

Additional context

Can't open exported zip archive because it's "invalid"

Hi!
Today I tested your plugin to write an article about it but I can't unzip the archive with the XML file for InDesign… I get an error, that the "zip file is invalid" (I'm on Windows 10 if it's important).
I use WordPress 4.5-alpha-35853.

Add a "Build release zip" GitHub Action

Is your enhancement related to a problem? Please describe.

  • Add "Build release zip" GitHub Action to generate the release zip before the actual release.
  • Release Instructions are updated to test generated zip before shipping the release.

Reference PR: 10up/autoshare-for-twitter#201

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Import images

hi folks
is there a solution to include the article-images?

Tom

Update all packages and build process

Is your enhancement related to a problem? Please describe.

  • Update all packages to their latest version, replacing deprecated packages
  • update the build process

Describe the solution you'd like
Spring cleaning, but in the winter.

Designs
n/a

Describe alternatives you've considered
none

Additional context
n/a

German translation

Attached is a German translation containing both .po and .mo. I translated to my best knowledge (am a webdev working in an agency heavily focused on print media). There are some interface strings that the plug-in didn't seem to include a translation mechanism for (see
screenshot below). I didn't bother with them for now.

screen shot 2016-06-10 at 09 24 05

Sorry for not making a proper PR, no time!

eight-day-week-de_DE.zip

Test against WordPress 5.8

Is your enhancement related to a problem? Please describe.
Once WordPress 5.8 is released, we'll want to test Eight Day Week to see if any incompatibility issues arise.

Describe the solution you'd like

  • test Eight Day Week on WordPress 5.8
  • open issues for any incompatibilities noted in testing
  • resolve issues identified in testing
  • bump "tested up to" version
  • if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
none

Additional context
Related: #54.

Release version 1.2.1

This issue is for tracking changes for the 1.2.1 release. Target release date: 09 January 2023

Release steps

  • Branch: Starting from develop, cut a release branch named release/1.2.1 for your changes.
  • Version bump: Bump the version number in eight-day-week.php, package.json, package-lock.json and readme.txt if it does not already reflect the version being released. Update both the plugin "Version:" property and the plugin EDW_VERSION constant in eight-day-week.php.
  • Changelog: Add/update the changelog in both readme.txt and CHANGELOG.md.
  • Props: update CREDITS.md file with any new contributors, confirm maintainers are accurate.
  • New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .gitattributes.
  • Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
  • ADD NEW ZIP ACTION AND UPDATE RELEASE INSTRUCTIONS
  • Merge: Make a non-fast-forward merge from your release branch to develop, then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
  • Test: While still on the trunk branch, test for functionality locally. If all is well, push to GitHub.
  • Release: Create a new release, naming the tag and the release with the new version number. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone (e.g. https://github.com/10up/eight-day-week/milestone/8?closed=1). Close the milestone.
  • SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
  • Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/eight-day-week-print-workflow/. This may take a few minutes.
  • Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close 1.2.1 milestone.
  • Punt incomplete items: If any open issues or PRs which were milestoned for 1.2.1 do not make it into the release, update their milestone to 1.3.0 or Future Release.

Custom Post Types

I see that the current post_type is set to pull "posts". I was wondering if there was a way to extend this to support custom post types as well?

We organize some content through CPTs so being able to export those posts as well would be awesome!

Bump WordPress and PHP minimums

Bump WP & PHP Minimums to the following

  • WordPress to 5.7
  • PHP to 7.4
  • Remove any no-longer-needed conditional code for older version support.
  • Take a look at adjusting our testing matrices, if applicable.
  • Bump the minimums in plugin documentation and header fields.

Release version 1.1.1

This issue is for tracking changes for the 1.1.1 release. Target release date: TBD

Pre-release steps

  • update CREDITS.md file with any new contributors, confirm maintainers are accurate
  • review #43 to see if a quick PR/review/merge is feasible, if so proceed, if not punt to v1.2.0
  • test develop against WordPress 5.3, assuming all goes well, update the "tested up to" value to 5.3
  • update GitHub Action workflow to YAML version: https://github.com/10up/eight-day-week/blob/develop/.github/main.workflow

Release steps

  • Starting from develop, cut a release branch named release/1.1.1 for your changes.
  • Version bump: Bump the version number in eight-day-week.php and readme.txt if it does not already reflect the version being released.
  • Changelog: Add/update the changelog in both readme.txt and CHANGELOG.md.
  • Check to be sure any new files/paths that are unnecessary in the production version are included in .gitattributes.
  • Readme updates: Make any other readme changes as necessary. CHANGELOG.md and README.md are geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
  • Merge: Make a non-fast-forward merge from develop to master (git checkout master && git merge --no-ff develop).
  • Release: Create a new release, naming the tag and the release with the new version number. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone (e.g. https://github.com/10up/eight-day-week/milestone/12?closed=1). Close the milestone.
  • SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
  • Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/eight-day-week-print-workflow/. This may take a few minutes.
  • Edit the 1.1.1 milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close 1.1.1 milestone.
  • If any open issues or PRs which were milestoned for 1.1.1 do not make it into the release, update their milestone to 1.2.0 or Future Release.

DateTimeZone Error

I was testing out this plugin for a client and got an error when trying to export.

{"success":false,"data":{"message":"DateTimeZone::__construct(): Unknown or bad timezone ()","_ajax_nonce":"6a4ac07ddc"}}

I replaced this:

/**
 * Builds the file name for the zip
 * Uses the print issue title & day/time
 *
 * @uses get_timezone
 *
 * @return string The zip file name
 */
function get_zip_file_name( ) {
    $date = new \DateTime( 'now', new \DateTimeZone( get_option( 'timezone_string' ) ) );
    return 'Issue ' . $this->issue_title . ' exported on ' . $date->format( 'm-d-y' ) . ' at ' . $date->format( 'h:ia' );
}

with your previous version:

/**
 * Builds the file name for the zip
 * Uses the print issue title & day/time
 *
 * @uses get_timezone
 *
 * @return string The zip file name
 */
function get_zip_file_name( ) {
    date_default_timezone_set( Core\get_timezone() );
    return sprintf( __( 'Issue %1$s exported on %2$s at %3$s', 'eight-day-week' ), $this->issue_title, date( 'm-d-y' ), date( 'h:ia' ) );
}

And the error went away and I could save the Export file. Not sure if you are seeing this on your end, but wanted to let you know.

Better Error Handling

Related to #5, let's add better error handling around the export zip functionality. If we get an error producing the zip file, log that error instead of downloading a corrupt zip.

Run E2E tests on the zip generated by "Build release zip" action.

Is your enhancement related to a problem? Please describe.

We are currently running E2E tests by installing dependencies and building plugin files. This is not the most accurate plugin build that will be shipped during the release. To make E2E tests more accurate and match the plugin build with the release build generated by our deploy action, we should generate a plugin build with the "build zip" action. Running E2E tests on this build will give us more accurate results.

PR for reference: 10up/autoshare-for-twitter#206

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Update taxonomy lables to include field descriptions, back links, etc

Is your enhancement related to a problem? Please describe.

In 6.0 the ability to customise the labels on a taxonomy's edit screen was introduced. This allow for the plugin to use context appropriate labels. For example avoid "URL" in the slug label.

Additionally, the use of labels should be reviewed to ensure any that appear on screen are populated

At least the following labels can be added

  • name_field_description
  • slug_field_description
  • parent_field_description
  • popular_items
  • parent_item
  • parent_item_colon
  • no_terms
  • back_to_items

Designs

After

Screen Shot 2022-05-12 at 3 42 03 pm

Before

Screen Shot 2022-05-12 at 3 40 59 pm

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.