Resolves#22692
I don't think there's a need for this entire row to be clickable (and
even different links depending on which segment you click)
The links still point to the same spot, so no information is lost here.
---------
Signed-off-by: jolheiser <john.olheiser@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Refactored `deps-docs` out of `docs` because #23629 broke Gitpod's docs
setup (which grepped to get the hugo install command).
Now `make deps` really installs everything to develop (includes `docs`).
Close#20553
There were already a lot of functions powered by JavaScript in Gitea.
Without JavaScript, the Gitea Web UI almost doesn't work (only some
static links work ....)
Follow:
* #23574
* Remove all ".tooltip[data-content=...]"
Major changes:
* Remove "tooltip" class, use "[data-tooltip-content=...]" instead of
".tooltip[data-content=...]"
* Remove legacy `data-position`, it's dead code since last Fomantic
Tooltip -> Tippy Tooltip refactoring
* Rename reaction attribute from `data-content` to
`data-reaction-content`
* Add comments for some `data-content`: `{{/* used by the form */}}`
* Remove empty "ui" class
* Use "text color" for SVG icons (a few)
Fixes#23645
* Added `describedby` attribute to the reference element.
* Eliminated `aria-expanded` attribute to the reference element in order
to conform strictly with WCAG 2.1 rules.
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>
`HookEventType` of pull request review comments should be
`HookEventPullRequestReviewComment` but some event types are
`HookEventPullRequestComment` now.
It use old en-US locales as reference, fill the old other locales with
new locales.
----
## More broken translations
Many translations are still broken. The reason is: at the last time
restoring the ini to crowdin, many semicolon are treated as comments.
Two kinds of broken strings:
### Some translations can be re-translated
<details>
```
skipping options/locale/locale_si-LK.ini org teams.add_nonexistent_repo
skipping options/locale/locale_tr-TR.ini repo commits.search.tooltip
skipping options/locale/locale_es-ES.ini repo settings.trust_model.committer.desc
skipping options/locale/locale_es-ES.ini admin dashboard.new_version_hint
skipping options/locale/locale_pt-PT.ini org teams.add_nonexistent_repo
skipping options/locale/locale_hu-HU.ini install require_sign_in_view_popup
skipping options/locale/locale_hu-HU.ini repo migrate.invalid_local_path
skipping options/locale/locale_id-ID.ini repo migrate.invalid_local_path
skipping options/locale/locale_id-ID.ini org teams.add_nonexistent_repo
skipping options/locale/locale_de-DE.ini repo settings.protect_protected_file_patterns_desc
```
</details>
So this PR also does some small changes on them, to trigger the
re-translation.
### The `locale_el-GR.ini` contains many broken tranlsations
I guess we should reset them from crowdin side, then translators can
re-translate them.
----
Update: in latest main, the strings have been fixed.
## TODO
Update: the el-GR translators have done great job and fixes these broken
translations.
<details>
Merge this PR ASAP and upload `locale_el-GR.ini` to crowdin to remove
broken strings.
Out-dated, fixed in main.
</details>
---------
Co-authored-by: delvh <dev.lh@web.de>
That's incorrect code caused by Copy&Paste.
`show-modal` / `show-panel` are used by JS to show something, but these
links have `href`, they should navigate to new page.
Close#23657
- **Installation**: includes how to install Gitea and related other
tools, also includes upgrade Gitea
- **Administration**: includes how to configure Gitea, customize Gitea
and manage Gitea instance out of Gitea admin UI
- **Usage**: includes how to use Gitea's functionalities. A sub
documentation is about packages, in future we could also include CI/CD
and others.
- **Development**: includes how to integrate with Gitea's API, how to
develop new features within Gitea
- **Contributing**: includes how to contribute code to Gitea
repositories.
After this is merged, I think we can have a sub-documentation of `Usage`
part named `Actions` to describe how to use Gitea actions
---------
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
Close#23622
As described in the issue, disabling the LFS/Package settings will cause
errors when running `gitea dump` or `gitea doctor`. We need to check the
settings and the related operations should be skipped if the settings
are disabled.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
## TLDR
* Improve performance: lazy creating the tippy instances.
* Transparently support all "tooltip" elements, no need to call
`initTooltip` again and again.
* Fix a temporary tooltip re-entrance bug, which causes showing temp
content forever.
* Upgrade vue3-calendar-heatmap to 2.0.2 with lazy tippy init
(initHeatmap time decreases from 100ms to 50ms)
## Details
### The performance
Creating a lot of tippy tooltip instances is expensive. This PR doesn't
create all tippy tooltip instances, instead, it only adds "mouseover"
event listener to necessary elements, and then switches to the tippy
tooltip
### The general approach for all tooltips
Before, dynamically generated tooltips need to be called with
`initTooltip`.
After, use MutationObserver to:
* Attach the event listeners to newly created tooltip elements, work for
Vue (easier than before)
* Catch changed attributes and update the tooltip content (better than
before)
It does help a lot, eg:
1a4efa0ee9/web_src/js/components/PullRequestMergeForm.vue (L33-L36)
### Temporary tooltip re-entrance bug
To reproduce, on try.gitea.io, click the "copy clone url" quickly, then
the tooltip will be "Copied!" forever.
After this PR, with the help of `attachTippyTooltip`, the tooltip
content could be reset to the default correctly.
### Other changes
* `data-tooltip-content` is preferred from now on, the old
`data-content` may cause conflicts with other modules.
* `data-placement` was only used for tooltip, so it's renamed to
`data-tooltip-placement`, and removed from `createTippy`.
Follow #23037
Fix [#22598
comment](https://github.com/go-gitea/gitea/issues/22958#issuecomment-1475763042)
Workflows with `pull_request` trigger event can't be triggered by
`pull_request_sync` event. This PR adds the `canGithubEventMatch`
function to check if a Github event can match any Gitea event. If the
Github event matches a Gitea event, the related workflows should be
triggered.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Add some review features that are notably missing from Gitlab CE but not
Gitea.
Also add Merge Queues which is not supported by Gitea but is quite an
important feature.
This PR follows #22599 and #23450
The major improvements:
1. The `aria-*.js` are totally transparent now, no need to call
`attachDropdownAria` explicitly anymore.
* It hooks the `$.fn.checkbox` and `$.fn.dropdown`, then our patch
works.
* It makes all dynamically generated checkbox/dropdown work with a11y
without any change
* eg: the `conversation.find('.dropdown').dropdown();` in `repo-diff.js`
2. Since it's totally transparent now, it could be easier to modify or
remove in the future.
3. It handles all selection labels as well (by onLabelCreate), so it
supports "multiple selection dropdown" now.
* It partially completes one of my TODOs: `TODO: multiple selection is
not supported yet.`
4. The code structure is clearer, code blocks are splitted into
different functions.
* The old `attachOneDropdownAria` was splitted into separate functions.
* It makes it easier to add more fine tunes in the future, and co-work
with contributors.
6. The code logic is similar as before, only two new parts:
1. the `ariaCheckboxFn` and `ariaDropdownFn` functions
2. the `onLabelCreate` and `updateSelectionLabel` functions
In `aria-dropdown.js` I had to mix jQuery and Vanilla JS somewhat, I
think the code is still understandable, otherwise the code would be much
more complex to read.
Thanks to fsologureng for the idea about "improving the 'delete icon'
with aria attributes".
If there is anything unclear or incorrect, feel free to ask and discuss,
or propose new PRs for it.
This updates the PR docs and explains how to work with PRs, for those
who may not know.
It was mentioned that this page could explain PRs a bit better, in case
some users are not familiar with GitHub or similar forges.
Signed-off-by: jolheiser <john.olheiser@gmail.com>
Since #23493 has conflicts with latest commits, this PR is my proposal
for fixing #23371
Details are in the comments
And refactor the `modules/options` module, to make it always use
"filepath" to access local files.
Benefits:
* No need to do `util.CleanPath(strings.ReplaceAll(p, "\\", "/"))),
"/")` any more (not only one before)
* The function behaviors are clearly defined
The `q` parameter was not rendered in pagination links because
`context.Pagination:AddParam` checks for existance of the parameter in
`ctx.Data` where it was absent. Added the parameter there to fix it.
Caught by @wxiaoguang in
https://github.com/go-gitea/gitea/pull/23337#issuecomment-1467317742.
Additionally, there were three instances that have the same content as `templates/base/deletion_modal_actions.tmpl` but that are not intended to delete something.
Instead of renaming the template above, these instances were simply re-hard-coded again.
Renaming/improving the template above is left for future PRs.
There are multiple duplicate reports of errors during template rendering
due to broken custom templates.
Unfortunately the error returned here is somewhat difficult for users to
understand and it doesn't return the context of the error.
This PR attempts to parse the error returned by the template renderer to
add in some further context including the filename of the template AND
the preceding lines within that template file.
Ref #23274
---------
Signed-off-by: Andrew Thornton <art27@cantab.net>
Related: #23590
Reference:
https://github.com/webcomponents/polyfills/tree/master/packages/webcomponentsjs
It seems that there are some users using old browsers, so the
`window.customElements` need polyfill.
The Custom Elements would help a lot for Gitea's UI problems, including:
* `<span class="js-pretty-number">`
* `<time data-format>`
So it's worth get polyfill.
---------
Co-authored-by: delvh <dev.lh@web.de>
---
Hi, very naive and **untested** first time ever Go code, feel free to
reject/edit this as needed.
(PyPI actually performs "naive" string comparison too)
---------
Co-authored-by: Lauris BH <lauris@nix.lv>
