Alles anzeigenHallo.
Ich wollte nur kurz beschreiben, wie ich Wallabag auf dem netcup Webhosting (Shared Hosting) installiert habe. Es läuft bis jetzt ohne Probleme, soweit ich das sehen kann.Ich erstelle eine Subdomain (z.B. wallabag.mydomain.tld) und ein entsprechendes Let's Encrypt SSL-Zertifikat. Auf der Sudomain läuft i.M. PHP 7.3.15 (hab irgendwo gelesen, wallabag hätte noch Probleme mit PHP 7.4).
Und im WCP noch eine mySQL-Datenbank für Wallabag erstellen.
Im Shared Hosting sind Befehle wie make nicht verfügbar. Doch zum Glück bieten die Entwickler von Wallabag fertige binary Pakete an, die bereits alle ansonsten zusätzlich zu installierenden Abhängigkeiten beinhalten.
Die normale URL zum aktuellen Paket https://wllbg.org/latest-v2-package scheint i.M. nicht zu funktionieren (SSL-Zertifikatsprobleme), aber es gibt noch eine andere:
https://static.wallabag.org/releases
Dort den Link zur aktuellsten Version (i.M. Version 2.3.8) kopieren und dann bei netcup :
cd wallabag.mydomain.tld
wget https://static.wallabag.org/releases/wallabag-release-2.3.8.tar.gz
Entpacken mit --strip-components=1, um nicht in einen Unterordner zu entpacken.
tar xvf wallabag-release-2.3.8.tar.gz --strip-components=1
Dann z.B. mit nano eine .htaccess Datei erstellen (immer noch im Ordner wallabag.mydomain.tld) mit folgendem Inhalt:
RewriteEngine On
# Rewrite auf https
RewriteCond %{HTTPS} !=on
RewriteCond %{ENV:HTTPS} !=on
RewriteRule .* https://%%7bserver_name%7d%%7brequest_uri} [R=301,L]
# wallabag Regeln
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /web/$1 [QSA,L]
# Schutz für .htaccess Datei
<Files ~ "^.*\.([Hh][Tt][Aa])">
order allow,deny
deny from all
satisfy all
</Files>
Options -Indexes
Dann z.B. mit nano dieParameter in der Datei app/config/parameters.yml anpassen.
Den Werten, die ihr anpassen müsst, habe ich mal ein > vorangestellt:
parameters:
database_driver: pdo_mysql
database_driver_class: null
> database_host: 10.11.12.133
> database_port: 3811
> database_name: k12345_DATENBANKNAME
> database_user: k12345_BENUTZERNAME
> database_password: Datenbank-BenutzerPasswort
database_path: null
database_table_prefix: wallabag_
database_socket: null
database_charset: utf8mb4
> domain_name: https://wallabag.mydomain.tld
mailer_transport: smtp
> mailer_host: mx1a2b.netcup.net
> mailer_user: Mailkonto-Benutzername
> mailer_password: Mailkonto-BenutzerPasswort
locale: en
> secret: hier_30-Zeichen-langes-Secret-wählen
twofactor_auth: true
> twofactor_sender: no-reply@mydomain.tld
> fosuser_registration: false
fosuser_confirmation: true
> from_email: no-reply@mydomain.tld
...Dann im Ordner der Subdomain (wallabag.domain.tld) den wallabag-Installationsdialog starten mit
php bin/console wallabag:install -e=prod
Die Frage nach einem Datenbank-RESET und dem Erstellen eines Adminstrator-Benutzers mit YES beantworten.
Für den Admin-Benutzer neuen Benutzernamen, Passwort und Emailadresse angeben. Sind nicht identisch mit irgendwelchen vorherigen Angaben.
Dann vielleicht noch diesen Befehl ausführen (auch wenn ich nicht sicher bin, dass er unbedingt notwendig ist):
php bin/console cache:warmup -e=prodUnd jetzt kommts:
Immer wenn ihr Änderungen an der Konfiguration vornehmt (z.B. in der Datei app/config/parameters.yml), müsst ihr anschließend den Cache löschen.
Dafür gibt es zwar einen eigenen Befehl php bin/console cache:clear -e=prod,ABER anscheinend löscht der Befehl nicht oder nicht zuverlässig den Cache.
Wenn der Cache aber mit
rm -rf var/cache/*(ausgeführt im Ordner der Subdomain) gelöscht wird, funktioniert Wallabag.
Das wars.
Danke für die super Anleitung! Konnte damit Wallabag auch bei mir und in relativer Windeseile installieren 
Einzig php bin/console wallabag:install -e=prod hatte so bei mir nicht funktioniert.
Habe dann in der Wallabag-Dokumentation gesehen, dass sich da scheinbar was geändert hat:
php bin/console wallabag:install --env=prod (von hier: https://doc.wallabag.org/en/admin/insta…stallation.html)
Damit ging's dann, vielleicht hilft es zukünftig ja noch wem 