Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Per-Project Logo to use as og:image (for social posts) #3825

Closed
coolaj86 opened this issue Apr 20, 2018 · 6 comments
Closed

Per-Project Logo to use as og:image (for social posts) #3825

coolaj86 opened this issue Apr 20, 2018 · 6 comments
Labels
type/enhancement An improvement of existing functionality type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@coolaj86
Copy link
Contributor

coolaj86 commented Apr 20, 2018 •
edited
Loading

If I paste a project link into Facebook, LinkedIn, Twitter, etc it will first try to read from the og:image tag to get the photo that it should use in the image preview.

For example, https://git.coolaj86.com/coolaj86/greenlock.js shows this in the <head>:

<meta property="og:image" content="https://secure.gravatar.com/avatar/0a8b345ddcfc5401f578c850442f1e1b?d=identicon">

And shows this preview:

screen shot 2018-04-20 at 3 13 36 pm

However, I have a specific logo for this project and I would rather show the project logo than my own headshot.

I kindly request a feature to be added which would allow a specific logo to be chosen. For example, if there is a .githeme/logo.png or .gittheme/logo.jpg in the project repository, that that be used instead of the default author logo.

branch master:

.gittheme
.gittheme/logo.png
main.go
README.md

I'd also like to have a feature so that if .gittheme/config.yml exists that it specifies whether the logo (if none is present already) be pulled from the author, organization, or site. For example:

.gittheme/config.yml:

logo: 'site'
@lunny lunny added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Apr 21, 2018
@lafriks
Copy link
Member

lafriks commented Apr 21, 2018

I would rather see this as setting in database not in git (also from performance point of view)

@coolaj86
Copy link
Contributor Author

Performance is a non-issue. All of the top-level git file structure is already cached anyway.

Putting it in a database would make it proprietary and non-portable.

As the number of git systems grows, I hope that a standard emerges so that features like default issue templates and og tags work just as well in gitea as they do on github or gitlab.

@saitho
Copy link
Contributor

saitho commented May 1, 2019

Related to #694

@lunny
Copy link
Member

lunny commented May 6, 2019

@solderjs maybe @sergey-dryabzhinsky could also solve this one in his coming PR.

@lunny
Copy link
Member

lunny commented Jul 6, 2019

Since #694 closed by #6986, this is easy to implement.

@lunny lunny added the type/enhancement An improvement of existing functionality label Jul 6, 2019
@6543
Copy link
Member

6543 commented Sep 7, 2020

closed by #12586

@6543 6543 closed this as completed Sep 7, 2020
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
type/enhancement An improvement of existing functionality type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@lunny @coolaj86 @lafriks @saitho @6543