Open nodiscc opened 9 years ago
@xrat I hack date+time from time to time. Firebug lets me edit the hidden field lf_linkdate
content from the edit_link
page. So I create a duplicate entry with the desired new timestamp and finally manually delete the original one.
Should PHP notices such as "Undefined index: HTTP_REFERER in .../index.php on line 1026" be reported?
Yes. We should check that the key exists.
OK, reported in #723
I'm going to delete https://github.com/shaarli/templates if that's OK with everyone.
Is there a way to mass rename / delete tags? I can't find it. I'm discovering Shaarli and it's been great so far!
Sorry I found it^^
I moved a bunch of issues to 0.9.1. There is still a lot of issue in 0.9.0, but most are related to the new theme or the API.
It doesn't really affect us, but since we use the service, it's worth mentioning Gitter have been acquired by GitLab Inc and will become open source. Blog post.
Hi,
I very recently joined the shaarli universe!
Today, while managing tags, I stubled upon an odd behaviour. When I tried to delete a tag named - (dash), shaarli instead removed the first tag on each links stored..
I searched through the wiki to see if that's a feature but could not find anything.
Is this intended ? If not, I'll create an issue to report this bug in more details.
PS : I'm looking forward to contribute as much as I can !
Hi @Esak8 !
This behaviour is not intended, feel free to fill a bug report using the Github issue tracker ;-)
Hi @virtualtam ,
Ok, that's what I'll do.
Thanks!
Hey.
Just wanted to drop a line to say that we've added Shaarli icons to ForkAwesome. Following this nice request: https://github.com/ForkAwesome/Fork-Awesome/issues/28
We've added 2 versions:
Hope you like it.
That's great! Thanks. Also, that's a good project. I'm a bit worried with FontAwesome project orientation since their 5.0 release.
@ArthurHoaro Thanks. Well, they certainly took a new direction. And wish them good luck. It's the PR freeze for more than a year and having PR refused that really drove me nuts. Also, with this fork, we plan to remove some of the clutter. Make it easier to contribute and open to a lot more icons promoting open source tools.
I see that Shaarli uses FontAwesome in its template. If you miss any icons, let us know. We could work on integrating them in the Fork Awesome project.
I may consider to switch at some point a use your icon instead of the quick & dirty star image I made for the new template. :)
Neat, thanks @xuv and @opitux!
FYI, I have received this email from Readthedocs (dev@readthedocs.org) which hosts Shaarli's online documentation:
Advertising update for mkdocs
Hey there,
As you might already know, Read the Docs has been using advertising to help build a sustainable business around open source documentation hosting. We call it Ethical Advertising, because we don't allow any thind party scripts, and all the ads are all served from our servers. These ads have only been displayed on certain Sphinx themes. We are now changing this, and we plan to start displaying ads on MkDocs when using the Read the Docs theme.
You're getting this email because you own a project that uses MkDocs, and will soon start getting ads on it. We wanted to be proactive about this change, and alert you. From a roll out perspective, this will be similar to how we have expanded advertising on Sphinx as outlined here: https://blog.readthedocs.com/ads-on-other-themes/
Read the Docs is provided for free to all open source projects. Running this service requires multiple people to wear pagers, respond to GitHub issues, and other work that is mostly invisible and thankless. We are using the money generated to help support our community and make the service sustainable.
You can read more about our advertising (including opting out) here: http://docs.readthedocs.io/en/latest/ethical-advertising.html. We are doing our best to respect our users, while making our service sustainable, and we care that you believe and support the work that we do. Please let us know if you have any questions or concerns, and we will do our best to address them.
Cheers, The Read the Docs Team
I see no problem in supporting readthedocs' free service through reasonable advertising. More advertising program docs are available at https://readthedocs.org/sustainability/advertising/ https://docs.readthedocs.io/en/latest/advertising-details.html https://docs.readthedocs.io/en/latest/ethical-advertising.html
Similar issue in another project https://github.com/jupyter/jupyter/issues/119 which shows an example of such ads. I recommend uBlock origin for those who want to block unwanted ads. If you think otherwise, there is a setting to turn this off in readthedocs project settings.
I'm not a big fan of the idea of having ads in our docs, but this seems reasonable, and we are indeed using their service for free. Just to be sure, this only affect the docs on RTD, not the locally generated ones?
no pun intended, but 3rd party hosting seems contradictory to the idea of self-hosting. And using an add-funded service (with IMHO zero benefit for a project that strives for minimalism) with an ad-blocker doesn't sound like fair game, either.
no pun intended, but 3rd party hosting seems contradictory to the idea of self-hosting. And using an add-funded service (with IMHO zero benefit for a project that strives for minimalism) with an ad- blocker doesn't sound like fair game, either.
I'm not sure I follow this line of reasoning.
Shaarli uses a third party to host its source, issues, etc. for free: GitHub. GitHub's business model is to be free for OSS projects, and pay for it by charging closed source projects.
Shaarli uses a third party to host its documentation for free: ReadTheDocs. ReadTheDocs' business model is to be free for OSS projects, and pay for it through ads.
What is the problem with it? Seems fair to me.
this only affect the docs on RTD, not the locally generated ones?
Yes.
Shaarli uses a third party to host its source, issues, etc. for free: GitHub Shaarli uses a third party to host its documentation for free: ReadTheDocs What is the problem with it? Seems fair to me.
My reasoning as well. The ads are not intrusive and seem to be privacy-respecting (no requests outside readthedocs domains, unlike Github which uses Google Analytics).
3rd party hosting seems contradictory to the idea of self-hosting
Yet we use Github. If it is not satisfying, there are multiple ways in which we could improve Shaarli's hosting, in order of cost/complexity/required time:
Don't get me wrong I think it is good to have a backup plan and am setting up a private Gitlab mirror of Shaarli out of personal interest, but GH/RTD have served us well and I don't think it would be wise to introduce more maintenance tasks/costs at the moment (unless these services do something unreasonable).
IMHO zero benefit for a project that strives for minimalism
The point is that we don't have to maintain the service handling the docs (but I see your point re. independence). This sounds pretty KISS to me.
Hey,
As an open-source project, Shaarli relies on several external services for the majority of development and hosting tasks:
Additionally, @ArthurHoaro manages the shaarli.org domain and hosts the demo.shaarli.org instance.
Using external / free-for-open-source services allows us to focus our efforts on development, welcome new users and provide them with support.
I am grateful for the software and services provided by the ReadTheDocs and WriteTheDocs communities, and will happily help support their services by allowing non-intrusive ads.
Now don't get me wrong: I'm all for self-hosting personal and community resources, but this doesn't come for free and raises a number of thorny issues such as:
lol, I see you got me.
Hello everyone,
Do maintainers have any ideas (pros/cons) about publishing shaarli on packagist?
This would allow automatic building of archive versions, and provide another way to install stable branch using something like composer composer create-project shaarli/Shaarli [folder] [version]
.
Any thoughts?
cheers!
Hi,
I've always used packagist to publish libraries which can be used as a dependency and never a whole tool. I didn't know this command (even though I might have used it it to bootstrap Symfony). From the docs:
create-project This is the equivalent of doing a git clone/svn checkout followed by a composer install of the vendors.
I don't mind adding Shaarli to Packagist, but with this command, it would still require to install/build front end dependencies using yarn/npm to work properly.
Also, you can open a separate issue if you're interested in this.
This would mostly be interesting if Shaarli could be used as a library to build other PHP applications, in which case it would make more sense to split the current codebase into reusable, vendored libraries, that would be published on Packagist.
Also note that Shaarli has a front-end part that is built using NodeJS/NPM, and is out of Packagist's scope.
Hello,
Okay, no problem. No need for a specific issue, I was asking only to know this would have been of any interest to the project.
As I view packagist, it is not only for library, the advantage of using create-project
command from composer is to rely only this tool to bootstrap php part, and not rely necessarily on a specific git/svn/other tool.
Even if there is a frontend part, using NodeJS/NPM, this does not seem to be a blocker for packagist, I'm not sure this is really relevant to packagist, but peoples seem to have created composer package for this kind of tool : https://packagist.org/?query=npm
Thanks for your replies. :)
hello everybody,
I just opened this issue about shaarli apparently working OK... using a datastore.php file that appears corrupted when read from php on the command line: https://github.com/shaarli/Shaarli/issues/1222
thanks in advance for your comments and help
Hi, there is a medium refactoring I'd like to suggest: Have you ever thought about re-packaging the daily view and the tag cloud as plugins? I do not consider these essential. This would allow people to just turn it off it they don't need them.
@heimpogo I'm not sure current plugin possibilities would allow to create this kind of pages 🤔
@heimpogo why would you do that!? the original shaarli works like that..
@kalvn Ok, I didn't check this yet. Thanks for pointing this out. @nicolasdanelon Shaarli allows very different ways of using it. And some might consider a tag cloud a Web 2.0 relict they don't really need.
@heimpogo The tag cloud/daily views have no impact on the rest of the application and you can hide those links using custom css, and block access to the pages using .htaccess
or other server configuration if you're really into that... But given the fact that they work as expected, have no other implcations, and maintenance time is already thin as is, it's unlikely they will be ported as plugins.
Github has informed us maintainers that there is a vulnerability in node tar which is included as a dev javascript dependency in Shaarli (CVE-2018-20834).
Vulnerable version of tar is included by node-sass, and fixing this issue is requires https://github.com/sass/node-sass/issues/2625 to be fixed.
I'm not sure what the security implications are, but as it is only a dev dependency, I recommend as a good practice that you remove node_modules
folder in production.
You are not impacted if you used the release archive during the install or the Docker image.
Re: @heimpogo :
Have you ever thought about re-packaging the daily view and the tag cloud as plugins? I do not consider these essential. This would allow people to just turn it off it they don't need them.
I'd like to +0.5 that. :) Personally I like the Tag-cloud feature/look, but don't really use the Daily-page or RSS/Atom feeds.
@heimpogo The tag cloud/daily views have no impact on the rest of the application and you can hide those links using custom css, and block access to the pages using
.htaccess
or other server configuration if you're really into that... But given the fact that they work as expected, have no other implcations, and maintenance time is already thin as is, it's unlikely they will be ported as plugins.
I agree it would be not be worth the effort to completely port them to plugins (as the current plugin-system would need to be changed as well).
But would it be an idea to add some more configuration-options/flags? Like the current setting for Thumbnails? So for example:
(Or change them around by making them "Disable X").
Then in the templates/routing simple switches could be added, like for example in the menu:
{if="$feature_tag_cloud_enabled"}<a href="?do=tagcloud">Tags</a>{/if}
I'd also like these configuration-options for my own theme, so I could make it usable for other people that would like to use the Daily-view AND my theme. ;)
Would you mind moving this discussion to its own issue?
On Thu, Jun 13, 2019, at 10:42, Elwin Schmitz wrote:
Re: @heimpogo https://github.com/heimpogo :
Have you ever thought about re-packaging the daily view and the tag cloud as plugins? I do not consider these essential. This would allow people to just turn it off it they don't need them.
I'd like to +0.5 that. :) Personally I like the Tag-cloud feature/look, but don't really use the Daily-page or RSS/Atom feeds.
@heimpogo https://github.com/heimpogo The tag cloud/daily views have no impact on the rest of the application and you can hide those links using custom css, and block access to the pages using
.htaccess
or other server configuration if you're really into that... But given the fact that they work as expected, have no other implcations, and maintenance time is already thin as is, it's unlikely they will be ported as plugins.I agree it would be not be worth the effort to completely port them to plugins (as the current plugin-system would need to be changed as well).
But would it be an idea to add some more configuration-options/flags? Like the current setting for Thumbnails? So for example:
- Enable RSS/Atom feeds
- Enable Tag-cloud
- Enable Daily-view (Or change them around by making them "Disable X").
Then in the templates/routing simple switches could be added, like for example in the menu:
{if="$feature_tag_cloud_enabled"}Tags{/if} I'd also like these configuration-options for my own theme, so I could make it usable for other people that would like to use the Daily-view AND my theme. ;)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/shaarli/Shaarli/issues/308?email_source=notifications&email_token=AAO7FNUC34H4UIL3YY7ONJLP2IB6TA5CNFSM4BMQTAI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXS7EKQ#issuecomment-501609002, or mute the thread https://github.com/notifications/unsubscribe-auth/AAO7FNTX4HX7U5OR2EN2OZLP2IB6TANCNFSM4BMQTAIQ.
A feature request for the markdown plugin: It would be wonderful to have a one-click copy button at the top of code blocks. This would make using Shaarli as a code snippet collection much more comfortable.
@heimpogo at the top of each code block inside the shaare? That would be difficult since markdown generation is handled by parsedown, which does a single thing, consuming markdown and returning the corresponding HTML. You would have to open an issue there.
A button to copy the whole shaare description would be doable, but I think it would considerably affect performance (we would have to load the rendered and raw descriptions into the page).
Please correct me if I'm wrong.
This shouldn't be done on server side, as you said it would be very difficult.
One easy solution would be to add this Copy-to-Clipboard plugin to my code coloration plugin, which rely on Prism.JS. Note that Prism is not really a lightweight library, as it supports many languages.
Hi all! I built a Shaarli version with Laravel: https://github.com/MarceauKa/laravel-shaarli At first it was just a 2 hours challenge to train a friend with Laravel but it's now a real package.
That's interesting, thank you for sharing!
Hey @MarceauKa, and thanks for sharing!
I would strongly advise you to rename your application and source repository though, as naming it after Shaarli is misleading to users:
Thanks for your understanding :)
This is also what I strongly recommended here https://github.com/awesome-selfhosted/awesome-selfhosted/pull/1864. It is misleading.
@virtualtam @nodiscc Yep, it was planned but it needs time to rename an application. It's done, Laravel Shaarli is now Shaark
the future is now
Moved from https://github.com/shaarli/Shaarli/issues/1446:
I'm proud to announce a new version of the iOS share extension. 🍏 📱
For those who want to give it a try, there's free copies at https://github.com/mro/ShaarliOS/issues/40
Pinging #308 and #323
Happy shaaring! 🎉
Cute:
There have been quite a few new features for v0.12.1, which I plan to release in one or two weeks. I have pushed all remaining issues (with milestone v0.12.1) tagged as feature for v0.12.2.
Followup to https://github.com/shaarli/Shaarli/issues/44