WordPress Wartung: Verwaltungsbereich sperren

 WordPress  Keine Antworten »
Aug 242011
 

Für WordPress existieren einige “Maintenance Mode”-Plugins, welche die komplette Seite sperren.

Oft möchte man während einer Wartung allerdings nur Änderungen an der Datenbank verhindern während die Seite für Besucher weiterhin angezeigt werden soll.

Der Artikel WordPress Maintenance Mode Without a Plugin Part 3 beschreibt den umgekehrten Ansatz – das Backend bleibt aktiv während Frontend Zugriffe verboten werden.

Dieser Ansatz muss also nur noch entsprechend angepasst werden.

WordPress Login Sperre einrichten

Dazu erstellt man im WordPress Hauptverzeichnis die Datei .maintenance mit folgendem Inhalt:

1
2
3
4
<?php
if ( stristr($_SERVER['REQUEST_URI'], '/wp-admin') || stristr($_SERVER['REQUEST_URI'], '/wp-login.php') )
    $upgrading = time();
?>

Möchte man die Meldung noch aussagekräftiger gestalten, kann man die Datei wp-content/maintenance.php erstellen. Beispielinhalt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="de-DE">

    <?php $heading = 'Wartungsarbeiten - Maintenance' ?>

    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <link rel='stylesheet' id='login-css'  href='/wp-admin/css/login.css' type='text/css' media='all' />
        <link rel='stylesheet' id='colors-fresh-css'  href='/wp-admin/css/colors-fresh.css' type='text/css' media='all' />
        <title><?php echo $heading; ?></title>
    </head>

    <body>
        <div style="margin:0px auto; max-width:960px;" >
            <h1><?php echo $heading; ?></h1>
            <br/>
            <h2><em>DEUTSCH:</em> Administrationsbereich tempor&auml;r gesperrt</h2>
            <p>Aufgrund von Wartungsarbeiten d&uuml;rfen derzeit keine &Auml;nderungen vorgenommen werden. Daher ist der Zugang zur WordPress Verwaltungsoberfl&auml;che gesperrt.</p>
            <br/>
            <h2><em>ENGLISH:</em> Admin-Interface temporarly locked</h2>
            <p>Due to scheduled maintenance changes are currently disallowed. Thus login to the WordPress backend is denied. </p>
        </div>
    </body>

</html>

Das Beispiel bindet die gleichen CSS Dateien ein, wie das WordPress Anmeldeformular und sorgt somit für die Verwendung der bekannten Schriftart.

Es kann natürlich beliebig optimiert werden. Einge Möglichkeit wäre die Sprache je nach Locale des Besuchers zu setzen.

 Veröffentlicht durch um 19:27

WAR Dateien in Tomcat 7 entpacken – unpackWARs

 FreeBSD, Grails  1 Antwort »
Aug 242011
 

Bereits in Vorgängerversionen ist Tomcat standardmäßig so konfiguriert, dass WAR Dateien beim Deployment entpackt werden.

Das ermöglicht unter anderem, statische Inhalte (CSS, JS, Bilder, …) über einen anderen Webserver bereit zu stellen.

Allerdings kann es unter gewissen Umständen passieren, dass nach dem Update auf Tomcat 7 Applikationen verpackt bleiben – obwohl unpackWARs oder unpackWAR gesetzt ist.

Wann bleibt unpackWARs in Tomcat 7 effektlos?

Ein Vergleich der Tomcat-Dokumentationen zu unpackWAR im Context Container-Abschnitt ‘Standard Implementation’ zeigt warum:

Wichtiger Unterschied: “Note that WAR files located outside of a Host’s appBase are never unpacked.”

Hat man also beispielsweise in der context.xml (oder ROOT.xml) einen Pfad außerhalb des laut server.xml definierten Hosts angegeben, so ist unpackWARs effektlos.

Beispiel

Inhalt von /usr/local/apache-tomcat-7.0/conf/Catalina/localhost/ROOT.xml

1
<Context docBase="/home/someuser/some-grails-app.war" path="" reloadable="true"/>

Lösung: Symlink zur Applikation in webapps Verzeichnis

Damit WAR’s wieder entpackt werden, kann man entweder die appBase in der Host-Definition anpassen oder man entfernt die ROOT.xml und setzt stattdessen einen entsprechenden Symlink:

1
2
3
4
# Verschieben der original ROOT-Applikation:
mv /usr/local/apache-tomcat-7.0/webapps/ROOT /usr/local/apache-tomcat-7.0/webapps/ROOT_orig
# Verlinken der Grails-Beispielapplikation als ROOT.war:
ln -s /home/someuser/some-grails-app.war /usr/local/apache-tomcat-7.0/webapps/ROOT.war

Der hier gesetzte Link sorgt dafür, dass die Grails Applikation mit dem Namen “some-grails-app” als ROOT-Anwendung entpackt und gestartet wird.

 Veröffentlicht durch um 14:45  Kennzeichnung:

Geb Starthilfe – Grails Functional Testing

 Grails  Keine Antworten »
Jul 252011
 

Mittels Unit- und Integration-Tests kann die Qualität einer Grails Web-Applikation zum Großteil sichergestellt werden.

Um eine Funktionalität aus Nutzersicht zu überprüfen ist eine andere Herangehensweise erforderlich: Man startet die Applikation und überprüft per Browser ob die verschiedenen Anwendungsfälle wie gewünscht durchgeführt werden können.

Um langfristig zu gewährleisten, dass die Funktionalität erhalten bleibt, müsste man die Schritte nach jeder weiteren Code-Änderung wiederholen.

Dies ist umständlich bis unmöglich und kann in Grails mittels Geb automatisiert werden.

Anwendungsfälle von funktionalen Tests

Es gibt unendlich viele Möglichkeiten durch eine Web-Applikation zu navigieren. Dementsprechend sinnlos ist der Versuch “möglichst Alles” zu testen.

Folgende Szenarien sind aus meiner Sicht für “functional testing” interessant:

Sicherstellung von Kern-Funktionalität

Die Durchführbarkeit, zumindest jener Anwendungsfälle ohne welche die Web-Applikation nutzlos werden würde, kann gut über funktionale Tests sichergestellt werden.

Planung von Usability-Tests

Bei der Planung von Tests der Benutzerfreundlichkeit kann man den idealen Ablauf zur Lösung der Aufgabe definieren und damit sicherstellen, dass zumindest dieser Weg zum Zeitpunkt des Tests mit dem Teilnehmer funktionieren wird.

Regressionsvermeidung

Regressionen – für mich einer der Hauptgründe überhaupt Tests zu schreiben.

Für jeden gefundenen Programmfehler wird ein Test geschrieben, welcher diesen Fehler reproduziert. Dann implementiert man die Lösung so, dass der Test erfolgreich verläuft – natürlich ohne dabei den Test zu ändern.

Somit wird eine Applikation langfristig immer “besser”, da sich ein bereits gefundener Bug unmöglich erneut in das Programm einschleichen kann.

Seiten: 1 2 3 4 5 6 7 8 9 10
 Veröffentlicht durch um 16:48  Kennzeichnung: ,
© 2011 Groovy Skills Suffusion theme by Sayontan Sinha