Just for testing, you could place the app into recovery mode then create those files/folders and then run the start.sh which for Wallabag is at /app/code/start.sh

@nebulon Thanks a lot for the quick fix – just updated the app and everything works perfectly now. Really appreciate the fast response and great support!

The second command seems promising.. It looks like it is writing to a hardcoded file /app/code/wallabag/wallabag-export.json (since it's a very old version maybe it didn't write to stdout) . Put the app in recovery mode - https://docs.cloudron.io/apps/#recovery-mode . this makes the filesystem writable In one web terminal, just run /app/pkg/start.sh . this runs the app and creates paths In another web terminal, try running the second command and check if that /app/code/wallabag/wallabag-export.json was created ... if it was you Download it using the Download button in web terminal ? or copy it to /app/data and use file manager .

I know this is an old thread, but figured I would leave another tip in case someone has the same issue as I. I was having difficulty activating on Chrome browser addon. I was not getting a token. It kept saying that the token was expired. I was able to access the api by loading the options page in inspect mode through the chrome browser. As described here: https://github.com/wallabag/wallabagger/issues/406

@jdaviescoates Really interesting, thanks for sharing. I'll have a read

@MorganGeek Totally unrelated to Cloudron but related to Linux servers hosting PHP applications, I ran into an issue where a Laravel application failed because of a lack of MySQL resources. I researching the specific message, many layers deep was a comment about an insufficient swap file. The server had plenty of RAM available, so it seemed unlikely. But my swap file turned out to be small and almost full (not even sure why it was needed at all). I increased the swap file and miraculously my problem disappeared. Application is now running. I would check the swap file and its utilization. I don't know why this seemed to matter, but I would up doing this across all my Linux servers. Many had 512MB swap files and one had no swap file at all - all from legacy images at various cloud providers. Perhaps this is worth checking and if not as large as your RAM, increasing the swap file size.

@robi Yes Robi, they use real device.

@girish Thank's Girish... I think this is a big limitation of Wallabag: cannot export highlights to other platforms

Then we can rule this out and it is better reported upstream. Maybe you can create an issue at https://github.com/wallabag/wallabag/issues and if so, please link it here then for context.

@nebulon Not that I could tell, other than there were no error messages in the logs when I tried importing via the app. I could see it was an image problem because of the cli progress. Oh, and I had o boost both my Wallabag app AND its Redis to 5 or 6GB of ram each to manage 1200 articles. Anything less than 5GB didn't seem to work. Afterwards I've lowered both to under 1GB and it's all good.

@nebulon How do I get this update to be visible? My current version is 2.4.1, but the app store lists that version is 2.5.2, but that doesn't show up when I press Check for Updates. NM. I found the notice from A YEAR AGO! https://forum.cloudron.io/post/23720

@ctrl Oh.. that wallabag you are using is very old, like 3 years ago and it's also the abandoned package. See https://forum.cloudron.io/topic/1691/wallabag-is-back If you go to Services -> redis -> restart the redis there. Then try to update the app to atleast package 1.5.0 and let us know how that goes.

So I guess we just wait for a wallabag release then. Generally allowing things to be modified in vendor/ folders is not ideal, as mostly those contain code.

@hillside502 thanks, corrected!

@jk Thanks for the write up! Indeed, the migration is a bit rough because Wallabag had made a 2.3.8 release back in May 2019. Then a 2.4 release came up after 1.5 years but this wasn't "upgrading" cleanly and had many migration issues. In fact, there are still migration issues pending upstream like 5197, 4820, 4979, 4821. We thus decided it's best to start "afresh" because it doesn't seem like the migration issues will be fixed any time soon.

@nebulon FWIW I was able to spin up an instance of the new version and migrate everything over without hiccup today. Fingers crossed that we won't need such a migration for future updates...

I've made another attempt to publish the new version with a fixed start script. Lets see if this mitigates the migration issue.

So we have to wait for the next patch release to fix a few regressions it seems: https://github.com/wallabag/wallabag/milestone/65