I have tested this item ✅ successfully on f912ddd

I have tested this item ✅ successfully on f912ddd

The ability to remove the metagenerator from the core has been rejected many times.

In addition I don't understand your comment that you need to create a plugin to customise it and that it doesn't always work.

All you have to do is to add this to your template

<?php $this->setGenerator(value); ?>
This has been true for every release of joomla and is exactly what very many templates already do.

If it works so great, why so many people have problem whit this in their templates and plugins?

Hiding the generator meta tag helps protect "identity of CMS" and prevention of attacks. I know it's not a huge protection but in my opinion it does matter - it will allow to decrease number of potential attacks.

I haven't heard of anyone saying it doesn't work. I have never had a problem.

Security through obscurity is no security at all and if that is the aim then this will not be accepted. As I said this has been rejected many times for good reason

And what is this good reason?

Security through obscurity is no security

I agree that there is no security reason. I too use the setGenerator() Method in templates and never had problems.

@brianteeman "The ability to remove the metagenerator from the core has been rejected many times."
But the web is full of tutorials / plugins / extensions for this,. Who wants to remove it will do so, whether Joomla has a option for this or not.

But think it is nice for novice users to set a Generator Text via a Param.

Not tested but I assume that anyone using the existing api for this on their site will no longer be able to

we already have too many options to scare off novice users

Joomla! is an open source web application. Its mean anyone can modify it according to own needs including change the value of the generator meta tag and also to hide it. This is the main reason of this new feature. Or maybe something has change and Joomla! isn't an open source project any more.

Additional profits like decreasing number of potential attacks and lower activity of janky bots written by "beginning hackers" are also on plus. It's a small profit but it does matter.

There won't be any conflict with setGenerator() used in templates or plugins. I didn't block interference in generator meta tag.
It can be blocked but after a time, when people get used to this new feature. It's still an open topic to discuss.

At this moment I don't see any argument against this feature.

we already have too many options to scare off novice users

The solution is quite simple.
We need a toggle button in Configuration Manager what will switch between the basic list settings and the full list of settings.

The changes to not print generator related tags if the generator is empty are valid.

The option to customize the generator via the global configuration I would suggest we do not accept. There are already more than enough extension options (many templates have an option for this, as well as plugins) to either customize or remove the generator. At this point, adding this configuration in core would only conflict with and be overridden by every extension which is already manipulating the generator in their own way; it would be a bigger inconvenience and introduce more user confusion to have it than to keep the status quo.

@mbabker, there is no conflict but ability of interference into generator meta tag by a template or a plugin can be block. You are trying to make problem which doesn't exist.

interference into generator meta tag by a template or a plugin can be block

That's a major B/C break and won't be accepted.

I'm not trying to make a problem out of nothing. We set the generator to our default value very early in the request process, anything that calls setGenerator() after that (we do it before components run, so at this point any component, module, plugin, or the template itself can change the generator) would overwrite what is set in the global configuration. Then we get bombarded with support questions about "I set the generator here but it's not right, why is Joomla broken!?". At this point, making this option work in core would be disruptive and an inconvenience to users and extension/template developers.

So if someone can interference to the generator meta tag by a template or by a plugin, why it's forbid to that person to use it from Configuration Manager?

As I wrote, there is no conflict and it won't be.

Your argument can be used to anything.

• Why to improve a SEF when there are an extension for that?
• Why to change back-end core templates when we have an other templates for that?
• Why to improve Joomla! when we have a lot of extensions? We can stop developing the Joomla!, we have extensions.

If it will so bad as you trying scare other, this feature can be removed.

For this proposal to work, it would mean moving where core calls setGenerator with the configured value to a spot where it overrides any values that can be set by extensions/templates. Effectively breaking the ability for extensions to manage the generator.

Because core sets the generator early in the request cycle, it leaves the door open for anything to override the value. When the core value doesn't take because a plugin or template is changing the generator (a very common thing), it creates a worse user experience because users will be confused why their configurations aren't taking.

Because the ecosystem has worked this way for so long, at this point it would be a majorly disruptive change to introduce this specific configuration option to core. Extensions and templates would have to adapt to it to avoid the user experience issues. Many of them won't. The end result is going to be depending on the combination of extensions on your site, you either have to customize the generator in a plugin, or your template's configuration, or the core global configuration. Right now, core has no UI for managing the generator, which means you know with certainty where to customize the generator value for your site because you will know if your template supports the configuration or if you've installed an extension (presumably a plugin) to do it.

As I wrote, there is no conflict and it won't be.

Sure there will. My extension calls $doc->setGenerator('I do not care what is in your global configuration'); after core has set the value. It conflicts with what you have in your global configuration. Without a major B/C break to force the global configuration value to be the only possibly usable value, it will always conflict.

You don't want to regulate (block) the access of extensions to the generator meta tag. Also you are trying to prove there is a bug (conflict) because access to the generator meta tag isn't regulated (blocked).

Forcing the core settings it the same think as blocking access to the generater meta tag for a templates or a plugins.

Decide what you want. You can't eat a cake and have a cake.

That's exactly why this PR can't work. You have to have a major B/C break and change the core API so that the generator can ONLY be set through this configuration. And that's highly problematic because it's going to break sites and extensions which are setting the generator on their own.

I'm going to close this PR. I understand the rationale behind it, but it just can't work without being majorly disruptive to every existing site and extension in some way shape or form.

There is no any disruptive. You don't understand it and you don't want to understand it.
It allow for a sort king of migration from extensions to core feature. So people can easily stop using extensions and start using core fearute.

You are just pretending it's a problem, a bug, a conflict.
It's all because it's not what you and Brian want to.

It is a problem.

If this PR is merged exactly as it is, any extension which is setting the generator will overwrite the core configuration. Basically making the core configuration invalid, creating user confusion.

If this PR changed core so that extensions could not change the generator and that only the core configuration could be used, it would create a major B/C break as it relates to user workflow, and would change the output on existing sites.

So yes, either way accepting this PR would be disruptive. It would raise the amount of support questions we have to deal with on the core platforms and force every extension and template to change their code.

So now people can gives a lot of questions why their extensions doesn't work properly while creating generator meta tag?

You are blocking any solution pretending they are wrong, just to pretend you are right.

You don't have to force to anything - this is the beauty of open source projects.

You are putting an own whim above the development and you forgotten what the open source mean.

Please, don't use argument about protecting and controlling the right progress. People decide what they want to use and in what form, because open source projects purify themselves from useless and obsolete features. But it works only if no one will restrict those projects.

So now people can gives a lot of questions why their extensions doesn't work properly while creating generator meta tag?

where?

On a forum. For egzample forum.joomla.pl.
Thought the last year there is at least one problem with generator meta tag monthly.

And it's all because the extensions work so fine, what they have an super extra feature like conflicts with other extensions or have a "bugs" - poor quality code.

as @mbabker has already explained with this pr we will have a huge number of complaints that this pr has broken their site. far more than 12 a year lol

the forum post you refer to http://forum.joomla.pl/showthread.php?85413-Jak-zmieni%C4%87-metatag-quot-generator-quot&highlight=meta+generator would NOT have fixed that users problem with byebyegenerator or admintools. they still would not have worked for them and in addition all the people in that post who said it did work for them would also have broken sites. so as well as not fixing the problem for that user this pr makes it worse for everyone else.

I'm not trying to restrict anything. Part of being a maintainer on an open source project's codebase includes reviewing feature proposals and analyzing all of their pros and cons. Yes, this proposal has several benefits. Unfortunately, those benefits are heavily outweighed by the issues and conflicts that it would cause. That is why in good faith I cannot suggest this PR be accepted, even if it seemingly makes things easier for users it introduces user experience issues and conflicts between the core global configuration and the configuration of every extension which has a generator setting option, or mandates a major API break and blocking extensions from being able to customize the generator.

Unfortunately, there is just no good way to introduce into core a feature that allows a user to globally manage the generator tag without adding other problems.

It won't in current form. Users who use an extension won't notice any differences but people who don't use them or use but they had any issues will achieve ability to change the generator meta tag easily.

Stop pretending there would be a problem.

You forgotten we are a volontiers and we don't have to do a job what should do an extension creator. We report issues to them but the rest depends on them.

There is something what we can do, we can improve Joomla!. For example, I'm trying to do right now.

@mbabker there won't be any problem. I don't know why you pretend it will be.

Current code is a great option to migrate easily and leave only core setting in Joomla! 4.

What's the use of adding that option to the configuration? What's the use of changing the meta tag generator? Satisfying egos? Sorry, that's the only reason I can see because it won't make your site more secure. So there's no benefits for me to do that.

Users who use an extension won't notice any differences but people who don't use them or use but they had any issues will achieve ability to change the generator meta tag easily.

Users who set the generator tag value in the global configuration and have an extension which overwrites that value will see it as Joomla being broken. The problem is the user expectation is that what is in the global configuration should be used. That is only the case if every extension which sets the generator updates their code to respect these new values.

Current code is a great option to migrate easily and leave only core setting in Joomla! 4.

This would be a highly unwelcome backward compatibility break for the sake of forcing some kind of philosophy. There is little practical benefit to enforcing it.

Again, to be crystal clear here. There is not a code problem with this proposal. It does exactly what it advertises. The problems that would be introduced are that it mandates that every line of code written for Joomla which allows users to modify the generator be updated to take into account these new configuration values and extensions which do not respect these configuration values will be seen as broken by users and cause extension developers to send pissed off issue reports to core, or will result in users seeing core Joomla as broken resulting in additional support requests and having to explain that the core feature only works if some combination of extensions either have their option removed or turned off. This is a case where accepting a feature proposal is not in the best interests of the project and its users.

You are assuming that user is an idiot, who barely can use a computer mouse.

It isn't so hard to add a post-installation message and a text to description of this option, about disabling an extensions.

Stop finding problems, which aren't exist and start find a solutions.

I don't understand your position in this matter but for me it looks like you don't want to develop Joomla!.

There's a lot of negative opinion but nothing constructive.
It's so encouraging.

Just tell me is it have a sense to implement this in J4 (wich keeping only core feature) or just to leave it because of you whim?

You are assuming that user is an idiot, who barely can use a computer mouse.

Sadly many are

It isn't so hard to add a post-installation message and a text to description of this option, about disabling an extensions.

Again not only will this annoy extension developers it is not as simple as it will also effect templates

Stop finding problems, which aren't exist and start find a solutions.

We would love to have a solution but this isnt it

I don't understand your position in this matter but for me it looks like you don't want to develop Joomla!.

You are addressing some of the people who have contributed more code than anyone else in the history of Joomla. For your first contribution that's pretty disrespectful.

... hat's pretty disrespectful.

And using an senseless arguments and seeing non existing problems isn't?

A lot of people use my code to contribute it, because they could count on my help.
This time I wanted add it by myself.

When I made this pull request I had hope for a constructive feedback in case if it was a bad feature. Especially from

people who have contributed more code than anyone else in the history of Joomla.

Because they should know the best what is good and what is not and also discuss about it in constructive way.

I apologize for having too high expectations to experienced people.

To be 100% clear - no one is saying that your code does not work. What we are saying is that it breaks backwards compatibility in a big way and that is not something we can do in Joomla v3

What with J4? May I prepare a "core only" solution for J4?