Add support for Staticman reCAPTCHA

[lobopraveen]

Three new configs have been introduced:
1. enableReCaptcha
2. reCaptchaSiteKey
3. reCaptchaSecret

Last two configs are the same as reCaptcha > siteKey and
reCaptcha > secret from the staticman.yml

Just set the reCaptcha configs in your staticman.yml file.

Fixes #220

Although this works, you may want to refactor the JavaScript introduced in layouts/partials/comments/staticman/form.html. I would do it but I don't know how the JavaScript is all packaged into static/assets/js/comments.1234.js

The COMMENT! submit button should be disabled on click of the REPLY button on a comment or the CANCEL button (after click on REPLY). This is because the reCAPTCHA checkbox gets cleared on those clicks. If I check the reCAPTCHA and then click on REPLY or CANCEL, I can still submit the comment even though the reCAPTCHA checkbox is disabled. This is not a problem as I would have proved that I'm human by clicking on it once already but it just looks odd.

[VincentTam]

Great PR! Any chance to weight this in?

[MunifTanjim]

@lobopraveen Would you mind if I change/rearrange some config options before merging?

[lobopraveen]

Feel free to modify any way you see fit.

…

[MunifTanjim]

@lobopraveen @VincentTam

I've removed the options from config.toml. Now the template reads directly from staticman.yml, so the users won't need to set the options at two places.

Can you confirm that it works?

[VincentTam]

Due to eduardoboucas/staticman#235 and eduardoboucas/staticman#243 (comment), please make it clear (say, by editing the title of this PR), that this concerns reCAPTCHA v2.

[VincentTam]

@MunifTanjim Thanks for update. These lines in 57277aa are a smart way to avoid setting the reCAPTCHA parameters twice. I've never seen that before in other Jekyll/Hugo themes supporting reCAPTCHA.

minimo/layouts/partials/comments/staticman/form.html

Lines 11 to 12 in 57277aa

	{{- $staticman := ( ( readFile "staticman.yml" ) | transform.Unmarshal ) -}}
	{{- $reCaptcha := $staticman.comments.reCaptcha | default ( dict "enabled" false ) -}}

However, calling parameters from staticman.yml in the theme's template file will break our traditional understanding of the roles played by staticman.yml and config.xxx. As the author of Staicman says in eduardoboucas/staticman#264 (comment), Staticman is only responsible for ge tting HTML form data into a GitHub/GitLab repo, and the repo config file staticman.yml is responsible for receiving the API's response. The logic of structuring the HTML form data and the rendering the comments and the HTML form should be left to the theme, and the corresponding site config file is config.xxxx. In short, staticman.yml is responsible for receiving data, whereas config.xxx sets the display and site parameters.

Between convenience of setting secret once only and the clear division of roles of site and repo config files, I personally prefer the later due to the maintenance cost in the future.

[MunifTanjim]

@VincentTam

Staticman is only responsible for getting HTML form data into a GitHub/GitLab repo, and the repo config file staticman.yml is responsible for receiving the API's response.

In short, staticman.yml is responsible for receiving data

The way I see it, staticman.yml is not responsible for anything. It's just a config file for Staticman. Anything that is related to Staticman can read it to do tasks specific to Staticman - just like the API server reads it to know about the configuration set by the user.

Also, it is required to exist if you are using Staticman.

So, I can't think of any problem reading staticman.yml file while rendering templates that will only be used for Staticman related stuffs.

The logic of structuring the HTML form data and the rendering the comments and the HTML form should be left to the theme

It is left to the theme. If the user is using Staticman, staticman.yml file will surely exist. And the theme is reading configuration file for Staticman for rendering template. It doesn't actually matter where the configuration is coming from (config.toml or staticman.yml). In fact, Minimo doesn't even store all the theme's configuration in the config.toml file, some of them are stored in the data folder in separate files.

Again, the config.* file is just the default fallback configuration file for Hugo. You can actually name it anything and pass it with the hugo --config cli arg.

I personally prefer the later due to the maintenance cost in the future.

Can you please give me any example about what could go wrong in the future? 🤔

[VincentTam]

I can't think of any problem reading staticman.yml file while rendering templates that will only be used for Staticman related stuffs.

@MunifTanjim Let's get out of the box and think about the possibility of an alternate commenting system with reCAPTCHA support (say, from Staticman to Stapsher). Setting it in the site config is the most convenient way enable the user to re-use the key in case of switching commenting system. Note that it's common to switch commenting system in case of its dysfuctionning, for example, eduardoboucas/staticman#260 (comment). Putting reCAPTCHA's parameter inside staticman.yml would require additional config from the user. That might be the reason why recaptcha parameters are kept outside the staticman hierarchy in Minimal Mistake's _config.yml.

In fact, Minimo doesn't even store all the theme's configuration in the config.toml file, some of them are stored in the data folder in separate files.

Thanks for clarification, but that doesn't affect my main point: a clear separation of roles of theme-specific site config files (config.xxx, data, etc) and Staticman's repo config file (staticman.yml). A theme template shouldn't care whether the user use Disqus/Staticman/etc or not; Staticman shouldn't care whether the site owner uses Hugo/Jekyll/etc or not. Such distinction of roles are observed for almost all static blog themes that I've seen, including Minimal Mistakes, Beautiful Hugo, Hugo Future Imperfect Slim, etc. @lobopraveen has also followed this practice in his original PR.

[MunifTanjim]

@VincentTam

A theme template shouldn't care whether the user use Disqus/Staticman/etc or not

I'm confused 😕 If the theme doesn't know if the user is using Disqus/Staticman, how would it render the template for those?

Staticman shouldn't care whether the site owner uses Hugo/Jekyll/etc or not.

Staticman API service is only concerned about the staticman.yml and the API request. It doesn't need to know anything else. So, yeah, I agree. But it's out of the scope of this discussion.

That might be the reason why recaptcha parameters are kept outside the staticman hierarchy in Minimal Mistake's _config.yml.

I skimmed through the docs for Minimal Mistakes and their approach is different. The docs tell you to put all the options from staticman.yml into the _config.yml 🙄 It's not comparable to the approach taken in Minimo.

Such distinction of roles are observed for almost all static blog themes that I've seen, including Minimal Mistakes, Beautiful Hugo, Hugo Future Imperfect Slim,

"other themes do it" not a good reason to just follow the same approach.

Also, the reason behind not reading staticman.yml in other Hugo themes might be that the transform.Unmarshal function was not available in earlier Hugo versions. So it was not possible to do previously.

I don't know if Jekyll has the equivalent function for Hugo's readFile and transform.Unmarshal. If not that would explain why they don't do it, because they can't.

With Hugo, we can!

Let's get out of the box and think about the possibility of an alternate commenting system with reCAPTCHA support (say, from Staticman to Stapsher). Setting it in the site config is the most convenient way enable the user to re-use the key in case of switching commenting system.

Staticman encrypts the reCaptcha Secret with their own private key. Setting it in config.toml because of re-using it with other commenting systems is pointless. To the other commention systems won't be able to decrypt that reCaptcha Secret.

Putting reCAPTCHA's parameter inside staticman.yml would require additional config from the user.

I don't think I get your point. Say somebody's using Staticman. According to your suggestion, they will have to set the reCaptcha config in both staticman.yml and config.yml. Now let's say Staticman stopped working and the user is going to switch to a new system CommentX. CommentX will need it's own config file, say commentx.yml. So then the user will need to set the recaptcha setting in that file too.

Accoding to my suggestion, when using Staticman, user puts reCaptcha config in staticman.yml. When using CommentX, user puts the reCaptcha config in commentx.yml. So this approach is, in fact, a shorter process and needs less duplication.

[VincentTam]

I'm confused 😕 If the theme doesn't know if the user is using Disqus/Staticman, how would it render the template for those?

@MunifTanjim Lemme say it in a better way. It's the user's choice to use whatever commenting system they like. A theme does care the user's choice, but its theme owner doesn't. I've mixed up the two.

I skimmed through the docs for Minimal Mistakes and their approach is different. The docs tell you to put all the options from staticman.yml into the _config.yml 🙄 It's not comparable to the approach taken in Minimo.

Where? You're referring to the deprecated Staticman v1? That's not the case since v2.

Staticman encrypts the reCaptcha Secret with their own private key. Setting it in config.toml because of re-using it with other commenting systems is pointless. To the other commention systems won't be able to decrypt that reCaptcha Secret.

My bad. My mind had blocked me.

Can you please give me any example about what could go wrong in the future? 🤔

Who knows? I suppose we aren't fortune tellers. By the time you asked this question, somebody reported error in eduardoboucas/staticman#302, which is caused by a breaking change in Staticman's authorisation mechanism with GitHub. Due to such uncertainty, we need a clear division of roles, so that things are maintainable.

[MunifTanjim]

@VincentTam

Where? You're referring to the deprecated Staticman v1? That's not the case since v2.

( Not talking about staticman's _config but the theme's _config.yml)
Here: https://mmistakes.github.io/minimal-mistakes/docs/configuration/#staticman-v2

Who knows? I suppose we aren't fortune tellers. By the time you asked this question, somebody reported error in eduardoboucas/staticman#302, which is caused by a breaking change in Staticman's authorisation mechanism with GitHub.

I don't see how that issue is related to this. If you choose to use Staticman, you have to deal with the problems that come with it. If Staticman someday shuts down parmanently, you will still have your static comment files in your repository. You can either run your own Staticman instance or migrate to another commenting system. But other commenting systems won't support the same format that Staticman uses. So, you will need to change the formats of those static comment files yourself. That's just how it is...

Due to such uncertainty, we need a clear division of roles, so that things are maintainable.

I have no idea why you keep bringing up "clear division of roles" in your comments or what exactly you mean by that...

I don't know if you've read through the whole source codes of Minimo and noticed how it's organized. Without knowing about how different parts of Minimo fits together, it's easy to be confused about things.

---

From all our discussions, I still don't see any downsides of reading staticman.yml from template. Instead there are upsides to this approach.

Upsides:

• User doesn't need to duplicate settings in multiple places.
• Staticman's configuration is scoped in a single file: staticman.yml

Downsides:

• ???

So, unless you or somebody else who is interested in using Minimo & Staticman together can point out exactly what the downsides of reading staticman.yml from templates are, I'll merge the this PR after a waiting period.

[VincentTam]

( Not talking about staticman's _config but the theme's _config.yml)
Here: https://mmistakes.github.io/minimal-mistakes/docs/configuration/#staticman-v2

The link is about Staticman v2. Just underneath the sample Staticman repo config, there's a site config file, saying that

These settings need to be added to your _config.yml file as well:

# _config.yml (defaults)
repository  : # GitHub username/repo-name e.g. "mmistakes/minimal-mistakes"
comments:
  provider  : "staticman_v2"
  staticman:
    branch    : "master"

So I can't understand why you say

The docs tell you to put all the options from staticman.yml into the _config.yml.

I don't know if you've read through the whole source codes of Minimo and noticed how it's organized. Without knowing about how different parts of Minimo fits together, it's easy to be confused about things.

Nobody would read the whole code---they'll only read the relevant part. I don't want to be self-advertising, but I did clone your project to Framagit, and its gl-pages branch does work, after some modification of your code due to issue 202. Besides, I think my experience on setting up custom instances and building demo sites with different themes on Framagit allows me to quickly extract the most relevant parts about Staticman from a theme's source code.

P.S. It's me who has written the section "staticman v3" above your linked Minimal Mistakes docs, that's why I'm a little bit shocked about your remarks on Minimal Mistake's _config.yml.

Upsides:

• User doesn't need to duplicate settings in multiple places.
• Staticman's configuration is scoped in a single file: staticman.yml

The second point can never be true. Can you find another theme that put all Staticman's configurations in a single file? That's impossible.

In a theme template, Staticman's configurations consist of configurations for sending, receiving and rendering data. The first task requires several parameters in the URL (e.g. Git service, Git user name, etc) that can't be put under staticman.yml.

[MunifTanjim]

The link is about Staticman v2. Just underneath the sample Staticman repo config, there's a site config file, saying that
So I can't understand why you say
P.S. It's me who has written the section "staticman v3" above your linked Minimal Mistakes docs, that's why I'm a little bit shocked about your remarks on Minimal Mistake's _config.yml.

Ah, I see, sorry about that. I looked at that link and https://github.com/mmistakes/minimal-mistakes/blob/master/_config.yml and got confused. My bad 😅

The second point can never be true. Can you find another theme that put all Staticman's configurations in a single file? That's impossible.

In a theme template, Staticman's configurations consist of configurations for sending, receiving and rendering data. The first task requires several parameters in the URL (e.g. Git service, Git user name, etc) that can't be put under staticman.yml.

Yeah, I know. That's why this exists:

minimo/exampleSite/config.toml

Lines 97 to 103 in 4436676

	[params.comments.staticman]
	enable = true
	apiEndpoint = "https://api.staticman.net/v2/entry"
	maxDepth = 2
	username = "MunifTanjim"
	repository = "minimo"
	branch = "master"

By Staticman's configuration, I meant the options that are supported in staticman.yml.
Cause, reCaptcha section of staticman.yml contains the secret key, which is only usable with Staticman. No other services can use that. So, putting that in the theme's config.toml doesn't provide any advantage.

[VincentTam]

... "clear division of roles" in your comments or what exactly you mean by that

Edited: I mean a distinction between the theme-specific parameters and theme non-specific ones.

1. site config file: config.xxxx
   • theme-specific
   • for sending form data
2. repo config file: staticman.yml
   • must be root-level, file name can't be changed
   • for receiving data from a Staticman API instance

[VincentTam]

@MunifTanjim

Upsides:

• User doesn't need to duplicate settings in multiple places.
• Staticman's configuration is scoped in a single file: staticman.yml

If you're really concerned about users' convenience, I would suggest you to add a reCAPTCHA section at the bottom of Staticman's config file.

  # reCAPTCHA (OPTIONAL)
  # Register your domain at https://www.google.com/recaptcha/ and choose reCAPTCHA V2
  # Use your OWN siteKey and secret.
  reCaptcha:
    enabled: false
    #siteKey: "6Lcv8G8UAAAAAEqV1Y-XEPum00C_DxhD6O--qkFo"
    # (!) ENCRYPT reCaptcha secret key using Staticman /encrypt endpoint
    # i.e. https://staticman3.herokuapp.com/v3/encrypt/{your-site-secret}
    # For more information, https://staticman.net/docs/encryption
    #secret: "p5uHlH9hCqpMJaGKXdt5MEWFo7K6fX8hoYUwR3aIafOI6rtItLauaDCkGOucysJtrVZy+sHffioGzMsOU64JFDSyPQgrXujegcOHFRXHhD4fOUuBXSvV+OZ8JhSPTGWaRcQcoiGX4pT5hlebLddOl59b6sn6kU1ODQcEbhP83xVLZlaTWOrNrF5Wvy3TMXpH5gyl1tZEORxADAShMYyUbNR7XZYLEg1DfgIBHfIg3cKwdFt7KVLejFGKIiBYRAZDE2JuHItNmzJ2x9JgSK3E+XnShV5tuWpncnyFonJVHGEky/zRfUVLHobDMcJ/u9nlZqE8u47W+833F1WaIYuwNw=="

At the first glance, this shows that reCAPTHCA is supported. reCAPTHCA users can uncomment the two parameters to get the service, and other users can simply let it untouched. That would reder | default ( dict "enabled" false ) useless and simplify line 12 of the code block below.

For your second upside, I think you meant to say "reCAPTCHA's config", taking your "Staticman's configuration" into account.

Downsides:

• ???

So, unless you or somebody else who is interested in using Minimo & Staticman together can point out exactly what the downsides of reading staticman.yml from templates are, I'll merge the this PR after a waiting period.

Having read your lines again, I have finally come up with a drawback from a pratical point of view.

minimo/layouts/partials/comments/staticman/form.html

Lines 11 to 12 in 57277aa

	{{- $staticman := ( ( readFile "staticman.yml" ) | transform.Unmarshal ) -}}
	{{- $reCaptcha := $staticman.comments.reCaptcha | default ( dict "enabled" false ) -}}

For active blogs like zcrc.me, it often receives comments from @staticmanlab. Every time a comment gets merged, the site is re-built. It would be more sensible to load only two parameters from config.toml instead of the entire file staticman.yml.

Besides, in the template file, the Hugo variable $staticman is only called once, just for another Hugo variable $recaptcha. No matter reCAPTCHA is used or not, the whole Staticman config file is loaded. This adds unnecessary burden to the site regenerating process. It's more sensible to load these two reCAPTCHA parameters if and only if reCAPTCHA is enabled. For example, in Beautiful Hugo, the template looks like this.

  {{ if .Site.Params.staticman.recaptcha }}
  <input type="hidden" name="options[reCaptcha][siteKey]" value="{{ .Site.Params.staticman.recaptcha.sitekey }}">
  <input type="hidden" name="options[reCaptcha][secret]"  value="{{ .Site.Params.staticman.recaptcha.secret }}">
  {{ end }}

The site and Staticman configurations are supposed to be done once only, until the next theme/Staticman update. On the other hand, site regeneration happens each time the site/theme content/static files/etc change, so that takes place much more frequently. The inconvience of pasting the parameters twice in a short-term downside, but the additional blog regeneration time is a long-term one.

[MunifTanjim]

@VincentTam

I absolutely agree with the first part of your suggestion. I'm gonna update the sample staticman.yml.

But the second part 🤔 well, let's be realistic... We all know how fast Hugo is... So, for small sites, the time needed to read and parse a file multiple times will not even be noticeable. It will probably be noticeable if the site has thousands of pages... but then again, with a site that big, who's gonna use Minimo 😂

For the sake of argument, let's say somebody uses Minimo with a very large site, then we can just separate the read-and-parse-file part of the template in a separate partial and cache that partial. So it will actually be only read and parsed once per build (not once per page). Hugo supports caching and returning data from partial. So it'll not be a problem.

But at this point, it's just premature optimization 🤷‍♂️

Edit: Well, scratch that last line. Let's implement that caching part right in this PR! 😃

[MunifTanjim]

@VincentTam That should solve the performance concern...

[VincentTam]

It will probably be noticeable if the site has thousands of pages... but then again, with a site that big, who's gonna use Minimo 😂

For the sake of argument, let's say somebody uses Minimo with a very large site, then we can just separate the read-and-parse-file part of the template in a separate partial and cache that partial. So it will actually be only read and parsed once per build (not once per page). Hugo supports caching and returning data from partial. So it'll not be a problem.

@MunifTanjim Big template for Minimo site! 😲

I don't see how that issue is related to this. If you choose to use Staticman, you have to deal with the problems that come with it. If Staticman someday shuts down parmanently, you will still have your static comment files in your repository. You can either run your own Staticman instance or migrate to another commenting system. But other commenting systems won't support the same format that Staticman uses. So, you will need to change the formats of those static comment files yourself. That's just how it is...

After you've put Staticman v2 URL, I know how that's related to this PR, which modifies the documentation for Staticman. That link PR reports the breaking of Staticman v2 on the public production API instance, while your instructions ask people to continue using @staticmanapp. In fact, there's many Staticman on GitHub. Some of them might be a bot.

[VincentTam]

First time I try GtiHub review

[VincentTam]

Staticman

For up-to-date information, check out the Documentation Site and the Public Repository of Staticman.

Configure Minimo for Staticman

First of all, set up the following options in your config.toml file:

[params.comments.staticman]
enable = true
apiEndpoint = "https://api.staticman.net/v2/entry"
maxDepth = 2
username = "MunifTanjim"
repository = "minimo"
branch = "master"

source: https://github.com/MunifTanjim/minimo/blob/222af07402b1dba815b2ceac5b2a99b6485c6347/exampleSite/content/docs/comments-support.md

@MunifTanjim Please stop propagating the errors reported in eduardoboucas/staticman#222, eduardoboucas/staticman#227 and eduardoboucas/staticman#302, which have resulted in the use of the official production Staticman instance.

https://api.staticman.net/v2/entry

Please update the your theme's docs like Minimal Jekyll, Beautiful Jekyll & Hugo Swift Theme to provide info about Staticman v3 URL scheme introduced in eduardoboucas/staticman#219, which Staticman's official docs don't cover.

If you feel that the docs are too heavy, at least, for the sake of user's convenience, add a commented line in Staticman config template like the following.

  # reCaptcha
  # Register your domain at https://www.google.com/recaptcha/ and choose reCAPTCHA V2
  reCaptcha:
    enabled: false
    #siteKey: "6LdRBykTAAAAAFB46MnIu6ixuxwu9W1ihFF8G60Q"
    # Encrypt reCaptcha secret key using Staticman /encrypt endpoint
    # For more information, https://staticman.net/docs/encryption
    #secret: "PznnZGu3P6eTHRPLORniSq+J61YEf+A9zmColXDM5icqF49gbunH51B8+h+i2IvewpuxtA9TFoK68TuhUp/X3YKmmqhXasegHYabY50fqF9nJh9npWNhvITdkQHeaOqnFXUIwxfiEeUt49Yoa2waRR7a5LdRAP3SVM8hz0KIBT4="

source: eduardoboucas/staticman#243 (comment)

You've spent effort in inventing a method for reading two parameters from a YML file for users' convenience during site setup. Why don't you spare some time to put in a one-line comment to give users a better idea on these two parameters?

  # reCAPTCHA (OPTIONAL)
  # Register your domain at https://www.google.com/recaptcha/ and choose reCAPTCHA V2
  # Use your OWN siteKey and secret.
  reCaptcha:
    enabled: false
    #siteKey: "6Lcv8G8UAAAAAEqV1Y-XEPum00C_DxhD6O--qkFo"
    # (!) ENCRYPT reCaptcha secret key using Staticman /encrypt endpoint
    # i.e. https://{your-api}/v3/encrypt/{your-site-secret}
    # For more information, https://staticman.net/docs/encryption
    #secret: "p5uHlH9hCqpMJaGKXdt5MEWFo7K6fX8hoYUwR3aIafOI6rtItLauaDCkGOucysJtrVZy+sHffioGzMsOU64JFDSyPQgrXujegcOHFRXHhD4fOUuBXSvV+OZ8JhSPTGWaRcQcoiGX4pT5hlebLddOl59b6sn6kU1ODQcEbhP83xVLZlaTWOrNrF5Wvy3TMXpH5gyl1tZEORxADAShMYyUbNR7XZYLEg1DfgIBHfIg3cKwdFt7KVLejFGKIiBYRAZDE2JuHItNmzJ2x9JgSK3E+XnShV5tuWpncnyFonJVHGEky/zRfUVLHobDMcJ/u9nlZqE8u47W+833F1WaIYuwNw=="

With minimal effort, everyone knows that

1. there's reCAPTCHA v2 support at the first glance.
2. reCAPTCHA users can get things started with minimal editing, and they know to use /v3/encrypt.
3. non reCAPTCHA users can leave it untouched without affecting the functioning of the rest of your theme.

[VincentTam]

If you want to avoid duplicate input, then branch should be treated equally as reCaptcha parameters.

{{- $branch := $staticman.branch -}}

[MunifTanjim]

I'm regreting my decision to include Staticman support in this theme 🙃

[lobopraveen]

With all due respect to Vincent, you decide what you want to incorporate from his suggestions. Although he has some valid points, it is you who will have to maintain this project so you make the ultimate call. I don't remember all the discussions but from what I recall I'd put the flag to enable/disable the staticman in theme's config and read rest from the staticman config like you did at first. I'd also put a link to the staticman documentation instead of writing it in your project. It is not this project's problem to solve if staticman documentation is not up to date.

…

On Sat, Jul 6, 2019, 8:32 AM Munif Tanjim ***@***.***> wrote: I'm regreting my decision to include Staticman support in this theme 🙃 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#224?email_source=notifications&email_token=AAKR3HIEAXLKW6TW5M4U6J3P6CNGHA5CNFSM4HK5BC5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZKZXFQ#issuecomment-508926870>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKR3HK54MGA4YVI7AJGX3DP6CNGHANCNFSM4HK5BC5A> .

[VincentTam]

I'm regreting my decision to include Staticman support in this theme

@MunifTanjim Why? You've done a great job in providing the Staticman integration. Honestly speaking, your Hugo skills and logic used in this theme are much more advanced than other Jekyll/Hugo themes I've seen. I've created a Staticman + Minimo + Framagit demo site based on your amazing work: https://framagit.org/staticman-gitlab-pages/minimo. Just a bit of documentation and modification in the template are needed to enhance it and to avoid Staticman's issues. I should have mentioned my changes to the docs here: https://staticman-gitlab-pages.frama.io/minimo/docs/comments-support/#framagit.

The benefits of static comments are numerous, and you're probably more familiar with them than I do. Nonetheless, I would like to mention the fact the Disqus (along with popular Western IT companies like Google, Facebook, etc) is blocked in the PRC, which has several hundred millions of netizens. You might know more from the GitHub repo cirosantilli/china-dictatorship. To make the static blogs static, but resposive, not just in terms of mobile-friendliness, but in terms of its ability to interact with its readers, a static commenting system is a great-to-have. You've put huge effort in developing an integration that excels that of Network Hobo, which contains a logical error mentioned the repo's first issue. This great feature has already provided convenience to Staticman users.

Please don't be discouraged by the recent errors and difficulities that I've brought up during the discussion because Staticman is a distributed commenting system that would give users total control over their comments. By distributed, it means everyone can has its own version. That would free users in case of central server being blocked (due to maybe political reasons). I've written my experience to free some interested users from @staticmanapp, whose v2 no longer accepts invitation, contrary to what the official documentation claims. Others have also written their own versions, based on their perception on Staticman.

Looking back, I should have used less "should" and find an alternative word for that.

I don't remember all the discussions but from what I recall I'd put the flag to enable/disable the staticman in theme's config and read rest from the staticman config like you did at first.

@lobopraveen Your code speaks for itself. In what way did you load parameters from staticman.yml? Everything was loaded from $config, which was defined at the beginning as {{- $config := .Site.Params.comments.staticman -}}.

minimo/layouts/partials/comments/staticman/form.html

Lines 45 to 58 in b72b3bd

	{{- if $config.enableReCaptcha -}}
	<input type='hidden' name='options[reCaptcha][siteKey]' value='{{ $config.reCaptchaSiteKey }}'>
	<input type='hidden' name='options[reCaptcha][secret]' value='{{ $config.reCaptchaSecret }}'>
	<div class='g-recaptcha' data-sitekey='{{ $config.reCaptchaSiteKey }}' data-callback="enableSubmitComment"></div>
	<script type="text/javascript">
	function enableSubmitComment(){
	document.getElementById("submitComment").disabled = false;
	}
	</script>
	<script async src='https://www.google.com/recaptcha/api.js'></script>
	{{- end -}}

That's why we need to be clear about the role played by different config files. If we don't make it clear, we might commit errors, which might mislead users by any means of communication.

I'd also put a link to the staticman documentation instead of writing it in your project. It is not this project's problem to solve if staticman documentation is not up to date.

The theme is named "Minimo". Would you expect users who want minimal setup to

1. dig into page 2 of the docs
2. read the docs for commenting system
3. follow what the documentation did and try https://api.staticman.net/v2/entry
4. 😞 "invitation not found", "too many requests"? wait for a week, a month, a year?

You've made great effort on the logical side, but please think from the users' point of view.. After failing to set up a correct URL, desperate users might try whatever they can think of. If they get a little bit of hint from our theme, which aims at providing convenience for site owners, they might spare more time to create more meaningful stuff in return. I've learnt a great deal from the developer of Staticman's native GitLab support. This has enabled me to create demos which helps others to understand in turn. There're growing number of Staticman bot on GitHub/GitLab. To sum up, don't ignore a little butterfly in our documentation. They might have a far-reaching impact on static site owners who wish to create great contents.

[MunifTanjim]

Everything that's in scope of this PR is covered already. Merging...