WordPress Multisite: Passwort reset bei Subsites korrigieren

In der WordPress Multisite eigenen Standardeinstellung leitet der Passwort reset Link immer zur Hauptseite. Dies ist für Admins und User die auf der Hauptseite einen Account haben kein Problem. Es kann allerdings bei vielen Multisite Szenarien zu Problemen und Verwirrungen führen.

Hat User 1 beispielsweise einen Account bei Seite 3 aber nicht bei Seite 2 oder der Hauptseite, funktioniert der Reset Link einfach nicht. Wenn man ihn händisch eintippt, also in diesem Beispiel seite3.example.com/wp-login.php?action=lostpassword statt wie von WordPress vorgegeben: example.com/wp-login.php?action=lostpassword funktioniert alles. Viel Spaß wenn man das einem simplen User jedes Mal erklären muss…

Ein ziemlich nerviges verhalten, was einem gerade bei Seiten mit vielen Nutzern einige Arbeit bereitet. Praktischerweise hat jemand einen Fix in Form eines WordPress Plugins geschrieben. Einfach als Plugin installieren und der Passwort Reset Link zeigt bei allen Unterseiten nun automatisch auch auf den exklusiven Passwort reset der Unterseite. Die Links in den Emails etc. werden durch das Plugin von Eric Teuber auch angepasst.

404 error bei admin-ajax.php und die mod_security

Problem: Eine WordPress Webseite lies sich bei einem Hoster beim Umzug partout nicht zum laufen überreden. Konfiguration, Datenbank, etc. alles korrekt. Auch sonst gab es keine Auffälligkeiten oder Fehler außer besagtem 404 error in der amin-ajax.php. Danach google ergab tausende Lösungsvorschläge und Ideen, keine davon hat allerdings funktioniert und wirkte auch generell eher nicht passend auf die Seite des Kunden. Bei mir in der Testumgebung lief ja alles problemlos.

Lösung:

mod_security deaktivieren. Ist zwar suboptimal aber wenn der Hoster keine eigene Konfiguration der mod_security erlaubt anscheinend die einzige Lösung…

Hoffentlich erspart das irgendjemand die Zeit die ich in die Fehlersuche investiert habe. Danke Daniel für die Hilfe.

WWAN / Mobile Broadband sorgt für Segfault in NetworkManager

Der Titel sagt schon alles: Heute mit dem Laptop draußen gewesen und auf einmal geht die SIM Karte im Laptop nichtmehr. Dmesg spuckte Folgendes aus:

[   58.654350] NetworkManager[327]: segfault at 8 ip 00000000004a0b52 sp 00007fff6271b5c0 error 4 in NetworkManager[400000+23e000]
[   60.537051] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready

Die Lösung war nach längerer Suche tatsächlich sehr einfach: Nachdem man IPv6 für diese Verbindung deaktiviert, sollte alles wie gehabt funktionieren. Es gibt wohl schon einen Fix ab NetworkManager 1.8.1 aber der ist im Arch Repo wohl noch nicht drin.

Quelle / Bugreport

Chrome und 2560×1440 WQHD unter Linux

Irgendwie sah bei mir unter Chrome die Schrift bei meinem neuen Monitor mit WQHD Auflösung (2560×1440) sehr verwaschen aus. Das Problem trat allerdings nur unter Linux auf und evtl. auch nur im Multimonitorbetrieb. Eventuell liegt das am proprietären Nvidia Treiber den ich nutze, habe ich jetzt aber alles nicht ausgiebig getestet. In jedem Fall hier die Lösung:

Bei mir schaut der Befehl um Chrome zu starten wie folgt aus:

chromium --force-device-scale-factor=0.75

Um das richtige Verhältnis rauszufinden muss man ein wenig rechnen. Die erste Zeile ist die aktuelle Pixelbreite des Monitors geteilt durch die FullHD Pixelbreite. Diese Teilen wir durch eins und haben das Verhältnis, welches wir an den Chrome Startbefehl anhängen.

2560 / 1920 = 1,3333333....
1 / 1.3333 = 0,75...

Anschließend Chrome mit dem obigen Befehl starten, und die Schriften sollten wieder knackig scharf und korrekt skaliert sein mit 2560×1440 WQHD. Warum hier Chrome so rumzickt weiß ich nicht, allerdings hat mir das Archlinux Wiki auf die Sprünge geholfen. Ich vermute, dass Chrome irgendwie von FullHD ausgeht und die WQHD Auflösung nicht korrekt erkennt. Eigentlich sollte der Device Scale Factor ja immer 1 sein aber nunja.

Hier aber noch 2 Bilder zum vorher / nachher Vergleich.

Den Monitor, einen Dell U2515H, kann ich übrigens uneingeschränkt empfehlen! Da mir 4K im Alltag noch zu unpraktisch ist und 27″ zu groß, waren 25″ und 2560×1440 WQHD ideal. Farbwiedergabe, Schwarzwert, etc. sind auch top und mit ca. 300€ ist er sogar günstiger als ich es bei der Leistung erwartet hätte.

php.ini Einstellungen für Uploads bei WordPress

Da mich häufiger bei frischen Installationen von Ubuntu Servern oder auch diversen Hostern schon häufiger diese Fehlermeldung:

„Are you sure you want to do this? Please try again“

Oder auch diverse Timeouts begrüßt haben, hier für mich zur Erinnerung und für alle anderen vielleicht auch PHP Settings, die für jede Standardinstallation bei WordPress gut funktionieren sollten. Ausahmen gibts natürlich, aber so macht WordPress in Zeiten immer größerer Template Files oder Plugins zumindest keine Probleme.

Einfach folgende Einstellungen in eurer php.ini überschreiben:

max_execution_time = 180
max_input_time = 600
post_max_size = 128M
upload_max_filesize = 256M

Damit sollten Timeouts beim Theme hochladen erstmal der Vergangenheit angehören.

Grund für die immer größeren Theme Dateien, sind gerade bei Premiumtemplates wie z.B. bei Themeforest, gebundelte Pluginfiles. Da kommen schnell mal 10-20mb zusammen, auch wenn das eigentliche Theme nur 2mb hat.

OpenELEC auf Raspberry Pi 2: Anleitung & Test

Nach langem Warten gab es endlich den Raspberry Pi 2 zu kaufen. Ich habe ihn direkt am Erscheinungstag bestellt und am Tag der Anlieferung gab es bereits eine lauffähige Version von OpenELEC.

Wer OpenElec noch nicht kennt, der kann sich genauere Infos zum MediaCenter auf deren Seite ansehen. Kurzgesagt ist es eine MediaCenter Distribution, die auf dem Pi (und anderen Systemen) lauffähig ist und auf Kodi (ehemals XBMC) basiert. Durch starke Optimierung lief OpenElec schon auf dem Pi erster Generation erstaunlich flüssig. Ab und an gab es im Menu zwar mal kleine Ruckler und die Indexierung der Medien bei der Datenbankerstellung dauerte auch etwas, aber das Wichtigste funktionierte einwandfrei und ohne Hakler: Videos in FullHD schauen.

Deshalb war ich insbesondere gespannt wie sich der neue Raspberry Pi 2 mit OpenElec schlägt. Kaufen könnt ihr den neuen PI beispielsweise hier.

Installation

Die Installation war gewohnt einfach. Einfach das richtige Image (ARMv7) von der Downloadseite runterladen und unter Linux per DD auf die SD Karte ziehen (detaillierte Anleitung).

Es funktioniert übrigens NICHT, einfach die alte SD Karte auf eine microSD zu klonen! Die Images für den Raspberry 1 und Raspberry 2 sind unterschiedlich und deshalb nicht direkt kompatibel.

OpenElec Einstellungen exportieren & importieren

Sämtliche Daten die ich über OpenElec wiedergebe liegen bei mir auf meinem kleinen Homeserver. Da die Einrichtung aller Einstellungen und Dienste doch recht nervig ist, habe ich bei der Gelegenheit auch direkt mal den Export ausprobieren. Dabei werden sämtliche Einstellungen, Datenbank, etc. in eine Datei exportiert. Diese kann man anschließend auf die neue SD Karte kopieren. Man geht einfach in die OpenElec Systemeinstellungen und erstellt zunächst ein Backup. Dieses zieht man anschließend auf die neue microSD Karte und zwar idealerweise in den gleichen Ordner, in dem es sich auf der alten SD Karte befand. Dann einfach die neue microSD im RaspPi2 booten, in den Optionen auf wiederherstellen gehen und das passende Backup auswählen.

Das Wiederherstellen dauert ein paar Minuten und ist erst nach einem Reboot vollständig. OpenElec meldet sich aber wenn es neugestartet werden will, also einfach den Anweisungen folgen. Beim Neustart sollten dann nach ein wenige Wartezeit alle Einstellungen, Themes, Datenbank etc. wieder da sein.

Performance von OpenElec auf dem RasPi2

Nun aber zum Wichtigsten: Der Performance. Diese ist im Vergleich zum Pi 1 auf dem Papier enorm gewachsen und OpenElec läuft nun wie geschmiert. Absolut keine Ruckler mehr im Menu und man kann nun problemlos auch aufwendigere Themes verwenden. Auch das Starten von Videos oder Suchen von Untertiteln geht nun eine ganze Spur flotter vonstatten.

Insgesamt lohnt sich das Update meiner Meinung nach enorm. Der Preis ist quasi gleich geblieben und man bekommt dafür eine extrem gesteigerte Leistung, sowohl auf dem Papier als auch in der Praxis.

Falls ihr den Pi 2 kaufen wollt, könnt ihr ihn hier bestellen.

CM12s auf dem OnePlus One

Es ist soweit, CM12s mit Android Lollipop ist raus und wird per OTA an die ersten User verteilt. Ich war zu ungeduldig und da ich ohnehin eine Custom Recovery (TWRP) auf meinem OnePlus habe, beschloss ich einfach manuell zu flashen.

Die passende Zip File findet sich hier. Hier noch die Details zur Datei:

Device.......: A0001
Filename.....: cm-12.0-YNG1TAS0YL-bacon-signed.zip
Filesize.....: 571M
MD5.CheckSum.: C12A966B93E0A45BADD2EC4EDDF2B8B6
------------------------------------------------------
Kernel.......: N/A
Android......: 5.0.2
Build.ID.....: LRX22G
------------------------------------------------------
OTA..........: N/A
Build........: LRX22G
Build.Date...: 2015-04-09 23:27:46 +0000

Sie kommt direkt von Cyanogen, ist also vertrauenswürdig.

Die Installation läuft über TWRP problemlos. Einfach im Recovery wie jede andere Zip installieren, Cache / Dalvik wipen und reboot. Der erste Boot dauert recht lange, also Geduld. Sämtliche Apps, Einstellungen und Nutzerdaten bleiben beim Update von CM11s auf CM12s / CyanogenOS erhalten.

Erster Eindruck von CyanogenOS auf dem OnePlus One

Mein erster Eindruck ist äußerst positiv. Alles läuft super flüssig und schaut gut aus. Bluetooth funktioniert einwandfrei, die Kamera auch. Sogar inklusive der ganzen Funktionen wie HFR Videos mit 120fps in 720p… eine Sache die unter OxygenOS schmerzlich vermisst wurde. Touch2Wake und Taschenlampe per Geste funktionieren und die neue Geste (Kreis) für die Kamera werde ich wohl häufiger nutzen.

Hier noch ein paar Screenhots vom neuen System. Jeder der Lolipop schonmal in Aktion gesehen hat dürfte es wohl kaum umhauen. Ich hab die Default Einstellungen von Lollipop genutzt, da mir das helle für den Moment besser gefallen hat. Die Darstellung ist bei mir generell etwas kleiner, da ich die DPI unter Android generell umstelle. Ich mag die große Darstellung nicht und hab lieber mehr Platz.

NFS Update verhindert Suspend / Hibernate

Seit einigen Tagen funktionierte Suspend2Ram auf meiner Workstation nichtmehr. Da ich dummerweise zum gleichen Zeitpunkt eine neue Grafikkarte eingebaut habe, dachte ich hier liegt der Fehler.

Weit gefehlt, der Übeltäter war das Paket nfs-utils-1.3.2. Unten der dmesg Output der mich auf die richtige Spur brachte. Es gibt auch schon mehrere Bugreports bei diversen Distributionen. Auch Debian ist betroffen. Da ich persönlich kein Hibernate benutze, kann ich hier nur vom kaputten Suspend berichten. Die Lösung dürfte aber in beiden Fällen funktionieren und lautet: NFS Downgrade.

Die Lösung: NFS Downgrade

Da NFS der Übeltäter ist und Suspend bei mir bisher einwandfrei funktionierte, war ein Downgrade die einfachste Lösung. Dummerweise habe ich meinen Package Cache vor einigen Tagen erst geleert. Die Lösung unter Archlinux lautet Arch Rollback Machine. Dort finden sich Mirrors, die eine Spiegelung älterer Builds vorhalten. Ich hab einfach die Version nfs-utils-1.3.1 genommen und Suspend funktioniert wieder einwandfrei.

Pro-Tipp: Bis zum nächsten NFS Update mit einem Fix sollte man an der Stelle noch das Paket nfs-utils in der pacman.conf unter „Ignored Packages“ eintragen.

nfs4.1-svc hangs and breaks suspend:
[ 242.963957] PM: Syncing filesystems ... done.
[ 243.535088] PM: Preparing system for mem sleep
[ 243.730776] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 243.733034] Freezing remaining freezable tasks ... 
[ 263.736906] Freezing of tasks failed after 20.007 seconds (1 tasks refusing to freeze, wq_busy=0):
[ 263.737154] nfsv4.1-svc D ffff8800a0fd7d78 0 951 2 0x00000000
[ 263.737165] ffff8800a0fd7d78 ffff8800a0f66d50 0000000000013f00 ffff8800a0fd7fd8
[ 263.737174] 0000000000013f00 ffff88012af86d50 ffff8800a0f66d50 ffffffffa0298aa0
[ 263.737181] ffff8800a0d70000 ffffffffa0298aa0 0000000000000000 ffff8800a0fd7cd8
[ 263.737188] Call Trace:
[ 263.737239] [] ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc]
[ 263.737262] [] ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc]
[ 263.737282] [] ? rpc_release_resources_task+0x34/0x40 [sunrpc]
[ 263.737301] [] ? __rpc_execute+0x2c8/0x4a0 [sunrpc]
[ 263.737313] [] ? lock_timer_base.isra.37+0x2b/0x50
[ 263.737323] [] schedule+0x29/0x70
[ 263.737332] [] schedule_timeout+0x11b/0x250
[ 263.737340] [] ? migrate_timer_list+0xd0/0xd0
[ 263.737362] [] nfs41_callback_svc+0x1aa/0x1e0 [nfsv4]
[ 263.737369] [] ? wait_woken+0x90/0x90
[ 263.737387] [] ? nfs4_callback_svc+0x60/0x60 [nfsv4]
[ 263.737396] [] kthread+0xd8/0xf0
[ 263.737404] [] ? kthread_create_on_node+0x1c0/0x1c0
[ 263.737412] [] ret_from_fork+0x58/0x90
[ 263.737419] [] ? kthread_create_on_node+0x1c0/0x1c0

Bilder verlustfrei komprimieren unter Linux

Viele Webworker dürften das Problem mit Bildern kennen. Irgendwie dauert die wenn möglich verlustfreie Komprimierung und das entfernen der Exif Daten dann doch länger oder kommt zu kurz. Ich habe mir jetzt vorgenommen künftig noch mehr darauf zu achten und bin auf die idiotensichere Lösung Trimage gestoßen.

Das Tool ist Open Source, für allerlei Plattformen verfügbar und kann genau eine Sache: Bilder im Format JPG oder PNG lossless zu komprimieren und auf Wunsch von sämtlichen Metadaten befreien.

Die Oberfläche ist bewusst simpel gehalten um ideal in den persönlichen Workflow eingebaut werden zu können. Außerdem kann das Tool auch prima übers Terminal angesteuert werden. Unterstützt werden JPGs und PNGs. Mehr brauche ich in 95% der Fälle nicht, insofern finde ich den KISS ansatz perfekt!

Webbasiert JPGs/PNGs verlustfrei komprimieren

Alternativ gibt es einige webbasierte Tool, wenn man keine Lust hat etwas zu installieren oder an fremden Rechnern sitzt. Mir am besten gefallen hat dabei https://compressor.io/.

Ist auch total fancy mit hipper .io URL…

Mit functions.php Code in Child Themes einfügen

WordPress bietet schon seit langem die Möglichkeit von Child Themes und man sollte es sich eigentlich zur Angewohnheit machen, direkt zu Beginn eins anzulegen. Man spart sich viel Stress und hat eigentlich nur Vorteile.

Will man bei einem Theme beispielsweise eine Datei verändern, kopiert man sie sich ins Child Theme und modifiziert wie gewünscht. Da diese nun priorisiert wird, werden die Modifikationen angezeigt.

Was aber nun, wenn man nur ein paar wenige Codezeilen in einem bestimmten Bereich einfügen will, z.B. im Header. Bei mir kommt das häufiger vor und es nervt gewaltig bei Theme Updates erst nachzusehen, ob die von mir modifizierte Datei auch geändert wurde und ich diese Änderungen dann ins Child Theme übernehmen muss.

Code irgendwo per functions.php einfügen

Praktischerweise gibt es dafür eine einfache Lösung: Mittels functions.php kann man vorhandene Funktionen deaktivieren bzw. neue einfügen. Also auch eine Funktion die in einem bestimmten Bereich ein wenig HTML injeziert.

Eine rudimentäre functions.php, welche Code in den Header einfügt sähe dann beispielsweise so aus:

<?php
add_action('wp_head', 'inject_wp_head');
function inject_wp_head(){
 ?> 
 <meta name="theme-color" content="#db5945">
 <?php 
}
?>

In diesem Beispiel füge ich ein Meta Tag für die mit Android Lolipop eingeführten Theme Colors ein. Nette Spielerei und jetzt habe ich den Code zum direkt kopieren auch endlich hier ;-)

1 2 3 9  Scroll to top