Add a token for publication status

Tested both tokens with Linkit, they work fine.

Coincidentally needed the exact same for Linkit, patch does what it says on the tin and has tests, think this can be RTBC!

1. +++ b/core/modules/node/node.tokens.inc
   @@ -51,6 +51,14 @@ function node_token_info() {
   +  $node['status'] = [
   +    'name' => t('Status'),
   +    'description' => t('The publication status of the node (0 or 1).'),
   +  ];
   

   I'm not sure that this is that useful as a token. Why do we want to add it?

2. +++ b/core/modules/node/node.tokens.inc
   @@ -51,6 +51,14 @@ function node_token_info() {
   +  $node['published_status'] = [
   +    'name' => t('Published'),
   +    'description' => t('The publication status of the node ("Published" or "Unpublished").'),
   +  ];
   
   @@ -167,6 +175,14 @@ function node_tokens($type, $tokens, array $data, array $options, BubbleableMeta
   +          $replacements[$original] = $node->isPublished() ? t('Published') : t('Unpublished');
   

   The one concern I have with this is how we also account for the content_moderation module. If you have that module enabled I think you'd want it to override this token and put its status label there. Or at least have it available too.

This works well for me. Incidentally, I also wanted this for Linkit!

I agree with mpp that this is still very useful even without the content_moderation info and that the content_moderation state should be handled in a follow-up issue. We're also using content_moderation but for this purpose we just want the published status.

This is working well for me too!

I'm also using it for LinkIt, but also think this would work well for other circumstances where a list of content is provided via an autocomplete.

--

The one concern I have with this is how we also account for the content_moderation module. If you have that module enabled I think you'd want it to override this token and put its status label there. Or at least have it available too.

I also agree that content moderation should be a separate issue. The base concept of published / unpublished exists whether content_moderation is used or not.

I'm not sure that this is that useful as a token. Why do we want to add it?

I imagine 'status' could be useful for modules like Rules Tokens .. where logic based decisions are based on token input. Would be good to get confirmation whether this assumption is true though.

Tagging for product manager review for #16.1 - it's also not clear to me how useful this is to provide in core.

Patch in #10 needs a reroll against 9.3.x.

Added tag and put on "Needs Work"

Added reroll of patch #10 for Drupal 9.3.x.

Addressed failed test of patch #25.

People looking for content moderation states token: #3225851: Add tokens for content moderation state

The patch in #27 worked great for me for Linkit. Thank you!

The patch at #27 worked for us on LinkIt. Would love to get this into core!
Cheers

Tested #27 and it works

Uploading a tests-only patch and copy of #27 if the tests-only fails and regular passes I'll mark RTBC

Everything looks good.

Putting back as it seems to be a random failure with quickedit.

+++ b/core/modules/node/node.tokens.inc
@@ -51,6 +51,14 @@ function node_token_info() {
+  $node['status'] = [
+    'name' => t('Status'),
+    'description' => t('The publication status of the node (0 or 1).'),
+  ];

We've still not provided reasons as to why this useful. See #16 / #17

The text version seems useful to people using linkit but #22 is still unanswered so setting back to needs review.

+++ b/core/modules/node/tests/src/Kernel/NodeTokenReplaceTest.php
@@ -67,6 +67,8 @@ public function testNodeTokenReplacement() {
+    $tests['[node:status]'] = (int) $node->isPublished();
+    $tests['[node:published_status]'] = $node->isPublished() ? t('Published') : t('Unpublished');

@@ -88,6 +90,8 @@ public function testNodeTokenReplacement() {
+    $metadata_tests['[node:status]'] = $base_bubbleable_metadata;
+    $metadata_tests['[node:published_status]'] = $base_bubbleable_metadata;

@@ -108,6 +112,28 @@ public function testNodeTokenReplacement() {
+    $tests['[node:status]'] = (int) $node->isPublished();
+    $tests['[node:published_status]'] = $node->isPublished() ? t('Published') : t('Unpublished');

Shouldn't we be more explicit here about what we expect? And remove the t() usage in tests?

We know exactly what we expect, we don't need to use the node API to get the expected values. Copying the implementation code as test code seems wrong.

Also agree that the integer-based tokens seem unlikely to be useful enough to be in core.

Re-reading the issue summary this seems like it probably should be handled by custom module. Mentions linkit so maybe that's where it should go?

Moving PNMI as don't know where else to put it.

Re-reading the issue summary this seems like it probably should be handled by custom module. Mentions linkit so maybe that's where it should go?

Some of the other comments (17, 21) mention other contexts where it would be useful to have a token that indicates the node status: Rules ("where logic based decisions are based on token input") and content moderation notifications (though #3225851: Add tokens for content moderation state will usually be more useful for folks than the published status). If there is more than one external context where this is relevant, it makes sense to put this in core: we wouldn't want to have to tell someone who's looking to use this in Rules that they need to install LinkIt!

An argument for not putting it in core is that folks might want to change the label of this output. For example, if they wanted "Unpublished" to render as a more comprehensible "Not published."

Implementing this in custom code, or in the LinkIt contrib module, is a facile change, but maybe there's an architectural rationale for putting it in core, too? The node entity is provided by core, node status (published/unpublished) is a paradigm originating in core, and the node module in core already has a number of similar tokens defined.

I've updated the issue description to better capture the community's conversation about this.

Thanks! Unfortunately I can't review it since I worked on it some. Will have to see if someone else can.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

The attached patch:
1. Removes the integer-based token, since multiple commenters above cannot establish its value in core (catch in #22, alexpott in #39, acbramley in #40).
2. Updates the test coverage to explicitly look for 'Published' and 'Unpublished' text, and removes the t() usage, per #40.
3. Declares usage of FormattableMarkup to make syntax checking happy (#47).

Setting back to "Needs review"!

I can confirm the patch works. Screenshots attached.

Hm, I see not many people found the numeric token useful in comments but do we have similar tokens where we only expose a derivative textual value of the internal value in tokens and not the base value? It seems like an odd pattern to me.

+1, patch working as expected.

do we have similar tokens where we only expose a derivative textual value of the internal value in tokens and not the base value. It seems like an odd pattern to me.

Yes, a number of the tokens in node.tokens.inc do this: the "author" token returns the username rather than the UID, and the "changed" and "created" tokens return formatted dates, rather than raw timestamps.

The Linkit use case seems suffcient for adding the proposed few lines of code. Added a CR to inform folks about the new token.

Committed b23fad5 and pushed to 11.x. Thanks!

Awesome, thanks for getting that merged to 11.x !

Could we also get that change backported for 10.2 ?

10.2.x will be branched from 11.x later this year and this will be in there 😊