General discussion - Githubissues

nodiscc commented 9 years ago

Followup to https://github.com/shaarli/Shaarli/issues/44

mro commented 7 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.

xrat commented 7 years ago

Should PHP notices such as "Undefined index: HTTP_REFERER in .../index.php on line 1026" be reported?

ArthurHoaro commented 7 years ago

Yes. We should check that the key exists.

xrat commented 7 years ago

OK, reported in #723

ArthurHoaro commented 7 years ago

I'm going to delete https://github.com/shaarli/templates if that's OK with everyone.

Laynee commented 7 years ago

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!

Laynee commented 7 years ago

Sorry I found it^^

ArthurHoaro commented 7 years ago

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.

ArthurHoaro commented 7 years ago

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.

ghost commented 7 years ago

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 !

virtualtam commented 7 years ago

Hi @Esak8 !

This behaviour is not intended, feel free to fill a bug report using the Github issue tracker ;-)

ghost commented 7 years ago

Hi @virtualtam ,

Ok, that's what I'll do.

Thanks!

nodiscc commented 6 years ago

star-counter-overflow

xuv commented 6 years ago

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.

ArthurHoaro commented 6 years ago

That's great! Thanks. Also, that's a good project. I'm a bit worried with FontAwesome project orientation since their 5.0 release.

xuv commented 6 years ago

@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.

ArthurHoaro commented 6 years ago

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. :)

virtualtam commented 6 years ago

Neat, thanks @xuv and @opitux!

nodiscc commented 6 years ago

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.

ArthurHoaro commented 6 years ago

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?

mro commented 6 years ago

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.

marcoskirsch commented 6 years ago

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.

nodiscc commented 6 years ago

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:

[x] Leave the docs as-is
[ ] Opt-out of Readthedocs ads program
[ ] Move the mkdocs documentation to Github Pages
[ ] Move the mkdocs documentation to a host under our control
[ ] Move the whole project to a host under our control (Gitlab instance?)

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.

virtualtam commented 6 years ago

Hey,

As an open-source project, Shaarli relies on several external services for the majority of development and hosting tasks:

Git repositories, issue trackers and release archives are hosted on GitHub
tests are run on Travis CI
PHP libraries are hosted on Packagist
Docker images are hosted on Docker Hub
static documentation sites are generated and hosted on ReadTheDocs

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:

who manages the services?
who pays for the services / servers / hosting / domain names?
who is accountable for the availability and reliability of the services?
what happens when the services / servers / network are down?
what happens if data gets corrupted or lost?
will there be any free time left for development and support?
do we actually want, as individuals contributing to open source software, for free, on our free time, to spend time and energy on that?

mro commented 6 years ago

lol, I see you got me.

pips- commented 6 years ago

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!

ArthurHoaro commented 6 years ago

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.

virtualtam commented 6 years ago

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.

pips- commented 6 years ago

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. :)

mfioretti commented 5 years ago

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

heimpogo commented 5 years ago

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.

kalvn commented 5 years ago

@heimpogo I'm not sure current plugin possibilities would allow to create this kind of pages 🤔

nicolasdanelon commented 5 years ago

@heimpogo why would you do that!? the original shaarli works like that..

heimpogo commented 5 years ago

@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.

nodiscc commented 5 years ago

@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.

ArthurHoaro commented 5 years ago

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.

elwinschmitz commented 5 years ago

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:

[ ] Enable RSS/Atom feeds
[x] 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"}<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. ;)

ArthurHoaro commented 5 years ago

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.

heimpogo commented 5 years ago

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.

nodiscc commented 5 years ago

@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.

ArthurHoaro commented 5 years ago

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.

MarceauKa commented 4 years ago

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.

ArthurHoaro commented 4 years ago

That's interesting, thank you for sharing!

virtualtam commented 4 years ago

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:

the project is not affiliated with the Shaarli community;
there is no shared codebase with the Shaarli application;
the project is not on-par with Shaarli feature-wise (e.g. Netscape import/export, Docker images, documentation);
the underlying technologies (save the choice of the PHP language) are different.

Thanks for your understanding :)

nodiscc commented 4 years ago

This is also what I strongly recommended here https://github.com/awesome-selfhosted/awesome-selfhosted/pull/1864. It is misleading.

MarceauKa commented 4 years ago

@virtualtam @nodiscc Yep, it was planned but it needs time to rename an application. It's done, Laravel Shaarli is now Shaark

nodiscc commented 4 years ago

milestone

the future is now

nodiscc commented 4 years ago

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! 🎉

ArthurHoaro commented 3 years ago

Cute:

ArthurHoaro commented 3 years ago

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.

shaarli / Shaarli

General discussion #308