Hardening Settings Are Not Applied and Can't be Modified

WordPress until the current version 4.4.1 uses a function named “wp_generator” [1] to print a HTML tag like this [2] if you add this code [3] in one of the hooks of the initiator of the header you will force WordPress to remove that tag. This is exactly what the Sucuri plugin does as you can see here [4].

I tested this with the latest three supported versions and it works; please provide more information about the environment where your website is being hosted so I can reproduce the issue, investigate it, and fix it if necessary.

[1] https://developer.www.ads-software.com/reference/functions/wp_generator/
[2] <meta name="generator" content="WordPress 4.4.1" />
[3] remove_action('wp_head', 'wp_generator');
[4] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/3b53624/sucuri.php#L283

Thank you for the recommendation but I already hacked my way through it and have it returning a different generator. That was not the point, I know how to hack my way around the installation. I decided to do it through the functions.php to make it as globally cascading as possible.

My issue was SPECIFIC to your settings and the fact that it shows hardened but its not, so what else is it reporting as active that is not actually doing anything? My question is not explained or answered by you giving me solutions how to hack around it, something I have already done but shouldn’t have had to if the reported settings ACTUALLY worked right.

See my point?

I was not explaining you how to do that, I was saying how the plugin does it and that there is not magic in the process, is just a single function call to one of the WordPress built-in functions, if that function call does not works then I suggest you to report the issue to the WordPress core developers. Marking this as resolved since you say that you already did it through the “functions.php” file.

It doesn’t change that despite HOW the plugin does it, its not doing it but saying that it is, that’s what I want clarification on.

It says hardened, reporting removed but its there. If I relied on it then I would not have noticed the generator still reporting. That’s a failure in the plugin, NOT WP core.

If YOUR plugin says, something is a certain way, it has to be factual or its wrong which means it failed. IF the page checks correctly, then it would know its claims are wrong, it would reflect the “true” state of it.

NO one should have to custom hack their own solution when they have a plugin that claims to be handling it.

Hello, you said that you were able to fix the issue with your own code, can you provide a copy of the code (or hack as you say) that you used to fix the issue? That way I can review it and include it in the next release of the plugin.

EDIT: You are asking for a “clarification”, that is what I did in my first comment but you said that it was not what you were asking, since I do not know why the plugin is not working in your website I do not know what to clarify; please provide more information about your environment so I can at least reproduce the issue in my server and investigate the error locally, otherwise I do not know how else can I fix it.

EDIT2: Removed unnecessary comments for the discussion.

EDIT3: Marking as not resolved for now.

As to the first request, yes, I modified it myself because after I removed the generator, decided that I would like to feed a “custom generator” in its place, so now it DOES return a generator but NOT what is supposed to be but rather what I want. The code for that is quite simple, but here it is for your review:

function remove_version() { return '<meta name="generator" content="CUSTOM CONTENT - CLEAR TO RETURN NOTHING" />'; }
add_filter('the_generator', 'remove_version');

EDIT: I put this at the end of my functions.php file so that it would let the theme do everything it needs and then sets the option last to ensure it overrides anything the theme might try on its own.

As for why I said your response didn’t answer the question is that software, especially “security” software needs to be ever vigilant and “live check” settings. Meaning, when you load the page, check all the settings and see if they are set or not, then report that status instead of the last status when it was “applied” and may no longer be enforcing.

SO it would check in this instance that indeed generator is NOT blocked and would show it in red, so it can be “reapplied” and when done, it should check each time to make sure its still enforcing that option. If not then alert or show it as open so the user knows and doesn’t take for granted that it says its enforced.

See what I mean? You apply and then you wash your hands of it, never check again to see if you are actually enforcing the settings set by the user and they are actually getting what they expected. Not just that at some point they applied the setting and you are content its done for good.

I am trying to be as clear about the expectation here as possible, hopefully you begin to understand the root of what I am saying. Its not just a specific setting but ANYTHING your software is interfacing with should ALWAYS be live checked on load to ensure they are ACTUALLY being enforced not that at some point they were set.

I have always loved this plugin and that’s why I have invested quite a bit of time over the years to ensure that I contribute to its greatness as much as possible. If at any time it casts doubt on how its ACTUALLY working, its a hit to the confidence that makes its hart to not worry if you are actually as secure as you “think” you are because it says so.

I understand now, thanks for the clear description of the issue; I will copy this to our internal task tracker, assign a priority, discuss with the development team, and work on it to include the changes in the code before the next version is released.

Keeping as not resolved until I commit the changes to the repository.

Sounds great, thank you. I look forward to it.

After many tests with all versions of WordPress released after this bug report I came to the conclusion that “remove_action” [1] has priority over “add_filter”. Any attempt from my part to insert or update the meta tag from another plugin or theme was in vain because the action that prints the content of the filter is being removed.

Marking as resolved, feel free to re-open if you have additional concerns.

As I said in the other issue, which was also over a year old, we couldn’t wait this long for a resolution – if it can be called that; so, we have moved on.

I will defer to those still using this addon to decide if it is important for them that (1) advertised features work correctly instead of luck of the draw and (2) if over a year to reply to an issue just to improve “closure” stats is appropriate.