Sidebar
ein-/ausblenden

10 Punkte zum perfekten WordPress Theme

Plugin für WordPress SEO

Anzeige

WP Logo

So der Titel eines Beitrags von Joost de Valk, den ich so aber nicht stehen lassen würde, denn einige Punkte sind doch zu starr und sollten durch den Autor im Vorfeld berücksichtigt und überlegt werden.
Daher habe ich einfach mal drüber nachgedacht und meine Gedanken und das Vorgehen beim Entwickeln eines neuen Themes in diesem Artikel abgebildet. Ergänzungen und Diskussion ist erwünscht und bereichert in meinen Augen nur den Wert eines solchen Artikels.

Checkliste; prüfe dein Arbeit

  1. Template-Dateien überlegt ?
  2. style.css inklusive der Kommentare ?
  3. Hooks gesetzt ?
  4. Suche notwendig, wenn ja - ist sie vorhanden ?
  5. Widgetfähig ?
  6. Pluginintegration ?
  7. Lesbarer & valider Code ?
  8. Browsertests ?
  9. Trackbacks ?
  10. Title ?

Hintergründe & Informationen zur Checkliste

  1. Welche Template Dateien im Theme?

    WordPress unterstützt eine ganze Reihe von Templates im Theme und zusätzlich kann man diese noch durch diverse Funktionalitäten erweitern.
    Trotzdem und gerade weil man WordPress in den unterschiedlichsten Anforderungen einsetzt, ist es erforderlich im Vorfeld über die notwendigen Templates nachzudenken. Wirklich zwingend ist nur die index.php. Als Empfehlung gilt jedoch, nutze mindestens die

    • index.php
    • header.php
    • footer.php - Wenn es einen Footer-Bereich gibt.
    • sidebar.php - Nur wenn es auch einen extra Bereich gibt, der diesem Template entsprechen würde.
    • single.php - Soll eine alternative Darstellung zur Startseite erstellt werden, dann ist dieses Template pflicht
    • page.php - Wird es statische Seiten geben und unterscheiden sich diese von der Darstellung mit Hilfe der index.php.

  2. Stylesheet inkl. Kommentaranweisung?

    WordPress benötigt eine style.css. Ohne diese Datei inklusiver der folgenden Kommentare, kann WordPress das Theme nicht erkennen und benutzen.
    Diese Datei kann gern auf andere Stylesheet-Dateien verweisen, diese können dann auch in Ordnern sein, in der dann die eigentlichen Anweisungen für das Stylesheet stehen.

    
@charset 'UTF-8';

/*
Theme Name: Basis
Theme URI: http://bueltge.de/basis-theme-fuer-wordpress/411/
Description: Basis style to start a new theme
Version: 0.1
Author: Frank Bueltge
Author URI: http://bueltge.de/
*/

@import url(css/style.css);

  3. Hooks im Theme?

    Eine ganze Reihe von Plugins und auch WordPress selbst greift auf die Hooks im Theme zu. Es sind drei Hooks, die als Minimum im Theme angesehen werden können.

    • In die header.php oder index.php, je nach Aufbau des Themes, gehört: wp_head();. Der Hook muss im head-Abschnitt sein, am besten direkt oberhalb des schließenden head-Tags. 
      
	<?php wp_head(); ?>
    • Ähnlich sollte es einen Hook im Footer-Bereich der Website geben. Daher bietet sich die Implementierung in der footer.php oder index.php an, wenn es keine footer.php gibt.
      Je nach dem, was per Hook implementiert wird, empfiehlt es sich, den Hook innerhalb des Layouts zu haben, also im übergreifenden div. Dies aber nur als Empfehlung, denn das kann man nicht verallgemeinern.

      
		<?php wp_footer(); ?>
	</div>

</body>
</html>
    • Den dritten Hook benötigt man innerhalb der Kommentarmöglichkeit, daher ist er auch nur notwendig ist, wenn es diese Möglichkeit gibt. Dies ergibt sich aber in der Regel durch die Implementierung der Kommentarmöglichkeit und die damit verwendete comments.php. Hier nur der Hinweis, verweist das Theme auf die Möglichkeit der Kommentare (comments_template();) und die comments.php ist nicht vorhanden, dann wird sie aus dem default-Theme gezogen!
      Gibt es also die Möglichkeit der Kommentare, dann ist der Hook do_action('comment_form', $post->ID); unterzubringen. Ich verwende ihn in der Regel unterhalb des textarea. Wichtig ist, er ist innerhalb des form.

      
	<textarea name="comment" id="comment" cols="60" rows="5" tabindex="4"></textarea>

	<?php do_action('comment_form', $post->ID); ?>

	<input name="submit" type="submit" id="submit" tabindex="6" value="<?php _e('Kommentar absenden', 'basis'); ?>" />
	<input type="hidden" name="comment_post_ID" value="<?php echo $id; ?>" />
</form>

    Es kann mehr geben, dann sind sie aber von Plugins zur Verfügung gestellt und sind auch dort bzw. beim Autor des Plugins dokumentiert.

  4. Suche vorhanden?

    Anwender sind es mittlerweile gewohnt, dass eine Suchfunktion vorhanden ist. Nicht immer ist die aber sinnvoll. Setzt man WordPress als kleines CMS ein, ob sinnvoll oder nicht sei hier nicht das Thema, dann ist die Suche nicht immer sinnvoll oder würde die Zielgruppe vor eine Herausforderung stellen.

    Daher gilt, überlege, ob die Suche ein Mehrwert für den Kunden ist. Kannst du diese Frage mit Ja beantworten, dann integriere die Suche auch und verstecke sie nicht vor dem Nutzer.

    Es empfiehlt sich, dass man dann auch ein eigenes Template, die search.php, dafür verwendet und die Ausgabe der Suche mit nützlichen Inhalten versorgt.

    Alternativ kann man eine Open Search - Suche anbieten, die via Add on für diverse Browser zur Verfügung steht und somit können „Poweruser“ der entsprechenden Website direkt aus ihrer gewohnten Umgebung suchen. Wie man das macht, das steht im Tutorial „OpenSearch - Suchfeld für Mozilla und Internet Explorer mit WordPress anbieten“

  5. Ist das Theme widgetized?

    In WordPress gibt es eine Möglichkeit, neue Funktionen in die Oberfläche zu integrieren, ohne manuell in den Code einer Template-Datei eingreifen zu müssen. Das Aktivieren und Positionieren wird per Drag&Drop erledigt. Dies erleichtert dem Anwender das Anpassen des Sidebar an die persönlichen Anforderungen enorm. Diese Technologie nennt man Widget.

    Zum Thema Widgets unterscheide ich für meinen Teil ganz klar, will der Nutzer diese verändern oder ist eine Integration ohne Widget-Funktionalität besser für den Anwender. In der Regel klärt das sich sehr schnell bei einem Gespräch.

    Wird die Funktionalität benötigt, dann sollte das Tutorial von Automattic helfen.
    Im Grunde muss der folgende Syntax in die sidebar.php.

    
<div id="sidebar">
	<ul>
		<?php 	/* Widgetized sidebar, if you have the plugin installed. */
			if ( !function_exists('dynamic_sidebar') || !dynamic_sidebar() ) : ?>

...

		<?php }
		endif; // End Widgets
		?>
	</ul>
</div>

    Zusätzlich muss die functions.php des Theme gefüttert werden.

    
// widget function
if ( function_exists('register_sidebars') )
	register_sidebars(0);

function my_widget_register() {
	if ( function_exists('register_sidebar') ) {
		register_sidebar(array(
			'name' => 'Sidebar',
		'before_widget' => "ntt" . '
<li id="%1$s" class="widget %2$s">',
			'after_widget' => '</li>

',
			'before_title' => "nt" . '
<h3 class="widgettitle">',
			'after_title' => '</h3>

',
		));
	}
}

add_action('widgets_init', 'my_widget_register', 1);

    Es gibt aber eine ganze mehr Möglichkeiten und Anpassungslösungen, so dass man die Widgets viel besser an das Design anpassen kann, aber dies soll hier kein Thema sein.

  6. Plugin-Funktionalitäten integriert?

    Vielen Funktionen und der resultierende Mehrwert werden mit Hilfe von Plugins realisiert. Wenn man dies tut, dann ist es zwingend, dass das Theme die jeweilige Funktion im Vorfeld auf Vorhandensein prüft. Ansonsten kann es zu Problemen kommen, beispielsweise, wenn das Plugin nicht aktiv ist oder bei einem Update sich der Funktionsname ändert.
    Die Prüfung ist leicht implementiert, je nach dem ob man ein Funktion oder Klasse einbindet.

    
if ( function_exists('FUNKTIONS_NAME') ) 

if ( class_exists('KLASSEN_NAME') )

    Näheres dazu wurde auch schon in der Vergangenheit von mir erklärt, siehe Beitrag „Abfrage einer PHP-Funktion, bzw. WP-Plugins“.

  7. Valides, lesbares Markup und CSS

    Auch für WordPress Themes gelten die Richlinien, Webstandards beginnen bei validem Code. Das Prüfen des Themes ist unumgänglich.
    Gutes Design ist sicher wichtig, aber ebenso gehört sauberes und übersichtliches Markup zum Theme. Damit meine ich nicht nur, dass der Validator keine Fehler meldet, sondern auch übersichtlich, strukturiert und lesbares Markup in den Templates. Denke daran, der Code kann von jedem gelesen werden, der Zugriff auf das Theme hat oder über die Oberfläche. Jeder halbwegs versierte User weis, wie man den Code lesen kann.
    Soll das Theme eventuell zum Download angeboten werden, dann ist es um so wichtiger und macht die folgende Arbeit sehr viel angenehmer.
    Sollte das Thema Webstandards in deinem Sprachgebrauch auf Unverständnis stoßen, dann nutze das Web und lerne.

  8. Browsertests ?

    Ohne ein Diskussion zu starten, der Test auf unterschiedlichen Systemen in unterschiedlichen Browsern gehört zu einem guten Theme. Jeder mag zum Thema Browserunterstützung eine andere Sicht haben; ein Mindestmaß an Browsern sollte jedeoch unterstützt werden.

    Bewegt man sich im Umfeld eines Unternehmens oder Intranets, so kann die Auswahl sicher eine andere sein, als wenn man ein Theme für die Community oder eine Kunden im Web schreibt.
    Erstellt man ein Theme nach den Regeln des Webstandards, dann ist man sicher schon auf dem richtigen Weg. Nicht immer ist das aber ausreichend, denn so manche Browser wollen nicht verstehen.

    Als nützliches Hilfsmittel haben sich Webservices wie browsershots.org und diverse Installationen von unterschiedlichen Browsern bewährt. Um das große Problemfeld zu testen, kann man den IETester nur wiederholend empfehlen.

  9. Unterstützung für Trackbacks?

    Als Trackback wird eine Funktion bezeichnet, mit der Weblogs Informationen über Backlinks in Form von Reaktionen bzw. Kommentaren durch einen automatischen Benachrichtigungsdienst untereinander austauschen können.
    Wikipedia

    Soll das Theme Trackbacks unterstützen, dann gehört ein WordPress Template Tag innerhalb des Loop, vor endwhile, auskommentiert für HTML.
    <!-- <?php trackback_rdf(); ?> -->

    Dem entsprechend gehört es also in das Template, welches die Möglichkeit der Kommentare schaft, kann also index.php, single.php oder page.php betreffen.

    Diese Anweisung wird nicht benötigt, wenn an anderer Stelle des Templates auf Trackbacks verwiesen wird. Es ist aber nötig, wenn es keine Ausgabe zu Trackbacks im Template gibt.

  10. Title nutzerfreundlich?

    Der Title des Blog und der jeweiligen Seiten ist ein wichtiges Element und das nicht nur aus der Sicht von Suchmaschinen. Ich wünschte mit manchmal, dass einige Webseiten mehr für den Leser als für die Suchmaschine optimiert werden.

    Ähnlich verhält es sich beim Title-Tag, denn dieser wird auch verwendet, wenn man eine Seite als Favorit ablegt. Es ist also für den Nutzer sehr schön, wenn er nicht in den ersten Zeichen über den Title des Blog, sondern über den Title des Beitrags.
    Weitere Information gibt es in den entsprechenden Artikeln „WordPress Titel ändern“ und „WordPress 2.5 und der neue Title Template Tag“.

    Eine Lösung wäre zum Beispiel:

    
<title><?php if ( is_archive() ) { _e('Kategorie'); } wp_title('-', true, 'right'); bloginfo('name'); ?></title>

Mit diesem kleinen Ausflug erschlägt man sicher nicht alle Punkte, aber es ist ein Anhaltspunkt und wie immer steht die Kommentarfunktion der Diskussion offen.

Artikel #784, 9. Oktober 2008 · Literatur, Plugin, Themes, Tipps, WordPress · 26 Kommentare · Kommentar schreiben
Tags: , , , ,
Kommentar-Feed zum Artikel · TrackBack URL · Kurzlink

«
»

20 Kommentare und 6 Trackbacks zu „10 Punkte zum perfekten WordPress Theme“

  1. 1
    Kommentar von Dominik
    10. Oktober 2008 um 00:55

    Ich finde zu Punkt 7 gehört gleichfalls auch formatierter Code, sowohl im Template mit PHP-Anweisungen als auch auf der generierten Seite (zugegeben: meist schließt letzteres ersteres aus...).

    Wenn ich die Form der (nicht) gesetzten Tabs bei Punkt 3.3 sehe, rollen sich mir die Zehennägel auf ;-) Im Ernst: entweder man setzt die Einrückung so, wie man sich auch mit HTMLTidy bilden kann, oder man verzichtet ganz darauf... Die Attraktivität von Themes bildet sich bei mir erst nach dem ich den Code gesehen hab.

    Jaaa... ich bin ein Nerd :-D
    Dominik

  2. 2
    Pingback von Zehn Punkte zum perfekten WordPress Theme | chris-b online
    10. Oktober 2008 um 01:13
  3. 3
    Kommentar von Frank Bültge
    10. Oktober 2008 um 07:33

    @Dominik: habe ich doch auch so drin:

    Damit meine ich nicht nur, dass der Validator keine Fehler meldet, sondern auch übersichtlich, strukturiert und lesbares Markup in den Templates.

  4. 4
    Kommentar von cywhale
    10. Oktober 2008 um 09:20

    Hrmpf. Mein WP-Adminbereich sagt mir dass mein recht ähnlicher Artikel zum Thema in 48 Minuten veröffentlicht werden würde. Werde ihn wohl auf Linkhinweise kürzen.
    Trotzdem Danke für diesen sehr ausführlichen Artikel :)

  5. 5
    Kommentar von Nils
    10. Oktober 2008 um 09:34

    Top Anleitung! Vielen dank.

  6. 6
    Kommentar von Frank Bültge
    10. Oktober 2008 um 09:56

    @cywhale: bitte lass ihn so, die Arbeit sollte man nicht kürzen. In dem Fall ist es kein doppelter Content, sondern eine Bereicherung.

  7. 7
    Pingback von 10 Punkte für das perfekte WordPress Theme
    10. Oktober 2008 um 10:00
  8. 8
    Kommentar von cywhale
    10. Oktober 2008 um 11:31

    Egal, ein paar Minuten später war es schon geschehen.
    Zum Artikel hier: Vor allem die Abschnitte über Bedeutung von Webstandards und Browserkompatibilität werden oft nicht erwähnt, schön sie hier zu finden.
    Dominik meint oben wahrscheinlich nicht den Inhalt des Artikels sondern das Codebeispiel zum Kommentar-Hook in welchen die Textarea und das PHP-Snippet wesentlich weiter eingerückt sind als die gleichwertigen Input-Elemente.

  9. 9
    Kommentar von Dominik
    10. Oktober 2008 um 14:22

    @Frank
    Ohje... es war schon spät :-D

    --Dominik

  10. 10
    Kommentar von Frank Bültge
    10. Oktober 2008 um 14:23

    @Dominik: stimmt, geht mir auch oft so - aber war es nicht eher früh

  11. 11
    Kommentar von Dominik
    10. Oktober 2008 um 14:28

    Ich versuche seit zwei Wochen meinen Tages-/Nachtrythmus wieder zu normalisieren... Die Semesterferien haben mich zu sehr zu 30-Stunden-Tage verleitet, sodass ich prinzipiell täglich ne Stunde später eingeschlafen bin... Für die jetzt beginnende Vorlesungszeit ist dieser Rythmus aber ein wenig, ähm, blöd...

    Sonst gäbe ich dir aber recht, um 1 Uhr beginnt erst der Tag :-D

    LG
    Dominik

  12. 12
    Pingback von Interessante Links - Tom Schimana
    10. Oktober 2008 um 19:59
  13. 13
    Kommentar von Ralf
    11. Oktober 2008 um 20:43

    Als erstes mal OT: Was ist denn hier mit der Schriftgröße passiert? Das ist ja Senioren-Format :D

    Die Formatierung des Codes ist (sorry for that) Bullshit. Wer weiß wie er an den Code kommt, kann diesen in den Editor seiner Wahl kopieren und dort z.B. von Tidy formatieren lassen. Ob der Code nun mit Einrückungen oder ohne an den Browser geliefert wird, ist dem Browser sowas von wumpe.
    Viel wichtiger sind erklärende und verständliche (!!!) Kommentare.
    Als Speicherplatz knapp war und Kommentare die Scriptsprache ausbremsten (also zu Zeiten als ein C64 Hightech darstellte und Basic das Nonplusultra war), entfernte man Kommentare um Ressourcen zu sparen und die CPU zu schonen.
    Diese Unsitte hat sich offenbar bis heute erhalten bzw. die meisten Autoren sehen es gar nicht ein warum sie ihre Werke mit Erklärungen versehen sollten.
    Die schönste Formatierung hilft nicht weiter wenn der Code an sich unverständlich ist. Ein paar Zeilen guter Kommentar ersetzen u.U. jede noch so tolle Formatierung. Sicherlich ist eine gute Formatierung sehr hilfreich, jedoch auch, wie bereits erwähnt, mit ein paar Mausklicks zu erreichen. zudem trennen sich bei der Formatierung auch die Geschmäcker. Der eine liebt es wenn jede Zeile 3 Tabs eingerückt wird, der nächste kann sich über das viele horizontale Scrollen nur aufregen.
    Wer technisch kniffelige Lösungen, prachtvolle Effekte oder andere Besonderheiten in seinen Werken verwendet, sollte dies vielleicht auch mal in einer kleinen Datei dokumentieren (readme.txt sollte der zweite Vorname eines jeden Programmierers sein!). Die meisten Sachen sind ohnehin Standard und immer wieder gleich. Den Header mit den meta-Tags kann man z.B. getrost in eine Zeile packen, dafür interessiert sich im Normalfall kein Mensch. dafür sind meistens die wirklich interessanten Bereiche so überformatiert das die Übersicht schon wieder verloren geht.

    Das Thema Suche möchte ich gar nicht so ausführlich ansprechen. Nur soviel: Die Suche von WordPress ist Mist und viele wissen es. Leider unternimmt kaum jemand etwas dagegen.
    Das ist aber wohl ein eigenes Thema für einen eigenen Beitrag.

    Das Verwenden von get_header/get_footer ist ebenso ein missverstandenes Thema. Es werden bei der Verwendung dieser Funktionen, auf den ersten Blick, lediglich die entsprechenden Dateien nachgeladen. Warum und wieso das so ist, darüber machen sich die wenigsten Gedanken.
    Der Unterschied zwischen dem einfachen Einbinden der Template-Datei (z.B. require(header.php) ) und dem get_header() ist der, dass bei der Verwendung der WP-Funktion noch Daten ausgewertet und in Variablen übergeben werden. Dieses Detailwissen macht manchmal den Unterschied zwischen funktioniert und funktioniert nicht aus.
    Im Grunde genommen kann man fast alle Template-Tags ersetzen, sollte dann aber vorher mal in den entsprechenden WP-Dateien genau nachschauen was diese Template-Tags so alles anstellen.

  14. 14
    Kommentar von Frank Bültge
    12. Oktober 2008 um 13:56

    @Ralf: zu OT; nichts verändert und da ich große klare Schriften mag, sind sie auch schon seit beginn so. Da ich aber auch in die Jahre komme, kann es sein, dass ich ein anderes Empfinden habe als du, oder du warst schon so lange nicht mehr hier?

    Die Formatierung des Code halte nicht für "Bullshit", sondern für Sorgfalt und Übersicht. Ich will dagegen keine Kommentare haben, unnötiger Code der nur aufbläht, Will man das Theme als Download anbieten, dann kann es sicher sehr nützlich sein. Ebenso sehe ich Kommentare innerhalb von Funktionen des PHP als sehr nützlich. Kommentare sind nützlich, keine Frage, aber in der Ausgabe eines Themes sind sind für mich überflüssig. Das dem Browser die Formatierung des Markup egal ist, ist sicher wahr, aber dem Menschen nicht, der der damit Arbeiten muss, der sollte einen sauberen Stil wahren und dazu gehört für mich eben Übersicht im Markup. Ebenso empfinde zu sauberem Stil gehört es einfach. Es ist quasi wie bei gutem Essen, die Zutaten sollten stimmen und nicht nur das Endprodukt.

    bzgl. Suche, stimmt - da muss etwas getan werden. Steht auch auf meiner Liste, aber leider fehlt mir einfach die Zeit. Gerade ich recht umfangreichen Blogs ist sie sehr dünn. Im Unternehmensumfeld bohre ich sie auf, leider bin ich hier nicht dazu gekommen.

    Template Tags: auch da stimme ich zu; aber ich blogge schon so lange hier und solche Themen nimmt sich kaum jemand an. Die Fragen sind immer wieder die gleichen, User wollen in erster Linie schnell ein Ergebnis und was unter der Haube läuft ist vielen Egal. Ich habe mir schon recht viele Themes angeschaut, auch kostenpflichtige und bin sehr oft enttäuscht, denn oft sind die Themen nur gespickt mit Schnippseln, die man 1:1 aus dem Web kopiert, ohne sich Gedanken zu machen, massenhaft Queries und unüberlegter Code, einfach kopiert, weile so war.

    Danke dir für deine ausführliche Meinung, du wiest, dass ich das schätze!

  15. 15
    Kommentar von cywhale
    12. Oktober 2008 um 15:14

    Zum Thema Einrückungen im Theme-Quelltext: Ich bin auch der Meinung das ein übersichtlich formatierter Quelltext durchaus seinen Sinn hat. Wer ein Theme anpassen möchte kann natürlich den Code selbst formatieren (wie geht Tidy mit PHP-Blöcken um, noch nie ausprobiert, geht das überhaupt?), das stellt aber dann wieder eine kleinere Hürde für unbedarftere Benutzer da die vielleicht nur eine kleine Änderung vornehmen wollen. Dem Browser ist es natürlich egal, dem Entwickler glaube ich nicht. Beim Thema Themekommentierung stimme ich aber zu, in Zeiten von DSL und Kabelnetz spricht eigentlich wirklich nichts dagegen, selbst in meinem eigenen Theme (Marke Eigenbau) vermisse ich manchmal einen kleinen Kommentar (und auch manchmal die Übersicht). Werde das Problem wohl auch selbst einmal angehen müssen :)

  16. 16
    Kommentar von Ralf
    12. Oktober 2008 um 15:52

    Über die Einrückungen muss man sich nicht streiten, dass ist, wie gesagt, Geschmackssache. Da kann jeder nur sagen was er bevorzugt und was nicht. Es soll aber auch Programmierer geben, die Syntaxhervorhebung für daneben halten weil ihnen die Farben nicht gefallen.
    Die Diskussion ist insofern Bullshit, als das jeder etwas anderes unter übersichtlich und gut lesbar versteht.

    Im Fall von HTML-Kommentaren kann ich dir recht geben. Gerade bei mobiler Nutzung zählt jedes Byte. Aber wie wäre es denn damit:
    [?PHP
    #
    # Ein Kommentar in PHP der einen HTML-Abschnitt kommentiert.
    # Saubere, einfache Lösung die vor der Auslieferung ausgefiltert wird.
    #
    ?]

    Im Zweifelsfall benutzt man halt zwei Versionen. Eine unformatierte und unkommentierte Version für den Betrieb. Und eine Download-Version die hübsch formatiert und kommentiert ist.
    Bei einer Download-Version halte ich übrigens eine gute Dokumentation für unumgänglich. Und die sollte dann bitte schön nicht mit dem Changelog beginnend mit der Version 0.01.03 prealpha vom 1.6.99 anfangen. Dokumentationen sind leider viel zu rar und wenn denn vorhanden, enthalten sie oft nicht das was gesucht wird. Ich denke mal das 90% der Fragen nur aufgrund einer mangelhaften Dokumentation anfallen.

    Bezüglich dem OT-Thema: Ich hab mal einen Screenshot hochgeladen. Also ich finde die Schrift extrem groß und dick geraten. Kann auch daran liegen das ich wirklich schon länger nicht mehr hier war. Oder das mein Browser (FireFox) spinnt.
    Was aber auch mal zeigt das Browsertests zwar das Gewissen beruhigen (ich hab ja alles getestet. muss gehen), aber nie 100%ige Sicherheit bringen da es wirklich so beim Besucher funktioniert und aussieht.

  17. 17
    Kommentar von Frank Bültge
    13. Oktober 2008 um 07:50

    @Ralf: Mit Sicherheit ist Formatierung ein Geschmacksthema, daher plädiere ich immer für Projekt- oder Teambezogene Normen.
    Die Lösung der PHP-Kommentare ist sicher eine Möglichkeit und auch ich vernachlässige oft die Doku., leider. Sie hat leider einen unterschwelligen wert, was nicht gerechtfertigt ist. Definitiv muss man mehr dokumentieren, lieber einen Satz zu viel. Auch in den Projekten im Job merke ich das immer wieder, die Prozesse und der Code sind unzureichend dokumentiert. Die Nacharbeit ist dann sehr mühselig und kostet ein vielfaches an Zeit und Geld.

    bzgl. OT: Ich werde es mir mal verändert ansehen, bin aber eigentlich auf all meinen Browsern zufrieden. Danke für den Screenshot, sieht korrekt aus.

  18. 18
    Kommentar von Frank Bültge
    13. Oktober 2008 um 08:46

    @Ralf: habe mal einige Veränderungen vorgenommen, eventuell fühlst du dich jetzt wohler?

  19. 19
    Kommentar von cywhale
    13. Oktober 2008 um 15:38

    Natürlich ist die korrekte Formatierung Geschmackssache, keine Frage. Trotzdem sollte man sich an rudimentäre Formatierungsmöglichkeiten wie z.B. Einrückung von verschachteltem Markup halten sofern nicht gesichert ist dass man ausschliesslich selbst am Markup arbeitet. Dadurch wird das Arbeiten für Fremde später wesentlich einfacher, z.B. für downloadbare Themes oder weitergegebene Projekte.
    Die Idee mit dem PHP-Kommentar ist nicht schlecht sofern auf dem benutzten Server PHP zu Verfügung steht - für z.B. WordPress-Themes eine gute Idee.

  20. 20
    Pingback von Weblog von Hartmut und Marcella » Der Blog in neuer Optik I » Blog, Weib, Klingt, DesignerGrafiker, Optik, “Neues”, Seite, Herbstblätter
    14. Oktober 2008 um 00:20
  21. 21
    Kommentar von Christoph
    17. Oktober 2008 um 22:35

    Es passt zwar nicht ganz, aber ich finde du hast ein wirklich tolles Theme. Es ist eine Augenweide und die Usability ist einfach super.

  22. 22
    Pingback von Link-Sunday: Greatest Link-Sunday Ever! - Blog, über, Sache, Langeweile, Icons, Plugin, Games, Mittel - Geldkrieg
    19. Oktober 2008 um 00:30
  23. 23
    Kommentar von Ralf
    19. Oktober 2008 um 11:41

    Frank, wirklich unwohl habe ich mich hier noch nie gefühlt. Nur etwas ungewohnt vielleicht. Aber so lange die Feeds nicht gekürzt werden, kann ich die Schriftgröße ja selber bestimmen ;)

    @cywhale: Gibt es noch Server die kein PHP oder zumindest eine andere Scriptsprache unterstützen?

  24. 24
    Pingback von Insomniaonline » Blog Archive » Wöchentliche Favoriten
    26. Oktober 2008 um 09:04
  25. 25
    Kommentar von Alex
    28. September 2009 um 16:11

    Hallo!

    Also hier mal ein riesen "RESPEKT!" vor der Arbeit :) Echt informativ und ausführlicher Artikel/Guide. Damit wird sicher ner Menge geholfen :)

    MfG

  26. 26
    Kommentar von Eknoes
    24. November 2009 um 21:38

    Wollte mich auch beidir für die viele Mühe bedanken, die du in deine tollen Tutorials oder Tips gesteckt hast! Respekt, tolle Arbeit. Ohne dich hätte ich immer noch kein eigenes WordPress Theme in meinem Blog ;D

    lg

Kommentar schreiben

Kommentarregeln: Bleib cool, kritisch ist in Ordnung, aber wenn du unhöflich bist, dann lösche ich deinen Kommentar. Bitte benutze deinen persönlichen Namen oder Initialen und nicht den Namen eines Unternehmens, dies würde als Spam gewertet und wird gelöscht. Der Zusammenhang zwischen Namen und URL sollte nicht offensichtlich auf Spam hindeuten! ♥ Ansonsten, vielen Dank für den Kommentar und viel Spaß mit meinem Blog.

E-Mail-Benachrichtigung bei weiteren Kommentaren.
Auch möglich: Abo ohne Kommentar.

Kommentar-Hilfe

händischer Spam:
Beachte die Kommentarregeln, jede Form von versuchtem Spam wird gelöscht. Warum und wieso steht in einem meiner Beiträge.

Bezug auf Textstellen:
Du kannst direkt bezug auf Textstellen im Beitrag nehmen. Dazu muss lediglich der Bereich im Artikel markiert werden; daraufhin erscheint ein Button, der den markierten Text in das Kommentarfeld übernimmt und als Zitat auszeichnet. Die Funktion ist nur bei aktivem JavaScript nutzbar.

xHTML:
Du kannst folgende Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <pre> <em> <strong> <strike> <ul> <ul> <li>

Achte darauf, wenn du Code im Kommentar hinterlegen willst, dann muss der Code maskiert sein. Dann wird er nicht interpretiert. Der Code muss mit Hilfe von HTML-Entities dargestellt werden, d.h. dass man z.B. < als &lt; und > als &gt; einfügt.

E-Mail-Benachrichtigung bei neuen Kommentaren ?
Wenn der Haken in der Checkbox gesetzt ist, dann wirst du über neue Kommentare vie E-Mail informiert. Der Versand erfolgt nur, wenn du die URL in der Bestätigungs-E-Mail genutzt hast oder schon Abonnent hier im Blog bist.

Kommentar erscheint nicht:
Alle Kommentare werden manuell geprüft, freigegeben und nach Möglichkeit beantwortet. Bitte um etwas Geduld und Nachsicht.

Identifikationsbilder (Avatare):
Auf Gravatar.com kann man sich mit seiner E-Mail-Adresse registrieren und ein Bild hochladen, dann erscheint dieses Gravatar hier und in vielen weiteren Blogs.

Spamschutz:
Das Kommentarformular ist mit einem Spamschutz ausgerüstet. Solltest du diesen Artikel ohne JavaScript besuchen und kommentieren wollen, so muss du die Frage beantworten und das jeweilige Wort in das Textfeld eingeben.