1. The previous color contrast calculation function was incorrect at
least for the `#84b6eb` where it output low-contrast white instead of
black. I've rewritten these functions now to accept hex colors and to
match GitHub's calculation and to output pure white/black for maximum
contrast. Before and after:
<img width="94" alt="Screenshot 2024-04-02 at 01 53 46"
src="https://github.com/go-gitea/gitea/assets/115237/00b39e15-a377-4458-95cf-ceec74b78228"><img
width="90" alt="Screenshot 2024-04-02 at 01 51 30"
src="https://github.com/go-gitea/gitea/assets/115237/1677067a-8d8f-47eb-82c0-76330deeb775">
2. Fix project-related issues:
- Expose the new `ContrastColor` function as template helper and use it
for project cards, replacing the previous JS solution which eliminates a
flash of wrong color on page load.
- Fix a bug where if editing a project title, the counter would get
lost.
- Move `rgbToHex` function to color utils.
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: Giteabot <teabot@gitea.io>
---
Conflict resolution: Trivial.
(cherry picked from commit 36887ed3921d03f1864360c95bd2ecf853bfbe72)
(cherry picked from commit f6c0c39f1a)
When mentioning a user, the markup post-processor did not handle the
case where the mentioned user did not exist well: it tried to skip to
the next node, which in turn, ended up skipping the rest of the line.
To fix this, lets skip just the mentioned, but non-existing user, and
continue processing the current node from there.
Fixes #3535.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 9a01062ae2)
This is a squashed result of conflict resolution for the following commits from Gitea:
- 36de5b299b
- 9a93b1816e
- 712e19fa6f
- 83850cc479
It is lacking CSS rule for archived labels, though.
Changes in this commit are authored by:
- 6543
- delvh
- silverwind
(cherry picked from commit 4b09dd11ec)
* "mail/issue/default.tmpl": the body is rendered by backend
`markdown.RenderString() HTML`, it has been already sanitized
* "repo/settings/webhook/base_list.tmpl": "Description" is prepared by
backend `ctx.Tr`, it doesn't need to be sanitized
(cherry picked from commit dae7f1ebdbe19620f40e110b285f7c0ecd0bb33b)
Str2html was abused a lot. So use a proper name for it: SanitizeHTML
And add some tests to show its behavior.
(cherry picked from commit fb42972c057364a1dc99dfb528554e7a94415be7)
Conflicts:
docs/content/administration/mail-templates.en-us.md
docs/content/administration/mail-templates.zh-cn.md
prefer their version always
This PR touches the most interesting part of the "template refactoring".
1. Unclear variable type. Especially for "web/feed/convert.go":
sometimes it uses text, sometimes it uses HTML.
2. Assign text content to "RenderedContent" field, for example: `
project.RenderedContent = project.Description` in web/org/projects.go
3. Assign rendered content to text field, for example: `r.Note =
rendered content` in web/repo/release.go
4. (possible) Incorrectly calling `{{Str2html
.PackageDescriptor.Metadata.ReleaseNotes}}` in
package/content/nuget.tmpl, I guess the name Str2html misleads
developers to use it to "render string to html", but it only sanitizes.
if ReleaseNotes really contains HTML, then this is not a problem.
(cherry picked from commit e71eb8930a5d0f60874b038c223498b41ad65592)
Conflicts:
modules/templates/util_string.go
trivial context conflict
When mentioning a user in a comment, or a similar place, sometimes one
would wish to use a possessive: `As per @user's suggestion` or somesuch.
This patch modifies the `mentionPattern` used to find mentions, to allow
- and then ignore - apostrophes and whatever comes after them.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Follow #29165
* some of them are incorrect, which would lead to double escaping (eg:
`(print (Escape $.RepoLink)`)
* other of them are not necessary, because `Tr` handles strings&HTML
automatically
Suggest to review by "unified view":
https://github.com/go-gitea/gitea/pull/29394/files?diff=unified&w=0
(cherry picked from commit d2f6588b66549b33adf8bac7044d03c89d668470)
Conflicts:
templates/code/searchcombo.tmpl
templates/mail/auth/register_notify.tmpl
templates/mail/issue/default.tmpl
templates/repo/code/recently_pushed_new_branches.tmpl
templates/repo/search.tmpl
templates/repo/settings/protected_branch.tmpl
templates/user/auth/activate.tmpl
templates/user/auth/forgot_passwd.tmpl
templates/user/dashboard/feeds.tmpl
context
After this PR: no need to play with the Safe/Escape tricks anymore. See
the changes for more details.
(cherry picked from commit f9207b09479df964872d68842469991042b5497f)
Conflicts:
templates/repo/issue/view_title.tmpl
templates/user/settings/applications.tmpl
context
RenderEmojiPlain(emoji.ReplaceAliases) should be called explicitly for
some contents, but not for everything.
Actually in modern days, in most cases it doesn't need such
"ReplaceAliases". So only keep it for issue/PR titles.
If anyone really needs to do ReplaceAliases for some contents, I will
propose a following fix.
(cherry picked from commit 10c7996b5a5c705964fc6cc9c1817eea1fc436ef)
Conflicts:
templates/base/head.tmpl
context
Follow #29165.
* Introduce JSONTemplate to help to render JSON templates
* Introduce JSEscapeSafe for templates. Now only use `{{ ... |
JSEscape}}` instead of `{{ ... | JSEscape | Safe}}`
* Simplify "UserLocationMapURL" useage
(cherry picked from commit 31bb9f3247388b993c61a10190cfd512408ce57e)
Refactor locale&string&template related code has .Title be
template.HTML and "Improve HTML title on repositories" needs to check
the prefix with StringUtils.HasPrefix
Clarify when "string" should be used (and be escaped), and when
"template.HTML" should be used (no need to escape)
And help PRs like #29059 , to render the error messages correctly.
(cherry picked from commit f3eb835886031df7a562abc123c3f6011c81eca8)
Conflicts:
modules/web/middleware/binding.go
routers/web/feed/convert.go
tests/integration/branches_test.go
tests/integration/repo_branch_test.go
trivial context conflicts
This implements "repository flags", a way for instance administrators to
assign custom flags to repositories. The idea is that custom templates
can look at these flags, and display banners based on them, Forgejo does
not provide anything built on top of it, just the foundation. The
feature is optional, and disabled by default. To enable it, set
`[repository].ENABLE_FLAGS = true`.
On the UI side, instance administrators will see a new "Manage flags"
tab on repositories, and a list of enabled tags (if any) on the
repository home page. The "Manage flags" page allows them to remove
existing flags, or add any new ones that are listed in
`[repository].SETTABLE_FLAGS`.
The model does not enforce that only the `SETTABLE_FLAGS` are present.
If the setting is changed, old flags may remain present in the database,
and anything that uses them, will still work. The repository flag
management page will allow an instance administrator to remove them, but
not set them, once removed.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit ba735ce222)
(cherry picked from commit f09f6e029b)
(cherry picked from commit 2f8b041489)
(cherry picked from commit d3186ee5f4)
Fixes #26548
This PR refactors the rendering of markup links. The old code uses
`strings.Replace` to change some urls while the new code uses more
context to decide which link should be generated.
The added tests should ensure the same output for the old and new
behaviour (besides the bug).
We may need to refactor the rendering a bit more to make it clear how
the different helper methods render the input string. There are lots of
options (resolve links / images / mentions / git hashes / emojis / ...)
but you don't really know what helper uses which options. For example,
we currently support images in the user description which should not be
allowed I think:
<details>
<summary>Profile</summary>
https://try.gitea.io/KN4CK3R
</details>
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Part of https://github.com/go-gitea/gitea/issues/27097:
- `gitea` theme is renamed to `gitea-light`
- `arc-green` theme is renamed to `gitea-dark`
- `auto` theme is renamed to `gitea-auto`
I put both themes in separate CSS files, removing all colors from the
base CSS. Existing users will be migrated to the new theme names. The
dark theme recolor will follow in a separate PR.
## ⚠️ BREAKING ⚠️
1. If there are existing custom themes with the names `gitea-light` or
`gitea-dark`, rename them before this upgrade and update the `theme`
column in the `user` table for each affected user.
2. The theme in `<html>` has moved from `class="theme-name"` to
`data-theme="name"`, existing customizations that depend on should be
updated.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Giteabot <teabot@gitea.io>
Part of #27065
This PR touches functions used in templates. As templates are not static
typed, errors are harder to find, but I hope I catch it all. I think
some tests from other persons do not hurt.
1. The `og:description` should be "a one to two sentence description of
your object"
* It shouldn't output all the user inputted content -- it would be
pretty huge.
* Maybe it only needs at most 300 bytes.
2. Do not render commit message as HTML
Backtick syntax now works in repo description too. Also, I replaced the
CSS for this was a new single class, making it more flexible and not
dependent on a parent. Also, very slightly reduced font size from 16.8px
to 16px.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
There are 2 kinds of ".Editorconfig" in code, one is `JSON string` for
the web edtior, another is `*editorconfig.Editorconfig` for the file
rendering (used by `TabSizeClass`)
This PR distinguish them with different names.
And by the way, change the default tab size from 8 to 4, I think few
people would like to use 8-size tabs nowadays.
Before:
* `{{.locale.Tr ...}}`
* `{{$.locale.Tr ...}}`
* `{{$.root.locale.Tr ...}}`
* `{{template "sub" .}}`
* `{{template "sub" (dict "locale" $.locale)}}`
* `{{template "sub" (dict "root" $)}}`
* .....
With context function: only need to `{{ctx.Locale.Tr ...}}`
The "ctx" could be considered as a super-global variable for all
templates including sub-templates.
To avoid potential risks (any bug in the template context function
package), this PR only starts using "ctx" in "head.tmpl" and
"footer.tmpl" and it has a "DataRaceCheck". If there is anything wrong,
the code can be fixed or reverted easily.
