Possibility to run script everytime an article is added
Hi everybody,
I really like wallabag however only in combination with my kindle. In order to implement a solution where new articles are pushed to my kindle I am trying to call a calibre recipe everytime a new article is added.
Is there any possibility to hook a script which is called everytime a new article is added to wallabag ?
Thanks in advance
Andy
It could work if you rely on your wallabag RSS feeds and check them regularly. I also advise you to look at poche-2-calibre. However, this will create a new file (containing all your articles) each time there is a new article in your wallabag. Of course, all of this will be much more easier to do when wallabag's v2 will be coming, with a complete API.
Thanks for your reply, but poche-2-calibre does no longer work (see this issue https://github.com/FaustXVI/poche-to-calibre/issues/9) with wallabag. Moreover, after spending hours looking for a proper solution, I would like to give you my thoughts about the implementation of this functionality:
I really think the implementation of a push to Kindle functionality should be considered as early as possible in the development process of wallabag because of two key reasons. First, there is an enormous demand for people who want to read long articles on their kindle, me included, (if you don't believe it, look at the Instapaper blog, it is one of most requested features for Instapaper). Secondly, it seems to be really complicated if not impossible to add such functionality post-hoc. Moreover, every external soultion will never fully reach a push mechanism, but always have a certain delay. In contrast, it is quite easy using kindlegen to combile a mobi form an html site (i.e. the one which is displayed in wallabag).
What do you think about that feature?
I think we all totally agree such a feature would be great. Moreover, it shouldn't be too hard to develop, since there's a good number of pieces of software doing this job (at least I've seen some on Github). But the real question is : do we do it now ? Our dev status is : we want a stable version 1.x with all base functionalities. In the same time, we (well, two of us) work on a v2 branch, which is based on a framework. This version will include two very important features : an API and the ability to create (and use) plugins. Therefore it may be better to start thinking to have a "send to kindle" plugin in v2, than beginning to hardcode this in current versions.
Also, there's the fact none of us seem to possess a kindle to make tests, though it's not problem number one.
In conclusion, I would say, of course, we need this functionality, but there's some things to do first, and then it should be easier to build it.
Note : I speak in my own name, of course.
Thanks for your reply, I fully understand that you keep your priorities and judging from the previous releases that strategy worked out pretty well. I really like wallabag and think to write the necessary routines myself. I looked at the code and from what I saw, it seems to me that a trigger in the database which executed an external script which in turn compiles the ebook and sends it away seems to be the best way to implement the functionality. What do you think? Of course I will publish my word on GitHub. Would you prefer to do it in another way? Is there already a first proposal of what API for plugins will look like?
Thanks
Andy
I'm not sure to understand what you mean by "a trigger in the database". A system using v1 as I would see it would be just an "always send new articles" option in config file, then just after the article is saved in the database (and this option true), call a function (with content as parameters) somewhere else to produce the export. Also, a button on each article which permits to call this function on a specific article (when the option is not set). Though I've seen some code on Github which can handle the "send to kindle" feature, I'm not sure it's written in php, but it's your part now. ;)
And no, sadly there's no specifications for v2's plugins. Maybe it will be something like #414, maybe not. In fact, there hasn't been any work on v2 since a while, I guess @nicosomb wants to have version 1.x really stable.
(Updated comment, first sentence meant nothing)
Scheduled for v2. API opens plenty of possibilities. :)
@j0k3r Will our custom events help such a thing ?
Yes and no. We should more things globally. Check that conference for example: https://www.youtube.com/watch?v=U8vBoBmN68E
Sumup (from https://github.com/wallabag/wallabag/pull/2982):
- add a table called
webhookwith uuid (as PK), name, url, boolean to enable/disable and user_id - fire each url on saving an article with the article as json in payload (should better be a POST request)
- optional: log each request with http response and sent payload to be able to re-play them (like Github webhook)
- optional: add webhooks uuid in header request
- optional: signature header based on a secret?
https://developer.github.com/webhooks/ is a good idea.
Interesting read https://brandur.org/webhooks
I started to work on this feature.
I played with IFTTT webhooks. It works well.
But, if there is an error on IFTTT side, I can't have the information and the IFTTT response is "ok, all was fine, the applet was triggered successfully". 😓
Thanks for those who put work into this already! @j0k3r @nicosomb
+1 for a webhook feature in wallabag. My use is to have wallabag article origin links automatically sent to linkding and possibly article docs to paperless-ngx via webhook. I may have a self-hosted n8n instance receive the webhook to customize the integration.
workarounds
- DB row trigger: Have a webhook triggered by changes to the database via nocodb (or similar). https://docs.nocodb.com/automation/webhook/webhook-overview
- RSS feed trigger: Interval checking the wallabag RSS feed with n8n (or similar). https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.rssfeedreadtrigger
webhooks.fyi
webhooks.fyi is a great resource for all things webhook.
Webhooks.fyi is a one-stop shop for information on how to build, consume, secure, maintain, and overall function with webhooks. While we've started with a heavy security focus with an eye towards future maintainability, we want to expand this into a clearing house for the best and worst practices you will see in the wild.