Request: Theme support and the Store #3804

New Issue

GiteaMirror · 2025-11-02T05:25:48-06:00

GiteaMirror commented

2025-11-02 05:25:48 -06:00

Originally created by @Th3Whit3Wolf on GitHub (Aug 18, 2019).

It would be cool if Gitea had a website or repo where people could download and contribute to themes for Gitea.

Originally created by @Th3Whit3Wolf on GitHub (Aug 18, 2019). It would be cool if Gitea had a website or repo where people could download and contribute to themes for Gitea.

GiteaMirror added the type/proposal label 2025-11-02 05:25:48 -06:00

GiteaMirror closed this issue

2025-11-02 05:25:48 -06:00

GiteaMirror commented

2025-11-02 05:25:48 -06:00

@lunny commented on GitHub (Aug 8, 2020):

A theme is a zip package which contains the css/less files and some custom golang template files. Js files should not be allowed currently for security consideration.

There is an entry file which could be named main.yml which contains all the meta informations which the theme needed. Css/less/template files location have been references as a relative path on the main.yml.

All possible informations:

File version, currently always 1. Once we have another file format, we may use 2.
Name: the theme name.
Type: theme. We may have another type like plugin.
Version: the version of the zip package.
Required gitea versions: Not matched gitea cannot install the theme in production mode.
Authors: name
Website link
Avatar: reversed word.
Screenshots: which maybe displayed on the market and the gitea instance if online mode enabled.
Css/Less files path
Template files path
Permissions: which parts the package will visit the gitea, it's similar with webhook options.

Gitea could have a feature to install a theme by administrator on admin panel by upload a theme package file or install it from the URL online.

When installing a theme, the theme information should be stored in database table maybe named theme or plugin(A theme is also some kind of plugin). All needed files should be copied to the location where the themes stored currently. And also gitea should reload all the themes.

A theme could be also uninstalled.

The site name could be https://themes.gitea.io or https://store.gitea.io

@lunny commented on GitHub (Aug 8, 2020): A theme is a zip package which contains the css/less files and some custom golang template files. Js files should not be allowed currently for security consideration. There is an entry file which could be named `main.yml` which contains all the meta informations which the theme needed. Css/less/template files location have been references as a relative path on the `main.yml`. All possible informations: - File version, currently always 1. Once we have another file format, we may use 2. - Name: the theme name. - Type: theme. We may have another type like `plugin`. - Version: the version of the zip package. - Required gitea versions: Not matched gitea cannot install the theme in production mode. - Authors: name <mail> - Website link - Avatar: reversed word. - Screenshots: which maybe displayed on the market and the gitea instance if online mode enabled. - Css/Less files path - Template files path - Permissions: which parts the package will visit the gitea, it's similar with webhook options. Gitea could have a feature to install a theme by administrator on admin panel by upload a theme package file or install it from the URL online. When installing a theme, the theme information should be stored in database table maybe named `theme` or `plugin`(A theme is also some kind of plugin). All needed files should be copied to the location where the themes stored currently. And also gitea should reload all the themes. A theme could be also uninstalled. The site name could be https://themes.gitea.io or https://store.gitea.io

GiteaMirror commented

2025-11-02 05:25:49 -06:00

@silverwind commented on GitHub (Aug 8, 2020):

Still that would not solve the fundamental issue that if we introduce new rules in the base theme, it breaks all existing themes.

.some-selector {
  background: #fff;
}

Now all themes break unless they copy that selector and override the rule. I think for themes to be actually feasible, we need:

All colors to be defined in CSS variables
(Optionally) Let the theme have its own remap-css configuration options so they can benefit from auto-generated selectors. This probably means a theme needs to be either a JSON or JS file.

@silverwind commented on GitHub (Aug 8, 2020): Still that would not solve the fundamental issue that if we introduce new rules in the base theme, it breaks all existing themes. ```css .some-selector { background: #fff; } ``` Now all themes break unless they copy that selector and override the rule. I think for themes to be actually feasible, we need: 1. All colors to be defined in CSS variables 2. (Optionally) Let the theme have its own `remap-css` configuration options so they can benefit from auto-generated selectors. This probably means a theme needs to be either a JSON or JS file.

GiteaMirror commented

2025-11-02 05:25:49 -06:00

@lunny commented on GitHub (Aug 8, 2020):

@silverwind So we could have some gitea versions on the theme. If the theme isn't matched gitea's version it will be disabled automatically. Only remap-css will limit the ability a theme could do. I noticed some themes need customerized templates.

And we should also consider how a theme creator to develop a theme with a gitea binary instance easily.

@lunny commented on GitHub (Aug 8, 2020): @silverwind So we could have some gitea versions on the theme. If the theme isn't matched gitea's version it will be disabled automatically. Only `remap-css` will limit the ability a theme could do. I noticed some themes need customerized templates. And we should also consider how a theme creator to develop a theme with a gitea binary instance easily.

GiteaMirror commented

2025-11-02 05:25:49 -06:00

@silverwind commented on GitHub (Aug 8, 2020):

Actually I don't think we even need to expose remap-css config. We can just have it generate the CSS variable-defined rules out of the gitea theme, overriding the fomantic rules (which in itself is around 150kB of CSS) which then can be overridden again by the theme and that way, the theme could stay pure CSS.

Only downside of that method is the extra CSS weight in the base theme but I see no other way given the unflexible nature of Fomantic.

@silverwind commented on GitHub (Aug 8, 2020): Actually I don't think we even need to expose `remap-css` config. We can just have it generate the CSS variable-defined rules out of the gitea theme, overriding the fomantic rules (which in itself is around 150kB of CSS) which then can be overridden again by the theme and that way, the theme could stay pure CSS. Only downside of that method is the extra CSS weight in the base theme but I see no other way given the unflexible nature of Fomantic.

GiteaMirror referenced this issue

2025-11-02 12:26:03 -06:00

[PR #3804] [MERGED] Added explanation for docker environment variables to docs #17089

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#3804