Post Type Archive options meta box

[sybrew]

From: Eelco's plugin review

New feature for options that allow custom titles and descriptions for non-editable query types, like 404 and search.

[sybrew]

Status update...

Title output:
The following filters are already present, these will be used for further manipulation through the planned extension:

Outdated filter example

/** 
 * 404 title filter.
 * @since 2.5.2
 */
add_filter( 'the_seo_framework_404_title', 'my_404_title' );
function my_404_title( $default = '404' ); {
    //* Will be escaped on output.
    return 'four oh four';
}

/**
 * Search title filter.
 * @since 2.6.0
 * @note The default title can be translated.
 */
add_filter( 'the_seo_framework_search_title', 'my_search_title' );
function my_search_title( $default_i18n ='Search results for:' ) {
    //* Will be escaped on output.
    return 'Custom Search:';
}

Description output:
On Search and 404, no description will be output currently to save resources.
In almost all cases, these pages will not rank well on SERP.
See: front end output code.

Facebook generates its own description from the content (like Google does) on pages without any description present.

Plausible resolutions:

1. Move the 404/Search check within the the_description() method (or further); however, this requires the filter to be used prior to the output or be moved (which might even improve performance when a filter is used).
2. Let the extension output its own meta tag. This might lead to bugs or incompatibilities if changes do happen (inconsistency).

Other output:
Images, and many other items that can be outputted, are currently not.
This is to save resources (404 and search pages are usually not cached).

Plausible resolution on 404: Transient cache for the whole 404 output.
Plausible resolution on Search: none yet — it's dynamic (in a certain sense).

I do not believe that there's any interest in any other output apart from the title and description.
Please provide feedback on use cases if otherwise.

[sybrew]

From Eusebiu's suggestions:
It would also be great if CPT registered Archives and other archive types without UI would contain its own metabox.

This metabox could be added to the SEO Settings page (or a new tab) with a default (or stripped) SEO metabox.
The metabox should have a CPT switcher at the top right/left, to prevent overpopulating the settings page. This switcher will allow you to select which CPT you wish to populate the SEO fields for.
How this would work without JavaScript is still in consideration.

[sybrew]

Here are filters which you can use before this is implemented.

Filter placeholder example: (click me)

/**
 * Filters the raw titles generated by The SEO Framework for non-queryable pages.
 * 
 * Doesn't require escaping.
 * 
 * @param string     $title The filter title.
 * @param array|null $args  The query arguments. Accepts 'id' and 'taxonomy'.
 *                          Is null to autodetermine query.
 * @return string The raw generated title output.
 */
add_filter( 'the_seo_framework_title_from_generation', function( $title, $query ) {

	// We don't want to filter predefined queries. This will conflict in breadcrumbs otherwise.
	if ( null === $query ) return $title;

	$tsf = \the_seo_framework();

	if ( $tsf->is_404() ) {
		// Overwrite 404 title here. Default is shown.
		$title = $tsf->get_static_404_title();
	} elseif ( $tsf->is_search() ) {
		// Overwrite search title here. Default is shown.
		$title = $tsf->get_generated_search_query_title();
	} elseif ( $tsf->is_real_front_page() ) {
		// Overwrite front page title here. Default is shown.
		$title = $tsf->get_static_front_page_title();
	} elseif ( $tsf->is_archive() ) {
		// Overwrite archive page titles here. Default is shown.
		$title = $tsf->get_generated_archive_title();
	} elseif ( $tsf->is_singular() ) {
		// Overwrite singular page titles here. Default is shown.
		$title = $tsf->get_generated_single_post_title();
	}

	return $title;
}, 10, 2 );

Real world example: (click me)

/**
 * Filters the raw titles generated by The SEO Framework for non-queryable pages.
 * 
 * Doesn't require escaping.
 * 
 * @param string     $title The filter title.
 * @param array|null $args  The query arguments. Accepts 'id' and 'taxonomy'.
 *                          Is null to autodetermine query.
 * @return string The raw generated title output.
 */
add_filter( 'the_seo_framework_title_from_generation', function( $title, $query ) {

	// We don't want to filter predefined queries. This will conflict in breadcrumbs otherwise.
	if ( null === $query ) return $title;

	$tsf = \the_seo_framework();

	if ( $tsf->is_404() ) {
		// Overwrite 404 title here.
		$title = '404 Not Found';
	} elseif ( $tsf->is_search() ) {
		// Overwrite search title here. Visitor-fed variable, best to pre-escape.
		$title = sprintf( 'Search: “%s”', \get_search_query() );
	} elseif ( $tsf->is_real_front_page() ) {
		// Use default title.
	} elseif ( $tsf->is_archive() ) {
		if ( is_post_type_archive( 'product' ) ) {
			$title = 'Product overview';
		} else {
			// Use default title.
		}
	} elseif ( $tsf->is_singular() ) {
		// Use default title.
	}

	return $title;
}, 10, 2 );

[sybrew]

I punted this to 3.4.0. I must send out 3.3.0 sooner.

[remcokalf]

I also am waiting for titles+descriptions+robots for Custom Post Types and Custom Post types archive pages. But I am also missing the same for Custom Taxonomies. Like in Yoast. My sites often rely heavily on CPTs and Custom Taxonomies.

Currently the absense of default CPT, CPT archive and Tax term title/meta/settings is the only thing holding me back to move from Yoast to TSF for larger sites.

[ooksanen]

Any news on this?

The above filters, or the ones in API docs, don't seem to work in 4.0.5
EDIT: CPT needs to be set to public for the filters to work

[sybrew]

Pushed to 4.2.0, because we need an update out quickly to support the new Core sitemap functionality (WP 5.5), due August 2020.

[sybrew]

From my comment above

How this would work without JavaScript is still in consideration.

I'm considering dropping non-JS support altogether, much as WordPress Core has with the Gutenberg (Block Editor) project. Dropping non-JS allows me to offload processing to the browser instead of redundantly pre-processing on the server. I have already dropped most of the title and description pre-processing.

The image below shows how the Post SEO Settings meta box looks with JS disabled (in 4.2.0-dev-39). Open Graph and Twitter titles still have redundantly prefilled titles, but the JS overrides that, anyway.

Ultimately, dropping support shrinks the codebase and increases maintainability.

I'll try to make this feature non-JS capable, but I'll forgo that effort at the earliest inconvenience.

[sybrew]

In TSF v4.0.0 (Sep 2019), I brought term support: On the term-edit screens, you can edit the title, description, robots, canonical URL, redirect, and social meta.

In TSF v4.1.0 (Aug 2020), I brought support for taxonomies: All taxonomies have global robots (noindex/nofollow/noarchive) settings.

In TSF v4.2.0 (ETA Nov 2021), I'll bring Post Type Archive (PTA) settings. Planned, I'll include all options terms have. Akin to what WordPress calls those internally, the meta-box will be named "Post Type Archive Settings." Even though that's not a name used colloquially among WordPress users to refer to these types of pages — they call it "Archives" — I prefer my own sanity.

TSF will store the data with all other settings within The SEO Framework's primary Key-Value Store (autodescription-site-settings, filter the_seo_framework_site_options, constant THE_SEO_FRAMEWORK_SITE_OPTIONS). This agglomeration will cause us to "needlessly" load all PTA SEO data during every admin/front-page request, which might cause slight memory/performance issues on sites that have dozens of PTAs; but, we can always migrate those settings later when the need calls.

The "Blog" page is a page — as such, it already has (most of) these settings available. If the blog page is the home page, then the homepage settings meta box should already be sufficient.

[sybrew]

Attached is a preview of how the box will appear. no-JS support works well, too.

Description, social input, and robots listeners still need to be implemented. Commits will follow in the next few days.
I'm still pondering how I'm going to convey that a post type is excluded via the exclusion settings.

[sybrew]

Provisioned layout (visibility tab) with multiple post type archives on the site:

Provisioned layout (social tab) with only one post type archive on the site:

[quadcom]

Please oh please can we get this put in pronto!

EDIT: Sorry, reading this a bit more it looks like this is really going to happen soon. I wish you could see the smile on my face at the moment!

Thank you, Thank you, Thank you, Thank you!

[sybrew]

In a30f46a, I added the final piece of this puzzle: "What would happen when the post type is disabled?" Well, this:

I thought about disabling the select-option and adding a hint, but common HTML select-styling wouldn't allow me to convey why it was disabled. So, I opted for removing the editor and putting in place a warning message.

This feature took 14 days, 140 hours, 15 commits, and 100 file changes to complete. You can view the timeline here: 64b64e2...0ae8fc3.

I think that'll make for a nice feature-packed 4.2.0 update. So, I'll punt most (all?) other items from the milestone. A complete code review will still occur, for I found a few bugs in need of resolving. As always, I'll test the update on my networks to find errors spawn and review changes in Google Search Console et al.

Fun fact: If you hit space in a Post Type Archive's title with Archive Title Prefixes enabled (under Title Settings), you'll find two floating titles. This feature was developed a couple of years back but never utilized (and I honestly forgot I coded it). The behavior is intentional, for your space will be removed on-save anyway. I consider it a bug that Terms (Category/Tags) do not behave the same.

[bonakor]

Hi,
Would it be possible to get it for the Custom Taxonomies too,please?

[sybrew]

Hi @bonakor,

This feature works with any registered Post Type Archive.
TSF already supports all public terms. If you do not have an interface for those, they may be registered as non-public.

Please open a support topic and share the code you used to register the custom taxonomy so we can investigate the issue: https://tsf.fyi/support/tsf/new-topic.