yes, it implies to change code on wallabag, no there is no api available to do that
a lot of things are in the backlog, there's low rate of contributions unfortunately
@mg64ve I said that there is an API on wallabag but there is no option nor endpoint to upload actuel content
@di72nn: well, indeed, I forgot that, however this endpoint will save the content as-is, bypassing graby extraction
@kdecherf:matrix.org yeah, the applicability depends on use cases 🤷♂️
I successfully migrated a Wallabag 2.3.8 MySQL database to another Wallabag 2.3.8 PostgreSQL instance using pgloader. All users and their articles can be accessed from the new PostgreSQL-backed Wallabag instance. It's also possible to edit existing article titles, and to delete articles. But, attempting to add new articles leads to "error 500". Ditto if I try to create tags. The specific error message is
Undefined table: 7 ERROR: relation "entry_id_seq" does not exist LINE 1: SELECT NEXTVAL('"entry_id_seq"') ^. Am I perhaps missing some obvious database-repair command? Does anyone have any experience with mysql -> pgsql migration for Wallabag?
Does wallabag support client-side javascript rendering (vuejs) to at least some extent?
kartoffelsalat: no, there is no javascript rendering done when wallabag fetches articles, and js tags are removed from the output content
(if you're talking about fetching articles)
yes, I'm talking about fetching articles. thanks! (although I wanted to hear that there is an option for that, nevermind).
btw you could have a tool that fetch a page using a headless browser and send the complete html to wallabag through the api
I'm trying to authenticate with a website that requires two additional fields. The following naïve solutions disregards the dependence of the values:
login_extra_fields: login_ticket=@=xpath('//input[@name="login_ticket"]/@value', request_html('https://id.sueddeutsche.de/login'))
login_extra_fields: _csrf=@=xpath('//form[@id="login-form"]//input[@name="_csrf"]/@value', request_html('https://id.sueddeutsche.de/login'))I couldn't find a configuration-based approach that allows implementing either caching the downloaded page or setting both values at once. What's the best way to go about this in your opinion?
Hey guys, I'm starting to see this error in my database logs -2021-11-13 18:52:31 6 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
The instance was running perfectly fine but recently I couldn't login with my login details.
I'm running wallabag using docker-compose on a Ubuntu 20.04 VM over Proxmox 7.
Here's the relevant details from my docker-compose -
version: '3'
services:
wallabag:
#build: https://github.com/wallabag/docker.git#2.4.2
image: wallabag/wallabag
#image: abhilesh7/wallabag-arm
container_name: wallabag_app
environment:
- MYSQL_ROOT_PASSWORD=secure-password
- SYMFONY__ENV__DATABASE_DRIVER=pdo_mysql
- SYMFONY__ENV__DATABASE_HOST=db
- SYMFONY__ENV__DATABASE_PORT=3306
- SYMFONY__ENV__DATABASE_NAME=wallabag
- SYMFONY__ENV__DATABASE_USER=wallabag
- SYMFONY__ENV__DATABASE_PASSWORD=password
- SYMFONY__ENV__DATABASE_CHARSET=utf8mb4
- SYMFONY__ENV__MAILER_HOST=smtp.gmail.com
- SYMFONY__ENV__MAILER_USER=gmail-user
- SYMFONY__ENV__MAILER_PASSWORD=gmail-password
- SYMFONY__ENV__FROM_EMAIL=gmail-email-address
- SYMFONY__ENV__DOMAIN_NAME=https://wallabag.domain.net
- SYMFONY__ENV__SERVER_NAME="Your wallabag instance"
ports:
- 80:80
volumes:
- /opt/wallabag/images:/var/www/wallabag/web/assets/images
healthcheck:
test: ["CMD", "wget" ,"--no-verbose", "--tries=1", "--spider", "http://localhost"]
interval: 1m
timeout: 3s
depends_on:
- db
- redis
restart: unless-stopped
db:
image: mariadb
container_name: wallabag_db
environment:
- MYSQL_ROOT_PASSWORD=secure-password
volumes:
- /opt/wallabag/data:/var/lib/mysql
healthcheck:
test: ["CMD", "mysqladmin" ,"ping", "-h", "localhost"]
interval: 20s
timeout: 3s
restart: always
redis:
image: redis:alpine
container_name: wallabag_redis
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 20s
timeout: 3s
restart: alwaysNot sure why it's overriding the database login credentials specified in the docker-compose. Any pointers how to fix this
Hi! The migration from 2.3.8 is failing for several users due to a DROP FOREIGN KEY failing (not existing)
Could someone tell if editing a migration is OK, to add a
IF EXISTS clause? See https://github.com/wallabag/wallabag/issues/5233#issuecomment-972667069
but actually I run nginx and php-fpm as root and make /usr/share/webapps/wallabag and /var/lib/wallabag belong to root.
I self-host wallabag with docker-compose. When the app container starts, the db (mariadb) says:
[Warning] Aborted connection 14 to db: 'unconnected' user: 'unauthenticated' host: '172.22.0.4' (This connection closed normally without authentication). Then the app says Provisioner finished.. That aborted connection is most likely from the provisioner. Anyone know what the provisioner is doing?
@meonkeys: the docker image starts an Ansible playbook at launch for provisioning things like the user
hmm, which task is making that connection, though? Maybe
wait for db container? https://github.com/wallabag/docker/blob/master/root/etc/ansible/entrypoint.yml#L75
ah yeah, that must be it.
I keep getting the "check URL" message -- tried everything I could think of:
- checked via network capture that its actually hitting the right IP (it is)
- turned off 2FA
- tried all sorts of permutations of the URL
any clues about why id keep getting the "wallabag service not found -- check URL" message ? havent found anything really useful in googling
@GreenTentacle_twitter Docker? Check this comment: https://github.com/wallabag/android-app/issues/997#issuecomment-641100325
trying to export all my articles, but PHP seems to be complaining that it has run out of memory
is there a relatively easy way break the export down into smaller chunks to avoid this problem?
I'm dealing with just over 2100 entries
I seem to be able to export my unread and starred entries just fine, but I'd like to be able to carry over the ~1800 unstarred archived entries as well
running wallabag via Docker
okay, found the container's php.ini file and bumped the limit up to 256M, and that seems to have done the trick
and, since I don't think I'll have to do this again, it probably shouldn't matter that docker will completely lose that change on the next restart
huh… looks like new (post-import) articles got added to the wrong end of the list