Und so sieht der Codeschnipsel bei uns aus, der in ein Seitentemplate (page.php) eingefügt und als tagcloud.php neu abgespeichert wurde:

• <?php if ( function_exists(‘wp_tag_cloud’) ) : ?>

• <?php wp_tag_cloud(’smallest=8&largest=22&format=flat&orderby=name&order=ASC&number=0′); ?>

• <?php endif; ?>

Über “smallest” und “largest” wird die Gewichtung der Tags bestimmt, oft vergebene Tags erscheinen so grösser.
Über “orderby” und “order” wird bestimmt, nach welchen Kriterien die Tags sortiert werden sollen, hier z.B. nach Alphabet in aufsteigender Reihenfolge.
Über “number” wird schliesslich die Anzahl der auszugebenden Tags festgelegt. Ist hier nichts eingetragen, oder fehlt “number” komplett, werden standardmässig 45 Tags ausgegeben, sollen alle Tags ausgegeben werden, einfach eine 0 eintragen.
Mehr Informationen über die verwendbaren Parameter findet ihr hier, für eine einfache Tagwolke reichen die Angaben oben jedoch allemal aus.

Nach dem abspeichern die Datei ins benutzte Theme hochladen und eine neue (leere) Seite erstellen, in der als Seitentemplate die tagcloud.php verwendet wird.

Schon fertig? Nicht ganz, das alte Plugin muss natürlich deaktiviert werden, sonst kommen sich einige Tags wohl gegenseitig ins Gehege und führen zu Fehlerseiten.

Warum man das überhaupt machen sollte? Damit man potentiellen Einbrechern die Sicherheitslücken nicht auch noch auf dem Silbertrablett präsentiert.

Am besten sollte man den Generator-Tag ja ganz rausnehmen, und auch auf alle öffentlich im Fuss der Seite ersichtlichen Angaben zur Software verzichten, um so wenig Angriffsfläche wie möglich zu bieten.
Nun kann man den Entwicklern trotzdem ihre Credits zukommen lassen und den Generator-Tag drinlassen, aber die genaue Versionsnummer muss da nun wirklich nicht stehen.

Genau das wird aber für die eher unbedarften Wordpress-Nutzer mit Version 2.6 quasi erzwungen, denn die Angaben dazu wurden nun im Code der general-template.php untergebracht. Dort stehen sie ganz am Ende und können zumindest um die Versionsnummer “erleichtert” werden.

Verrückt, entweder kennt sich da eine/r überhaupt gar nicht mit der Blogosphäre und mit dem Textgewerbe aus, oder er kennt sich aus und versucht, so unliebsame Konkurrenten loszuwerden (deshalb das ? hinter dem Angebot des Auftraggebers, obwohl dies nach etwas Recherche eher nicht stimmen dürfte).

Dann will ich mal die Politik unseres Blogs – und die der meisten Blogs, die ich kenne – vorstellen: werbende Kommentare werden komplett gelöscht, solange sie nur Werbemüll enthalten, mindestens jedoch wird der Link zur Website des Werbers entfernt, öfter wird auch eine Rechnung für die unerwünschte Werbung gestellt.

Liebe Möchtegern-SEOs, denkt doch vorher lieber ein paar Minuten nach, bevor ihr euer Unternehmen mit so einer billigen Aktion sehr schnell in Misskredit bringt …

(Nein, ich verlinke nicht auf das Angebot, das im übrigen noch ohne Gebot dasteht; wer mag, kann dies bei MyHammer selbst suchen.)

Und manchmal klappt auch das automatische Update von Plugins nicht, dann wird zwar das alte Plugin rausgeschmissen bzw. gelöscht, aber das neue nicht installiert. Da heisst es dann doch wieder, selbst Hand anzulegen.

Sie müssen über eine angemessene Datenschutzrichtlinie verfügen, die eindeutig darauf hinweist, dass Dritte, im Zuge der Anzeigen, die auf Ihrer Website geschaltet werden, Cookies auf den Browser Ihrer Nutzer platzieren und auslesen oder Web Beacons zur Sammlung von Informationen verwenden können.

Was sind eigentlich Web Beacons? Egal, was Cookies sind, wissen wir hoffentlich alle, dennoch müssen wir es dem Leser, der Leserin also noch einmal ausführlich erläutern. Wer schon über eine laut Telemediengesetz sowieso geforderte Datenschutzerklärung verfügt (kostenlos verwendbares Muster gibt es z.B. hier), kann den Absatz zu Cookies am einfachsten ergänzen, denke ich, einen beispielhaft formulierten Text findet man z.B. hier.

Bei der Gelegenheit möchte ich auch mal darauf hinweisen, dass alle, die Google Analytics einsetzen, schon immer (oder zumindest schon lange) verpflichtet sind, eine entsprechende Erklärung zur Verwendung von Cookies zu veröffentlichen (siehe hier unter Punkt 8 ).

1. temp.linkaktuell= CONTENT
2. temp.linkaktuell {
3. wrap = <div class=”linktipp”><h2>Aktueller Linktipp</h2>|</div>
4. table = tx_ablinklist_link
5. select {
6. pidInList = 5
7. where = status=1
8. orderBy = uid DESC
9. max = 1
10. }
11. renderObj=COA
12. renderObj{
13. 10 = TEXT
14. 10.field = label
15. 10.typolink.parameter.field = href
16. 10.wrap = <p>|<br />
17. 20 = TEXT
18. 20.field = description
19. 20.wrap = |</p>
20. }
21. }

Zeile 5: Abfrage mit Typoscript erstellen
Zeile 6: Nummer des Sysordners mit den Link-Datensätzen
Zeile 7: Nur freigeschaltete Links auswählen
Zeile 8: Den neuesten Link auswählen
Zeile 9: und nur einen!
In den übrigen Zeilen wird der Link (Feld href enthält den URL, Feld label den angezeigten Linktitel) und die Beschreibung (Feld description) ausgegeben. Fertig!

• Meine Überschrift
• Sie befinden sich hier: Kontakt >> Impressum
• Und jetzt kommt der erste Absatz des Seitentextes

Generiert man in TYPO3 die H1 der Seite aus der Überschrift des ersten Textelements, hat man jetzt ein Problem, da man hier nicht einfach einen Platzhalter für das Menü anlegen kann. Und so klappt es doch:

1. temp.breadcrumb = HMENU
2. temp.breadcrumb {
3. wrap = <p>Sie sind hier:  |</p>
4. special = rootline
5. special.range = 1|-1
6. 1 = TMENU
7. 1 {
8. NO {
9. allWrap = |*| |&nbsp;&gt;&gt;&nbsp; |*||
10. }
11. CUR = 1
12. CUR.doNotLinkIt = 1
13. }
14. }
15. lib.stdheader.10.1 = COA
16. lib.stdheader.10.1 {
17. 20 = TEXT
18. 20.current = 1
19. 20.insertData = 1
20. 20.fontTag = <h1>|</h1>
21. 30 < temp.breadcrumb
22. }

Zeile 15: Das Standardtyposcript für die H1-Überschrift wird in ein COA umgeschrieben, in Zeile 21 das Breadcrumb-Menü eingefüllt.

Darüber haben sicher schon viele Entwickler geschrieben: Die passende Testumgebung möglichst mit freien Tools zusammenzustellen. Ich mache das mal als eigene Gedächtnisstütze und für die, die es brauchen können .

• Entwicklerleiste
  Die Entwicklerleiste ist inzwischen standardmäßige im FF vorhanden.
  Sie enthält diverse Validatoren, CSS-Editor, Browser-Verkleinerer, Funktionen zum Ausblenden von CSS, Bildern, Leeren von Cache und Cookies u.v.m. Einige Funktionen lassen sich nach Bedarf anpassen.
• DOM Inspector
  Ist ebenfalls bereits im FF enthalten, muss aber bei der Installation im Modus “benutzerdefiniert” über die Checkbox aktiviert werden.
  Der Inspector ist ein mächtiges Tool zur Analyse der Seitenstruktur samt der enthaltenen Elemente (DIVs, H1-6, p, img usw.). Neben den Elementen werden jeweils die CSS-Eigenschaften angegeben. Darüber hinaus lassen sich Elemente entfernen oder CSS-Angaben verändern und life anzeigen. Verschiedene Szenarien können damit direkt ausprobiert bzw. Styles auf Machbarkeit geprüft werden. Ein Einsteiger-Tutorial in deutsch gibt’s bei stichpunkt.de.
• IE Tab und Launchy
  sind brauchbare Plugins für den Browser-Test. IE Tab zeigt die aktuelle Seite mit der jeweils installierten IE-Browser-Engine direkt in FF an. Auch lässt sich festlegen, ob bestimmte Seiten immer per IE Tab aufgerufen werden sollen. Das ist dann interessant, wenn Zugriffe auf die Seite (Formulare, Web-Editoren etc.) nur für den IE optimiert sind. Launchy startet sonstige Browser und Programme, die auf dem Rechner installiert sind. Welche Programme das sein sollen, lässt sich konfigurieren. Beide Aktionen werden jeweils über die rechte Maustaste in der aktuellen Seite aufgerufen.
• Measure-It und Colorzilla
  sind sehr hilfreich, um die angezeigte Webseite zu vermessen bzw. Farbwerte zu kontrollieren. Bilder, Div-Boxen, Schrifthöhen oder Abstände zwischen den Elementen einer Webseite lassen sich mit Measure-It abmessen, allerdings nur in Pixelwerten. Die Pipette von Colorzilla gibt den Hex-Wert der angesteuerten Farbe aus.
• Flash-Switcher
  finde ich ein tolles Tool, denn damit kann ich ältere Versionen des Flash-Players simulieren oder das Plugin deinstallieren. Ich muss nicht mehr verschiedene Plugin-Versionen in meinem Browsern vorhalten, sondern kann Browserweichen und Alternativ-Texte bequem über den Switcher testen.
• HTML Validator (CSE HTML Validator)
  Das Validator-Plugin benötigt die CSE HTML Validator-Engine zur Anzeige von Skriptfehlern, Zeilennummern oder CSS-Hinweisen. Neben dem FF-Plugin muss daher zusätzlich der CSE-Validator auf dem Rechner installiert sein. Ruft man den Quellcode auf, erhält man detaillierte Fehlerhinweise.
• Fangs
  ist hilfreich bei der Erstellung barrierefreier Seiten. Es simuliert den Leseablauf eines Screenreaders. In der Hauptansicht zeigt es die Abfolge der Überschriften (h1-h6), gibt Links an und kennzeichnet vorhandene Sprachwechsel. In zwei weiteren Reitern werden a) alle genutzten Überschriftenformate in der vorhandenen Reihenfolge und b) Linktexte angezeigt. Damit lässt sich leicht überprüfen, ob H-Formate ordnungsgemäß geschachtelt sind und Links sprechende Bezeichnungen haben oder diese evtl. doppelt vorkommen.
• Greasemonkey
  Mit Greasemonkey lassen sich alternative Stylesheets managen und auf die angezeigte Seite anwenden. Das ist hilfreich bei der Entwicklung barrierefreier Seiten, um die Auswirkung von nutzerdefinierten Styles (bestimmte Farbwelten oder größere Schriften) auf das eigene CSS-Arangements zu zeigen. Auch ein Styleswitcher lässt sich so lokal ohne Server simulieren.
• Firebug
  Und dann gibt es noch Firebug. Dieses Tool legt gegenüber dem DOM-Inspector noch ein paar Funktionen drauf. Damit lassen sich nicht nur HTML, CSS und Javascript inspizieren, man kann seine Skripte damit auch editieren und debuggen. Die Anzeigefunktionen sind zudem komfortabler als im DOM-Inspector. Allerdings musste ich mich erstmal einarbeiten, was ich bisher noch nicht wirklich geschafft habe.
  Aber es gibt auch dafür einige hilfreiche Tuts z.B.:
  • www.photoshop-screencast.de/tutorials/firebug.mov
  • www.digitalmediaminute.com/article/2157
  • bueltge.de/firefox-add-on-firebug-fuer-webentwickler-ein-muss/294/

Klar gibt es noch mehr Tools. Aber das sind für mich die wichtigsten und es soll ja auch übersichtlich bleiben in der Testumgebung .

Grundsätzlich finde ich es ja nicht schlecht, dass man als Werbeplatzanbieter/-in doch noch etwas Einfluss nehmen kann. Stellt sich allerdings die Frage: Hat das schon jemand ausprobiert und funktioniert es besser als die normalen Adsense-Anzeigen?

Wie beispielsweise Add Meta Tags, mit dem individualisierte description und keywords als custom fields eingegeben und im Seitenkopf ausgegeben werden können. Sehr nützlich, die Anzeige klappt aber ohne wp_head() nicht. Intriganterweise merkt man davon nichts, weil das Plugin voll funktionsfähig im Wordpress-Backend erscheint und die Meta-Tags auch eingegeben werden können. Also hinein mit wp_head() in die header.php des Templates!
Hat man dieses Codesnippet wieder eingebunden, kann es andererseites passieren, dass man sich bisher unbemerkte weitere Funktionen lädt, die man eigentlich garnicht braucht. Ich hatte gerade das Kontaktformular aus dem Dagon Design Form Mailer gestyled, doch das Plugin schob mir jetzt ein eigenes Stylesheet unter. Wem das auch passiert: so läßt es sich durch Auskommentieren im Code des Plugins entsorgen:
/* add_action(‘wp_head’, ‘ddfm_add_css’);*/