Cleaning up the <head>

discobot · December 30, 2020, 8:07pm

Traditionally the section is bloated with all kinds of things that should not be there, or at least not by default.

There is already an open issue to remove the Windows Live Writer (Remove Windows Live Writer action · Issue #222 · ClassicPress/ClassicPress-v1 · GitHub), but this feature request takes things further.

For example the output of the REST API link tag into page header should not be added by default in my opinion.

Of course there are many more individual links that bloat the of ClassicPress, vote this request up if you agree to a clean up!

Read-only archive: GitHub · Where software is built

Author: Pieter Bos

Vote count: 64

Status: open

Tags:

request-modify-feature

Comments

A big list of the most commonly removed actions are

remove_action(‘wp_head’, ‘rsd_link’);
remove_action(‘wp_head’, ‘wp_generator’);
remove_action(‘wp_head’, ‘feed_links’, 2);
remove_action(‘wp_head’, ‘feed_links_extra’, 3);
remove_action(‘wp_head’, ‘index_rel_link’);
remove_action(‘wp_head’, ‘wlwmanifest_link’);
remove_action(‘wp_head’, ‘start_post_rel_link’, 10, 0);
remove_action(‘wp_head’, ‘parent_post_rel_link’, 10, 0);
remove_action(‘wp_head’, ‘adjacent_posts_rel_link’, 10, 0);
remove_action(‘wp_head’, ‘adjacent_posts_rel_link_wp_head’, 10, 0);
remove_action(‘wp_head’, ‘wp_shortlink_wp_head’, 10, 0);
remove_action(‘wp_head’, ‘rel_canonical’);
remove_action(‘wp_head’, ‘rel_alternate’);
remove_action(‘wp_head’, ‘wp_oembed_add_discovery_links’);
remove_action(‘wp_head’, ‘wp_oembed_add_host_js’);
remove_action(‘wp_head’, ‘rest_output_link_wp_head’);
remove_action(‘rest_api_init’, ‘wp_oembed_register_route’);
remove_filter(‘oembed_dataparse’, ‘wp_filter_oembed_result’, 10);
remove_filter(‘pre_oembed_result’, ‘wp_filter_pre_oembed_result’, 10);
add_filter(‘embed_oembed_discover’, ‘__return_false’);

of course there is already discussion on emojis, so i didn’t add them here.

~ posted by Chris Chiotis

Removing the rel_canonical action would be extremely detrimental to any site that uses taxonomies in any meaningful way. Canonical links are used to tell search engines that content is duplicate – and to give a reference to the original content. Without this, 2 things can happen:
1) you compete against yourself in search (best case scenario), or
2) your site is penalized for duplicate content (worst case scenario.)
One might assume that simply not having any duplicate content is the answer. Seems logical. However, in the real world, this is not how it works. Let’s examine commerce, for example.

Let’s say that I’m selling shirts and one of them is a Hawaiian shirt. Once my store and taxonomies are setup, that same shirt might be listed under any (or even all) of the following URLs:

https://site.com/shop/shirts/my-cool-shirt/
https://site.com/shop/shirts/hawaiian/my-cool-shirt/
https://site.com/shop/shirts/tourist-wear/my-cool-shirt/
https://site.com/shop/shirts/floral/my-cool-shirt/
https://site.com/shop/shirts/printed/my-cool-shirt/
https://site.com/shop/shirts/leisure/my-cool-shirt/
https://site.com/shop/shirts/buttoned/my-cool-shirt/
https://site.com/shop/shirts/collared/my-cool-shirt/
https://site.com/shop/shirts/short-sleeve/my-cool-shirt/

To a search engine, the above URLs will appear to be duplicate content. Then, it has to do some guesswork.
- Is the content duplicated to game the system? Penalize it!
- Is the content duplicated in error? Ok, so which page do I serve?
- Is the content not actually duplicate? Hmmm...something is fishy.
These are not questions you want a search engine asking or answering about your site. You want to specifically give the search engine the answer.

The solution is to specify the canonical URL to tell the search engine, “I’m not gaming the system, and I haven’t made a mistake; this page is indeed a mirror of INSERT URL HERE… and that page is the one that should get the search mojo if you, dear search engine, are ever in doubt.”

While I can provide a solid example of why removing the rel_canonical action is a bad idea, I cannot speak to the other actions listed, so I’d just like to say: please tread very carefully when removing things that seem needless – many times, a thing is actually quite necessarily, even though you may not necessarily understand how or why.

~ posted by John

anon71687268 · January 30, 2021, 8:52pm

We do have the dedicated Head Cleaner plugin for ClassicPress. It can remove a whole bevy of scripts, styles, and tags from the head section with just a click. It includes helpful descriptions and examples of the code removed, leaving little guesswork. Here’s a sampler of the admin screen.

So, yeah… here it is.

~~https://codepotent.com/classicpress/plugins/head-cleaner/~~
https://directory.classicpress.net/plugins/head-cleaner

1stepforward · January 31, 2021, 3:27pm

My view is that this is plugin territory and that @anon71687268’s plugin satisfies the requirements of this petition.

I guess the question is: do we close this particular petition now? Any other thoughts?

<aside>
Leaving the generator tag in the head can be useful to ClassicPress as it is one of the key indicators used by the likes of BuiltWith and W3Tech to determine a website’s underlying technology.
</aside>

anon71687268 · January 31, 2021, 5:12pm

I agree this is plugin territory.

Not sure how petition closure works – I asked in #random a few days ago, but, didn’t hear back. With 64 votes, it’s fairly popular; we should proceed with care.

1stepforward · January 31, 2021, 8:57pm

Very true.

viktor · August 29, 2021, 5:25pm

In addition to the dedicated plugin, the code snippet to clean <head> can also be added to the upcoming snippet repository. So this petition will be closed as easy solutions already exist.