Skip to content
This repository has been archived by the owner on Mar 9, 2022. It is now read-only.

Staticman v2 error: Too many requests in this time frame #373

Closed
VincentTam opened this issue Nov 14, 2018 · 4 comments
Closed

Staticman v2 error: Too many requests in this time frame #373

VincentTam opened this issue Nov 14, 2018 · 4 comments

Comments

@VincentTam
Copy link

screenshot from 2018-11-14 21-33-36

This reminds me eduardoboucas/staticman#222 and eduardoboucas/staticman#227. I suspect that the public production instance of Staticman v2 is hosted on a paid Heroku dyno and that the server is hitting the limits of his Heroku billing plan.

Here's the comment that I intend to leave under your great post about nested Staticman comments.


Test reply to Dan.

I think the "In reply to <name>" contains a logic error. When the "reply to thread button is clicked, the changeValue function only sets reply_to to _id of the head of the thread, and the parentName is tied with parentId. In one single thread, there's only one head (i.e. parentId), but it may have multiple participants (i.e. parentName).

Nonetheless, I've learnt a lot from your explanations. Thanks for this great article!

@dancwilliams
Copy link
Owner

Thanks for the great comment! I will sit down and give this a look.

@VincentTam
Copy link
Author

I've just published a pre-release of my fork of Beautiful Hugo and built an demo site on GitLab, thanks to your great tutorial.

@dancwilliams
Copy link
Owner

@VincentTam

Ugh...I am finally getting around to reviewing this code and your pull request on Beautiful Hugo. You have done some great stuff. I am going to work on integrating it into my setup over the next few days.

I put Staticman into my blog before someone built it into Beautiful Hugo and just never circled back. I am glad you found my blog useful. I know very little about forms and was learning Go templating on the fly, so thanks for taking my madness and making it clean!

@VincentTam
Copy link
Author

Looking back, the code for the reply target anchor in a comment reply can be much simpler if the id attribute for the article tag which wraps the comment is set to be the comment id in the YML file. This makes the link of a post comment much more stable than the current approach (id=comment-1). I didn't implement this in halogenica/beautifulhugo#222 because that would break the existing links to comments. However, you may further simplify my code by getting rid of the JS code for smooth scrolling, which I added to alter the behavior of the anchor.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants