Das Plugin blieb das gleiche wie es bei ihm zum Download gibt,daran habe ich nichts geändert. Jedoch verwende ich das Theme K2 für den grundsätzlichen Themeaufbau (Banner usw sind selbstgemacht), welches mir viele schöne Ajax-Sachen bereitstellt (und leider das Blog ein wenig aufbläht…). Das Problem daran ist, dass dieses Theme zwar eine “single.php” besitzt, diese jedoch keinen erkennbaren sinnvollen Content besitzt.

Bei Layer-Ads wird beschrieben, dass man die Layer am besten kurz vor dem </body>-Tag einbauen sollte, was mir diesmal sehr zu pass kam. Ich editierte also meine footer.php des Themes mit folgendem Code: Suche den </body>-Tag und füge davor ein:

1
2
3

<!--?php if(showlayerad() == '1' && !is_user_logged_in() && is_single() && !is_home()) { ?-->
    <script src="http://layer-ads.de/la-60116-subid:<?php the_ID(); ?>.js" type="text/javascript"></script>
<!--?php } ?-->

Wobei 60116 durchaus durch die eigene Layer-Ads-ID ersetzt werden darf ;)

Was macht dieser Code? Zunächst wird mittels des Plugins von Torsten (showlayerad) überprüft, ob der Benutzerdefinierte Feld “Layerad” auf 1 gesetzt wurde. Wenn dies der Fall ist, und es eine einzelne Seite (nicht aber die Startseite) ist, so wird die Werbung angezeigt, sofern der User nicht eingeloggt ist (d.h. Registrierte Nutzer bekommen keine Werbung). Da ich persönlich Werbung immer etwas nervig finde, zeige ich einen Hinweis für alle Nutzer rechts oben, wie man diese recht leicht loswird (Ausser über einen Werbeblocker). Diesen habe ich über ein Widget im K2 Sidebar Manager (SBM) eingebaut, welches folgendermaßen aussieht:

1
2
3

<!--?php if(showlayerad() == '1' && !is_user_logged_in() && is_single() && !is_home()) { ?-->
<img src="/upload/blog/attention.webp" align=left />Dieser Beitrag ist werbefinanziert. Sie können ohne Werbung auf meinen Seiten surfen, indem Sie sich <a href="/wp-login.php?action=register">registrieren</a>
<!--?php } ?-->

Leider hat sich die Layer-Ads mit meiner Amazon-Werbung überhaupt nicht vertragen haben, daher musste ich diese ausschalten, wenn Layer-Ads an ist. Gleichzeitig habe ich noch eingebaut, dass es nur unregistrierten Nutzer angezeigt wird:

1
2
3

<!--?php if(showlayerad() != '1' && !$user_ID) { ?-->
<!-- Amazon Werbe-Javascript-Code hier -->
<!--? } ?-->

Es sind nun nur ausgewählte Beiträge ( Beispiel) mit Werbung versehen worden. ich denke, mit dieser nervigen Art von Werbung können sich die meisten noch anfreunden. Mal schauen, wie lange ich das so lasse :P

Danke an Torsten für das Plugin :)

Angefangen mit einfachen Linux-Artikeln dann vielen NAS-Artikeln und nun eher Smart Home (FHEM) und Programmierung hat sich doch irgendwie immer ein Thema gefunden ;) Nun auf zu den nächsten 1000 Artikeln ;) Danke für die vielen Kommentare (aktuell 8476 Kommentare) und Rückmeldungen!

Edit: Postie 1.1 kann leider mit dem neuen Kategoriensystem von Wordpress nicht mehr zusammenarbeiten, da sich das Datenbankschema geändert hat. Daher hat ein findiger Blogger die beiden Dateien gepatched. Das geht nun schon mal wieder…

So bezeichnet es zum Beispiel eine Sprache bzw. einem Geheimcode. In Leetspeak werden in der einfachsten Stufe verschiedene Buchstaben durch Zahlen ersetzt. So wird i/I/j/J zu 1, e/E zu 3, a/A zu 4, s/S zu 5, G zu 6, t/T zu 7, b zu 8, g zu 9, o/O zu 0. Ungeübte Personen kommen bereits hier ins Straucheln.

In der nächsten Stufe werden bestimmte Zeichen durch zwei Zeichen ersetzt. So wird beispielsweise ein V zu \/, ein U zu |_| oder ein W zu \^/. So wird das lesen schon deutlich komplizierter.

Natürlich kann man das beliebig steigern, beispielsweise könnte man ein P als |* oder ein N als |1 schreiben. Die Lesbarkeit ist hier nicht mehr entscheidend.

Teilweise aufgrund des 1337, aber auch in verschiedenen Chats haben sich einige Kürzel entwickelt, die mittlerweile als Standard des 1337 angenommen wurden. Beispielsweise wird oft “you” als “u” bzw. “ya” und “See” als “C” abgekürzt. “later” hat sich so auch zu “l8er” entwickelt. (“Bis später” heisst daher: “C u l8er” oder “Cya l8er”).

1337 ist aber auch eine Lebenseinstellung. So steht 1337 auch für eine Abgrenzung der Personen, die dessen mächtig sind. Man spricht daher oft von einer Elite (daher wird 1337 auch von manchen als 313373 geschrieben). Auch gibt es viele Webseiten, die dieser Elite eine Plattform bieten, um sich auszutauschen. Diese Elite sind oft Personen, die viel Zeit vor/mit elektronischen Kommunikationsmitteln und Geräten verbringen und häufig viel oder sogar ausschließlich über diese kommunizieren.

Man merkt, dass der Artikel nicht alles erklären kann, daher stehe ich für Fragen über die Kommentarfunktion bereit ;)

PS: Natürlich gibt es auch Google mit Leetspeak .

Neuer Blog-Eintrag: Umleitung bei ausschließlicher Angabe der post_id in der URL auf den vollen Wordpress-Permalink mittels Nginx https://wolf-u.li/3385/ 

Früher wurde dann per Wordpress auf die volle URL umgeleitet, jedoch funktioniert dies in der Version 2.9.2, die ich momentan fahre, nicht mehr so. Das führte dazu, dass unter https://wolf-u.li/3385/  und der langen Url des Beitrags der gleiche Inhalt angezeigt wurde, was zu Problemen mit den Suchmaschinen führen kann. Da ich keinen Bock hatte, mich bei mir auf Fehlersuche zu begeben, habe ich kurz gegoogled und festgestellt, dass dies für Version 3.1 von Wordpress wieder geplant  ist. Ein wenig Recherche  brachte an den Tag, dass man auch manuell per .htaccess (bei Nutzung von Apache) auf index.php?p={POST_ID} umleiten kann.

Dieser Artikel ist Teil einer Reihe zum Webserver nginx. Schau dir auch die anderen Artikel an: Zum Leitartikel

Da ich den Webserver Nginx einsetze, habe ich also nun einfach eine Prüfung geschrieben, die nachsieht, ob nach wolf-u.li/ einfach nur eine Zahl folgt und in diesem Fall auf die index.php leitet, welche dann auf die korrekte lange URL leitet. Die komplette Location könnte also so aussehen:

1
2
3
4
5
6
7

location / {
 if (-f $request_filename) {
 break;
 }
 rewrite ^/([0-9]+)/$ /index.php?p=$1 last;
 rewrite ^(.+)$ /index.php last;
}

Zuerst wird geprüft, ob der angeforderte Dateiname vorhanden ist. Wenn dem der Fall ist, werden keine weiteren Prüfungen durchgeführt und diese Datei zurückgegeben. Wenn nicht, wird zunächst die oben beschriebene Prüfung durchgeführt. Wurde kein Match ermittelt, so wird einfach nur auf index.php umgeleitet.

Das behob bei mir das Problem des doppelten Contents ;)

• Bei einer offenen Benutzerregistrierung führt eine sogenannte “ SQL Column Truncation ” dazu, dass der gewählte Benutzername ein existierender sein kann und deshalb dessen Passwort zurückgesetzt wird. Nur ärgerlich, da der Angreifer keinen Zugriff auf den Account erhält.
• Ein Fehler in der PHP-Funktion mt_rand() führt dazu, dass das während der Registrierung erstellte Passwort vorhersagbar ist. Dies betrifft auch andere Webapplikationen und ist derzeit mittels des Sicherheitspatches “ Suhosin ” behebbar. Daher sind die Applikationen auf meinem Server nicht davon betroffen.

Das Update ist auf den englischsprachigen Seiten  ( Release-Blog-Eintrag )schon erschienen, die Version von Wordpress-Deutschland wird sicher auch bald erscheinen ist ebenfalls erschienen . Derweil kann man sich schon mal die Liste der geänderten Dateien  ansehen und bei Bedarf manuell Updaten.

Ich habe zwei Tests gemacht: Zunächst mit einer meiner größten Seiten ( Installation des fun_plug), da diese für Besucher am schmerzhaftesten ist:

Details 

Die Unterschiede sind eher marginal, hier würde es sich meiner Ansicht nach nicht oder kaum lohnen auf den Service zu gehen.

Bei einer kleinen Seite ( Review des SpiderPro) sieht das ganze schon etwas anders aus:

Details 

Die Unterschiede sind hier deutlicher zu sehen und fordern mich nun auf, noch mehr auf Optimierung Wert zu legen. Für meinen Teil ist natürlich die Start Render Time ein interessanter Faktor und so kann ich nun dank des ausführlichen Vergleichs auch herausfinden was ich selber tun kann.

Fazit: Google hat hier wieder einen verrückten Weg beschritten, der dafür sorgt, dass das Web schneller wird. Heruntergeladen hat Google die Daten sowieso schon, da gibts also keine Geheimnisse. Interessant wirds aber wenn man dann an das Backend (Admininterface) oder Foren denkt. Ob das auch so gut ist? Für mich ist die Optimierung meiner Webseite schon ein wichtiger Faktor, jedoch behalte ich das ganze gerne in meiner Hand. Natürlich nehme ich mir aber die Ergebnisse zu Herzen und versuche mich an der Optimierung.

Der Autor ist an einer Weiterentwicklung interessiert und veröffentlicht beispielsweise nach einem Bugreport  auch schnell neue Versionen .

Dazu muss man in der .htaccess folgende Zeilen hinzufügen:

1
2
3
4

# PHP (CGI mode) HTTP Authorization with ModRewrite:
RewriteEngine on
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule ^(.*) - [E=HTTP_AUTHORIZATION:%1]

Anmerkung: Sofern die Rewrite-Engine schon aktiviert wurde, muss man das natürlich nicht nochmal machen…

Nun muss man die Datei des Plugins bearbeiten. Suche in der Datei disclose-secret.php:

1
2
3
4

if (!empty($current_user))
 return;

if (!isset($_SERVER['PHP_AUTH_USER']) || !isset[$_SERVER['PHP_AUTH_PW']]

Ersetze durch:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

if (!empty($current_user))
 return;

if (isset($_SERVER['HTTP_AUTHORIZATION']))
{
 $ha = base64_decode( substr($_SERVER['HTTP_AUTHORIZATION'],6) );
 list($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW']) = explode(':', $ha);
 unset($ha);
}

if (!isset($_SERVER['PHP_AUTH_USER']) || !isset[$_SERVER['PHP_AUTH_PW']]

Momentan überlege ich aufgrund der Bugs in Disclose-Secret im Zusammenhang mit Wordpress 2.7 (Beim Bearbeiten von Posts gehen die Berechtigungen verloren, neue Posts können nicht mit Berechtigungen versehen werden (nur über direktes Einfügen in der Datenbank) und das Berechtigungspanel erscheint ÜBER der Eingabemaske) auf Role Scoper  zu wechseln. Gleichzeitig würde ich mir damit den Role-Manager  sparen, der ebenfalls viele seltsame Bugs hat. Blöderweise kann Role Scoper den RSS-Feed noch nicht schützen, aber das habe ich bereits als Feature beim Autor requested. Mal sehen, ob das vielleicht kommt. Dann steige ich auf jeden Fall um.

• Ist das Bild vorhanden?
  • Wenn ja: Direkte Auslieferung
  • Wenn nein: Aufruf einer PHP-Datei zum Download des Bildes

Die Umsetzung war dann einfach:

Das ist die Konfigurationsdatei für den vHost in nginx:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

server {
 listen 80;
 server_name img.yourdomain.tld;
 error_log /path/to/your/logs/error/img.yourdomain.tld.log warn;
 root /path/to/your/document/root/;

 location ~ \.php$ {
 fastcgi_pass 127.0.0.1:1234;
 include /etc/nginx/fastcgi_params;
 }

 location / {
 index cdn.php;
 # if the requested file exists, return it immediately
 if (-f $request_filename) {
 break;
 }

 # all other requests go to CDN-PHP-File
 if (!-e $request_filename) {
 rewrite ^(.+)$ /cdn.php last;
 }
 }
}

Nun speichert man in /path/to/your/document/root/ die Datei cdn.php mit folgendem Inhalt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

 $grav_img,
 CURLOPT_HEADER => false,
 CURLOPT_RETURNTRANSFER => true,
 CURLOPT_TIMEOUT => 20,
 CURLOPT_BINARYTRANSFER => true,
 CURLOPT_MAXREDIRS => 2
 );
 curl_setopt_array($gch, $gcurl_options);

 $gdata = curl_exec($gch);
 if(!curl_errno($gch)) {
 $info = curl_getinfo($ch);
 if(curl_getinfo($gch, CURLINFO_HTTP_CODE) != 200) {
 echo "Foo";
 exit;
 }
 }
 curl_close ($gch);
 unset($gch);
 }
 $gfilehandle_img = fopen("g/" . $cache['size'] . "/" . $cache['hash'] . ".webp", "wb+");
 fwrite($gfilehandle_img, $gdata);
 fclose($gfilehandle_img);
 unset($gfilehandle_img);

 header('content-type: image/png');
 echo $gdata;
}

Was macht diese Datei?

Zunächst wird die URL zerlegt und anhand des Typs die Quelle für die Avatare ausgewählt. Warum der Unterordner /g/? Ich wollte mir damit offen halten, verschiedene Bildertypen zu cachen. Das habe ich gelöst, indem ich meinen Bilderhashes ein “/g/” vorstelle, welches diese als Gravatar-Bilder markiert. Fällt mir also irgendwann mal ein, dass ich beispielsweise gerne noch Pavatar (wie auch immer geartet) cachen möchte, dann kann ich dies hier einbauen.

Der nächste Teil der URL ist die größe des Avatars, die nur aus Zahlen bestehen darf.

Anschließend wird eine Prüfung der md5-summe der E-Mailadresse durchgeführt, die einige mögliche Angriffsvektoren ausfiltern soll. Dabei bleiben dann nur Strings mit 32 Zeichen in Groß- und Kleinbuchstaben übrig, andernfalls wird das Script beendet. Im Anschluss wird dann das Bild geholt (per curl, wenn möglich), gespeichert und ausgegeben. Das verzeichnis /path/to/your/document/root/g/ sollte hierzu vorhanden sein.

Die Url für ein 32x32 großes Bild sieht also am Ende so aus:

http://img.yourdomain.tld/g/32/a9ec4695d424a6dcb6f896afb0ee22bc.webp

und wird bei ersten Aufruf gecached mittels php und anschließend in den weiteren Aufrufen immer statisch durch den Webserver ausgegeben. Möchte man nun regelmäßig die Bilder aktualisieren, empfiehlt es sich, das hier bereits vorgestellte Script in regelmäßigen Abständen laufen zu lassen.

Für den Einbau in Wordpress ist das ganze auch recht einfach. Hierzu nimmt man einfach mein Wordpress-Plugin wu-get_avatar.

Zu guter letzt noch ein Hinweis für Apache-Nutzer: Das PHP-Script lässt sich natürlich auch mit diesem Webserver nutzen.

Damals war das Plugin Global Translator dafür verantwortlich, welches bei einer nicht vorhandenen Übersetzung ein 404 ausgespuckt hatte, was Google nicht so sehr gefallen hatte. Mittlerweile siehts in meinen Google Webmaster Tools schon wieder nicht so rosig aus. Da der Anteil ausländischer Besucher aus Ländern, deren Sprache nicht Englisch oder Chinesisch ist, täglich nur bei ~2% liegt, habe ich mich nun entschlossen, alle überflüssigen Sprachen zu entfernen, um mehr Anfragen für die Übersetzungen der Sprachen Englisch und Deutsch verfügbar zu haben. Natürlich ist das nicht so leicht, da ja doch mittlerweile knapp 12k Seiten im Google Index gelandet sind und ich für Unerreichbarkeit keine Schelte bekommen möchte ;)

Der mehrstufige Actionplan sieht nun folgendes vor:

• Erstellung von Rewrite-Rules für nginx zur 301-Umleitung (Moved Permanentely) auf Webserverebene
• Beantragung der Entfernung der Übersetzungen aus dem Google Suchindex
• Anpassen der Einstellungen in Global Translator
• Entfernung der überflüssigen Übersetzungsverzeichnisse
• Aktualisierung des Page-Cache

Erstellung von Rewrite-Rules für nginx zur 301-Umleitung

Die Übersetzungslinks sollen für eventuelle, schon vorhandene Verlinkungen, auf den Originalartikel umgeleitet werden. Da ich, wie vielleicht einige wissen, als Webserver Nginx einsetze (Siehe Leitartikel), benötige ich hierfür die entsprechenden Rewrite-Rules. Leider bin ich ein Experte in Regex, jedoch funzt der folgende Code:

1
2
3

location ~* ^/(ar|be|ca|cs|da|el|es|et|fa|fi|fr|ga|gl|hu|is|ko|mk|ms|mt|nl|bg|hr|id|it|hi|iw|ja|no|lv|lt|pl|pt|ru|sk|sl|sq|sr|sv|ro|th|tl|tr|uk|vi)/ {
  rewrite ^/(ar|be|ca|cs|da|el|es|et|fa|fi|fr|ga|gl|hu|is|ko|mk|ms|mt|nl|bg|hr|id|it|hi|iw|ja|no|lv|lt|pl|pt|ru|sk|sl|sq|sr|sv|ro|th|tl|tr|uk|vi)/(.*)$ /$2 permanent;
}

Er muss mit in den Server-Teil der betreffenden Blog-Domain eingebaut werden. Vermutlich könnte man von der Location her direkt die Sprache capturen, so wie oben funzt es aber auf jeden Fall ;) Die Sprachen “en”, “zh-CN” und “zh-TW” habe ich weggelassen, da ich diese vorerst weiter behalte.

Beantragung der Entfernung der Übersetzungen aus dem Google Suchindex

Bis dato hatte ich von den angebotenen Sprachen des Global Translator nur jene aktiviert, die seitens Google Adsense erlaubt sind. Diese müssen nun über die Google Webmaster Tools entfernt werden. Dazu loggt man sich zunächst dort  ein. Man wählt die betreffende Webseite und geht zu “Website-Konfiguration” -> “Crawler-Zugriff”. Dort klickt man auf den Tab “URL entfernen”. Im folgenden Auswahlfenster wählt man dann als Option “Ein Verzeichnis sowie alle Unterverzeichnisse auf der Website”, da wir beispielsweise /ar/* entfernen möchten. Im nächsten Eingabefeld muss dann ar/ eingegeben werden.

Laut Google  sollte man ausserdem nun die robots.txt anpassen, da ein 301 Redirect nicht als “nicht mehr erreichbar” gilt. Hierzu legt man für jede entfernte Sprache ein

1

Disallow: /{SPRACHCODE}/

an, sodass dies dann beispielsweise so aussieht:

1
2
3

User-agent: *
Allow: /
Disallow: /ar/

Anpassen der Einstellungen in Global Translator

Nun rate ich dazu, die Sprachen im Plugin zu entfernen. Bei mir bleiben derzeit nur “en”, “zh-CN” und “zh-TW” übrig, den Rest habe ich deaktiviert. Nach dem Speichern sollte die Sitemap neu erzeugt werden, da nun die überflüssigen Sprachen wegfallen.

Entfernung der überflüssigen Übersetzungsverzeichnisse

Hat man die obigen Schritte erfolgreich durchgeführt, so können die überflüssigen Übersetzungsverzeichnisse gelöscht werden. Glücklich ist, wer Shellzugriff hat, da gehts etwas schneller als per FTP ;). Die Übersetzungen finden sich in {WORDPRESS_HOME}/wp-content/gt-cache/. Ich würde das Verzeichnis “stale” nicht mitlöschen, auch dort würde ich nur die nicht mehr benötigten Sprachen entfernen.

Aktualisierung des Page-Cache

Ich setze für das Cachen meiner Seiten das Plugin WP-Super-Cache  ein, welches nun auch aktualisiert werden sollte. Ein Klick auf “Delete Cache” auf der Einstellungsseite des Plugins würde dies durchführen. Ich persönlich verwende aber zusätzlich das Plugin “ Askapache Crazy Cache ”, welches mir erlaubt, schnell alle Seiten neu zu cachen. Auf einem shared Webspace macht dies jedoch nur begrenzt Sinn, da die CPU-zeit häufig begrenzt ist.

Fazit: So bin ich nun relativ sauber die überflüssigen Sprachen losgeworden und hoffe so die nicht erreichten Seiteninhalte reduzieren zu können.

Grad auf Facebook noch ausgegraben (Urheber unbekannt):

1
2
3
4
5
6

*.˛.°★。˛ °.★** **★* *˛.
˛ °_██_*。*./ \ .˛* .˛.*.★* *★ 。*
˛. (´• ̮•)*˛°*/.♫.♫*˛.* ˛_Π_____. * ˛*
.°( . • . ) ˛°./• '♫ ' •\.˛*./______/~＼*. ˛*.。˛* ˛. *。
*(...'•'.. ) *˛╬╬╬╬╬˛°.｜田田 ｜門｜╬╬╬╬ .
¯˜"*°••°*"˜¯`´¯˜"*°••°*"˜¯ `­´¯˜"*°´¯˜"*°••°*"˜¯`´¯˜" *°