miradlo bloggt

…endlich mal wieder eine neue WordPress-Version ;-)

10. September 2008 ute

Na gut, das ist ein bisschen ironisch, denn grad dachte ich, die eigenen und betreuten Blogs seien soweit aktuell, da steht doch im Adminbereich schon wieder:

“eine neue Version 2.6.2 ist verfügbar“

Ja, ich finde es sinnvoll, wenn Fehler und Lücken so schnell wie möglich behoben werden, dieses Mal hat auch alles problemlos geklappt ***mal vorsichtshalber auf Holz klopfend***

Klasse finde ich die Geschwindigkeit der deutschen Entwickler, die die angepasste Version 2.6.2, wie gewohnt, innerhalb eines Tages zur Verfügung stellten.

Ein bisschen strukturierter und nicht ganz so häufige Aktualisierungen wären jedoch zuweilen schon nett.

Ich habe brav wie immer, erstmal lokal probiert, was passiert, anschließend alle Datenbanken gesichert und erst dann aktualisiert… Klar fange ich jeweils erstmal mit dem Blog an, bei dem es am wenigsten auffällt, falls was wiederhergestellt werden muss. Es folgen die eigenen Blog und erst wenn da alles ok ist, gehe ich an Kundenblogs.

Plugin quote-comments

Das Plugin quote-comments (Kommentare zitieren) von Peter Kröner läuft jetzt auch hier. Nach einigem Rumprobieren und nachfragen, kam ich beim ersten Blog lokal zu einer Lösung. Ich musste die comments.php meines Themes ein bisschen anpassen, um validen Code zu bekommen.

Im Plugin habe ich in der wp-quote-comments.php statt eines Paragraphs (p) auf <li class=”quote_comments”> umgestellt, sonst passte es nicht in meinen Themes. Das erste, ein internes Blog, lief nachdem ich den relativen Pfad in der wp-quote-comments.js  von ../../../wp-content/plugins/wp-quote-comments/ auf absolute Pfade vom root aus /bloggt/wp-content/plugins/wp-quote-comments/ geändert hatte.

Beim Rumprobieren hatte ich diverse Versionen und irgendwann wusste ich gar nicht mehr, was ich alles geändert hatte. Ich habe dann nochmal mit den Ursprungsversionen angefangen. Dabei fiel mir auf, dass die Seiten plötzlich nicht mehr valide waren. An der Stelle ist das Plugin noch empfindlicher als der Validator, bei mir verweigerte es bei jedem Fehler seinen Dienst. Da ich selbst auf validen Code achte, ist das kein Problem, aber ich hatte nicht damit gerechnet.

Hier hatte ich einen Fehler zwischen den lokalen Tests und dem Hochspielen eingebaut und suchte das Problem zunächst in den Pfaden, die waren es jedoch nicht, denn kaum war der Fehler weg, war auch das Plugin zufrieden und zitierte so, wie ich mir das vorgestellt hatte.

So ganz nebenbei tauchte noch ein Problem auf, welches viel Zeit kostete, für das ich noch keine Lösung habe, da ich die Ursache nicht kenne, welches aber nicht so gravierend ist. Erstmals hatte ich Unterschiede im Quelltext zwischen meiner lokalen und der Serverversion. Das Plugin schreibt mir lokal in jeden Kommentar:

id=”quote_comments_loader”

Sobald es auf dem Server ist, beschränkt es sich jedoch darauf, das exakt einmal zu tun.

Leider dauerte es ziemlich lang, bis ich kapiert habe, dass das so ist. Bis dahin hatte ich nach, mir unerklärlichen, Fehlern im Validator gesucht… :-(

Ähnliche Beiträge

Kategorie tipps, wordpress | 0 Kommentare »

Sprachproblem bei Update auf WordPress 2.6.1

8. September 2008 ute

Vor einigen Tagen, habe ich dieses Blog aktualisiert auf die Version 2.6.1. Wie immer hatte ich vorher lokal alles installiert und ausprobiert. Irgendwann bei einer Änderung, hatte ich lokal plötzlich das Problem, dass die Sprache im Adminbereich und im Blog nicht mehr deutsch war. Da ich einiges hin und her probiert hatte, auch mit verschiedenen Plugins, mal installiert und dann wieder entfernt, dachte ich es wäre nur ein lokales Problem und spielte alles hoch. Leider stimmte das nicht, auch hier auf dem Server war anschließend alles im Adminbereich englisch.

Nur dieser Bereich wäre ja nicht so schlimm, allerdings sind damit auch alle Angaben wie Datum und Texte, die direkt von WordPress kommen englisch. Ich recherchierte an verschiedenen Stellen, unter anderem in der FAQ des deutschen WordPress-Forums. Ich probierte alle Hinweise aus, aber nichts half. Als nächstes wollte ich wissen, ob das Problem in der Datenbank zu suchen ist. Zuerst schaute ich mal rein, ob es da weitere Sprachinformationen gibt, da war jedoch nichts.

Dann installierte ich lokal eine völlig neue Datenbank, denn mehrere andere neu aufgesetzte Blogs kamen ja mit derselben Kombination WP 2.6.1 und dieselben Plugins zurecht. Wieder kein Ergebnis, dieselben Dateien ergeben bei Neuinstallation wieder englische Ergebnisse.

Nächster Schritt alle Plugins deaktivieren, umstellen auf’s Standardtheme in deutscher Version und alle WordPress-Dateien aus einem Blog kopieren, die mit deutsch zurecht kommen. Vorher natürlich sicherstellen, dass auch die lokale Version gesichert ist, nicht dass die einzige Originalversion auf dem Server liegt.

Wieder kein Erfolg, alle geänderten Dateien von einem Blog, welches die deutsche Sprache anzeigt als Grundlage ändern nichts daran, dass wieder alles auf Englisch ist. So ganz allmählich gingen mir die Ideen aus, denn wenn es weder die Datenbank, noch die Dateien, noch das Theme, noch die Plugins waren, was könnte denn dann noch sein?

Nun, das einzige, was jetzt noch anders war, war die wp-config. Ich hatte zwischendurch schon einige Male mit Änderungen der Sprachangabe und verschiedenen Sprachdateinamen an unterschiedlichen Stellen experimentiert, da ja auch der Pfad zwischen WP 2.3 und WP 2.6.1 für Sprachdateien anders ist. Statt /wp-includes/languages findet man die Sprachdateien ja inzwischen unter: /wp-content/languages

Da ich von Hand schon einige Male probiert hatte, dachte ich, die einzige Chance ist noch, die relevanten Zeilen zu kopieren. Tja, und genau das war’s! Jetzt spricht alles wieder brav deutsch. Hätte ich die Kommentare in der Datei genau gelesen, hätte ich drauf kommen können. Nun, das hatte ich jedoch nicht. :-(

Lösung des Sprachproblems

define (’WPLANG’, ‘de_DE’);
/* That’s all, stop editing! Happy blogging. */
define(’ABSPATH’, dirname(__FILE__).’/');
require_once(ABSPATH.’wp-settings.php’);
// define(’ABSPATH’, dirname(__FILE__).’/');
// require_once(ABSPATH.’wp-settings.php’);
// define (’WPLANG’, ‘de_DE’);

Na, seht ihr den Unterschied?
Ich habe es mehrfach nicht gesehen. Es gibt Definitionen, die dürfen stehen wo sie wollen, z.B.

define(’ABSPATH’, dirname(__FILE__).’/');

,

das gilt jedoch nicht für die Sprachdefinition, die muss vor dem folgendenKommentar stehen.

/* That’s all, stop editing! Happy blogging. */

Wie das passieren konnte?

Für die Umbennenung des Blogs musste ich in der wp-config folgende Zeile eingeben:

define(’RELOCATE’, true);

Dabei habe ich wahrscheinlich versehentlich den Spracheintrag um eine Zeile verschoben… Nun gut, wieder was gelernt, jetzt sind jedenfalls wieder alle Ausgaben deutsch und vielleicht hilft es ja noch jemand… ;-)

Ähnliche Beiträge

Kategorie blog, tipps, wordpress | 0 Kommentare »

Firefox 3 : Dialog - Lesezeichen hinzufügen - vergrößern ::: Adminize WordPress

5. September 2008 ute

Wie ihr wisst, mag ich Platz, große Auflösung und viel direkt übersichtlich Sichtbares. Leider wird der Spielkram zur Zeit meines Erachtens an einigen Stellen übertrieben.

Im Firefox 2 war das Dialogfenster “Lesezeichen hinzufügen” noch ein ganz normales kleines Fenster. Das konnte ich also genau so in der Größe anpassen, wie ich das mag, das ist ja unter KDE alles kein Problem.

Seit Firefox 3 musste das natürlich auch mal wieder toller, neuer, verspielter eingebaut werden. Jetzt ist das kein ganz normales Fenster mehr, sondern irgendsoein eingeblendetes Spielkramteil. Damit ärgerte ich mich in den letzten Wochen ständig über die doch immerhin vier! sichtbaren Einträge in meiner Bookmarks Toolbar, denn an dem Fenster ließ sich so einfach nichts verändern. Heute hatte ich jetzt die Nase voll und beschloss mal zu recherchieren. Nach ein bisschen Suchen fand ich ein Add-On, welches meine Probleme löst.

Dialogfenster “Lesezeichen hinzufügen” anpassbar

Mit dem OpenBook Add-On für den Firefox 3 geht das jetzt endlich wieder. In den Optionen gibt es eine Checkbox “Schaltfläche zur Größenänderung” anzeigen. Freundlicherweise bleiben zuletzt gewählte Einstellungen erhalten, wenn ich jetzt wieder eine Lesezeichen hinzufüge öffnet sich das Ding auf Fensterhöhe und ich kann wieder viele meiner Ordner in der Übersicht sehen, ein Traum! ;-)

Überflüssiger Spielkram

Für mich gehört sowas zu völlig überflüssigem Spielkram, denn ein ganz normales anpassbares Fenster ist schneller, einfacher anzupassen und funktioniert damit einfach besser.

WordPress Adminbereich 2.6 Spielkram

Offenbar sind solche Spielereien jedoch grad modern, denn im Adminbereich von WordPress 2.6 bekomme ich auch so hochmoderne mit JavaScript und schickem Hintergrund aufblendende Fenster, wenn ich z.B. im Standardeditor einen Link hinzufügen will. Das Ganze ist viel langsamer, bei meinen Einstellungen sind einige Schaltflächen nur zu einem Drittel sichtbar und ändern lässt es sich so auf Anhieb auch nicht.

Einige der tollen modernen Neuheiten lassen sich mit Frank Bültges Adminize-Plugin freundlicherweise konfigurieren und so anpassen, dass ich auch damit klarkomme. Das an WP 2.3 angelehnte Theme, ist beispielsweise nicht in solchen Quietschfarben und lässt sich bildschirmfüllend darstellen. Ich hasse es, wenn der halbe Bildschirm leer ist, weil irgendwer ein schickes Theme mit fester Breite entworfen hat…

Falls irgendwer von euch weiß:

  • wie ich statt des tollen neuen JS-Popup mit abgedunkeltem Hintergrund im Admin von WP 2.6 wieder zu einem ganz normalen Fenster komme…

dann schreibt mir einen Kommentar. Ansonsten muss ich wohl bei Gelegenheit nochmal suchen gehen…

Warum ich in der Sidebar erst alles Mögliche habe und erst weiter unten meine Kategorien, muss ich auch nicht verstehen.

Achja, und wenn ich nicht immer klicken müsste, um zu einem anderen Zeitpunkt als jetzt was zu veröffentlichen, wäre das auch fein.

Wunschzettel

Ich hätte gern, dass die Hersteller von Software, egal ob jetzt sowas wie Firefox oder eben WordPress statt ständiger neuer Spielereien, lieber mehr Konfigurationsmöglichkeiten bieten würden. Dass ich für eine Fenstergrößenänderung im Firefox ein Plugin brauche finde ich nervig. Ebenso, dass es nötig ist, dass es ein Adminize-Plugin braucht, weil WordPress von Haus aus so gut wie keine Konfigurationsmöglichkeiten bietet.

So ein bisschen Benutzerfreundlichkeit wäre grad bei Software, die sich häufig ändert schon nett. Ich denke nur wenige Nutzer haben Zeit und Lust sich bei jeder Versionsänderung neu in ihre Software einzulernen und länger zu recherchieren, bis sie wenigstens den bisherigen Stand wieder erreichen.

Ähnliche Beiträge

Kategorie software, wordpress | 0 Kommentare »

Blogadresse geändert ::: Weiterleitungsprobleme mit .htaccess

5. September 2008 ute

Wie ja bereits erwähnt, hat sich die Blogadresse hier geändert. Die Feeds gibts neu hier:  http://www.miradlo.net/bloggt/feed und nicht mehr unter: miradlo.net/blog_miradlo.

Ich habe sofort einige Weiterleitungen ausprobiert, die jedoch partout nicht so recht klappen wollten. Insbesondere der Feed weigerte sich und wollte sich nicht umleiten lassen.

Beim Recherchieren zur .htaccess, die den Apache steuert gab’s unzählige Ideen und Vorschläge:

  • wie werden Feeds zu Feedburner umgeleitet
  • welches WordPress Plugin leitet wie um
  • wie leitet man überhaupt um

Die ein oder andere Umleitung leitete zwar teilweise so um, wie ich wollte, hatte aber derart unangenehme Nebeneffekte, dass es auch keine Lösung war. Denn mit den versuchten Umleitungen für das gesamte alte Blogverzeichnis blog_miradlo auf bloggt, ließ sich der Feed nicht umleiten. Versuche, erst den Feed umzuleiten und dann den Rest gesamt, führten zu internen Serverfehlern (Error 500). Der eine oder andere sonstige Versuch hatte Probleme damit, dass es bisher noch anderer Stelle ein Bilderverzeichnis gab, was auch blog_miradlo hieß.

Aber jetzt habe ich eine Lösung!

Blog von einem Verzeichnis in ein anderes umleiten inklusive des Feeds

RewriteEngine On

RewriteRule ^blog_miradlo/(.*)$ http://www.miradlo.net/bloggt/$1 [R=301,L]

Damit leitet es jetzt sowohl einzelne Aufrufe nach Beiträgen, wie auch den Feed brav um.
Für diesen Fall ungeeignet waren folgende Möglichkeiten:

Mit direkten Umleitungen der Feeds (auch für mehrere Versionen) passierte gar nichts:

  • RedirectPermanent /blog_miradlo/wp-rss.php http://www.miradlo.net/bloggt//wp-rss.php
  • RedirectPermanent /blog_miradlo/feed/ http://www.miradlo.net/bloggt/feed

Auch angepasste Anleitungen, die einen Feed vom eigenen Blog zu Feedburner umleiten wollten nicht so, wie ich, egal ob diese:
WordPress zu Feedburner umleiten oder sowas wie diese:

  • <IfModule mod_rewrite.c>
    • RewriteEngine on
    • RewriteCond %{REQUEST_URI} ^/?(/blog_miradlo/feed.*|comments.*) [NC]
    • RewriteCond %{HTTP_USER_AGENT} !^.*(FeedValidator) [NC]
    • RewriteRule ^feed/?.*$ http://www.miradlo.net/bloggt/feed [L,R=301]
    • RewriteRule ^comments/?.*$ http://www.miradlo.net/bloggt/comments/feed [L,R=301]
  • </IfModule>

Als Zwischenlösung hatte ich deshalb alles auf die Blogstartseite umgeleitet, das klappte jedoch nicht mit den Feeds und auch nicht mit den einzelnen Beiträgen, aber es war zunächst einmal besser als nichts:

  • RedirectMatch 301 ^/blog_miradlo/(.*) http://www.miradlo.net/bloggt/

Ähnliche Beiträge

Kategorie tipps, wordpress | 4 Kommentare »

umgebaut : aktualisiert : optimiert : verändert : neue Adresse alles neu macht…

4. September 2008 ute

der September macht in diesem Fall alles neu.

  • miradlo.net altes Design

Nicht erschrecken, falls ihr die Seite nicht auf Anhieb wiedererkennt, ich habe so ziemlich alles außer den Inhalten geändert.

An ein paar Stellen kann es in den nächsten Tagen noch ruckeln, bis ich alle Probleme gefunden habe.

Feeds aktualisieren ::: neue Feedadresse: http://www.miradlo.net/bloggt/feed

Ich habe aus der alten Version miradlo.net/blog_miradlo die obige kürzere Version gemacht. Bitte aktualisiert eure Lesezeichen und vor allem den Feed:

Selbstverständlich leite ich so weit es geht auch automatisch um, allerdings klappt das aufgrund der alten Struktur nicht an allen Stellen wie gewünscht. Ich habe den Umbau auch mal bei Blogwartung gemeldet und werde versuchen so schnell wie möglich alle Schwierigkeiten zu beheben.

Die Änderungen auf miradlo bloggt

  • Design
    • das Design ist ganz neu und jetzt angepasst an das der Unternehmensseite, geblieben ist nur, dass es ein flexibles Design ist, welches bei jedweder Auflösung möglichst optimal nutzbar ist
  • WordPress-Version
    • das Blog läuft jetzt endlich mit der aktuellen Version
  • Plugins
    • weitere Plugins, die neue Möglichkeiten bieten sind dazugekommen, z.B:
      • Kommentare eines Beitrags per E-Mail abonnieren
      • Beiträge per E-Mail abonnieren
      • bereits gesendete Kommentare nochmal bearbeiten
  • Blogadresse geändert
    • aus miradlo.net/blog_miradlo wurde miradlo.net/bloggt/

Bitte gebt mir in den Kommentaren Bescheid, wenn euch noch Probleme auffallen.

Ich habe länger überlegt, ob es sinnvoll ist, auch die Adresse zu ändern, da ich damit rechnete, dass das nicht ganz problemlos klappt. Aber ich habe dann entschieden, dass dieses lange Ungetüm miradlo.net/blog_miradlo einfach weg muss das schlichte miradlo.net/bloggt ist einfach besser zu nutzen. Entstanden ist die Adresse, weil ich normalerweise lokal alles in diesem Stil benenne. Ich habe einfach nicht dran gedacht, dass dieser Name ja bei jedem Link gebraucht und genutzt wird. Deshalb habe ich entschieden, jetzt einmal diesen Schritt zu machen, damit es in Zukunft einfacher wird.

Ähnliche Beiträge

Kategorie krimskrams | 1 Kommentar »

Spezialfälle: akzeptabler Verzicht auf valides CSS ::: was sagt der Validator?

4. September 2008 ute

Normalerweise bin ich ja der Meinung, dass Webstandards eingehalten werden sollen. Damit verbunden sind normalerweise auch Seiten, deren CSS valide ist. Ab und zu eine Ausnahme, ist für mich in einigen Situationen akzeptabel. In meiner Session beim Blogcamp in Zürich kam von einigen der Hinweis, dass die Meldungen des Validators teils unverständlich seien. Deshalb werde ich versuchen, ab sofort diese Meldungen mit zu erklären, wenn ich grad dabei bin.

-moz-border-radius

Wenn es um besondere Eigenschaften geht, die gerade noch nicht dem aktuellen Standard entsprechen, z.B:

  • -moz-border-radius: 5px;

statt der in CSS 3 kommenden Eigenschaft

  • border-radius: 5px;

führt zwangsläufig dazu, dass der Validator meldet: Diese Eigenschaft existiert nicht.

In diesem Fall ist das jedoch kein Problem, denn interpretiert wird die Eigenschaft nur von Mozilla-Browsern, die sie verstehen, alle anderen ignorieren die Definition.

Zuweilen nutze ich solche Spielereien daher ganz gern. Allerdings kann das natürlich zu Problemen führen, wie z.B. bei mir letztens mit radius und Firefox 3. Inzwischen habe ich nochmal ein bisschen damit experimentiert.

Bei relativ langen Seiten scheint Firefox 3 grundsätzlich dann Schwierigkeiten mit dieser Definition zu haben, wenn sie sich im gleichen div-Container befindet, wie eine größere Menge Text und ein Hintergrundbild. Nach wie vor konnte ich dieses Problem im Firefox 2 zumindest nicht in diesem Ausmaß feststellen, dort kann es mal etwas langsamer werden, aber kein Vergleich… Im Seamonkey gibt’s gar keine Probleme, da ruckelt und wackelt gar nichts.

Transparenzeffekte

Jegliche Transparenzen werden ebenfalls angemahnt, z.B:

  • -moz-opacity:0.75

Alle Eigenschaften, die mit sowas wie -moz oder -webkit (für Safari) beginnen, stammen aus CSS 3 und werden irgendwann kommen, zur Zeit ist jedoch noch CSS 2 oder CSS 2.1 aktuell. Ebenso wird natürlich die proprietäre Eigenschaft der Internet Explorer als Einlesefehler gewertet:

  • filter:alpha(opacity=75);

Hacks für den Internet Explorer

Weitere Hacks für den Internet Explorer, wie z.B. die Eigenschaften, die mittels expression eingebunden werden, versteht der Validator ebenfalls nicht:

  • height: expression(document.body.scrollHeight > document.body.offsetHeight ? document.body.scrollHeight : document.body.offsetHeight + ‘px’);

Hier meldet der Validator:

  • Ungültige Nummer: height Lexical error at line 149, column 81. Encountered: “?” (63), after : “” ? document.body.scrollHeight : document.body.offsetHeight + ‘px’);
  • Ungültige Nummer: height Parse error - Unrecognized }

Die erste Meldung bezieht sich darauf, dass nach height ein Wert stehen sollte, z.B:

  • height:150px;

Die zweite Meldung ist ein typischer Folgefehler, da der Wert für die Eigenschaft fehlt, versteht der Validator nicht, warum jetzt bereits die Klammer für die Deklaration geschlossen wird.

Bei speziellen Definitionen für den IE, bevorzuge ich Extra-Stylesheets für den jeweiligen IE, die per Conditional Comment eingebunden werden. Damit liest nur der betroffene Browser diese Definitionen ein, alle anderen ignorieren den Kommentar.

Das Beispiel hier stammt aus dem CSS der thickbox, die z.B. vom WordPress-Plugin Ajax-Edit-Comments genutzt wird. Dort wird es nicht per CC eingebunden, was jedoch nicht so schlimm ist, da durch die Transparenzeigenschaften das CSS thickbox.css sowieso nicht valide ist.

Validatormeldungen verstehen

Was man sich beim Korrigieren von Fehlern immer angewöhnen sollte:

  • immer zuerst den obersten Fehler reparieren
  • zwischendurch erneut prüfen

Häufig verschwinden mehrere Fehler, sobald ein Fehler korrigiert ist. Den ersten Fehler zunächst korrigieren, ist sinnvoll, um nicht etwaige Folgefehler zu suchen, die vielleicht schon gar nicht mehr existieren.

Hm, zu verstehen, was welche Meldung bedeutet, ist wohl Übungssache. Für mich ist meist klar, was gerade nicht passt, Beispiele:

  • Diese Eigenschaft existiert nicht.
    • bedeutet genau das, so wie es im CSS steht, ist die Eigenschaft nicht zulässig, also z.B: -moz-border-radius
  • Einlese-Fehler opacity=75)
    • Der Validator hat etwas nicht verstanden, in diesem Fall die Eigenschaft filter:alpha( deshalb meldet er einen Einlesefehler, weil der Wert nicht interpretiert werden kann.
  • Ungültige Nummer: margin-top Lexical error at line 60, column 105 Encountered: “&” (38), after : “” & &document.documentElement.scrollTop | document.body.scrollTop) + ‘px’);
    • Lexical error bedeutet hier, dass ein Zeichen benutzt wurde, was da nicht hingehört, in diesem Fall ein “&”
  • Parse error - Unrecognized }
    • Der Validator kann die Klammer an dieser Stelle nicht korrekt analysieren, da sie hier nicht hingehört. Mögliche Fehlerquellen
      • vorher war eine Definition nicht ok
      • es fehlt ein Semikolon nach einer Definition
    • deshalb kommt die Klammer unerwartet.
  • Ungültige Nummer : display inline-block ist kein display-Wert : inline-block
    • Die Eigenschaft gibt es in der geprüften Version nicht, zur Zeit wird im Standardfall auf CSS 2 geprüft, die meisten Browser verstehen jedoch auch CSS 2.1. Dort existiert inline-block, deshalb kann man es zwar verwenden, muss jedoch auf CSS 2.1 prüfen, um ein korrektes Ergebnis zu bekommen.

Ähnliche Beiträge

Kategorie css, web | 2 Kommentare »

Mit Vista per virtuellem Host auf lokalem Webserver (Linux) testen

2. September 2008 ute

Ich brauche es ja ganz selten, aber so ab und zu zum Testen muss es halt doch auch Windows sein. Zum Beispiel um den IE 7 (Internet Explorer) zu testen, wäre es ja schön, wenn das auch lokal klappt und nicht nur, wenn die Daten bereits auf dem Server sind.

Die relevanten Daten habe ich natürlich trotzdem auf Linux, in meinem Fall auf tacita, das ist mein Standardrechner 17″ Fujitsu Siemens Amilo Laptop mit 1920*1280 Auflösung, betrieben ausschließlich mit Gentoo Linux. Auf meinem kleinen Notebook, devika, ebenfalls ein Fujitsu Siemens Amilo Laptop mit etwa 1280 Auflösung, betrieben mit Dualboot, einerseits ebenfalls Gentoo Linux, jedoch zu Testzwecken mit Windows Vista.

Apache Webserver und Rechnernamen

Wir haben unsere Rechner so eingerichtet, dass auf allen ein Webserver läuft. Unsere Rechner sind im internen Netz daher auch mit fester IP erreichbar, z.B.

  • 192.168.13  tacita
  • 192.168.12 devika

Sich die Zahlen zu merken ist bei mehreren Rechnern lästig und auch nicht nötig, deshalb können wir auf die Webserver der jeweiligen Rechner mit Namen zugreifen. Angenommen ich möchte von tacita aus, den Webserver von devika erreichen  dann genügt:

  • http://devika

Virtuelle Hosts

Da wir einige verschiedene Projekte bearbeiten, war es unpraktisch jedesmal den Apache neuzustarten (als root mit /etc/init.d/apache2 restart), deshalb nutzen wir virtuelle Hosts, damit kann man Projekte z.B. so aufrufen:

  • tacita_miradlo_net
  • tacita_miradlo_com
  • usw.

Bestehenden Webserver auf Windows nutzen

Ist pro Rechner nur ein localhost, aber keine virtuellen Hosts, eingerichtet, klappt das auch mit Windows. Ich greife dann z.B. von devika aus mit Windows Vista auf tacita mittels der IP 192.168.13 zu. Der localhost, der als Standard fungiert wird damit auch noch aufgerufen, selbst wenn es weitere virtuelle Hosts gibt. In vielen Fällen genügt das, denn auf Linux einen anderen localhost als Standard zu setzen, geht recht schnell. Mir jedenfalls ist das lieber, als zu sehen, wie ich irgendwas bei Windows einstellen kann. (Ja, stimmt, wenn ich es vermeiden kann, fasse ich es gar nicht erst an, dann klappt es zum Testen und mehr brauche ich nicht.)

Das Ganze klappt jedoch nicht mehr, wenn z.B. ein Blog in einem Unterordner installiert ist, dann behauptet Vista, dass es die Seite nicht gäbe. Manchmal will ich jedoch auch Blogs auf Windows testen, bevor ich irgendwas ins Netz stelle.

Selbstverständlich will ich nicht vorher erst das ganze Projekt auf Windows installieren, sondern nur auf den Webserver des Rechners zugreifen, auf dem das Projekt gerade liegt.

/etc/hosts auf Windows

Der Aufruf mit IP und Projektname, z.B. 192.168.13_miradlo_net klappt nicht, da findet Vista ebenfalls nichts. In diesem Fall muss man tatsächlich Vista beibringen andere Hosts zu erkennen. Im Netzwerk existieren diese Hosts ja bereits, Windows greift auf dasselbe interne Netzwerk zu, es fehlt also nur an den korrekten Namen. Es existiert auch unter Windows ein Verzeichnis etc und eine Datei hosts, die so aufgebaut ist, wie das eben unter Linux üblich ist.

Das Problem bei Vista ist zunächst, die Datei zu finden…

  • c:\Windows\System32\drivers\etc\hosts

…anschließend, sie auch ändern zu dürfen. Die Anleitung dazu, mit dem Aufruf des Editors als Administrator habe ich bei LANtastic gefunden.

In der hosts konnte ich dann wie gewohnt meine Einträge machen, z.B:

  • 192.168.13     tacita_miradlo_com.name_des_internen_netzes      tacita_miradlo_com
  • 192.168.13     tacita_miradlo_net.name_des_internen_netzes       tacita_miradlo_com

So kann ich auch von Vista aus, z.B. ein Blog testen und alles verhält sich so, wie später auf dem Server:

  • http://tacita_miradlo_net/blog/

Ich gehe davon aus, dass das so ähnlich auch mit einem Vista auf VM-Ware (virtuelle Maschine) klappen müsste, das habe ich jedoch noch nicht getestet. Mit XP und VM-Ware geht es auf jeden Fall…
Klasse, oder?! ;-)

Ähnliche Beiträge

Kategorie linux, tipps, web | 0 Kommentare »

« Vorherige Einträge Nächste Einträge »

zum Seitenanfang