Add `link_to` label to post types

[benoitchantre]

In order to fix the Gutenberg issue 55057, we think the best way would be to add a new label which could be used as it instead of using sprintf

<ToggleControl
	__nextHasNoMarginBottom
	label={
		postType?.labels.singular_name
			? sprintf(
					// translators: %s: Name of the post type e.g: "post".
					__( 'Link to %s' ),
					postType.labels.singular_name
			  )
			: __( 'Link to post' )
	}
	onChange={ () =>
		setAttributes( { isLink: ! isLink } )
	}
	checked={ isLink }
/>

​https://github.com/WordPress/gutenberg/issues/55057

Trac ticket: https://core.trac.wordpress.org/ticket/63534

[riccardodicurti]

Ciao, while reviewing this change, I noticed the array formatting is inconsistent (some entries inline, others multiline).

Is it generally acceptable to update the formatting for consistency when touching these arrays, or is it better to leave existing style unchanged unless it's directly related to the fix?

Just want to align with best practices.

[SirLouen]

@benoitchantre can you explain how this can be displayed or tested?

@ravigadhiyawp commented this during our patch testing session, the thing is after the patch I can't see anything changing with this patch (I was expecting the post/page not capitalized). I wondered if a newer version of Gutenberg is required for this to display or something.

For example after applying the patch, the Page is still capitalized:

Replying to riccardodicurti:

Ciao, while reviewing this change, I noticed the array formatting is inconsistent (some entries inline, others multiline).

Is it generally acceptable to update the formatting for consistency when touching these arrays, or is it better to leave existing style unchanged unless it's directly related to the fix?

Just want to align with best practices.

Generally you should pass the PHPCS. If the line is going to be too long with a single line, you have to move into multiline. You can go multiline if you wish. There is no real rule of thumb other than being PHPCS compliant.

Here as I run the PHPCS checker script:

$ vendor/bin/phpcs src/wp-includes/class-wp-post-type.php
. 1 / 1 (100%)

No issues are found. A different thing will be if they use the short form of array like this:

'link_to_item'             => [
	_x( 'Link to post', 'editor control label' ),
	_x( 'Link to page', 'editor control label' ),
],

Then it will throw the PHPCS error, which is unnaccepted

FILE: src/wp-includes/class-wp-post-type.php
--------------------------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------------------------------
 1029 | ERROR | [x] Short array syntax is not allowed (Universal.Arrays.DisallowShortArraySyntax.Found)
--------------------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
--------------------------------------------------------------------------------------------------------

[benoitchantre]

@SirLouen This ticket is a first step to fix the issue in Gutenberg. Once added to trunk (if approved), some changes will be needed in Gutenberg to close the Gutenberg issue.

[SirLouen]

Replying to benoitchantre:

@SirLouen This ticket is a first step to fix the issue in Gutenberg. Once added to trunk (if approved), some changes will be needed in Gutenberg to close the Gutenberg issue.

Ok, this is what I was expecting, but maybe there was already the patch in Gutenberg to do the full testing (which I see it's not ready yet)

[wildworks]

The only thing we can test now is to make sure that this new field is included in the REST API.

After appliying the patch, open the post editor and run the following in your browser console:

wp.data.select('core').getPostType('post').labels

You will see the new field included in the response.

To reflect this new field in the UI, we will need to submit a new PR in the Gutenberg repository and update the following:

​https://github.com/WordPress/gutenberg/blob/7d045178de5879471793a627efeadfc1225073cb/packages/block-library/src/post-featured-image/edit.js#L258-L264

However, I would like to suggest a different approach than adding a new field. See: ​https://github.com/WordPress/gutenberg/issues/55057#issuecomment-3095164735

[wildworks]

Response when "wp.data.select('core').getPostType('post').labels" is executed in the browser console

[sachinrajcp123]

Testing Instructions: 1. Apply the patch. 2. Register a custom post type with: 'labels' => array( 'link_to' => ( 'Link to Book' ) ) 3. Verify the label is available via REST API and used in Gutenberg UI. 4. For post types without link_to, confirm fallback label shows “Link to <singular_name>”.

[wildworks]

I prefer to use a generic label rather than extending post type labels.

See ​https://github.com/WordPress/gutenberg/issues/55057#issuecomment-3121386400

There are two reasons I'm reluctant to expand post type labels:

• The link_to_item field will be only for the Featured Image block and is not currently used for any other purpose.
• It's possible that the Featured Image block will be used in custom post types. In that case, users would need to add the link_to_item field for all register_post_type() functions in order for the Featured Image block to display the appropriate toggle label.

[wildworks]

I prefer to use a generic label rather than extending post type labels.

I prefer this approach and would love your feedback.

​https://github.com/WordPress/gutenberg/issues/55057#issuecomment-3341307726