I read a post on Morten Rand-Hendricksen's site about the 80/20 rule. Summary is that it isn't really adhered to anymore, but for some reason WordPress still notes it as a guiding principle.

Partly, he states that often there is no data to even know if a feature is used. I find that somewhat interesting, and wonder if we shouldn't be using data to make better informed decisions about the codebase (versus letting random core contributors guide/push for their pet ideas).

There may be some debate on new things like Gutenberg since, of course, a new thing is always resisted and, also of course, a new thing will have an adoption period, and also even more of course, there are some who will raise the rebel flag and yell "never!" and attempt to drive a wedge to hold onto classic ideologies. I'm not saying that is bad or good; just that it is expected.

However, then we come across work/effort on things like this. Who says this is a problem? Where is the data? I'm sure it has *been* a problem for many sites, but what percentage of sites? 1%? 10%? 30%? I doubt the very people who wrote this code have any real data.

This is a ripe idea for a security plugin for those who feel that their websites (or their clients' websites) need this because it is, or potentially could be, an issue there. (I won't even go into whether I think this 'check' will actually solve anything).

Are not the big vendors in the security plugin world already adding this 'feature'? If not, why? Why is this now more (bloated) code in core?

I'll have to look at the code, but questions also arise as to its implementation. I know no one cares about performance anymore and we (collectively as web developers) seem to think its a niche hobby. Talk all you want about carbon output and global warming. Every piece of code causes it. Thus, I think the 80/20 rule is a decent guide here. How often is this six-month check being performed? Is this being done via wp-cron? Daily? Hourly? Sigh... you get my point.

Lastly, the whole 80/20 thing sort of grates me. We *still* have a call to Windows Live Writer loading on WordPress. Microsoft themselves, the creator of WLW, abandoned it in 2012, and officially declared it dead in 2017. If it was ever used by more than 10% of WordPress users, I'd be shocked, but most WP devs don't even know what it is anymore at this point. Some discussions over in core a few years back where had about removing it, but they seemed to have died. So, it lives on, maybe for another five years.

Clearly, it should have long ago been slung off to its own plugin. In fact, I don't even think it's WordPress's role to make it a plugin, just to kill it in the core.

So, think about this. We now have 'niche' performance/optimization experts who, among many other 'adjustments' insert code into child theme functions.php or snippet plugins or their own custom plugin, to remove/undo support for WLW.

Of course, that code *also* has to execute (more CPU cycles) so while it's a major improvement (since it's server-side only at the speed of (hopefully) PHP 7.3, it's still a band-aid on the real issue: WordPress's fear of letting legacy code die.

My personal feeling is that the WordPress codebase could be about 10-15% leaner and not affect 99% of its current users.

Adding this personal pet project of someone's doesn't help WordPress, really. It just becomes one more thing, one more hook, that developers have to deal with now. I know no one at WordPress is fearing SSGs, or even Drupal & Co., as they stand no chance of taking marketshare of WordPress. But does it need to be about fear? Can't we just do what is sensible for our users?

Start by cleaning up the core instead of adding to it. I was recently reminded about a not-so distant iOS update that was _mostly_ about tightening up the performance and cleaning up legacy code in the O/S. I think WordPress needs to dedicate an upcoming release (maybe 5.5?) to that end.