Dies ist eine ganz besondere Episode der v10-Redesign-Serie im Stil von DAS IMPERIUM SCHLÄGT ZURÜCK!
Alles beginnt ganz gut. Wir beginnen damit, einige Dinge von unserem statischen Mockup in unsere WordPress-Vorlage zu verschieben. Wir haben den Header in unserem statischen Mockup funktionsfähig, also fangen wir damit an. Das ist immer ein guter Ausgangspunkt, da wir dort all die grundlegende Arbeit erledigen, wie das bedingte Laden der CSS für den Website-Bereich und all das.
Dann schauen wir uns an, welches Markup für das Handbuch bereits existiert. So ziemlich die gesamte Seite ist in <nav> eingeschlossen, da die Homepage des Handbuchs im Grunde nur eine Navigation zu den eigentlichen Inhalten ist.
Dann beginnen wir mit dem Layout und erstellen das zweiseitige Layout, das wir in Photoshop entworfen haben. Wir verwenden hier CSS-Verläufe, um die Schattenwirkung zu erzielen, natürlich mit Compass-Mixins. Hier geht es dann ein wenig bergab, als wir damit kämpfen, den Verlauf richtig hinzubekommen.
Etwa in der 20-Minuten-Marke in diesem Video beginnen wir, all die Dinge auszugeben, die wir hier ausgeben müssen. Im Wesentlichen verwenden wir viel wp_list_pages(), um Unterseiten des Handbuchs auszugeben.
Und dann explodiert die Welt! Aus völlig unerklärlichen Gründen funktioniert die Ausgabe nicht richtig. Das ist ein extrem frustrierender Moment. Ich teile solche Dinge gerne, weil sie sehr realitätsnah sind. Man weiß, dass so etwas passiert! Die Fehlersuche ist Teil des Jobs.
Wir versuchen, Dinge zu googeln. Wir versuchen, die Abfrage zurückzusetzen. Wir versuchen, den Code doppelt zu überprüfen. Wir versuchen, die Parameter zu manipulieren. Wir versuchen verschiedene Funktionen. Nichts.
Wir versuchen, define('WP_DEBUG', true); in unserer wp-config.php-Datei zu setzen, um mehr Informationen zu erhalten. Das funktioniert, sobald wir den ausgegebenen Text lesen können. Es hilft aber nicht viel, bis wir den "out of memory"-Fehler finden! Jetzt kennen wir das Problem, aber wie lösen wir es?
Wir beenden diesen Screencast völlig besiegt, wie Luke Skywalker. Man könnte mir genauso gut sagen, dass <table>s mein Vater sind.
Eines der Dinge, die ich bei der Entwicklung/Fehlersuche unter WordPress tue, ist, Folgendes in meine
wp-config.phpeinzufügen:define('WP_DEBUG', true); if (WP_DEBUG) { define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); define('SAVEQUERIES', true); @ini_set('display_errors',0); }Dies verbirgt Fehler auf der Webseite und gibt alles in eine Log-Datei im Verzeichnis wp-content namens debug.log aus. Öffnen Sie debug.log im Programm Console.app unter
/Applications/Utilitiesund stellen Sie sicher, dass in den Console-Einstellungen die Option „Bounce the dock icon“ aktiviert ist, wenn ein offenes Protokoll aktualisiert wird. Lassen Sie nun die Konsole geöffnet, während Sie codieren, und wenn Sie auf einen WordPress-Fehler stoßen, wird die Konsole aufspringen und Sie können die Fehlermeldung sehen, ohne danach im Browser suchen zu müssen. Lassen Sie die PHP-Notices aktiviert, damit Sie sicherstellen können, dass keine vorhanden sind, aber es kann ziemlich unübersichtlich werden, wenn Sie schlecht codierte Plugins verwenden. (Vergessen Sie auch nicht, debug.log zu Ihrer .gitignore-Datei hinzuzufügen, damit es nicht auf Ihren Live-Server hochgeladen wird!)