[#36888] - [3.10] Disable google fonts for 3.10.x new installs
- Fixed in Code Base
- 17 Mar 2022
- Medium
- Build: 3.10-dev
- # 36888
- Diff
- zero-24:disable_googlefonts_for_newinstalles
User tests: Successful: Unsuccessful:
Summary of Changes
With this PR all new installes of Joomla will come with Google Fonts switched off. This is already the case with 4.x but in my opinion should be backported to 3.10 too.
For example there have been recent court decisions about this issue too.
I would not like to debate whether that are good rules or not in the end its not our decision anyway. But I think we should provide our system with as less possible privacy issues as possible out of the box. Everyone is still free to enable this option and on updates the setting is not changed. So it only affects new installations using the core protostar template.
Testing Instructions
First test
- Make a new install of Joomla 3.10.4
- update to a new package using the pre-build package: here
- check within the tempalte settings that the google font setting is still enabled
Second test
- Make a new install of this package: here
- check within the template settings that google fonts are swiched off.
Actual result BEFORE applying this Pull Request
Google Fonts are enabled by default
Expected result AFTER applying this Pull Request
Google Fonts are disabled by default
Documentation Changes Required
none
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | SQL Administration com_admin Installation Postgresql MS SQL Front End Templates (site) Unit Tests |
Joomla should be politically and culturally neutral. Just because one place in the world has made a decision does not mean that joomla should react.
Ignoring the obvious mistake of FLoC which you are not rushing to respond to Joomla has never made this type of political decision.
For example we do not ship with anything special for impressum ( a germany specific regulation).
No work has been done to remove cookies by default or to provide a cookie blocker.
We ship with certain google based features even though they are not available globally.
Out of the box a joomla installation by default also breaks the accessibility laws in multiple countries.
Do I need to go on.
Politics does not belong here.
final comment - if you were really serious about this then you would be leading by example and removing the google fonts from downloads.joomla.org - yes that's right you can't download joomla without the evil google fonts (or google analytics or googletag manager) or 5 tracking cookies.
final comment - if you were really serious about this then you would be leading by example and removing the google fonts from downloads.joomla.org - yes that's right you can't download joomla without the evil google fonts (or google analytics or googletag manager) or 5 tracking cookies.
Sure you can and I do get along without google fonts, google tag manager and google analytics since ages :D But that does not matter here. Its an decision by the people running that site which you know is not me so blaming it on me is wrong and you know that.
The thing here is do we as CMS think its right that the CMS by default should not depend on stuff that could for example also not be reachable when you are on an intranet site? We decided on this topic for 4.x already to not ship with it enabled by default this here just backports this decision into 3.10.
For example we do not ship with anything special for impressum ( a germany specific regulation).
Thats true and why should we do. Not every site is required to ship with it too nor can we ship such regulatory things which are changed often.
No work has been done to remove cookies by default or to provide a cookie blocker.
We dont have to as the core does not ship with any cookies that fall under that regulatory.
We ship with certain google based features even though they are not available globally.
Yes let me call them legacy reasons, we also have decisions to not to include new externenal services like that for the reasons too. And that mentiond google based feature (recaptcha) is disabled by default too, the same is true for that yubikey plugin.
Out of the box a joomla installation by default also breaks the accessibility laws in multiple countries.
Yes but is that really a reason to not working on accessibility? No we rightfully focus on improving accessibility with any release we do we even now ship a plugin to help every webmaster to improve accessibility.
Everyone of your answers confirms everything I said. Thanks for proving my argument
Joomla should be politically and culturally neutral.
True. So, for this very same reason, Google Fonts should be removed also.
the obvious mistake of FLoC
Again: It was no mistake. The decision was absolutely correct.
yes that's right you can't download joomla without the evil google fonts (or google analytics or googletag manager) or 5 tracking cookies.
That's nonsense. I can download there without any of that shit activated in my browser.
Maybe my english is not good enough.
All I said is: I can go to downloads.joomla.org with everything deactivated in my browser. Everything set to disallowed = "block loading".
JS, Cookies, GA, Fonts, whatever.
And can start a successful download.
| Labels |
Added:
?
?
|
||
We are not against Google, we are just for privacy (freedom software)... far as I know Google is also for this, and has done a great deal to give the choice back to their end-users in this regard. This mean we will be helping them... as we are turning off the default to "no tracking" as is suggested as best practice. We are not against the option of them tracking (as part of their business model), we are just giving the choice back to the end user (which is the right thing to do). So why there is even a conversation against this change is strange.... excellent work @zero-24 THANK YOU!
This is not a bug fix. Therefore it can not be merged into 3.10.x only 3.11 https://semver.org/
We are not against the option of them tracking (as part of their business model), we are just giving the choice back to the end user (which is the right thing to do). So why there is even a conversation against this change is strange..
Because google state that they are not tracking users when they use google fonts. https://developers.google.com/fonts/faq
But I guess you know something different and big brother really is watching you
I have tested this item
Tested only with mariaDB.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/36888.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/36888.
I think both sides have their valid points but (and I know it was mean as contra argument) one is very important:
Out of the box a joomla installation by default also breaks the accessibility laws in multiple countries.
Although this is the case, we still try every day to make it more accessible and improve. The same counts for security and for potential tracking. Probably the next step should really be to remove the google fonts at all (or ship them as a local file) but that is not what this PR is about.
Thanks for this constructive discussion and after weighing up both sides I think the benefit of disabling this parameter by default brings more benefits, especially it's very easy to enable it again.
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-03-17 20:28:05 |
| Closed_By | ⇒ | bembelimen |
Thanks :)
So no one cares about semver then when its a release lead that wants to break it. Will remember that for the future
Yes we are not 100% strictly following semver and have sometimes decide on a case to case basis whats the correct thing to do for the CMS but the generall rule still is to follow it, also here for example there are no changes to the existing sites.
Some recent examples: Removing FLoC is also not 100% semver complient as we removed an functionality within a patch version but still we have accepted it. I have also merged another PR which removed class attributes (that are nowdays comming from the extended class) to improve PHP 8.1 support with 3.10. Strictly following semver we would have to stop supporting PHP 8.1 for 3.10 for a none issue.
So yes the RL is the person who takes the decisions on suche things in coordination with the other maintainers.
On the other hand when the RL decides to stick with the rules that we where set he gets blamed for that too thats the balance job of the RL. And thats why he is always wrong :)
This is not a bug fix. Therefore it can not be merged into 3.10.x only 3.11 https://semver.org/
SemVer? IF it was done by someone else than russian shitass nikic from php/php-src, Id use it. As semver is done with cooperation with russian shitdevs, Im highly against using it
@cronlabspl I'm going too lock this issue here now, there is no relation to who created what document with whatever nationality. Thank you for your understanding.
Please no.