# Rewrite einschalten (# = Kommentarzeichen)
RewriteEngine On

# Bedingung definieren
# %{REMOTE_ADDR} enthält die IP-Adresse des Besuchers.
RewriteCond %{REMOTE_ADDR} !=Deine feste oder dynamische IP

# %{REQUEST_URI} enthält die aufgerufene URL ab dem Root, also ohne http://blablabla...
# [NC] bedeutet, Gross-, Kleinschreibung egal
RewriteCond %{REQUEST_URI} !=/ordner/wartungsinformation.html [NC]

# Wenn die vorgenannten Bedingungen erfüllt sind, wird der Besucher mit RewriteRule auf root/ordner/… umgeleitet.
# ^ (Ausdruck einleiten) . (ein beliebiges Zeichen) * (Wiederhollung) $ (Ende des Ausdrucks)
# [R=302 (temporär verschoben), NC, L (letzte Anweisung)]
RewriteRule ^(.*)$ /ordner/wartungsinformation.html [R=302,NC,L]

Klartext:
Wenn die Besucher-IP nicht (!=) Deine IP ist und
die aufgerufene URL nicht (!=) /ordner/wart…. ist, dann
leite auf (^(.*)$) http://blablabla/ordner/wart... um.

Beispiel:
Deine IP ist: 123.123.12
Deine Domain: http://www.beispiel.org
Deine Wartungsinformation liegt in: /wartung/info.html
Erreichbar über: http://www.beispiel.org/wartung/info.html

Dann sollte die .htaccess so aussehen:
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !=123.123.12
RewriteCond %{REQUEST_URI} !=/wartung/info.html [NC]
RewriteRule ^(.*)$ /wartung/info.html [R=302,NC,L]

Wichtig: Eine vorhandene .htaccess muss natürlich gesichert und nachher wieder hergestellt werden. Htaccess funktioniert nicht auf jeden Server.

Wenns jetzt nicht verständlich ist, weiß ich wirklich nicht, wie ich es noch besser erklären könnte…

ich häng' mich da an conhunters Fragen gleich mit dran.
Du – und andere hier – haben wohl mehr Erfahrung mit der .htaccess, ein kleiner Lehrgang (mit verständlichen Worten wäre etwas Feines

Im Voraus meinen heißesten Dank.

Lieber Gruß
Rata

also erst mal danke für die .htaccess-direktiven. aber bevor ich anfange eine eigene umleitungsdirektive zu basteln, habe ich noch ein paar banale fragen, die sich aufgetan haben, nachdem ich ein wenig im netz bei bananajoe über .htaccess recherchiert habe:

1. muss ich deinen vorgeschlagenen .htaccess-codeschnipsel mit den entsprechenden abänderungen der eigenen ip-adresse und des umleitungsordners bzw. -datei hinzufügen (was mir logischer klingt) oder eine neue leere .htacces-datei erstellen mit den direktiven und dann die .htaccess-datei auf meinem server zu überschreiben?

2. da beim programmieren jedes einzelne falsche zeichen zur fehlermeldung führt, interessiert mich welche zeichen in deiner anweisung zum code gehören und welche als beispiel fungieren.

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !=Deine feste oder dynamische IP
RewriteCond %{REQUEST_URI} !=/ordner/wartungsinformation.html [NC]
RewriteRule ^(.*)$ /ordner/wartungsinformation.html [R=302,NC,L]

soll ich nur die fettgedruckten stellen durch eigene angaben ersetzen oder gehört das ausrufezeichen und gleichheitszeichen zum code dazu?

übrigens: kopie der jetzigen .htaccess vom provider habe ich mir schon angelegt. komisch, dass diese datei überhaupt keinen namen trägt!

gruss

zu Komm-Nr. 31
SaarBreaker, mach mir keine Angscht, dann probier ich es erst gar nicht aus! Oder doch?
Gibt es dafür nicht auch irgendein tolles Plugin? Kann ich bei der Fülle an Plugins fast nicht glauben!

das Plugin Simple Tagging hat schon seit der Version 2.3 nicht mehr mit WordPress funktioniert, deswegen gibt es auch das Plugin Simple Tags (der Nachfolger). Guckst du hier:

• Simple Tags beerbt Simple Tagging
• Nach Simple Tagging kommt Simple Tags

Du musst außerdem die Tags nicht neu anlegen, schaue dich bitte unter "Verwalten" und dann "Import" um und wirst die Möglichkeit sehen, die Tags von Simple Tagging in das neue System zu überführen.

während eines Updates und auch anderen Änderungen, die die Besucher nicht mitbekommen sollen, leite ich alle IPs bis auf meine eigene mittels einer htaccess auf eine Informationsseite um. Es wäre ja auch nicht sehr schön, wenn ein Besucher während eines Updates nur Fehlermeldungen zu sehen bekommt.

Meine Update htaccess hat folgenden Inhalt:

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !=Deine feste oder dynamische IP
RewriteCond %{REQUEST_URI} !=/ordner/wartungsinformation.html [NC]
RewriteRule ^(.*)$ /ordner/wartungsinformation.html [R=302,NC,L]

Was hier passiert ist folgendes: Wenn die Besucher-IP (!=) nicht "Deine feste oder dynamische IP" ist, leite diese Besucher-IP auf "/ordner/wartungsinformation.html" um.

Wichtig: Zieht euch ne Kopie (umbenennen geht auch) von der vorhandenen .htaccess, bevor ihr diese (Update) htaccess auf den Server-Root kopiert. Nach dem Update müsst ihr die Original-htaccess wieder herstellen.

Noch wichtiger: Macht bloß keine Experimente, wenn ihr euch nicht mit reguläre Ausdrücke auskennt und – das muss ich auch noch anmerken – ich bin darin auch keine große Leuchte. Hab mir bei meinen Experimenten schon mehrmals ins Knie geschossen.

An alle, die von htaccess keine Ahnung haben: Es ist nicht schlimm und man muss es auch nicht unbedingt einsetzen. Zudem ist bei vielen Hostern der Einsatz von htaccess nicht möglich oder gestattet.

Seit meinem Update auf Wordpress 2.5 funktioniert das Simple Tagging Plugin 1.7 von Amaury Balmer nicht mehr. Ihr Plugin war erweitert und basierte auf dem coolen Simple Tagging Plugin 1.6 von Michael Wöhrer, für das es ebenfalls keinen Support mehr gibt. Woran es liegt, kann ich als Blog-User nicht herausfinden, dazu schwächeln meine PHP-Kenntnisse deutlich. Vielleicht kollidiert es mit der neuen eigenen Tag-Funktion von Wordpress. Auf alle Fälle werde ich jetzt in der neuen Version sämtliche Tags in meinem Blog über Concept Cars neu anlegen müssen, bis dato waren es derer mindestens 50 Stück und mit dem Besuch jeder Automesse kommen noch mindestens 20 hinzu. Die Tag-Wolke funzte demnach ebenfalls nicht, auf welche ich im Augenblick ebenfalls verzichten muss. Soviel zum Thema Plugins und Aktualität von Drittanbietern. Na dann prosit und auf ein Neues!

Als langer WP-User muss man sich da wirklich erstmal ein wenig umorientieren. Dennoch halte ich die Änderungen im Backend ebenfalls für durchdacht - nur eine Frage der Gewohnheit denke ich. Das gilt auch für das peppige "Outfit"

ich kam jetzt doch selbst dahinter.
Für andere Dussel die Lösung: Ich habe WordPress der besseren Übersicht halber in einem Unterverzeichnis im Verzeichnis /html installiert.
Beim Update muß man natürlich die index.php anpassen und in das Root-Verzeichnis (/html) legen.

Jetzt funktioniert alles.

Perun, wenn Du magst, schalte diese beiden Beiträge einfach nicht frei.
Obwohl sie auch hilfreich sein könn(t)en

Nochmals ein lieber Gruß
Rata

Nun hab ich alles exakt bis auf’s i-Tüpfelchen so gemacht, wie Du die Update-Prozedur vorschlugst.
Einziges Problem, welches danach auftrat: Alle Archiv-Seiten bringen nun einen 404-Error.
Ich bin echt überfragt, muß aber auch erwähnen, daß meine Site 3-sprachig ist, wobei ich Language Switcher 1.11 einsetze.

Bevor ich wieder auf 2.3.3 zurückgehe, wo alles lief, wollte ich mich doch hier einmal melden Vielleicht weiß ja jemand, woran es liegt, liegen könnte.
Ich bin nämlich ein ziemlicher Grünschnabel, was WP, PHP und HTML anbelangt.
Das Update der Datenbank lief übrigens angeblich fehlerfrei durch, Backups sind in Hülle und Fülle Dank PlugIn (WordPress Database Backup 2.1.5) verfügbar

Ach so, nochwas: Deine Darstellung der Zusammenhänge in WordPress war übrigens die erste, die mir als alternder Ratte einleuchtete 8); dafür wollte ich mich gleich mit bedanken.

Meine Site, bevor jemand meckert: http://www.tuvidaloca.net/

Lieber Gruß
Rata

Das würde mich auch mal brennend interessieren!
Welche funktionalen Möglichkeiten habe ich Besucher zu informieren, dass ich im Augenblick update oder Theme-und Codetests durchführe, ohne dass sie die Veränderungen jedesmal mitbekommen?
Eine Weiterleitung der Domain zu einer html-Seite reicht nicht, denn dann werde ich ebenfalls jedesmal bei der Vorschau weitergeleitet. Wie umgeht man diesen Umstand geschickt, vor allem später wenn man viel mehr Traffic und Besucher hat?