feat(indesign-export): platform + post types settings, en-dash fix

[miguelpeixe]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

Fixes two bugs in the InDesign Tagged Text export and adds two site-level settings under Newspack > Settings > Print > Adobe InDesign.

• Platform mismatch on macOS. The exporter hardcoded the <ASCII-WIN> header on every file, which caused InDesign on Mac to render the tagged-text markup literally instead of interpreting it. A new "Header platform" setting controls the header:

  • Auto-detect (per export) — default. Sniffs the User-Agent of whoever clicks Export and emits the matching <ASCII-MAC> / <ASCII-WIN> header.
  • Mac — always emit <ASCII-MAC>.
  • Windows — always emit <ASCII-WIN>.

  A newspack_indesign_export_platform filter is available for code-level overrides.

• En-dash silently converted to em-dash. Every en-dash (–, U+2013) in post content was being rewritten to an em-dash (U+2014). Each dash now maps to its own code point.

• Choose which post types are exportable. A new "Available post types" setting lets admins pick which post types show the export action on their list screens. The picker lists every public post type with an admin UI (excluding attachments), so plugins that register custom post types — events, classifieds, etc. — can opt in without code. The default stays at post to preserve current behavior. The existing newspack_indesign_export_supported_post_types filter still runs after the setting and can extend or restrict the result.

Closes NPPM-2813.

How to test the changes in this Pull Request:

1. Enable the optional InDesign Export module: visit Newspack > Settings > Print > Adobe InDesign and toggle "Enable InDesign Export" on. New "Header platform" and "Available post types" sections appear.

Header platform

2. Confirm the platform dropdown defaults to Auto-detect (per export).
3. Create a post containing an en-dash, an em-dash, and a double-hyphen (e.g. before – after, before — after, before -- after).
4. From the posts list, choose "Export as Adobe InDesign". Open the downloaded .txt. With Auto-detect, the first line should be <ASCII-MAC> on macOS or <ASCII-WIN> on Windows. The body should contain before <0x2013> after for the en-dash and before <0x2014> after for the em-dash and the double-hyphen.
5. Switch the setting to Mac, re-export, and confirm the first line is <ASCII-MAC> regardless of your OS. Repeat with Windows and confirm <ASCII-WIN>.

Available post types

6. Confirm the "Available post types" section lists every public post type with an admin UI on your site (post, page, and any active CPTs). Attachments should not appear.
7. Confirm only Posts is checked by default (preserves prior behavior).
8. Visit the Pages list — the "Export as Adobe InDesign" bulk action and row action should be absent.
9. Check the Pages box. Reload the Pages list — the export actions should now appear. Export a page and confirm the file content matches the post output format.
10. Confirm both settings persist across page reloads.

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

[Copilot]

Pull request overview

This PR fixes InDesign Tagged Text exports by making the platform header configurable per export and correcting en-dash conversion.

Changes:

• Adds a platform conversion option to emit <ASCII-MAC> or <ASCII-WIN>.
• Detects platform from the exporting request’s User-Agent and exposes a filter override.
• Corrects en-dash mapping from <0x2014> to <0x2013> and adds unit coverage.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
includes/optional-modules/class-indesign-exporter.php	Detects export platform and passes it into conversion.
includes/optional-modules/indesign-export/class-indesign-converter.php	Adds platform-aware header output and fixes en-dash conversion.
tests/unit-tests/indesign-exporter/indesign-exporter.php	Adds tests for explicit platform headers and dash conversion.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 6 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 6 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (3)

includes/optional-modules/class-indesign-exporter.php:162

• Filtering the saved setting with post_type_exists() breaks the bulk action for typical plugin-defined post types. InDesign_Exporter::init() is called immediately when this file is included from includes/class-newspack.php, before the normal init hook where most CPTs are registered; at that point saved CPT slugs are filtered out, so bulk_actions-edit-{$post_type} and its handler are never registered for those post types.

		return array_values(
			array_filter(
				$value,
				static function ( $slug ) {
					return is_string( $slug ) && post_type_exists( $slug );
				}

includes/optional-modules/class-indesign-exporter.php:132

• Once supported post types come from this setting, the bulk export path still uses the hard-coded edit_posts capability in handle_bulk_action(). That rejects users who can edit an enabled CPT with custom capabilities but do not have post editing rights, and it does not align the permission check with the selected post type; use the post type’s capability or per-post edit_post checks when exporting non-post content.

	public static function get_supported_post_types() {
		$supported_post_types = self::get_post_types_setting();

includes/wizards/newspack/class-print-section.php:108

• The update endpoint accepts any existing post type, including slugs deliberately excluded from the “Available post types” list (such as attachment or product). A direct REST request can therefore persist a hidden post type and enable export actions for it; validate against get_available_post_types() (or the same exclusion list) before saving rather than only checking post_type_exists().

			$post_types = array_values(
				array_unique(
					array_filter(
						$post_types,
						static function ( $slug ) {
							return is_string( $slug ) && post_type_exists( $slug );
						}