Use this guide if you already have a website configured with Welcomments, its website ID and a working integration that delivers comment files to this repository. Configure that service-side integration using the provider’s instructions before testing new submissions.
Review the integration files
Review any pull request generated by Welcomments before merging it. Retain the
customized _includes/welcomments/ templates supplied by
Chulapa, rather than replacing them with generic
provider templates. Review any local copies left by another theme: local files
override the installed theme’s files.
Keep the provider’s comment data and repository integration. The theme reads
comment data from _data/welcomments/; the website ID alone does not deliver
that data or configure the external service.
Select Welcomments
In _config.yml, edit the existing comments section, or add it once if absent.
Replace the example website ID and preserve unrelated settings:
comments:
provider: welcomments
website_id: "YOUR_WELCOMMENTS_WEBSITE_ID"
Check the form URL on a project site
The current theme form builds its permalink without baseurl. If your site
is under a path such as https://ana.github.io/my-blog, the submitted URL can
point outside /my-blog. Check this before using the integration.
For a site with baseurl, copy the theme’s
customized form
to _includes/welcomments/comment_form.html in your repository. Use the file
from your installed theme version; the linked main file is the development
version. Preserve the rest of that file; replace only the hidden permalink
input with:
<input type="hidden" name="permalink" id="permalink" value="{{ page.url | absolute_url }}">
When you publish the post below, inspect its hidden permalink value in your browser’s
developer tools. It must match the full article address, including the project
path. Keep this local override under review when upgrading the theme.
Enable one post
Open an existing post using layout: default. Add or update this value between
its existing --- lines, preserving the title, date, layout and other settings:
show_comments: true
Selecting a provider alone does not enable comments on the page. Save all changes on the publishing branch, wait for Actions to succeed and open the article on your public website.
Verify the form and saved comment
Check the form below the article. If appropriate, submit a test comment, verify that the service delivers its data to your repository, then check that a successful site rebuild displays it. A temporary browser placeholder is not proof that the comment has reached the published static site.
If the form is missing, check the website ID, show_comments, layout and local
template overrides. If a submitted comment never appears after a rebuild, check
the provider’s repository integration and delivered data, and confirm that the
post’s slug still matches its existing comment data. Renaming a post can change
that match; switching providers does not transfer old comments automatically.
For more posts, set show_comments: true individually or merge it into an
appropriate existing front matter default.
Other providers and exact fields are in the comments reference.