Closed jbrown123 closed 4 months ago
wow! thanks for reporting. this bug doesn't apply to the set-comment made from the list
There's a way to set comments elsewhere? Other than editing the descript.ion file, where can they be set?
Commenting from a phone is painful
If you can upload, you should also see the "comment" command when you open the file menu, from the files list
Ah, yes. I see that. And I can confirm that it works mostly correctly.
It doesn't support a leading return in the comment (it gets stripped). You can manually edit the descript.ion file and add a leading return and that does work correctly. (I prefer the v2 style comments where they appear below the item rather than starting to the right of it.)
Any chance we can get rid of the quotes around the comment?
Maybe make both of these options (comments beside / comments below and with or without quotes)?
you can customize the style of the comments of course, and make all the changes you said. it's CSS, so it heavilty depends on your knowledge on the topic. once you devise all the changes that you need, you can enter your new style rules like described at https://github.com/rejetto/hfs/wiki/Customization
to know what rules you need you should study how the page is done, as there's no documentation about it yet. People making web pages know how to do that even without documentation: you right click on the comment, click inspect. You'll see that you are on a div with class entry-comment. This "studying" tool is nothing specific to hfs, but all web pages, so I expect some guide/documentation to exist somewhere.
Maybe make both of these options (comments beside / comments below and with or without quotes)?
the possible styles are virtually infinite, the option is not the right way to go. Someone can make a simple plugin/theme that just change the style of the comments, and you can install it.
for example, this can be a good start
.entry-comment { display: block }
.entry-comment::before, .entry-comment::after { display: none }
this is was fixed in 0.53.0-rc18
BEFORE
Not using one, also not applicable
To Reproduce
Steps to reproduce the behavior: Upload a file via HFS to an upload enabled folder Click the comment button and put in more than one word separated by spaces Upload the file
Describe the bug
The upload process injects for each space or other non-alphanumeric character
Expected behavior
I expected the comment to be recorded as sent. At the very least, I expect the output to interpret the HTML escaped characters corretly.
Screenshots
Environment (please complete the following information):
Additional context
None