-
-
Notifications
You must be signed in to change notification settings - Fork 614
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
simple comment system #700
Comments
This comment was marked as outdated.
This comment was marked as outdated.
Hmm... not answering your question, but you know that there's already a comment plug-in? |
Yes, that's a good point. Having a lot of pages has a noticeable negative performance impact on Pico, so keeping the total number of pages down is a good thing. Please note that even though |
@dkyme thanks for the hint. Everything can be made to work, but I want to learn the correct (Pico) way :) So, as in many other projects, like the same pico-comments plugin, login plugin, etc., is it reasonable to move out of the content folder and create your own data structure? On paper, I don't like this solution, for the sake of cleanliness, ease of backup, and a touch of my own personal closed-mindedness. Perhaps for this type of application, it's better to use a different extension, like .yaml? They are YAML data, but they don't need to be manipulated like a regular .md page, given that they extend it... but they can remain in the In all functions that require knowing the ID (like this plugin, but also, for example, the one on statistics), is it correct to use @PhrozenByte Naturally, thanks as always for your availability; maybe these are obvious questions. |
It has both advantages and disadvantages. The biggest advantage is that such extra structure doesn't cause Pico to prematurely load the contents. The biggest disadvantage is that you have to implement the page parsing logic yourself (even though Pico provides methods for that, so that it's no big deal in the end). There's no "true" answer. However, if you choose to create your own structure, I'd always recommend moving such data into its own directory, i.e. not relying on just different file extensions.
|
Why avoid something like this?
At this point, the holy grail for performance is to use YAML inside the MD file (in theory, we don't have many concurrent write operations).
If I request the |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! 👍 |
I would implement a simple comment system. The concept is to add
_comment-datenumber.md
files inside a directory namedpage.id
.So, for example, if I have a page file "my-post.md", the directory structure would be:
I think some plugin editor can edit these files, and I can use Pico parser for read/write tasks. My plugin reads all
_comment-*.md
files and returns an array for Twig.The downside is the number of files. I think a blog can easily accumulate various comments for each post, which could be an issue for Pico's performance (in long term).
So I think
$skipPage
help here:Are there any blunders to correct?
The text was updated successfully, but these errors were encountered: