Ein Blick auf die Route-Konfiguration verriet mir, dass im ersten Moment Feedburner das Problem war. Der Versuch, die Abruffunktion zu reaktivieren, schlug leider fehl.

Zudem gelang es nicht mehr, direkt auf den Blogs Beiträge per Feed zu abonnieren. Nur noch das Abonnieren von Kommentaren war möglich, diese Funktion ist aber auch nicht über Feedburner konfiguriert. Der Höhepunkt der Bugs war, dass bei Weiterblättern über die Paginierung nur noch eine weiße Seite erschien.

Was war geschehen?

Ursachenforschung

Ich überlegte, was ich in letzter Zeit in meinen Blogs geändert haben könnte. Waren eventuell Einträge in php-Dateien oder irgendwelche Updates dafür verantwortlich? Und tatsächlich, für drei Plugins hatte ich vor Kurzem Updates hochgeladen: Advanced Permalinks, Broken Link Checker und All in One SEO Pack.

Also deaktivierte ich zuerst Advanced Permalinks und … Treffer! Ein Zurückspielen der Plugindateien per FTP zeigte mir, dass unter der alten Version das seitenweise Navigieren funktionierte. Spielte ich das Update (Release 0.1.2) auf, war der Fehler wieder vorhanden.

Advanced Permalinks verwende ich, seitdem ich die Permalink-Struktur verändert habe und war bisher auch ganz glücklich mit diesem Plugin.

Ich finde es sehr schade, dass es nun so problembehaftet ist und so teilte ich den Bug in der Plugin Directory auf WordPress.org mit. Ich war schon ein wenig erstaunt – aber auch fast beruhigt, dass ähnliche Beiträge bereits vorhanden waren.

Nachdem ich das Plugin deaktiviert hatte, die Pagination klappte, das Feed-Abonnement und der Abruf über dlvr.it wieder möglich war, testete ich, ob ältere Beiträge trotz neuer Permalinkstruktur auf meinen Blogs über die Google-Suche erreicht werden. Und siehe da … ich gelange nun auch ohne Plugin auf die richtigen Beiträge.

Scheinbar hat dessen eineinhalbmonatige Einsatz ausgereicht, damit Besucher nun nicht mehr fehlgeleitet werden oder sehe ich das falsch?

Ähnliche Beiträge:

• Gute Nachrichten – mit Jamendo geht es wieder bergauf
• Jamendo – wie geht es nun weiter?
• Social Media-Buttons – mein Tipp für Joomla 1.6 ist ITPShare
• Fuchs wird zur Schnecke – wenn der Firefox-Start lahmt
• Vollanzeige der Kommentare im Backend – Plugin Full Comments

Wie heißt es doch so schön? “Klicke niemals ohne vorherige Prüfung auf einen getwitterten Kurzlink von jemandem, den Du nicht kennst.”

Klar hätte es mich schon stutzig machen müssen, dass mich jemand direkt erwähnt, der noch nicht einmal Follower ist.

Wie es anfing

In TweetDeck sah ich, dass mich jemand erwähnt hatte – erkennbar unter “Mentions”.

Normalerweise schaue ich mir bei unbekannten Twitterern den Link etwas genauer an.

Bei erstem Klick darauf erscheint zum Beispiel in TweetDeck ein Fenster, der den Kurzlink aufschlüsselt. (Anmerkung: hierbei handelt es sich um ein Beispiel und nicht um den vorgenannten Link)

Meist schaue ich mir aber solche Links auf der Twitterseite im Browser an, denn durch das Firefox-Addon PowerTwitter werden Links durch das Anzeigen des jeweiligen Favicon (falls eingerichtet) und des Beitragstitels visualisiert.

Gut … normalerweise geh ich so vor , aber dieses eine Mal eben nicht. Und kaum auf den Link geklickt, öffnete sich mehrfach das Kaspersky-Warnfenster in der Taskleiste. Erkennen konnte ich das Wort “download”, da aber ein Fenster nach dem anderen in rasender Geschwindigkeit aufpoppte, konnte ich auf die Schnelle gar nicht erfassen, was genau an Text darin angezeigt wurde.

Meine Reaktion

So schnell wie möglich verließ ich die Seite und ging einen Moment in mich.
Einerseits habe ich zwar Kaspersky vertraut und hoffte, dass alles geblockt wurde, wollte aber doch lieber auf Nummer sicher gehen. Daher startete ich eine komplette Untersuchung meines Computers.

Ende gut, alles gut

Und siehe da, meine Internetsecurity wurde doch noch fündig:

Interessant fand ich die Tatsache, dass sich dieser Trojaner in die footer.php von Template-Dateien eingeschleust hatte, die sich lediglich in einem Download- bzw. Dokumente-Ordner befanden. Diese Templates verwende ich aber nicht aktiv auf meinen Seiten – Gott sei Dank.

Vielleicht habe ich es ja dem schnellen Verlassen der Seite zu verdanken, dass er sich nicht in meinen gesicherten FTP-Dateien meiner aktiven Blogs einnisten konnte. Nach den ersten Fundmitteilungen habe ich die betroffenen Dateien – also die kompletten Templates – sowohl auf meinem Notebook als auch meiner externen Festplatte, die ich zur Datensicherung verwende, gelöscht.

Eine erneute Kontrolle ergab, dass sämtliche Trojaner nun tatsächlich entfernt wurden. Einen Blick in die Webmaster-Tools, ob sich nicht doch noch über irgendwelche Umwege Malware auf meine Seiten gemogelt hat, lässt mich auch (erst einmal) beruhigt aufatmen.

Fazit

Auf jeden Fall hat mich dieser Zwischenfall ordentlich wachgerüttelt und ich werde wohl künftig lieber einen Link weniger als einen zu viel anklicken.

Ähnliche Beiträge:

• Wenn Addons nach Update von Firefox und Thunderbird inkompatibel sind
• 7 Dinge, die mich an Facebook nerven
• Wie editiere ich Beiträge?
• Urlaub und Blog – passt das zusammen?
• Adminbar wurde nach WordPress Update nicht richtig angezeigt

Was mir besonders gut an diesem Programm gefällt ist, dass Screenshots schon vorab per Konfiguration “aufgepeppt” werden können. Wenn ich bei “Schnappschuss hat Schatten” ein Häkchen setze, wirken die Bilder plastisch und nach meinem Empfinden auch sehr hochwertig.

Ich bin absolut begeistert, von den vielfältigen Möglichkeiten der nachträglichen Bildbearbeitung bei Ashampoo Snap 5. Ich kann darin bestimmte Bereiche eines Screenshots hervorheben,  in den unterschiedlichsten Form- und Farb-Variationen mit Pfeilen und Texten versehen, Stellen markieren und/oder verpixeln, ins Rampenlicht stellen, Nummerierungen einfügen und und und …

Nun könnte man sagen, das leisten andere Programme auch, aber die Bearbeitungsmöglichkeiten bei Snap 5 sind äußerst vielfältig und die Effekte wirken zudem sehr edel.

Nach der Bildschirmaufnahme erscheint die Arbeitsoberfläche, von der ich das Bild unter anderem direkt auf Facebook posten kann.

Die Videofunktion

Für meine Tutorials ist eine Videofunktion natürlich unverzichtbar. Ashampoo hat bei diesem Programm dazugelernt und die letzte Version nicht nur ordentlich nachgebessert, sondern auch um einige Funktionen erweitert. Nachdem es mir aufgrund einer fehlenden Pausetaste an meinem Notebook in der Vorversion nicht möglich war, problemlos eine Aufnahme zu stoppen, hatte ich mich an den Support gewandt und ihm mein Anliegen geschildert.
Der Vorschlag, ähnlich wie bei ScreenCapturer eine Konfigurationsmöglichkeit anzubieten, in der Funktionen mit Tastenkombinationen belegt werden können, wurde tatsächlich in der Folgeversion umgesetzt.

Toll finde ich auch die angebotenen Effekte während einer Aufnahme.

Ich habe die Möglichkeit, eine anvisierte Stelle heran zu zoomen oder bei Betätigung eines Mausklicks diese Aktion optisch durch einen farblichen Spot hervor zu heben. Ein nettes Zusatzfeature hierbei ist, dass ich die Darstellung des Spots vorher auch noch einstellen kann. (Diesen Screenshot über die Videoeinstellungen musste ich allerdings mit IrfanView erstellen. )

Eine Software-Dokumentation könnte zum Beispiel so aussehen:

Sobald ich die Aufnahme stoppe, wird auch hier die Arbeitsoberfläche anzeigt, in der ich mich nun entscheiden kann, was mit ihr geschehen soll. Neben dem normalen Abspeichern oder Versenden per E-Mail wird nun noch das direkte Hochladen des Videos auf YouTube angeboten.

Einen kleinen Wermutstropfen gibt es bei diesem Programm: das Abfotografieren einer längeren Webseite funktioniert immer noch nicht einwandfrei. Getestet habe ich es im Firefox, Chrome und Internetexplorer. Das Bild wird mittendrin abgeschnitten. Daher verwende ich für Screenshots kompletter Webseiten das Firefox-Addon FireShot.

Ashampoo Snap 5

Anbieter: Ashampoo

Software-Typ: Screenshotprogramm mit Videofunktion

Preis: 19,99 € (es lohnt sich allerdings immer mal wieder auf Sonderangebote von Ashampoo zu achten. Derzeit wird es zu einem Schnäppchen-Preis von 15,00 € angeboten.)

Weitere empfehlenswerte Screenshotprogramme

• Programm Ashampoo Snap 4  – Vorversion (kostenlos)
• FireShot: kostenloses Addon für Firefox, Google Chrome, Internet Explorer und Seamonkey. Hier sind allerdings nur Bildschirmaufnahmen im Browser möglich, ohne Videofunktion
• Free Screen Capturer: Kostenloses Screenshotprogramm mit Videofunktion

Ich wünsche Euch nun viel Spaß bei Euren Foto- und Videodokumentationen!

Ähnliche Beiträge:

• Dell Notebook Studio 1745 und die fehlende Pause/Break-Taste
• Software-Tipp Teil 2: Warum ich auf mp3DirectCut nicht verzichten möchte
• Neues Outfit für meinen Blog
• Bearbeitung von Avataren – Teil 1: Avatare verkleinern
• Riot – kleines Tool mit großer Wirkung

Nun bin ich immer auf der Suche nach Möglichkeiten, Plugins durch manuelle Umsetzungen zu ersetzen. Und so bin ich auf einen schönen Beitrag von Hecht MediaArts gestoßen, in dem wunderbar erklärt wird, wie Codes in Beiträgen nicht nur manuell umgesetzt sondern auch schön dargestellt werden können.

Ich hatte es umgesetzt, für gut befunden und trotzdem bin ich wieder zu dem Plugin SyntaxHighlighter Evolved zurückgekehrt. Warum?

Ich würde wohl doch eher die manuelle Methode verwenden, wenn ich nur hin und wieder einfache Codes in meinen Beiträgen darstellen würde. SHE ist schon ein mächtiges Plugin und wenn ich mir meinen Seitenquelltext anschaue, werden eine Menge an JavaScripten geladen. Auch eine Überprüfung bei PingdomTools ergab, dass die Seite schneller lud, als ich das Plugin entfernt hatte. Andererseits schwanken dort die Ergebnisse oftmals sehr.

Wie ich es umgesetzt hatte, möchte ich ein wenig beschreiben, denn es ist wirklich eine tolle Alternative.

Umsetzung der Funktion

Den Eintrag in der functions.php habe ich genauso wie im Beitrag beschrieben übernommen. Das heißt, eigentlich habe ich diese Funktion als Modul in dem Plugin Toolbox von Sergej Müller angelegt.

Dieses Plugin bietet den Vorteil, dass einerseits die functions.php nicht unendlich lang und unübersichtlich wird. Außerdem brauche ich nur das entsprechende Modul einfach deaktivieren, falls ich eine Funktion nicht verwenden möchte. Ich muss das entsprechende Script dann nicht umständlich in der functions.php suchen und herauslöschen.

Das Modulscript sieht dann so aus:

<?php
/*
Module Name: Codedarstellung
Description: Stellt Code im Beitrag dar [Frontend]
Author: Sergej Müller
Author URI: http://ebiene.de
*/

/* Sicherheitsabfrage */
if ( !class_exists('Toolbox') ) {
	header('Status: 403 Forbidden');
	header('HTTP/1.1 403 Forbidden');
	exit();
}

function pre_esc_html($content) {
  return preg_replace_callback(
    '#(<pre.*?>)(.*?)(</pre>)#imsu',
    create_function(
      '$i',
      'return $i[1].esc_html($i[2]).$i[3];'
    ),
    $content
  );
}

add_filter(
  'the_content',
  'pre_esc_html'
);

Dieses Script – ich habe es mal code_darstellung.php genannt -  habe ich dann in dem Verzeichnis modules des Plugins toolbox abgespeichert. Die entsprechende Funktion erscheint dann automatisch unter den Einstellungen zu diesem Plugin.

Umsetzung per CSS

In dem Beitrag von Hecht MediaArts wurde auch schon ein Code vorgestellt, der in die style.css des Themes eingefügt werden kann. Gefiel mir auch schon ganz gut, aber dadurch wurde das Element mit schlichtem grauen Hintergrund dargestellt. Ich wollte aber einen Hintergrund mit weiß-hellgrauen Streifen und damit ein wenig den Hintergrund von SyntaxHighlighter-Plugins simulieren.

Dafür habe ich den Stripe Generator verwendet, mit dem ich ganz einfach einen entsprechenden Hintergrund erstellen und als png-Datei herunterladen konnte.

Den css-Code habe ich für Beiträge und Kommentare unterschiedlich angelegt. Für die font-size- und line-height-Befehle habe ich deswegen em-Werte bis zu drei Stellen hinter dem Komma ausgewählt, damit die Codezeilen in etwa auf dem gestreiften Hintergrund angepasst dargestellt werden.

CSS für Beiträge

pre {
background:url("http://www.extern.sylvis-blog.de/images/grey_white2.png") repeat scroll left top;
padding:15px 0px 15px 5px;
border: 3px ridge #5F5F5F;
overflow: auto;
margin: 0 0 15px 0;
width: 590px;
font-family: Courier, Monospace;
line-height:1.353em;
font-size:0.9em;
}

Und sieht dann so aus:

Die Werte sorgen unter anderem dafür, dass bei längeren Codezeilen ein Scrollbalken erscheint.

CSS für Kommentare

.commentmet_text pre {
background:url("http://www.extern.sylvis-blog.de/images/grey_white2.png") repeat scroll left top;
padding:1px 0 11px 5px;
border: 3px ridge #5F5F5F;
overflow:auto;
width:400px;
font-family: Courier, Monospace;
line-height:1.39em;
white-space:pre-wrap;
}

Und sieht dann z. B. so aus:

Ich habe hier eine geringere Breite für die Darstellung gewählt. Außerdem soll die Codezeile am Ende umbrochen werden. Den Tipp habe ich übrigens von Tanja aus ihrem Beitrag Code in WordPress Artikel einfügen und richtig darstellen.

Nach der Umsetzung

Als ich alles manuell umgesetzt hatte, fielen mir dann doch einige Nachteile dieser Methode auf. Einige Codes werden einfach nicht richtig dargestellt.

Hier mal zwei Beispiele:

In meinem Beitrag Jetzt gefällt mir auch der valide “gefällt-mir”-Button wird der mit SyntaxHighligther Evolved korrekt angezeigte Code bei der manuell umgesetzten Methode nicht als Code umgesetzt sondern direkt ausgeführt. Aus

<iframe style="overflow: hidden; width: 380px; height: 80px;" src="http://www.facebook.com/widgets/like.php?href=&lt;?php the_permalink();?&gt;&amp;t=&lt;?php the_title();?&gt;&amp;send=false" frameborder="0" scrolling="no" width="320" height="240"></iframe>

wurde plötzlich.

Während ich diesen Beitrag schreibe, probiere ich in meinem Testblog weiter aus, diesen Code einzufügen und siehe da …

… plötzlich funktioniert es. Anfangs dachte ich, ich spinne. Warum wird der Code nun richtig dargestellt?

Und dann fiel es mir ein. Ich hatte bei dem oberen Screenshot genau den Code per copy & paste aus dem Originalbeitrag kopiert und in den pre-Code eingefügt.

Bei der unteren Variante hatte ich den Code aus dem Testblog verwendet, der noch mit allen Sonderzeichen dargestellt wurde – also statt “<” war ein “&lt;” im Code enthalten.

Aber mal ganz ehrlich, das finde ich dann doch zu umständlich, für eine korrekte Darstellung sämtliche Sonderzeichen für Klammern und Leerschritte herauszusuchen. Ich beherrsche sie leider nicht aus dem effeff.

Ein weiteres Beispiel, bei dem ein Code nicht korrekt dargestellt wurde und zwar hier:

Aus                                                                               wird

Zur Not könnte ich Codes zwar auch in eckigen Klammern darstellen und eine Erklärung mitliefern, aber schön ist das natürlich nicht.

Fazit

Daher habe ich mich doch erst einmal dafür entschieden, weiterhin das Plugin zu verwenden. Hier noch einmal die Punkte die dafür sprechen:

1. Alle Arten von Codes werden richtig dargestellt.
2. Darstellung der Codes kann individuell und einfach angepasst werden.
3. Schöne unterschiedliche Farbdarstellung der jeweiligen Werte.
4. Mit dem Zusatzbutton im TinyMCE Advanced-Editor ist das Einfügen eines Codes auch in der WYSIWYG-Ansicht kinderleicht zu bewerkstelligen.
5. Besonders gut gefällt mir das Hervorheben bestimmter Zeilen – gerade dann, wenn ich die Unterschiede zweier Codes dokumentieren möchte.
6. Auch die Zeilennummerierung kann individuell angepasst werden.
7. Sehr besucherfreundlich, wenn die Toolbar aktiviert ist, um Codes zu kopieren.

Ihr seht, da sprechen schon einige und für mich sehr wichtige Punkte dafür, dass ich SyntaxHighlighter Evolved weiterhin verwenden möchte. Ich habe einige “Konkurrenten” ausprobiert, aber ich halte es nach dem derzeitigen Stand einfach für unschlagbar.

Und wem es darin ein Zuviel an Scripten ist, kann diese ja gegebenenfalls noch ein wenig reduzieren.

Ähnliche Beiträge:

• JavaScript komprimieren – ganz einfach mit JSmin und Notepad++
• Bye, bye Articles und WP-PageNavi
• Meist gelesene Beiträge ohne Plugin in Sidebar anzeigen
• Mehr Spritzigkeit mit CSS Sprites?
• Weiterlesen jetzt auf Knopfdruck und per CSS

Momentan verwende ich das Plugin Editable Comments, da dieses im Gegensatz zu Edit Comment XT auch mit verschachtelten Kommentaren klarkommt.

Auf diesem Blog funktioniert es auch einwandfrei. Aber ein Besucher meiner bunten Blogwelt teilte mir mit, dass die Buttons für ein Update bzw. Abbruch nicht richtig angezeigt wurden.

Daraufhin nahm ich in der Konfiguration des Plugins den Haken bei der Java-Script-Ausgabe heraus, so dass sich statt eines Popup-Fensters nun eine neue Seite bzw. neuer Tab zum Editieren öffnete. Um die Fehlersuche wollte ich mich später kümmern.

Stutzig machte mich nur, dass die Update-Funktion als Button, die Abbrechen-Funktion aber nur als Link angezeigt wurde.
Ein kurzer Test zeigte mir, dass ein Editieren wohl trotzdem einwandfrei möglich war.

Nun informierte mich netterweise Daniel darüber, dass bei ihm die Editierfunktion in der bunten Blogwelt Probleme bereitete. Also beschloss ich, mich endlich auf Fehlersuche zu begeben. Mich wunderte allerdings, dass es mit dem Plugin hier auf diesem Blog kein Problem gab.

Nachdem ich ein wenig recherchiert hatte, vermutete ich ein Javascript-Problem und stellte fest, dass im Seitenquelltext kein Eintrag

<script type="text/javascript" src="<?php bloginfo('stylesheet_directory'); ?>/js/jquery.min.1.2.6.js"></script>

existierte. Daher versuchte ich, durch Einfügen dieses Script-Codes an unterschiedlichen Stellen – mal in der header.php, mal in der footer.php des Themes den Fehler zu beseitigen. Vorher hatte ich noch die Javascript-Datei jquery.min.1.2.6.js in mein Theme-Verzeichnis eingefügt.
Dieser Eingriff bewirkte zwar, dass der Abbrechen-Button nun nicht mehr als Link, sondern als richtiger Button angezeigt wurde. Dafür war er aber funktionslos.

Gut, ein Javascript-Problem habe ich dann erst einmal ausgeschlossen und richtete daher den Focus auf die Datei style.css in meinem Theme.
Ein kleines Versehen bestärkte mich dann auch in meiner Vermutung, dass es sich um einen CSS-Eintrag handeln musste, der diesen Fehler verursachte. Im Eifer des Gefechts hatte ich irrtümlich die style.css dieses Blogs in das Verzeichnis der bunten Blogwelt hochgeladen. Ich bemerkte es erst gar nicht und freute mich schon, dass sich das Script-Fenster öffnete und die beiden Buttons einwandfrei angezeigt wurden … bis ich das verschobene Templatedesign bemerkte.

Was war schuld?

Problem also erkannt, aber welcher Eintrag war denn nun für die Fehlanzeige verantwortlich? Eine Kontrolle mit Firebug zeigte mir, dass es sich um irgendeinen Befehl mit dem Wort “input” oder/und “check” handeln musste.

Also habe ich erneut die style.css nach diesen Begriffen abgesucht und einen Code-Block gefunden, in dem ich den Fehler vermutete. Als ich diesen komplett entfernt hatte, klappte es mit der Javascript-Anzeige einwandfrei. Ich wollte aber nun wissen, welche Zeile genau für diesen Bug verantwortlich war und nach Wiedereinfügen des Blocks und zeilenweise Entfernen kam ich dem Verursacher auf die Spur. Es handelt sich um folgenden Eintrag:

input.checkbox{cursor:default;background:transparent;color:#bcbab7
;border:0;padding:0;margin:0;width:14px;height:14px}

Ich weiß nicht genau, wie dieser Eintrag dort entstanden ist. Es ist gut möglich, dass im Rahmen einer CSS-Optimierung durch Free CSS Toolbox eine Verschiebung der Befehle und somit den Bug verursacht hat.

Nun berichtete Daniel unter anderem noch von einem Caching-Problem. Bei ihm wurden nicht alle drei Kommentare eines Beitrages angezeigt, die bereits seit längerer Zeit online waren. Ich hoffe, dass dieses damit nun auch beseitigt ist, bitte Euch aber um Rückmeldung, falls Eure Kommentare nicht gleich erscheinen sollten.

Ähnliche Beiträge:

• Nachträgliches Editieren von Kommentaren – auf meinem Blog nun möglich
• Editable Comments hat wieder Einzug gehalten
• Jetzt gefällt mir auch der valide “gefällt-mir”-Button
• Vollanzeige der Kommentare im Backend – Plugin Full Comments
• Korrektur der Hinweisanzeige über geschlossene Kommentare

Leider gibt es bei der versteckten Umsetzung einen Nachteil: nach dem Einloggen lande ich immer auf meiner Profilseite. Egal was ich als Umleitungsadresse im Anmelde-Modul eingestellt habe, bewirkt diese Funktion leider bei der Auswahl der Zugriffsebene “Spezial” gar nichts.

Nur noch einmal zur Demonstration. So sah meine Startseite kurz nach meinem Frontend-Login per verstecktem Modul aus:

Nach fast endloser Recherche bin ich heute plötzlich auf einen Forenbeitrag gestoßen, der mich nicht nur bei meinem Problem weitergebracht hat, sondern letztendlich der Schlüssel für die Lösung war. Und das Tolle bei dieser Umsetzung ist, es ist supereinfach!

Im Beitrag des Forenautors sollte die Umleitung zwar umgekehrt erfolgen – also genauso wie ich es eben nicht wollte. Aber letztendlich musste ich nur die Urls nach meinen Umleitungswunsch ändern.

So sieht der Eintrag aus, den ich in die .htaccess im Hauptverzeichnis meiner Joomla-Installation eingefügt habe:

Redirect permanent /component/users/profile.html http://www.sylvis-bunte-seite.de

Im vorderen Teil des Redirects steht das Ziel (/component/users/profile.html), wohin ich immer kurz nach dem Login ungewollt umgeleitet wurde, nach dem Leerschritt steht meine Webseiten-Url (http://www.sylvis-bunte-seite.de) die gleichzeitig auch meine Startseite ist und nun das Ziel sein soll. Ich habe diesen Code einfach ziemlich weit oben in Zeile 9 kurz nach dem Lizenzkommentar eingetragen.

Nun werde ich endlich nach der Anmeldung wie gewünscht direkt auf die Startseite umgeleitet.

Viel Spaß beim Ausprobieren!

Ähnliche Beiträge:

• Modul vor Besuchern verstecken
• Anzeige von Fehlerseiten nach Änderung der php-Version bei Strato beheben
• Anzeigeeinstellung von Kommentaren in Modul bei yvComment
• SyntaxHighlighter Evolved vs. manuelle Umsetzung von Codes in Beiträgen
• Facebook: Favoriten ganz einfach anlegen, entfernen und sortieren