Remove per page redirect option if using redirect manager

Hello!

I understand what you want to achieve.

We always saw these options as complementary, and we haven’t ever given it much thought beyond that. Thank you for shedding some new light onto this.

Unfortunately, there’s no proper way to disable this functionality in TSF. Disabling the redirect callback doesn’t make the rest of the plugin aware, because we never built it with that in mind:

1. There is no API to hide fields. You must do this via injecting CSS and JS into the administrative dashboard.

• Hiding the fields will still allow a user to set redirects (that’s called hacking… red flag!) unless you obstruct this in WordPress’ meta-saving API.
• Hiding the fields will still maintain whatever may have been inputted earlier unless you purge the database. This results in a loss of data you may want to access later.

• The redirect item is still visible in the SEO Bar. Until TSF v4.0, there’s no way to modify the SEO Bar.
• In the next update, redirects are also coming to terms, like categories and tags, adding onto that complexity.

To fix all of the above (and possible bugs that may arise), you’ll need a big blob of both destructive and obstructive functionality which you’ll need to maintain actively.

I think, for now, it’s best to educate your clients to only use the Redirection plugin for redirecting, and not the respective SEO meta input fields. The SEO Bar will exclaim when a redirection is set, so that’s easily spotted.

With all that said, this snippet will disable redirecting of TSF, without hiding its presence. It’ll prevent your clients from making that mistake, regardless:

add_action( 'the_seo_framework_after_front_init', function() {
	remove_action( 'template_redirect', [ the_seo_framework(), '_init_custom_field_redirect' ] );
} );

We’re looking into making the meta fields modular (in code). That’ll be a huge task, as we have to account for all issues above: loss of data, disabling setting those fields, etc. So, don’t hold your breath for an easy solution just yet.

Thank you so much for your thorough response, it was very informative.

These are going to be fresh websites, so I have the luxury of not needing to worry about legacy data from redirects, just setting them up for success in the future.

The snippet you provided worked exactly as described. I’ve done a few extra things to make functional expectations clear to users. I’m going to post the code, in case someone else is having the same issue. This was done quickly so forgive any code slop.

You did mention some additional flexibility with the SEO Bar coming in the next major release. Is there somewhere I can follow the progress of this version?

Anyways, for those who find this ticket and are wanting to make this a bit more user friendly here is what I did.

In functions.php

This snippet is the one provided above by the Plugin Author

add_action( 'the_seo_framework_after_front_init', function() {
	remove_action( 'template_redirect', [ the_seo_framework(), '_init_custom_field_redirect' ] );
} );

This snippet will allow you to add a script to just load on the screens for creating posts/pages and the screen for editing posts/pages (custom post types should also be covered). You will need to change the path on the enqueue to wherever you want to keep your js files. As Sybre mentioned above, this snippet works now, but when they extend this to terms it will need to be tweaked

function admin_posts_enqueue_admin_script( $hook ) {

    if ( 'post.php' === $hook || 'post-new.php' === $hook ) {
        wp_enqueue_script( 'admin_tsf_redirect_disable', get_template_directory_uri() . '/assets/src/temp/admin-tsf-redirect-disable.js', array('jquery'), '2.0' );
    }else{
        return;
    }
}
add_action( 'admin_enqueue_scripts', 'admin_posts_enqueue_admin_script' );

Custom JS file referenced from the enqueue

This is using jquery, but that is by no means required, should be easy enough to recreate in vanilla.

( function( $ ) {

    $(document).ready(function(){
        $('#autodescription_redirect')
            .attr('disabled', 'disabled')
            .attr('placeholder', 'This field has been disabled.*')
            .after('<p>* The redirect field here may conflict with the redirect manager installed on this site. While this has been disabled here, you will have full ability to <a target="_blank" href="/wp-admin/tools.php?page=redirection.php">manage redirects here</a>.</p>');
    });

} )( jQuery );

Hello again ??

Yes, I don’t have that luxury, so I go over all the negatives! I’m glad you’ve found a compelling way around those facts and shared that with us. Thank you very much!

The next update (TSF v4.0) is currently under Release Client-testing. It means that we’ve frozen the API, and it’s unlikely to change unless a destructive bugfix needs to be implemented. As of now, we’re inspecting the SEO performance on our networks, and when we’re satisfied with the results, we will push the update to www.remarpro.com. ETA: 6 to 13 days from now.

This can all be seen at our GitHub page: https://github.com/sybrew/the-seo-framework
Here’s a direct overview of all issues undertaken for the next update.

We’re also going to update the API documentation right before the release. For now, I spotted that you can’t remove the redirect entry for the SEO Bar without side effects. So, stay tuned for a snippet that can do that correctly.

Cheers!

Alright, a new hook will be commited soon. This will remove the redirect test from the SEO Bar in TSF v4.0+:

/**
 * Adjust SEO Bar interpreter and builder items here.
 *
 * @since 4.0.0
 * @param string                             $interpreter The interpreter class name.
 * @param \The_SEO_Framework\Builders\SeoBar $builder     The builder object.
 */
add_action( 'the_seo_framework_prepare_seo_bar', function( $interpreter, $builder ) {

	$builder::$tests = array_diff(
		$builder::$tests,
		[ 'redirect' ]
	);
}, 10, 2 );

Thanks so much.

It seems that 4.0 has been officially released now. I can verify that the provided snippet works as described by the plugin author. Closing.