3 Commits (0c9dcda10d3938b80166a4cffa2854d34a0134fb)

Author	SHA1	Message	Date
silverwind	9730d3a9af	Update various logos and unify their filenames (#29637) ... 1. Checked all logos, updated 3 of them to newer versions. 2. Remove `open-with-` infix on the editor logos to be consistent with other files. <img width="626" alt="image" src="https://github.com/go-gitea/gitea/assets/115237/3b2d9486-6e0a-45c6-b0e4-d38dc4c0b118">	12 months ago
silverwind	06dcb251f3	Update JS and PY dependencies (#28120) ... - Update all JS and PY dependencies minus `@mcaptcha/vanilla-glue` - Adapt to eslint rule rename - Regenerate all SVGs because of [new optimizations](https://github.com/svg/svgo/releases/tag/v3.0.4) from svgo. - Tested mentions, mermaid, vue, api docs	1 year ago
wxiaoguang	faa28b5a44	Move public asset files to the proper directory (#25907) ... Move `public/*` to `public/assets/*` Some old PRs (like #15219) introduced inconsistent directory system. For example: why the local directory "public" is accessed by `http://site/assets`? How to serve the ".well-known" files properly in the public directory? For convention rules, the "public" directory is widely used for the website's root directory. It shouldn't be an exception for Gitea. So, this PR makes the things consistent: * `http://site/assets/foo` means `{CustomPath}/public/assets/foo`. * `{CustomPath}/public/.well-known` and `{CustomPath}/public/robots.txt` can be used in the future. This PR is also a prerequisite for a clear solution for: * #21942 * #25892 * discourse.gitea.io: [.well-known path serving custom files behind proxy?](https://discourse.gitea.io/t/well-known-path-serving-custom-files-behind-proxy/5445/1) This PR is breaking for users who have custom "public" files (CSS/JS). After getting approvals, I will update the documents. ---- ## ⚠️ BREAKING ⚠️ If you have files in your "custom/public/" folder, please move them to "custom/public/assets/". --------- Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: Giteabot <teabot@gitea.io>	2 years ago
silverwind	a51b115b0a	Use inline SVG for built-in OAuth providers (#25171) ... The plan is that all built-in auth providers use inline SVG for more flexibility in styling and to get the GitHub icon to follow `currentcolor`. This only removes the `public/img/auth` directory and adds the missing svgs to our svg build. It should map the built-in providers to these SVGs and render them. If the user has set a Icon URL, it should render that as an `img` tag instead. ``` gitea-azure-ad gitea-bitbucket gitea-discord gitea-dropbox gitea-facebook gitea-gitea gitea-gitlab gitea-google gitea-mastodon gitea-microsoftonline gitea-nextcloud gitea-twitter gitea-yandex octicon-mark-github ``` GitHub logo is now white again on dark theme: <img width="431" alt="Screenshot 2023-06-12 at 21 45 34" src="https://github.com/go-gitea/gitea/assets/115237/27a43504-d60a-4132-a502-336b25883e4d"> --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>	2 years ago