Remove User meta fields for facebook and twitter

Hello!

You can enter the URL in the Twitter field — TSF will convert it for you on-save (I anticipated some confusion for the discrepancy).

TSF uses the data to supply various meta tags such as twitter:creator and article:author. Still, those haven’t proven much use over the years (if any).

To hide the fields, you’d have to set headless-mode for ‘user’ in wp-config.php:

define( 'THE_SEO_FRAMEWORK_HEADLESS', [ 'user' => true, 'meta' => false, 'settings' => false ] );

Learn more here: https://tsf.fyi/kb/headless.

With that enabled, even if those Facebook and Twitter fields were populated, they’ll be ignored. User headless mode still allows some user-specific settings handled like the counter-type (click on the character counter number to see that in action).

Hello Sybre and thanks for helping!

the “headless” route seems a bit too complex and prone to mistakes… And all I want is that those fields are not displayed in the admin page, because they will be confusing if I also add my own custom fields with similar names and different purpose.

so in the end I’ve used a dirty workaround which literally just hides the fields from the backend by wrapping them into a div set to display:none.

add_action('the_seo_framework_before_author_fields', function() {
    echo '<div style="display:none">';
});
add_action('the_seo_framework_after_author_fields', function() {
    echo '</div>';
});

Would be better if there was a filter to actually skip those fields, but for now this works well enough for my needs.

cheers!

Hello!

I can not recommend using the filter above. I think it’s dangerous. Allow me to explain.

Filters can’t be used for these fields because they can be implemented anywhere at any time — the result could be that a filter runs too late or is overwritten, and data can still be processed for the fields.

This is also the case with the filter you provided: Because it obscures input fields, data can be inserted by accident via faulty password managers, or be inserted by something with nefarious intent. Also, since you’ve hidden the fields, the data cannot be inspected with ease and may linger for years to come.

The constant definition must be provided in time, or will otherwise crash your website because TSF will write to it instead — you’ll recognise this error immediately (blank screen or error displayed).

Look at it this way: constant definitions are like filters; but, they cannot be overwritten, are native to PHP, and accept only simple strings, integers, or arrays. They create an environment you require, instead of one you desire.

Constants are actually less error-prone than any other syntax because they are so restricted, especially compared to filters. Plus, since I created the software listening for the constant, I am responsible for handling its input, not you.

I understand my use of PHP 7 syntax can be scary, but there’s nothing for you to adapt: the code I provided is tailored to your request. If you copy+paste mine as-is to wp-config.php, you’re done and do not have to reinvent the wheel. Plus, you can always reach out if you require assistance adjusting it. Lastly, might you every want the fields displayed again, you can remove the constant at any time and continue where you left off.

hello! my apologies for the belated reply…

after your last reply I had a better look at your suggestion and I actually tested it and in the end I’ve decided to use that approach.

I am sorry but I’ve been mislead by the naming “headless” and I initially misunderstood the directions on the page you linked. So it all sounded too convoluted for my needs.

but in the end I’ve realised it was just about copying that very same single line you provided in your first reply, and pasting into wp-config.php. And it didn’t have any other effects that to remove those 2 fields.

it’s a bit of an uncommon way to disable some options but it worked perfectly!

thanks!