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
- In markdown, links are proccessed to be made absolute against the
relevant base in that context. Such that `./src` will be transformed
into `http://example.com/owner/repo/src/branch/main/src`.
- Don't try to make the link absolute if the link has a schema that's
defined in `[markdown].CUSTOM_URL_SCHEMES`, because they can't be made
absolute and doing so could lead to problems (see test case, double
slash was transformed to single slash).
- Adds unit test.
- Resolves https://codeberg.org/Codeberg/Community/issues/1489
- For regular non-image nonvideo links, they should be made relative,
this was done against `r.Ctx.Links.Base`, but since 637451a45e, that
should instead be done by `SrcLink()` if there's branch information set
in the context, because branch and treepath information are no longer
set in `r.Ctx.Links.Base`.
- This is consistent with how #2166 _fixed_ relative links.
- Media is not affected, `TestRender_Media` test doesn't fail.
- Adds unit tests.
- Ref https://codeberg.org/Codeberg/Community/issues/1485
Although GitHub removed support for the legacy callout syntax, we don't
have to! Restore this support via another AST transformer.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This lifts out the GitHub callout transformer from
`modules/markup/markdown/goldmark.go` to `callout/github.go`.
While there, clean up the transformer code:
- Use a map to look up supported callout types, rather than a regexp.
- Allow the callout type to be in any case, rather than just uppercase.
- Simplified `.Segment.Value()` to `.Text()`.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
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
- It's possible that the description of an `Regularlink` is `Text` and not
another `Regularlink`. Therefor if it's `Text`, convert it to an
`Regularlink` trough the 'old' behavior (pass it trough `org.String` and
trim `file:` prefix).
- Adds unit tests.
- Resolves https://codeberg.org/Codeberg/Community/issues/1430
(cherry picked from commit 385fc6ee6be25859066a716aa15be09991e2d33c)
- This adds coverage to the most common and the edge cases of what the
footnote implementation should be capable of. This was partly done to
ensure no hidden surprises when changing the implementation, as markdown
rendering is one of the more important features of Forgejo.
(cherry picked from commit 16ecdb41705332843921af8d58c1c9a242add95b)
(cherry picked from commit 19dc5ef5e5808abe8a5f85d3eaca3317865595ad)
(cherry picked from commit d5955efc0a463164c0b3a75b6621974af22ea47f)
(cherry picked from commit 2cdaf1083617acbeec558deeb657a1375cbb3904)
(cherry picked from commit 251b567794d3437aac614370e4fe2fdf7ad8b917)
Conflicts:
modules/markup/markdown/markdown_test.go
https://codeberg.org/forgejo/forgejo/pulls/2153
(cherry picked from commit f863f4b0054c3310fc487091c353670c65c96f35)
(cherry picked from commit f39f108934ae964c0efe79a1ccb5080d02e6dc72)
(cherry picked from commit 6d46f9ee4083128c2d43d2d73829d335f007cd34)
It will determine how anchors are created and will break existing
links otherwise.
Adapted from Revert "Make `user-content-* ` consistent with github (#26388)
(cherry picked from commit 1666fba8f577e11ea234c8a671aeaab1290cfbaf)
(cherry picked from commit 48f38280e8b9f34d7c45399f05a670ef3460dac1)
(cherry picked from commit 03adb3a2b46081e183738a86ca3d54bf730de0bd)
(cherry picked from commit a0ad36f0ad5d99896d5319e9aca11d0cf0ce23ee)
(cherry picked from commit 3aac9900640da2eeaac7950d14132361923d1a69)
(cherry picked from commit 137daabc9b437c9bd37b45a80e44880d0ac44656)
(cherry picked from commit b438aed4c1ff57985fcbe3687fc54c54ba680464)
(cherry picked from commit 90b36f2e67acec00870005647b906ea69ae11d27)
- Currently the parser will look for `\[` and `$$` to detect when Latex
code starts, it will look for `\]` and `$$` respectively in order to
determine the end of the code. However if no end is found the parser
assumes the rest of the input is part of the Latex code.
- Adjust the parser's behavior to not allow the case to assume the rest
of the input is part of the Latex code and requires in order to
determine if some input is Latex code that the end sequence is also
specified.
- Example: `\[hello]` would no longer be detected as Latex code with
this patch.
- Added unit tests.
- Resolves https://codeberg.org/forgejo/forgejo/issues/1817
(cherry picked from commit 452aef1bb1a5ccf986f187b6467d9827b01789f3)
(cherry picked from commit 8a857c24b0421145ece67a69d54e78af20689e0d)
(cherry picked from commit acd1456db9e5a16ad0f697b52b789cca4f96fc7c)
(cherry picked from commit 6523b45073838c168df75108b444f7fb2ef9dd2c)
(cherry picked from commit e2e1a8afe7f8a2627d518e7dc18cc7f97ca86e48)
(cherry picked from commit a46ef652ebac4422f6e4d48a676f8386dbfb7d0d)
(cherry picked from commit 54d5a8c073f49332358d181a8dd78464c6d58641)
(cherry picked from commit 4a88dc6416c7c6c552018ca0382373aa63329c9e)
(cherry picked from commit f88b58be3f6964d71094a7d7fe5067d9004a303c)
(cherry picked from commit 316ff9767ffc37a44949b6c504d465fc65ed4a60)
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>
In #26365 issue references were disabled entirely for documents,
intending to match GitHub behavior. However cross-references do appear
to work in documents on GitHub.
This is useful for example to write release notes in a markdown document
and reference issues. While the simpler syntax may create links when not
intended, hopefully the cross-reference syntax is unique enough to avoid
it.
Fix #28526, regression of
* #26365
(although the author of #26365 has recent activities, but there is no
response for the regression, so I proposed this quick fix and keep the
fix simple to make it easier to backport to 1.21)
- Currently the repository description uses the same sanitizer as a
normal markdown document. This means that element such as heading and
images are allowed and can be abused.
- Create a minimal restricted sanitizer for the repository description,
which only allows what the postprocessor currently allows, which are
links and emojis.
- Added unit testing.
- Resolves https://codeberg.org/forgejo/forgejo/issues/1202
- Resolves https://codeberg.org/Codeberg/Community/issues/1122
(cherry picked from commit 631c87cc2347f0036a75dcd21e24429bbca28207)
Co-authored-by: Gusted <postmaster@gusted.xyz>
- In org mode you can specify an description for media via the following
syntax `[[description][media link]]`. The description is then used as
title or alt.
- This patch fixes the rendering of the description by seperating the
description and non-description cases and using `org.String()`.
- Added unit tests.
- Inspired by
6eb20dbda9/org/html_writer.go (L406-L427)
- Resolves https://codeberg.org/Codeberg/Community/issues/848
(cherry picked from commit 8b8aab83113b34bade61964e2097ed497abc39e9)
Co-authored-by: Gusted <postmaster@gusted.xyz>
- Currently the post processing will transform all issue indexes (such as `#6`) into a clickable link.
- This makes sense in an situation like issues or PRs,
where referencing to other issues is quite common
and only referencing their issue index is an handy and efficient way to do it.
- Currently this is also run for documents
(which is the user profile and viewing rendered files),
but in those situations it's less common to reference issues by their index and instead could mean something else.
- This patch disables this post processing for issue index for documents. Matches Github's behavior.
- Added unit tests.
- Resolves https://codeberg.org/Codeberg/Community/issues/1120
Co-authored-by: Gusted <postmaster@gusted.xyz>
Regression: https://github.com/go-gitea/gitea/pull/24805
Closes: #25945
- Disallow `javascript`, `vbscript` and `data` (data uri images still
work) url schemes even if all other schemes are allowed
- Fixed older `cbthunderlink` tests
---------
Co-authored-by: delvh <dev.lh@web.de>
# The problem
There were many "path tricks":
* By default, Gitea uses its program directory as its work path
* Gitea tries to use the "work path" to guess its "custom path" and
"custom conf (app.ini)"
* Users might want to use other directories as work path
* The non-default work path should be passed to Gitea by GITEA_WORK_DIR
or "--work-path"
* But some Gitea processes are started without these values
* The "serv" process started by OpenSSH server
* The CLI sub-commands started by site admin
* The paths are guessed by SetCustomPathAndConf again and again
* The default values of "work path / custom path / custom conf" can be
changed when compiling
# The solution
* Use `InitWorkPathAndCommonConfig` to handle these path tricks, and use
test code to cover its behaviors.
* When Gitea's web server runs, write the WORK_PATH to "app.ini", this
value must be the most correct one, because if this value is not right,
users would find that the web UI doesn't work and then they should be
able to fix it.
* Then all other sub-commands can use the WORK_PATH in app.ini to
initialize their paths.
* By the way, when Gitea starts for git protocol, it shouldn't output
any log, otherwise the git protocol gets broken and client blocks
forever.
The "work path" priority is: WORK_PATH in app.ini > cmd arg --work-path
> env var GITEA_WORK_DIR > builtin default
The "app.ini" searching order is: cmd arg --config > cmd arg "work path
/ custom path" > env var "work path / custom path" > builtin default
## ⚠️ BREAKING
If your instance's "work path / custom path / custom conf" doesn't meet
the requirements (eg: work path must be absolute), Gitea will report a
fatal error and exit. You need to set these values according to the
error log.
----
Close #24818
Close #24222
Close #21606
Close #21498
Close #25107
Close #24981
Maybe close #24503
Replace #23301
Replace #22754
And maybe more
Fixes #25160.
`data-source-position` of checkboxes in a task list was incorrect
whenever there was YAML front matter. This would result in issue content
or PR descriptions getting corrupted with random `x` or space characters
when a user checked or unchecked a task.
This change makes the CSS for `<video>` in markup match that of `<img>`,
and also allows additional attributes to be used. This way the width,
padding, alignment should work equally well for both.
The old code has a lot of technical debts, eg: `repo/wiki/view.tmpl` /
`Iterate`
This PR improves the Wiki TOC display and improves the code.
---------
Co-authored-by: delvh <dev.lh@web.de>
Remove `[repository.editor] PREVIEWABLE_FILE_MODES` setting that seemed
like it was intended to support this but did not work. Instead, whenever
viewing a file shows a preview, also have a Preview tab in the file
editor.
Add new `/markup` web and API endpoints with `comment`, `gfm`,
`markdown` and new `file` mode that uses a file path to determine the
renderer.
Remove `/markdown` web endpoint but keep the API for backwards and
GitHub compatibility.
## ⚠️ BREAKING ⚠️
The `[repository.editor] PREVIEWABLE_FILE_MODES` setting was removed.
This setting served no practical purpose and was not working correctly.
Instead a preview tab is always shown in the file editor when supported.
---------
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
This branch continues the work of #23092 and attempts to rid the
codebase of any `nil` contexts when using a `RenderContext`.
Anything that renders markdown or does post processing may call
`markup.sha1CurrentPatternProcessor()`, and this runs
`git.OpenRepository()`, which needs a context. It will panic if the
context is `nil`. This branch attempts to _always_ include a context
when creating a `RenderContext` to prevent future crashes.
Co-authored-by: Kyle D <kdumontnu@gmail.com>
As you can imagine, for the Blender development process it is rather
nice to be able to include videos in issues, pull requests, etc.
This PR allows the `<video>` HTML tag to be used in MarkDown, with the
`src`, `autoplay`, and `controls` attributes.
## Help Needed
To have this fully functional, personally I feel the following things
are still missing, and would appreciate some help from the Gitea team.
### Styling
Some CSS is needed, but I couldn't figure out which of the LESS files
would work. I tried `web_src/less/markup/content.less` and
`web_src/less/_base.less`, but after running `make` the changes weren't
seen in the frontend.
This I would consider a minimal set of CSS rules to be applied:
```css
video {
max-width: 100%;
max-height: 100vh;
}
```
### Default Attributes
It would be fantastic if Gitea could add some default attributes to the
`<video>` tag. Basically `controls` should always be there, as there is
no point in disallowing scrolling through videos, looping them, etc.
### Integration with the attachments system
Another thing that could be added, but probably should be done in a
separate PR, is the integration with the attachments system. Dragging in
a video should attach it, then generate the appropriate MarkDown/HTML.
Some bugs caused by less unit tests in fundamental packages. This PR
refactor `setting` package so that create a unit test will be easier
than before.
- All `LoadFromXXX` files has been splited as two functions, one is
`InitProviderFromXXX` and `LoadCommonSettings`. The first functions will
only include the code to create or new a ini file. The second function
will load common settings.
- It also renames all functions in setting from `newXXXService` to
`loadXXXSetting` or `loadXXXFrom` to make the function name less
confusing.
- Move `XORMLog` to `SQLLog` because it's a better name for that.
Maybe we should finally move these `loadXXXSetting` into the `XXXInit`
function? Any idea?
---------
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: delvh <dev.lh@web.de>
These functions don't examine contents, just filenames, so they don't
fit in well in a markup module.
This was originally part of
https://github.com/go-gitea/gitea/pull/22177.
Signed-off-by: Nick Guenther <nick.guenther@polymtl.ca>
