getgrav / grav

Modern, Crazy Fast, Ridiculously Easy and Amazingly Powerful Flat-File CMS powered by PHP, Markdown, Twig, and Symfony

Home Page:https://getgrav.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[add-resource] New Plugin/Theme: Console Log

liam1241 opened this issue · comments

I would like to add my new plugin/theme to the Grav Repository.
Here are the project details: liam1241/grav-plugin-console-log

I believe I have included everything, however this is my first time publishing a Grav plugin, so I apologize if anything is missing. This is a rather niche plugin, it adds a Twig function that allows you to print a message to the browser's console. I wrote it for my own personal use and decided to share it.

Thank you!

I've taken the liberty to run a brief review on the plugin...

README.md

  • I'm afraid I fail to see the use/fun to write Easter Eggs to the console.
  • What's the use-case of this plugin? Both for the end-user and for the developer?
  • Does it solve a problem other Grav users might face? When would this plugin be really handy?
    • If I would want to dump something from within a page to the console, I would just add {{ dump('something') }} in the page and watch the output in Clockwork. I wouldn't install a plugin for that.

consolelog.yaml

  • What's the use of variable 'active'?

blueprints.yaml

  • Users of the plugin might not be shell oriented. You might want to add a proper form for the plugin so users can switch the plugin on/off in Admin.
  • Are there any dependencies like a min version of Grav?

consolelog.php

  • According to my IDE and the docs, FILTER_SANITIZE_STRING has been deprecated as of PHP 8.1 and htmlspecialchars should be used instead.
  • Code might be simplified using:
    public function onTwigInitialized(Event $e)
    {
      $this->grav['twig']->twig()->addFunction(
        new \Twig_SimpleFunction('conlog', [$this, 'conlogFunction'])
      );
    }
    
    public function conlogFunction(string $input)
    {
      $encoded = htmlspecialchars($input);
      echo "<script type='text/JavaScript'>console.log('$encoded');</script>";
    }
    

@pamtbaau Thank you so much for the detailed feedback! I really appreciate you taking the time to look over everything.

README.md
Regarding the use-case, it doesn't really solve a problem or have a practical use. On my personal website I'm working on, I like leaving notes in the console for fun. No one really sees it and there is no reason for it other than that I like to do it. I had already written the plugin for myself, so I decided it wouldn't hurt to share it in the off chance someone else finds it useful. I understand not wanting to pollute the GPM repository with this kinda stuff, so I can withdraw/close this issue if you think that would be best.

consolelog.yaml
I was following the tutorial here and it said to include the active variable. It says, "All plugins also have the active option. If this is false in the site-wide configuration, each page will need to activate your plugin." If that option isn't needed I can remove it.

blueprints.yaml
That's weird, I thought there was a switch to enable/disable in admin. I have a development VM running Grav v1.7.34 and Admin v1.10.34 and I see a toggle that lets me disable the plugin via admin. Regarding dependencies, it doesn't rely on anything external to the best of my knowledge as it's just basic PHP. I also decided to set the minimum version to Grav v1.7.0 as it simplifies things. I tested and it does work on some versions of v1.6.x, but not all versions of v1.6.x function properly in my standard VM. I also know changes were made in regards to autoload in v1.7.x, so its probably best to cap it at v1.7.0.

consolelog.php
Good catch! I'm new to PHP, so I totally missed that. I implemented the changes you suggested and made sure to credit you. I had to remove "Event $e" from onTwigInitialized to get the plugin to function properly, other than that it worked perfectly.

Thanks again!

Regarding the use-case, it doesn't really solve a problem or have a practical use.

In that case I would not add this plugin to GPM. In due time, it will be yet another outdated/incompatible, unmaintained and abandoned plugin causing issues to community users.

"All plugins also have the active option. If this is false in the site-wide configuration, each page will need to activate your plugin."

You're right, it is mentioned in the docs. I'm afraid it has been added in a PR created by a user who says "Please correct if my understanding is wrong. This was a point of confusion for me".

The statement "All plugins also have the active option" is incorrect. Yes, some plugins allow the activation of a plugin on a page by page basis. Some use variable active which can be overridden in the page's frontmatter and others use array variable routes with a list of pages/routes on which the plugin should be active. In both cases the code should check whether the plugin should run or not.

That's weird, I thought there was a switch to enable/disable in admin.

Yes, there is toggle in the list of plugins, but usually (not required), the plugin provides a toggle on the config page of the plugin.

and made sure to credit you

That's nice, but I would appreciate it if you didn't credit me...

I had to remove "Event $e" from onTwigInitialized to get the plugin to function properly

That's probably because you used an incorrect Event class.

I'm new to PHP

I always wonder why people new to something want to share their first fruits for others to use...

Some more notes:

  • If you create a plugin, please use $ bin/plugin devtools new-plugin as shown in the tutorial you are referring to. This will setup a plugin infrastructure that complies with Grav's standards/preferences.
    • It will setup composer correctly
    • It will create a correct php skeleton
      • Which uses autoload instead of require as you did.
      • With correct enabling of events. You are now running your plugin for each and every page request.
    • It creates a proper blueprints.yaml with requirements and form.
    • etc.

Final note:

  • I'm afraid this plugin does not provide an added value to the community.

@pamtbaau I appreciate you taking the time to provide additional feedback. I did remove credit where I could as I was unaware you didn't want credit. I'll start off by saying I don't care if my plugin is added to the GPM or not, I simply thought I'd share it since I'm going to be using it personally. I'm going to keep working on my plugin and continue to improve it. I have decided to leave it up to the Grav maintainers to decide if this plugin should be added to the GPM. While the use-case is niche, it does have some value. I do feel some of your feedback is unreasonably harsh given the fact that I followed official Grav documentation in the creation of my plugin (specifically the first example in "Plugin Recipes"). You make the assumption that I won't maintain this plugin, which you honestly have no backing for. I do intend to maintain it, as I made it for myself to use. I also feel the need to say that this isn't my "first fruit" using PHP. I'm simply new to PHP and didn't realize that the sanitization method I was using is deprecated. Honestly, a lot of this seems to stem from inconsistent documentation. The official example I followed had me manually create the files and set everything up like I did, so I assumed it was ok. As I said before I appreciate the feedback, I just wanted to let you know how it came off. Responses like yours can discourage new people from joining communities and contributing to projects. I totally get where you are coming from, I'm just trying to let you know how it came off. Anyways, I hope you have a nice rest of your day.

fwiw even though the plugin is niche i think there is still value for it to be added to the gpm. i don’t really want to get into the process of evaluating plugins for potential value or usefulness. if one person found it useful enough to create, others may also find value in it. that’s good enough reason for me.

also while the reviewing of plugins is awesome and often helps people improve their code, it needs to be constructive criticism and not personal views or opinions to ensure that development is encouraged and not stifled.

we aren an open and inclusive community and the last thing we want is to turn people way.

Added