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 #69 · ClassicPress/ClassicPress · 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 : Issues · ClassicPress/ClassicPress · GitHub
Author : Pieter Bos
Vote count : 64
Status : open
Tags :
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
I apologize if I didn’t make myself clear. Of course some of the actions I listed are important one way or another. I just listed them so we can take a look and decide if any of them is worth removing
~ posted by Chris Chiotis
I am all in favor of cleaning up head, but I would like to tie some of it to functionality. So, if you disable comments, for example, it disables comment feed by default, etc.
~ posted by David Shanske
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
4 Likes
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>
2 Likes
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.
3 Likes
viktor
August 29, 2021, 5:25pm
8
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.
1 Like