Remove Staticman #21
Remove Staticman #21
Conversation
Hi, this is the collaborator of Hugo Swift Theme, and the maintainer of @staticmanlab, a public GitLab instance of Staticman. You see from the linked GitHub bot's activities and from an array of Staticman demo sites on Framagit that Staticman v3's URL scheme suggested in eduardoboucas/staticman#219 is actually working. |
|
Thanks, I'll read through there and update the theme appropriately (or feel
free to make a PR that holds everything correctly). I couldn't get it to
work for the longest.
…On Tue, Jun 25, 2019, 6:48 AM Vincent Tam ***@***.***> wrote:
Staticman is dead and has been for awhile. No reason to support it at this
time. I would like some sort of feedback before merging this.
eduardoboucas/staticman#243
<eduardoboucas/staticman#243>
Hi, this is the collaborator of Hugo Swift Theme
<https://github.com/onweru/hugo-swift-theme>, and the maintainer of
@staticmanlab <https://github.com/staticmanlab>, a public GitLab instance
of Staticman. You see from the linked GitHub bot's activities and from an
array of Staticman demo sites on Framagit
<https://framagit.org/staticman-gitlab-pages> that Staticman v3's URL
scheme suggested in eduardoboucas/staticman#219
<eduardoboucas/staticman#219> is actually working.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#21?email_source=notifications&email_token=ACWVJSPKL6GP6CCRVYXMS4LP4HZXHA5CNFSM4H2V5IE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYP2RRY#issuecomment-505391303>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACWVJSMDEKGAVMWZI3YJK53P4HZXHANCNFSM4H2V5IEQ>
.
|
|
I don't (and I won't) know how Staticman v3 works with GitHub Apps, which is a proprietary technology that won't interest much evangelical free software users. However, the Node.JS app itself after PR219 and before PR243 works well with custom GitLab instance like Framagit. I'm sorry that I lack time to make a PR, but the official API instance failure doens't necessarily imply a bug in the Node.JS app or an error in the theme's Staticman integration. There's no need to remove the later due to the former, a little tweak in the HTML <form id="comment-form" class="js-form form" method="post"
action="{{ .Site.Params.staticman.endpoint | default "https://staticman-frama.herokuapp.com" }}/v3/entry/{{ .Site.Params.staticman.gitProvider }}/{{ .Site.Params.staticman.repo }}/{{ .Site.Params.staticman.branch }}/comments">in my tweak of Huginn theme will do. |
|
Essentially, my motivation is that a user should be able to serve this theme with minimal set-up. This means using a public instance like Staticman v2 was. It is my understanding that If you are implying that If you are implying that the user needs to create their own instance of Staticman (which would imply that Staticman as a service is dead), that is beyond the scope of what the theme should include and becomes bloat. I would rather have that as an "add-on" in a separate repository as things you can implement at the site level rather than the theme level. |
|
Your motiviation echoes that of the author of Beautiful Jekyll, which has incorporated my port of Minimal Mistake's Staticman integration. Just like many big projects, users may either build their own API instance, or choose any existing public instances. Many users choose the official one, but it's reported in eduardoboucas/staticman#285 that the official one is not quite stable due to unnotified upgrades. To avoid that, I suggest using an alternative API instance. By saying "alternative", it simply means "anything but official". It can be custom-built, an existing third-party one, etc. What I'm suggesting is Minimal Mistake's approach: add an additional parameter in the site config file to allow specifying a custom Staticman API instance, with a default value to a currently working instance. P.S. Having suggested the adoption of an alternative API instance, I have to mention that I've built @staticmanlab, as my user bio reads. |
|
Thanks for that clarification. That is what I was looking for. My assumption based on your comment was that I should just leave it and then users could just host their own version, which would be annoying to people looking at the theme as an "out-of-the-box" solution. I will look into your version. I love Staticman and hated that the official ran into issues. |
|
| "name" | "public GitLab instance" | "public Framagit instance" |
|---|---|---|
| GitLab instance served | GitLab.com | Framagit |
gitlabBaseUrl |
https://gitlab.com | https://framagit.org |
| GitLab Bot | staticmanlab | staticmanlab1 |
githubBaseUrl |
https://github.com | https://github.com |
| API URL | https://staticman3.herokuapp.com | https://staticman-frama.herokuapp.com |
Both of them are run on a Heroku free dyno, which sleeps after 30 minutes of inactivity and has a 20s wake-up time.
|
I've just tested Staticman with this theme on Framagit with my API instance. Staticman really does its job of getting the form data to the GitLab repo, despite some URL errors similar to #32. As a result, there's no reason to remove this support and please drpo this PR. Demo site: https://vincenttam.frama.io/fish-demo/blog/creating-a-new-theme |
Description
Removal of all references to Staticman.
Motivation and Context
Staticman is dead and has been for awhile. No reason to support it at this time. I would like some sort of feedback before merging this. eduardoboucas/staticman#243
Through a waterfall effect, this closes #7.
How Has This Been Tested?
Hugo Version: 0.50
Browser(s): Chrome
Screenshots (if appropriate):
Types of changes
Checklist:
theme.toml, accordingly.