Merge branch 'develop'

Author: michael-sumner

CHANGELOG.md

@@ -13,6 +13,16 @@ All notable changes to this project will be documented in this file, per [the Ke
 ### Security
 -->
 
+<!-- ... -->
+## [1.13.0] - 2025-06-07
+
+### Fixed
+* Platform Script by @michael-sumner in #86
+
+### Changed
+* i18n improvements by @michael-sumner in #84 and #85
+* Chore updates by @michael-sumner in #87
+
 <!-- ... -->
 ## [1.12.1] - 2025-03-21
 
@@ -154,6 +164,7 @@ All notable changes to this project will be documented in this file, per [the Ke
 - Initial plugin release
 
 [Unreleased]: https://github.com/scoredetect/timestamps/compare/trunk...develop
+[1.13.0]: https://github.com/scoredetect/timestamps/compare/1.12.1...1.13.0
 [1.12.1]: https://github.com/scoredetect/timestamps/compare/1.12.0...1.12.1
 [1.12.0]: https://github.com/scoredetect/timestamps/compare/1.11.0...1.12.0
 [1.11.0]: https://github.com/scoredetect/timestamps/compare/1.10.0...1.11.0

CONTRIBUTING.md

@@ -26,38 +26,36 @@ The `develop` branch is the development branch which means it contains the next
 
 ## Release instructions
 
-Open a [new blank issue](https://github.com/scoredetect/timestamps/issues/new) with `[Release] 1.12.1`, then copy and paste the following items, replacing version numbers and links to the milestone.
+Open a [new blank issue](https://github.com/scoredetect/timestamps/issues/new) with `[Release] 1.13.0`, then copy and paste the following items, replacing version numbers and links to the milestone.
 
-- [ ] 1. Branch: Starting from `develop`, cut a release branch named `release/1.12.1` for your changes.
+- [ ] 1. Branch: Starting from `develop`, cut a release branch named `release/1.13.0` for your changes.
 - [ ] 2. Version bump: Bump the version number in `timestamps.php`, `package.json`, `package-lock.json`, `readme.txt`, and any other relevant files if it does not already reflect the version being released. In `timestamps.php` update both the plugin "Version:" property and the plugin `SDCOM_TIMESTAMPS_VERSION` constant.
-- [ ] 3. Changelog: Add/update the changelog in `CHANGELOG.md`, ensuring to link the [1.12.1] release reference in the footer of `CHANGELOG.md` (e.g., https://github.com/scoredetect/timestamps/compare/1.12.1-1...1.12.1).
+- [ ] 3. Changelog: Add/update the changelog in `CHANGELOG.md`, ensuring to link the [1.13.0] release reference in the footer of `CHANGELOG.md` (e.g., https://github.com/scoredetect/timestamps/compare/1.13.0-1...1.13.0).
 - [ ] 4. Props: Update `CREDITS.md` file with any new contributors, confirm maintainers are accurate.
 - [ ] 5. 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.
 - [ ] 6. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in `.distignore`.
-- [ ] 7. POT file: Run `wp i18n make-pot . lang/timestamps.pot` and commit the file. In case of errors, try to disable Xdebug.
-- [ ] 8. Release date: Double check the release date in the `CHANGELOG.md` file.
-- [ ] 9. Merge: Merge the release branch/PR into `develop`, then make a non-fast-forward merge from `develop` into `main` (`git checkout main && git merge --no-ff develop`). `main` contains the stable development version.
-- [ ] 10. Test: While still on the `main` branch, test for functionality locally.
-- [ ] 11. Push: Push your `main` branch to GitHub (e.g. `git push origin main`).
-- [ ] 12. [Check the _Build and Tag_ action](https://github.com/scoredetect/timestamps/actions/workflows/build-and-tag.yml): a new tag named with the version number should've been created. It should contain all the built assets.
-- [ ] 13. Release: Create a [new release](https://github.com/scoredetect/timestamps/releases/new):
+- [ ] 7. Release date: Double check the release date in the `CHANGELOG.md` file.
+- [ ] 8. Merge: Merge the release branch/PR into `develop`, then make a non-fast-forward merge from `develop` into `main` (`git checkout main && git merge --no-ff develop`). `main` contains the stable development version.
+- [ ] 9. Test: While still on the `main` branch, test for functionality locally.
+- [ ] 10. Push: Push your `main` branch to GitHub (e.g. `git push origin main`).
+- [ ] 11. [Check the _Build and Tag_ action](https://github.com/scoredetect/timestamps/actions/workflows/build-and-tag.yml): a new tag named with the version number should've been created. It should contain all the built assets.
+- [ ] 12. Release: Create a [new release](https://github.com/scoredetect/timestamps/releases/new):
   * **Tag**: The tag created in the previous step
-  * **Release title**: `Version 1.12.1`
+  * **Release title**: `Version 1.13.0`
   * **Description**: Release changelog from `CHANGELOG.md` + `See: https://github.com/scoredetect/timestamps/milestone/#?closed=1`
-- [ ] 14. SVN: Wait for the [GitHub Action](https://github.com/scoredetect/timestamps/actions/workflows/push-deploy.yml) 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.
-- [ ] 15. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/timestamps/. This may take a few minutes.
+- [ ] 13. SVN: Wait for the [GitHub Action](https://github.com/scoredetect/timestamps/actions/workflows/push-deploy.yml) 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.
+- [ ] 14. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/timestamps/. This may take a few minutes.
 
 ## Hotfix release instructions
 
 There may be cases where we have an urgent/important fix that ideally gets into a release quickly without any other changes (e.g., a "hotfix") so as to reduce (1) the amount or testing before being confident in the release and (2) to reduce the chance of unintended side effects from the extraneous non-urgent/important changes.  In cases where code has previously been merged into `develop` but that ideally is not part of a hotfix, the normal release instructions above will not suffice as they would release all code merged to `develop` alongside the intended urgent/important "hotfix" change(s).  In case of needing to release a "hotfix" the following are the recommended steps to take.
 
-1. Branch: Starting from `main`, cut a hotfix release branch named `hotfix/1.12.1` for your hotfix change(s).
+1. Branch: Starting from `main`, cut a hotfix release branch named `hotfix/1.13.0` for your hotfix change(s).
 1. Version bump: Bump the version number in `timestamps.php`, `package.json`, `readme.txt`, and any other relevant files if it does not already reflect the version being released.  In `timestamps.php` update both the plugin "Version:" property and the plugin `SDCOM_TIMESTAMPS_VERSION` constant.
-1. Changelog: Add/update the changelog in `CHANGELOG.md` and `readme.txt`, ensuring to link the [1.12.1] release reference in the footer of `CHANGELOG.md` (e.g., https://github.com/scoredetect/timestamps/compare/1.12.1-1...1.12.1).
+1. Changelog: Add/update the changelog in `CHANGELOG.md` and `readme.txt`, ensuring to link the [1.13.0] release reference in the footer of `CHANGELOG.md` (e.g., https://github.com/scoredetect/timestamps/compare/1.13.0-1...1.13.0).
 1. Props: Update `CREDITS.md` file with any new contributors, confirm maintainers are accurate.
 1. 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.
 1. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in `.distignore`.
-1. POT file: Run `wp i18n make-pot . lang/timestamps.pot` and commit the file.
 1. Release date: Double check the release date in both changelog files.
 1. Merge: Merge the release branch/PR into `main`.  `main` contains the stable development version.
 1. Test: While still on the `main` branch, test for functionality locally.

includes/blocks/timestamp-post/register.php

@@ -7,9 +7,6 @@
 
 namespace SDCOM_Timestamps\Blocks\TimestampPost;
 
-use function SDCOM_Timestamps\Utils\is_block_editor_active;
-use function SDCOM_Timestamps\Utils\is_platform_script_in_content;
-
 /**
  * Hooks into WordPress lifecycle.
  */
@@ -22,10 +19,7 @@ function setup() {
  * Enqueue scripts.
  */
 function scripts() {
-	// Only enqueue the script if the block is being used and the platform script is not already in the content.
-	if ( ! is_platform_script_in_content() && is_block_editor_active() ) {
-		wp_enqueue_script( 'sdcom-timestamp-post-block', 'https://platform.scoredetect.com/widgets.js', array(), SDCOM_TIMESTAMPS_VERSION, true );
-	}
+	wp_enqueue_script( 'sdcom-timestamp-post-block', 'https://platform.scoredetect.com/widgets.js', array(), SDCOM_TIMESTAMPS_VERSION, true );
 }
 
 /**

includes/utils.php

@@ -49,72 +49,6 @@ function is_authenticated() {
 	return ! empty( $timestamps_api_key );
 }
 
-/**
- * Checks if the Block Editor is active.
- *
- * @since 1.0.0
- * @return bool Returns true if the Block Editor is active, false otherwise.
- */
-function is_block_editor_active() {
-
-	$classic_editor_replace = get_option( 'classic-editor-replace' );
-
-	// We assume that the Block Editor is active, whilst the Classic Editor plugin never existed.
-	if ( empty( $classic_editor_replace ) ) {
-		return true;
-	}
-
-	// If the Classic Editor plugin is installed and activated, we check the setting.
-	if ( $classic_editor_replace === 'block' ) {
-		return true;
-	}
-
-	// If the Classic Editor plugin is installed and activated, we check the setting.
-	if ( $classic_editor_replace === 'classic' ) {
-		return false;
-	}
-
-	// We assume that the Block Editor is active by default.
-	return true;
-}
-
-/**
- * Checks if the platform script is in the post content.
- *
- * @since 1.0.0
- * @param WP_Post|int|null $post Optional. Post to check. Defaults to the current post.
- * @return bool Returns true if the platform script is in the post content, false otherwise.
- */
-function is_platform_script_in_content( $post = null ) {
-
-	$post = get_post( $post );
-
-	if ( empty( $post ) ) {
-		return false;
-	}
-
-	$content = $post->post_content;
-
-	if ( empty( $content ) ) {
-		return false;
-	}
-
-	$content = new \WP_HTML_Tag_Processor( $content );
-
-	$script = $content->next_tag(
-		array(
-			'tag_name' => 'script',
-			'src'      => 'https://platform.scoredetect.com/widgets.js',
-		)
-	);
-
-	if ( ! empty( $script ) ) {
-		return true;
-	}
-
-	return false;
-}
-
 /**
  * Checks if the WooCommerce plugin is active.
  *