Enhancement: Align Gavatar and Federated Avatars options to be Enable #15014

New Issue

2025-11-02T11:28:01-06:00

GiteaMirror commented

2025-11-02 11:28:01 -06:00

Originally created by @markbrown87 on GitHub (Oct 11, 2025).

Feature Description

Admin settings for Picture and Avatar Configuration under Configuration are misaligned. Meaning, Gravatar is Disable Gravatar and Federate Avatars is Enable Federated Avatars. The proposed enhancement is a small refactor to align the two to be Enable for both (see screenshot).

Since this was a fast refactor, I implemented the approach of changing the naming and logic for disable gravatar to enable gravatar locally. However, I am not certain how the Gitea team would want to handle the database entry and migration from older instances to this proposed state. I assume there are standard procedures for migrating database entry names.

The alternative approach would be to keep all disable gravatar naming in the backend and flip the boolean when the control sends the value to the frontend. Of course, that comes with the confusion of the UI using Enable and the backend using Disable for naming convention for Gravatar.

Screenshots

Originally created by @markbrown87 on GitHub (Oct 11, 2025). ### Feature Description Admin settings for `Picture and Avatar Configuration` under `Configuration` are misaligned. Meaning, Gravatar is `Disable Gravatar` and Federate Avatars is `Enable Federated Avatars`. The proposed enhancement is a small refactor to align the two to be Enable for both (see screenshot). Since this was a fast refactor, I implemented the approach of changing the naming and logic for disable gravatar to enable gravatar locally. However, I am not certain how the Gitea team would want to handle the database entry and migration from older instances to this proposed state. I assume there are standard procedures for migrating database entry names. The alternative approach would be to keep all `disable gravatar` naming in the backend and flip the boolean when the control sends the value to the frontend. Of course, that comes with the confusion of the UI using `Enable` and the backend using `Disable` for naming convention for Gravatar. ### Screenshots <img width="1065" height="505" alt="Image" src="https://github.com/user-attachments/assets/c95fca41-4a49-40af-9965-a67bad46d17e" />

GiteaMirror added the type/proposal label 2025-11-02 11:28:01 -06:00

GiteaMirror commented

2025-11-02 11:28:02 -06:00

@wxiaoguang commented on GitHub (Oct 11, 2025):

Well, open-source and crowd-contributed.

You can see there are a lot of "DISABLE_xxx" https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini, most of them were added without careful design or thinking ....

@wxiaoguang commented on GitHub (Oct 11, 2025): Well, open-source and crowd-contributed. You can see there are a lot of "DISABLE_xxx" https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini, most of them were added without careful design or thinking ....

GiteaMirror commented

2025-11-02 11:28:02 -06:00

@wxiaoguang commented on GitHub (Oct 11, 2025):

I implemented the approach of changing the naming and logic for disable gravatar to enable gravatar locally

If your change is compatible with existing settings (won't break existing users: either by database migration, or flip the boolean in the fly) and could also help more "DISABLE_xxx" cases in the future (flip the boolean), I think it would be pretty good.

By the way, I think we can completely drop libravatar

https://github.com/go-gitea/gitea/issues/34284#issuecomment-2830150121

libravatar is introduced by https://github.com/gogs/gogs/pull/3320 and maintained by @strk

It's really questionable any one is really using it

@wxiaoguang commented on GitHub (Oct 11, 2025): > I implemented the approach of changing the naming and logic for disable gravatar to enable gravatar locally If your change is compatible with existing settings (won't break existing users: either by database migration, or flip the boolean in the fly) and could also help more "DISABLE_xxx" cases in the future (flip the boolean), I think it would be pretty good. ----- By the way, I think we can completely drop `libravatar` https://github.com/go-gitea/gitea/issues/34284#issuecomment-2830150121 > [libravatar](https://github.com/strk/go-libravatar) is introduced by https://github.com/gogs/gogs/pull/3320 and maintained by @strk It's really questionable any one is really using it

GiteaMirror commented

2025-11-02 11:28:02 -06:00

@markbrown87 commented on GitHub (Oct 11, 2025):

Though what I did locally was quick and dirty, targeting Gravatar exclusively, I will work on expanding it for others. I will put some time in removing libravatar as well.

@markbrown87 commented on GitHub (Oct 11, 2025): Though what I did locally was quick and dirty, targeting Gravatar exclusively, I will work on expanding it for others. I will put some time in removing libravatar as well.

GiteaMirror commented

2025-11-02 11:28:02 -06:00

@wxiaoguang commented on GitHub (Oct 11, 2025):

Thank you very much.

Though what I did locally was quick and dirty, targeting Gravatar exclusively, I will work on expanding it for others.

My initial idea is to add a FlipBoolean field to config.Value, then it can use "enable" key in database and work with "disable" key in the legacy INI. Haven't really looked into it and thought more.

I will put some time in removing libravatar as well.

I think it doesn't need to be in this issue's scope. Maybe it can be a separate PR, in case some people have feedbacks and they still need it. (maybe wait for more feedbacks: https://github.com/go-gitea/gitea/issues/34284#issuecomment-3392767372)

@wxiaoguang commented on GitHub (Oct 11, 2025): Thank you very much. ---- > Though what I did locally was quick and dirty, targeting Gravatar exclusively, I will work on expanding it for others. My initial idea is to add a `FlipBoolean` field to `config.Value`, then it can use "enable" key in database and work with "disable" key in the legacy INI. Haven't really looked into it and thought more. ---- > I will put some time in removing libravatar as well. I think it doesn't need to be in this issue's scope. Maybe it can be a separate PR, in case some people have feedbacks and they still need it. (maybe wait for more feedbacks: https://github.com/go-gitea/gitea/issues/34284#issuecomment-3392767372)

GiteaMirror commented

2025-11-02 11:28:02 -06:00

@markbrown87 commented on GitHub (Oct 12, 2025):

I spent some time yesterday modifying the config.Value such that the value was flipped whenever retrieved. This was accomplished by specifying .Invert() in the init function.

-			DisableGravatar:       config.ValueJSON[bool]("picture.disable_gravatar").WithFileConfig(config.CfgSecKey{Sec: "picture", Key: "DISABLE_GRAVATAR"}),
+			EnableGravatar:        config.ValueJSON[bool]("picture.disable_gravatar").WithFileConfig(config.CfgSecKey{Sec: "picture", Key: "DISABLE_GRAVATAR"}).Invert(),

However, the frontend sets based on input check box which required a flip there as well.

-	setting.Config().Picture.DisableGravatar.DynKey():       strconv.FormatBool(form.DisableGravatar),
+	setting.Config().Picture.EnableGravatar.DynKey():        strconv.FormatBool(!form.EnableGravatar),

This meant the retrieval control flow and the setting control flow would both need to be flipped to accomplish flipping on the fly. This is the commit on my forked repo to flip on the fly, which is more confusing, in my opinion. It does, however, retain backwards compatibility for picture.disable_gravatar without requiring a database migration for the value.

I did spend the majority of my available time attempting to convert based on a composed "MigrateFrom" function such as

EnableGravatar:        config.ValueJSON[bool]("picture.enable_gravatar").MigrateFrom("picture.disable_gravatar").WithFileConfig(config.CfgSecKey{Sec: "picture", Key: "DISABLE_GRAVATAR"}).Invert(),

But found the use case of migrating from the old key value would cause for both picture.disable_gravatar and picture.enable_gravatar to be present in the database. This made it trickier to do purely from config.Value as the database would need to be updated only if picture.disable_gravatar was present at startup.

I am not familiar enough with the codebase, so I didn't make it far before shutting down for the night. Do you have any suggestions or pointers where I could begin implementing or using a database get, delete, and set? I feel it's more extensible if config.Value was composed with a setting to migrate the old dynKey to a new dynKey over flipping the value when retrieving or setting.

The link to the commit above does accomplish this ticket, but I feel it just serves to be more confusing when working in the code base and it's not very extensible.

@markbrown87 commented on GitHub (Oct 12, 2025): I spent some time yesterday modifying the config.Value such that the value was flipped whenever retrieved. This was accomplished by specifying `.Invert()` in the init function. ```diff - DisableGravatar: config.ValueJSON[bool]("picture.disable_gravatar").WithFileConfig(config.CfgSecKey{Sec: "picture", Key: "DISABLE_GRAVATAR"}), + EnableGravatar: config.ValueJSON[bool]("picture.disable_gravatar").WithFileConfig(config.CfgSecKey{Sec: "picture", Key: "DISABLE_GRAVATAR"}).Invert(), ``` However, the frontend sets based on input check box which required a flip there as well. ```diff - setting.Config().Picture.DisableGravatar.DynKey(): strconv.FormatBool(form.DisableGravatar), + setting.Config().Picture.EnableGravatar.DynKey(): strconv.FormatBool(!form.EnableGravatar), ``` This meant the retrieval control flow and the setting control flow would both need to be flipped to accomplish flipping on the fly. This is the [commit on my forked repo](https://github.com/markbrown87/gitea/compare/main...markbrown87:gitea:feature/35627/align-enable-gravatar-and-removal-of-libravatar) to flip on the fly, which is more confusing, in my opinion. It does, however, retain backwards compatibility for `picture.disable_gravatar` without requiring a database migration for the value. --- I did spend the majority of my available time attempting to convert based on a composed "MigrateFrom" function such as ```golang EnableGravatar: config.ValueJSON[bool]("picture.enable_gravatar").MigrateFrom("picture.disable_gravatar").WithFileConfig(config.CfgSecKey{Sec: "picture", Key: "DISABLE_GRAVATAR"}).Invert(), ``` But found the use case of migrating from the old key value would cause for both `picture.disable_gravatar` and `picture.enable_gravatar` to be present in the database. This made it trickier to do purely from config.Value as the database would need to be updated only if `picture.disable_gravatar` was present at startup. --- I am not familiar enough with the codebase, so I didn't make it far before shutting down for the night. Do you have any suggestions or pointers where I could begin implementing or using a database get, delete, and set? I feel it's more extensible if config.Value was composed with a setting to migrate the old dynKey to a new dynKey over flipping the value when retrieving or setting. The link to the commit above does accomplish this ticket, but I feel it just serves to be more confusing when working in the code base and it's not very extensible.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#15014