Community-maintained fork of deprecated Grav Comments plugin (Admin trash / restore)

,
1

Hello,

The official Grav Comments plugin has been deprecated and is no longer actively maintained.

I’ve published a community-maintained fork that focuses on improving
a posteriori comment management in the Grav Admin, while strictly preserving:

  • frontend behavior,
  • existing YAML storage format,
  • backward compatibility with Comments v1.2.8.

onglet-commentaires-actifs
onglet-commentaires-actifs1478×578 71.8 KB

This fork does NOT try to replace the original plugin functionally,
but to keep it usable and safer for sites that still rely on it.

Admin-side additions only:

  • Non-destructive deletion (Trash workflow) with restore
  • Trash tab in the Admin interface
  • Pagination for both Active comments and Trash
  • Unified and robust Admin permission (admin.comments)
  • Localized Admin messages (fr / en / es where available)
  • No changes to frontend rendering
  • No changes to comment YAML data format

onglet-corbeille
onglet-corbeille1484×510 64 KB

compteur
compteur1244×592 49.5 KB

Latest release (recommended):

This is a community effort, not an official Grav plugin.
Feedback, testing reports, and suggestions are welcome.

Best regards,
Philippe

2

@pcrest, Please take a look at the Abandonned Resource Protocol to add a smooth upgrade for existing Comment users to you new fork. And please ensure backwards compatibility…

3

Thank you.
I’m currently publishing this as a community-maintained fork (manual install), but I understand the value of a smooth upgrade path for existing comments users.
I’ll review the Abandoned Resource Protocol and consider the takeover process once the fork has a bit more community validation/testing. Backwards compatibility (frontend behavior + YAML format) is a core requirement of this fork.

1 Like
4

the reason i understand why pamtbaau said that and what is abandoned resource protocol for is doing things for long run. but what i see is many plugins dont move let alone running or walking and i think short walk is better than waiting for long run.

if pcrest could create a plugin that does a work and wont hurt any other thing like plugins or system etc. im glad and thankful for what he did.

to avoid that protocol, i think you can just put a new name to it. like there are many plugins for image sliding.

im gonna try it.
btw about “Make sure you add your own Recaptcha site and secret keys too.”
i hope we can use grav’s captcha. i like it because i dont have to connect to anything outside of my website and it is easy to set and it does the work nice for me.

5

i couldnt make it work…
maybe because of this setting
“To set the enabled routes, create a user/config/plugins/comments.yaml file”

enable_on_routes:
  - "/"

i edited it as this to make it work for home page but couldnt see working result.
actually i cant see any changes on my page.

it would be better if you put “enabled routes” and " Enabling Recaptcha" settings in admin plugin too imo.

6

Thank you for taking the time to test the fork and for sharing such thoughtful feedback — it is genuinely appreciated.

Regarding the Abandoned Resource Protocol, I understand the long-term rationale behind it, and I agree with your observation: in practice, many plugins simply stop evolving, sometimes indefinitely. This fork is intentionally a small, careful step, not a long-term takeover. For now, the goal is simply to improve a very specific Admin-side gap without claiming broader responsibility. Renaming the plugin is indeed one of the reasons why this fork is clearly positioned as unofficial and kept outside GPM for the time being.

Thank you as well for the kind words — the main objective has been exactly that:
to add something useful without breaking anything, without changing data formats, and without impacting existing sites.

About reCAPTCHA / CAPTCHA

You are correct to point this out.
This fork does not introduce any new CAPTCHA mechanism and fully relies on what the original Comments plugin already supports. If your site is currently using Grav’s built-in CAPTCHA successfully, that remains unchanged. The note about reCAPTCHA keys comes from the upstream documentation and can indeed be misleading if you are not using Google reCAPTCHA specifically. This is something I will clarify in the documentation.

About “enabled routes” and not seeing changes

This is an important point, and thank you for reporting it.

A key clarification:
this fork does not change anything on the frontend.
If your comments were not visible before, they will not suddenly appear after installing the fork.

The changes introduced by the fork are Admin-only, namely:

  • managing existing comments,
  • trash / restore,
  • pagination,
  • counters.

The enable_on_routes setting only controls where comments are allowed to appear, but it does not alter templates or force comments to display if they were not already working. If comments are not visible on the homepage, the cause is usually one of the following:

  • the page template does not include comments,
  • comments are disabled at page or site level,
  • the original plugin was not fully configured before installing the fork.

I will make this Admin-only scope clearer in the README to avoid confusion.

About adding these settings to Admin

Your suggestion makes sense from a usability perspective, and I agree it would be cleaner.
However, adding route configuration and CAPTCHA setup to the Admin UI would go beyond the very narrow scope I have deliberately set for this fork. For now, the focus remains on post-moderation only, with minimal surface area and minimal risk.

That said, this is valuable feedback, and it helps define where the natural boundaries of the project are.

Thanks again for testing, for the constructive tone, and for taking the time to report back. This kind of feedback is exactly what helps decide what to clarify, what to document better, and what not to overextend.

1 Like