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 385fc6ee6b)
- 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 16ecdb4170)
(cherry picked from commit 19dc5ef5e5)
(cherry picked from commit d5955efc0a)
(cherry picked from commit 2cdaf10836)
(cherry picked from commit 251b567794)
Conflicts:
modules/markup/markdown/markdown_test.go
https://codeberg.org/forgejo/forgejo/pulls/2153
(cherry picked from commit f863f4b005)
(cherry picked from commit f39f108934)
(cherry picked from commit 6d46f9ee40)
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 1666fba8f5)
(cherry picked from commit 48f38280e8)
(cherry picked from commit 03adb3a2b4)
(cherry picked from commit a0ad36f0ad)
(cherry picked from commit 3aac990064)
(cherry picked from commit 137daabc9b)
(cherry picked from commit b438aed4c1)
(cherry picked from commit 90b36f2e67)
- 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 452aef1bb1)
(cherry picked from commit 8a857c24b0)
(cherry picked from commit acd1456db9)
(cherry picked from commit 6523b45073)
(cherry picked from commit e2e1a8afe7)
(cherry picked from commit a46ef652eb)
(cherry picked from commit 54d5a8c073)
(cherry picked from commit 4a88dc6416)
(cherry picked from commit f88b58be3f)
(cherry picked from commit 316ff9767f)
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 631c87cc23)
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 8b8aab8311)
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/24805Closes: #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#24818Close#24222Close#21606Close#21498Close#25107Close#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>
