RobertRiebisch.de

Debugging procedures in Worry-Free Business Security (WFBS) 8.0

Durch meinen zuletzt veröffentlichten Artikel ist mir klar geworden, dass ich nicht darum herumkomme, mich mit Cascading Style Sheets (CSS) auseinanderzusetzen.
Wenn das Bullet-Zeichen links aus dem Artikel herausragt, sieht das einfach nicht schön aus.

Als Lösung habe ich in der Datei index.php über der Zeile div.clear { folgenden kurzen Abschnitt notiert:

div.post-content ol, ul {
  line-height: 1.6em;
  margin: 1em 0 0.6em;
  padding: 0 0 0 2em;
}

div.post-content li {
  margin-bottom: 0.4em;
}

Kurze Erläuterung (natürlich in Form einer Liste):

1. Für nummerierte Listen (<ul>...</ul>) und Aufzählungslisten (<ol>...</ol>) lege ich wie für <p>...</p> die Zeilenhöhe auf das 1,6-fache der Schriftgröße des Elements fest.
2. Weiterhin bekommen diese Listen von mir einen Außenrand/Abstand (margin:...) verpasst, der oben der Schriftgröße des Elements entspricht. Rechts und links soll es keinen Abstand geben. Unten soll der Abstand das 0,6-fache betragen.
3. Die Innenabstände (padding:...) definiere ich so, dass nur links ein Abstand des 2-fachen der Schriftgröße des Elements entsteht.
4. Zuletzt sollen Listeneinträge (<li>...</li>) unten den 0,4-fachen Abstand besitzen, damit mehrzeilige Einträge deutlicher zusammenstehen.

Beim Verfassen dieses Artikels habe ich dann bemerkt, dass auch bei <pre>...</pre> zumindest der Abstand unten nicht stimmt. Daher notierte ich direkt darunter noch:

div.post-content pre {
  margin: 1em 0;
}

Beide Änderungen sind allerdings mit Vorsicht zu genießen, da ich kein CSS-Profi bin und deswegen unerwünschte Nebenwirkungen nicht ausschließen kann.

Heute kam ich das erste Mal mit den Vorlagendateien für Office 2013 in Berührung, da ich die Neuausrüstung einer kleiner Firma vorzubereiten hatte. Himmel, was hat Microsoft da bloß angestellt! OK, auch in früheren Office-Versionen waren die Templates nicht frei von Fehlern, aber Office 2013 übertrifft das locker. Obwohl ich nur einige wenige Einstellungen anpassen wollte, erwuchsen daraus einige Stunden Arbeit.

So lässt sich z. B. der Pfad für die Arbeitsgruppenvorlagen nicht mehr festlegen. Die Einstellung ist zwar wie bei Office 2010 vorhanden, aber sie "zieht" nicht. Wertet man den Startvorgang von Word mittels Process Monitor aus, stellt man fest, dass Word überhaupt nicht auf den resultierenden Registry-Wert "HKCU\Software\Policies\Microsoft\Office\15.0\Common\General\SharedTemplates" schaut. Offenbar haben da einige Mitarbeiter bei Microsoft aneinander vorbei gearbeitet.

Sehr "schön" sind auch die beiden Einstellungen bezüglich des ersten Starts von Office. Eigentlich sollen sie die Dialoge "Willkommen bei Ihrem neuen Office!" (siehe unten) usw. unterdrücken. Aktiviert man BootedRTM und DisableMovie jedoch, werden diese Dialoge fortan bei jedem Office-Start angezeigt. Echt prima!

Die derzeit einzig mögliche "Lösung" ist das Setzen bestimmter Registry-Werte per Group Policy Preferences:

1. "HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\FirstRun\BootedRTM", Typ REG_DWORD, Wert 1
2. "HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\FirstRun\DisableMovie", Typ REG_DWORD, Wert 1
3. "HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\General\SharedTemplates", Typ REG_EXPAND_SZ, Wert <gewünschter Pfad>

Ich bezweifle jedoch, dass Microsoft noch eine andere Lösung präsentieren wird, da die GPPs ja bereits funktionieren.

Tipp: Wer auch noch folgenden Dialog unterdrücken will, sollte ein REG_DWORD namens ShownFileFmtPrompt mit dem Wert 1 im Zweig "HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\General" erstellen.

Es ist jetzt 22:30 Uhr und das Thermometer im Wohnzimmer zeigt immer noch 31,7 Grad Celcius an. Im Bad werden sogar 32,4 Grad Celcius angezeigt. Dabei fing der Tag relativ entspannt an, so dass man schon glauben mochte, die Meteorologen hätten sich vertan gehabt. Es waren in der Nacht zwar auch um die 25 Grad Celcius, aber gegen 7 Uhr zog sich der Himmel zu und es regnete an paar Tropfen, weswegen die Temperatur kaum anstieg. Zur Mittagszeit herrschte aber wieder blauer Himmel mit ein paar kleinen weißen Wölkchen vor. So landete Berlin doch wieder bei offiziellen 34,4 Grad (gemessen in Tempelhof). Ab Mitternacht soll ein heftiges Gewitter endlich Abkühlung bringen. Allerdings könnte es am nächsten Wochenende schon wieder ähnlich warm werden.

Kommen im Titel eines Artikels Anführungszeichen vor, werden diese im Admin-Panel mit einem vorangestellten Backslash angezeigt. Da hat spyka wohl ein stripslashes() vergessen. Also in der Datei adm/index.php ändern von: <td><a href=\"admin.php?mode=edit&id={$row['post_id']}\">{$row['post_title']}</a></td> nach: <td><a href=\"admin.php?mode=edit&id={$row['post_id']}\">" . stripslashes($row['post_title']) . "</a></td>

Hinweis: Bei der korrekten Formatierung des Quellcodes in diesem Artikel hat mir das Online HTML escape tool sehr geholfen.

Es gefällt mir nicht, dass im Admin-Panel der neueste Artikel ganz unten in der Liste steht. Je mehr sich mein Blog füllt, desto weiter muss ich nach unten scrollen, wenn ich kürzlich veröffentlichte Artikel nachbearbeiten möchte. Somit habe ich nun in der Datei adm/index.php an den SQL-Befehl SELECT * FROM `miniblog` noch ORDER BY `date` DESC' angehängt, damit der neueste Artikel ganz oben steht.

Ich weiß nicht, wie es passiert ist, aber die Blog-Software hat die Zeilen in der SQL-Tabelle miniblog nicht in der erwarteten Reihenfolge angelegt. Die Reihenfolge der Post-IDs lautet: 1, 3, 4, 5, 2, 6. In der Ansicht für Besucher spielt das keine Rolle, aber im Admin-Panel stört es einfach. (In der Datei adm/index.php steht nämlich ganz simpel SELECT * FROM `miniblog`. Es findet also keine Sortierung z. B. nach der Spalte post_id statt.)

Ich sortiere nun mittels ALTER TABLE miniblog ORDER BY post_id um und werde das beobachten.

Entwickelt man für das WWW sollte man die erzeugten Seiten wenigstens (!) hin und wieder mal durch den W3C Markup Validation Service jagen um zu prüfen, ob die Seiten den gängigen Standards entspricht. Das habe ich nun mit meiner miniblog-Installation getan und sogleich einige "Schusselfehler" in meinen Artikeln gefunden und korrigiert. Ich sollte wohl alsbald die Markdown-Syntax einbinden.

Weiterhin habe ich noch zwei grobe Schnitzer in der von spyka ausgelieferten Datei index.php gefunden. Die Zeile <body> gehört selbstverständlich direkt unter </head> und über der Zeile </body> muss noch ein </div> notiert werden, damit das Block-Element <div class="wrapper"> geschlossen wird. Um bezüglich des verwendeten Zeichensatzes auf der sicheren Seite zu sein, habe ich auch noch die Zeile <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> unter <head> eingefügt. Letzteres muss spyka wohl ausgerechnet hier vergessen habe, denn in den Dateien adm/header.php, adm/simple-header.php und install.php ist die Zeile bereits vorhanden.