bluefish: probleme mit absoluten pfaden bei der Vorschau

[michaa]

Hi,

in meinem derzeitigen Projekt hatte ich alle Pfade _relativ_ zum Basisverzeichnis der HP angegeben. Das funktioniert sowohl in der lokalen Vorschau hier auf meinem Rechner als auch nach dem Hochladen auf den Server ohne weitere Änderungen.

Ich habe nun alle Pfade zu absoluten Pfaden gemacht (ohne Protokoll und ohne Domain, sie beginnen nun aber alle mit einem "/"). Für den Apachen auf dem Server beginnen damit alle Pfade mit dem Basisverzeichnis der HP. Bluefish bezieht diese Pfade aber nun auf localhost, und nicht wie zuvor auf das lokale Basisverzeichnis, produziert also nur Fehler: Ich kann zwar
"file://localhost/home/<user>/projekteprojektname>/hp-basisverzeichis/index.html"
öffnen, das Bilderverzeichnis (/img/) versucht Bluefish jedoch als "file://localhost/img/" zu öffnen.

Ich habe gestern und heute Stundenlang gesucht dem Bluefish irgendwie die Eingabe eines neuen Basisverzeichnisses abzuringen, in den Projekteinstellungen gib es keine Möglichkeit, falls das unter "Datei/erweitertes öffnen" gehen sollte verstehe ich nicht wie? Auch in der Bluefish Projekt Datei habe ich keine Möglichkeit gefunden, irgendwo eine Pfaderweiterung (von "localhost" auf "localhost/home/<user>/projekte/<projektname>/hp-basisverzeichis/") für die lokale Vorschau anzugeben.

Gibt es hier eine Bluefish user der mir weiterhelfen kann?

[Der Martin]

Hallo,

Ich habe nun alle Pfade zu absoluten Pfaden gemacht (ohne Protokoll und ohne Domain, sie beginnen nun aber alle mit einem "/").

also relativ zum Domain-Root. Gut.

Für den Apachen auf dem Server beginnen damit alle Pfade mit dem Basisverzeichnis der HP.

Nein, für den Apachen nicht, sondern für den Browser, der die Dokumente abruft.

Bluefish bezieht diese Pfade aber nun auf localhost, und nicht wie zuvor auf das lokale Basisverzeichnis, produziert also nur Fehler: Ich kann zwar
"file://localhost/home/<user>/projekteprojektname>/hp-basisverzeichis/index.html"
öffnen, das Bilderverzeichnis (/img/) versucht Bluefish jedoch als "file://localhost/img/" zu öffnen.

Dann gibt es zwei naheliegende Lösungen, gern auch kombiniert.

1. Bringe deinem Editor bei, nicht an den eingegebenen Pfaden rumzuspielen.

2. Richte deinen lokalen Testserver so ein, dass das Projekt direkt unter http://localhost/ liegt, bzw. im gleichen Verzeichnis wie auf dem Server beim Hoster.

Ich habe gestern und heute Stundenlang gesucht dem Bluefish [...] für die lokale Vorschau anzugeben.

3. Verzichte auf die Vorschaufunktion eines Editors, sondern verwende einen richtigen Browser dafür. Besser noch: Mehrere unterschiedliche.

So long,
 Martin

[michaa]

1. Bringe deinem Editor bei, nicht an den eingegebenen Pfaden rumzuspielen.

Das macht er ja gerade nicht. Schön wenn er's täte!

2. Richte deinen lokalen Testserver so ein, dass das Projekt direkt unter http://localhost/ liegt, bzw. im gleichen Verzeichnis wie auf dem Server beim Hoster.

_Das_ ist genau was ich _nicht_ will. Ich will keine server lokal laufen lassen _müssen_ (ich nutze kein php). Ich will meine Projekte im Homeverzeichnis erstellen. Da sie dort mit relativen Pfaden direkt zu betrachten sind, sollte das mit absoluten, auf das Dokument Root bezogenen Pfaden auch _irgendwie_ gehen.

Ich habe gestern und heute Stundenlang gesucht dem Bluefish [...] für die lokale Vorschau anzugeben.

3. Verzichte auf die Vorschaufunktion eines Editors, sondern verwende einen richtigen Browser dafür. Besser noch: Mehrere unterschiedliche.

Mehrere unterschiedliche sowieso, das ist selbstverständlich, aber nicht das Problem.

Ok, da habe ich mich nicht eindeutig ausgedrückt. Bluefish hat keine eigene Vorschau, das geht immer über einen Browser. Aber der öffnet eben
file://localhost/pfad/zu/basedir/index.html ganz korrekt, die darin verlinkten bilder, die in basedir/img/ liegen und beispielsweise den Pfad "/img/pic1.png" haben versucht er aber als file://localhost/img/pic1.png" zu öffen, was natürlich fehlschlägt. Andere Editoren (phase5/win) basteln da ein Prefix (localhost/pfad/zu/basedir) rein.

[Der Martin]

Hallo,

1. Bringe deinem Editor bei, nicht an den eingegebenen Pfaden rumzuspielen.
   Das macht er ja gerade nicht. Schön wenn er's täte!

nein, das wäre für mich nicht akzeptabel.

2. Richte deinen lokalen Testserver so ein, dass das Projekt direkt unter http://localhost/ liegt, bzw. im gleichen Verzeichnis wie auf dem Server beim Hoster.
   _Das_ ist genau was ich _nicht_ will. Ich will keine server lokal laufen lassen _müssen_

Warum nicht? Ich finde es pervers, wenn ich einen Webauftritt, der eigentlich für HTTP gedacht ist, stattdessen "behelfsmäßig" im lokalen Filesystem testen soll. Die Installation eines lokalen Webservers (nackter Apache, XAMPP, IIS) ist kein Hexenwerk, und dann hat man eine wesentlich realistischere Testumgebung.

Ich will meine Projekte im Homeverzeichnis erstellen. Da sie dort mit relativen Pfaden direkt zu betrachten sind, sollte das mit absoluten, auf das Dokument Root bezogenen Pfaden auch _irgendwie_ gehen.

Sicher - aber das Root-Verzeichnis im lokalen Dateisystem ist eben in der Regel ein anderes als das Root-Verzeichnis des HTTP-Servers. Wenn du deine lokale Testumgebung so einrichten kannst, dass file:///local.html wirklich http://local.html entspricht, ist das okay.

3. Verzichte auf die Vorschaufunktion eines Editors, sondern verwende einen richtigen Browser dafür. Besser noch: Mehrere unterschiedliche.
   Ok, da habe ich mich nicht eindeutig ausgedrückt. Bluefish hat keine eigene Vorschau, das geht immer über einen Browser. Aber der öffnet eben
   file://localhost/pfad/zu/basedir/index.html ganz korrekt, die darin verlinkten bilder, die in basedir/img/ liegen und beispielsweise den Pfad "/img/pic1.png" haben versucht er aber als file://localhost/img/pic1.png" zu öffen, was natürlich fehlschlägt.

Dann ist das Prinzip unbrauchbar.

So long,
 Martin

[michaa]

Hi,

2. Richte deinen lokalen Testserver so ein, dass das Projekt direkt unter http://localhost/ liegt, bzw. im gleichen Verzeichnis wie auf dem Server beim Hoster.
   _Das_ ist genau was ich _nicht_ will. Ich will keine server lokal laufen lassen _müssen_

Warum nicht? Ich finde es pervers, wenn ich einen Webauftritt, der eigentlich für HTTP gedacht ist, stattdessen "behelfsmäßig" im lokalen Filesystem testen soll. Die Installation eines lokalen Webservers (nackter Apache, XAMPP, IIS) ist kein Hexenwerk, und dann hat man eine wesentlich realistischere Testumgebung.

Ok, ich komme bei absoluten Pfaden also um einen lokalen Webserver nicht herum. Apache2 ist eh' schon lange installiert (unter Debian/(apto-)sid), also werde ich den nun eben auch nutzen.
Dazu ein paar Fragen, von denen ich hoffe, dass sie hier im Forum beantwortet werden können:

1. Wie kann ich den Apachen so konfigurieren, dass er (aus Gründen der Sicherheit) nur auf lokale Anfragen reagiert.
2. Derzeit ist er so konfiguriert, dass "http://localhost" auf "/var/www/" gemapped ist. Wie und wo konfiguriere ich den Apachen so, dass das DocumentRoot auf /home/<user>/projekt/<name>/<domain.tld>/ liegt? Läßt sich das für verschiedene Projekte verschieden konfigurieren?

[Der Martin]

Hallo,

1. Wie kann ich den Apachen so konfigurieren, dass er (aus Gründen der Sicherheit) nur auf lokale Anfragen reagiert.

indem du darauf achtest, dass der Indianer nur auf dem loopback-Interface 127.0.0.1 lauscht. Das wird über die Listen-Direktive geregelt.
Bei der in viele Einzeldateien zerstückelten Konfiguration[1] von Apache 2.2 steht diese Direktive in /etc/apache2/vhosts.d/00_vhost_default.conf.

[1] Möchte nur wissen, wer auf die blöde Idee gekommen ist, die Konfiguration so unübersichtlich zu verstreuen. Früher hatte man alles kompakt in *einer* Konfigurationsdatei, das war viel praktischer.

2. Derzeit ist er so konfiguriert, dass "http://localhost" auf "/var/www/" gemapped ist. Wie und wo konfiguriere ich den Apachen so, dass das DocumentRoot auf /home/<user>/projekt/<name>/<domain.tld>/ liegt? Läßt sich das für verschiedene Projekte verschieden konfigurieren?

Am besten ist, du legst für jedes Projekt einen vhost an. Das ist in einem eigenen Abschnitt der Apache-Doku gut beschrieben, einschließlich einiger einfacher Beispiele.

So long,
 Martin

[michaa]

Hi,
danke, da werde ich mich nunmal durchbeißen, habe das ja schon früher mal gemacht, nur nutze ich Webserver so selten, dass das gedanklich nie richtig abgespeichert wurde ... und die ja auch von dir kritisierte zerstückelte Konfiguration tut ihr übriges.

M.

[michaa]

Hi,
danke, da werde ich mich nunmal durchbeißen, habe das ja schon früher mal gemacht, nur nutze ich Webserver so selten, dass das gedanklich nie richtig abgespeichert wurde ... und die ja auch von dir kritisierte zerstückelte Konfiguration tut ihr übriges.

M.

Das doofe ist nur, dass es die von dir beschriebenen Verzeichnisse/Dateien bei mir unter Debian nicht gibt. Da stehe ich derzeit etwas auf dem Schlauch, habe das nun nach der deutschen Anleitung gemacht (Diese gibt, im Gegensatz zur englischen, auch an, in _welcher Datei_ die schlauen Angaben vorzunehmen sind ;-).

Deutsche Version

Nach Neustart des Indianers erscheint die Fehlermeldung:
[Wed Feb 02 16:43:15 2011] [warn] NameVirtualHost *:80 has no VirtualHosts

... was nicht weiter verwundert, weil DNS für die vhosts (noch) nicht konfiguriert ist. Ich wollte das durch einen Eintrag in /etc/hosts erledigen, nur weiß ich nicht genau, was ich dort eingeben müsste. Ich speichere meine Projekte ja unter
/pfad/zu/projekt/<domain.tld> ab und der Vhost Eintrag in httpd.conf lautet

<VirtualHost *:80>
ServerName <domain.tld>
ServerAlias <domain.tld> *.<domain.tld>
DocumentRoot /home/user/proj/name/hp/<domain.tld>
</VirtualHost>

Nur wenn ich in der /etc/hosts
127.0.0.1    <domain.tld> (oder muss das localhost.? heißen)
eingeben würde, dann könnte ich (wenn ich das dann mal richtig mache) so die lokale Version erreichen, dafür wäre dann natürlich die reale Domain auf dem entfernten Webserver nicht mehr erreichbar. Muss ich also lokal einen anderen Namen wählen? Was wäre denn sinnvoll?

[michaa]

... nicht dass ich konkrete Hinweise verschmähen würde, aber ich habe hier auf selfhtml die folgende Seite gefunden, die das nach erstem Anschein recht gut beschreibt:
http://aktuell.de.selfhtml.org/artikel/server/apacheconf/apconf06.htm

[Der Martin]

Hallo,

Das doofe ist nur, dass es die von dir beschriebenen Verzeichnisse/Dateien bei mir unter Debian nicht gibt.

ach was, machen die wieder etwas eigenes??

Deutsche Version

Das ist *exakt* dieselbe URL, die ich in meinem letzten Beitrag schon verlinkt hatte. Aber ganz exakt. ;-)

Nach Neustart des Indianers erscheint die Fehlermeldung:
[Wed Feb 02 16:43:15 2011] [warn] NameVirtualHost *:80 has no VirtualHosts
... was nicht weiter verwundert, weil DNS für die vhosts (noch) nicht konfiguriert ist.

Das eine hat mit dem anderen nichts zu tun. Aber ich werde ehrlich gesagt aus dieser Meldung auch nicht schlau. Google führt mich aber zum Apache-Wiki - hast du die Direktive NameVirtualHost mehrmals in der Config?

Ich wollte das durch einen Eintrag in /etc/hosts erledigen, nur weiß ich nicht genau, was ich dort eingeben müsste.

In der hosts-Datei stehen Zeile für Zeile je eine IP-Adresse und dahinter, durch Leerzeichen oder Tabs abgetrennt ein oder mehrere Domainnamen, für die diese IP gelten soll. Trägst du also zum Beispiel ein:

127.0.0.1  holiday.local holiday.de

... dann wird dein Rechner künftig die Domainnamen holiday.local und holiday.de "bei sich selbst" suchen. Was natürlich zur Folge hat, dass du holiday.de im öffentlichen Internet nicht mehr erreichen kannst.
Konkret also: Lege einen Domainnamen fest, unter dem du die lokale Entwicklungsversion deines Projekts ansprechen willst. Trage diesen Domainnamen sowohl als ServerName im zugehörigen Apache-VHost ein, als auch in der hosts-Datei zur IP 127.0.0.1, wie oben demonstriert. Das sollte alles sein.
Der Apache braucht einen Neustart, damit er die geänderte Konfiguration zur Kenntnis nimmt; die Änderungen in der hosts-Datei werden sofort wirksam.

<VirtualHost *:80>
ServerName <domain.tld>
ServerAlias <domain.tld> *.<domain.tld>
DocumentRoot /home/user/proj/name/hp/<domain.tld>
</VirtualHost>

Den ServerName unter ServerAlias nochmal zu wiederholen, ist unnötig. Ansonsten sieht das plausibel aus, aber es fehlt noch ein Directory-Container. Bei mir sehen die Virtual Hosts ungefähr so aus:

<VirtualHost *:80>
ServerName example.local
ServerAlias www.example.local
ServerAdmin me@localhost

DocumentRoot "/server/web/example.com"

<Directory "/server/web/example.com">
   Options Indexes FollowSymLinks
   AllowOverride All
   Order allow,deny
   Allow from all
</Directory>

<IfModule mpm_peruser_module>
ServerEnvironment apache apache
</IfModule>
</VirtualHost>

Die letzten drei Zeilen sind Teil der Defaultkonfiguration; ich habe noch nicht darüber nachgedacht, ob sie sinnvoll oder gar nötig sind.

Nur wenn ich in der /etc/hosts
127.0.0.1    <domain.tld>
eingeben würde, dann könnte ich (wenn ich das dann mal richtig mache) so die lokale Version erreichen, dafür wäre dann natürlich die reale Domain auf dem entfernten Webserver nicht mehr erreichbar.

Richtig. Eine geht nur. ;-)

Muss ich also lokal einen anderen Namen wählen? Was wäre denn sinnvoll?

Sinnvoll und nötig. Bewährt hat sich zum Beispiel die Konvention, für die lokale Testversion die TLD des öffentlichen Servers durch ".local" zu ersetzen.

So long,
 Martin

[michaa]

Deutsche Version

Das ist *exakt* dieselbe URL, die ich in meinem letzten Beitrag schon verlinkt hatte. Aber ganz exakt. ;-)

Ja, hast recht, ich meinte den anderen Link, ist aber doppelt egal, weil ich mit der doku dort eh' nicht zurecht gekommen bin, ganz im Gegensatz zu Beschreibung hier auf Selfhtml (im zwischenzeitlichen Posting verlinkt).
Laut dieser Beschreibung reicht jedoch das Limitieren auf lokale IPs _nicht_ um den Apachen nach Aussen unsichbar zu machen! Muss ich noch schaun, ob das nicht schon im Router geblockt ist.

Danke an selfhtml.org ,super Beschreibung!

Den ServerName unter ServerAlias nochmal zu wiederholen, ist unnötig. Ansonsten sieht das plausibel aus, aber es fehlt noch ein Directory-Container. Bei mir sehen die Virtual Hosts ungefähr so aus:

<VirtualHost *:80>
ServerName example.local
ServerAlias www.example.local
ServerAdmin me@localhost

DocumentRoot "/server/web/example.com"

<Directory "/server/web/example.com">
   Options Indexes FollowSymLinks
   AllowOverride All
   Order allow,deny
   Allow from all
</Directory>

<IfModule mpm_peruser_module>
ServerEnvironment apache apache
</IfModule>
</VirtualHost>

Danke auch für deine Beschreibung, die hat die letzte Frage beantwortet bevor ich sie gestellt habe: Bei mir klappte der Zugriff zunächst wegen einer .htaccess Datei mit dort konfiguriertem mod_rewrite nicht. Nach Aktivierung des entsprechenden Moduls und Anlegen eines entsprechenden Directory-Containers klappt nun der direkte Browserzugriff auch mit aktiver .htaccess .

Nun muss ich das  nur noch in Bluefish entsprechend hinbekommen, aber das scheint mir nun machbar.

Die letzten drei Zeilen sind Teil der Defaultkonfiguration; ich habe noch nicht darüber nachgedacht, ob sie sinnvoll oder gar nötig sind.

Bei mir fehlen die und es klappt dennoch.

Sinnvoll und nötig. Bewährt hat sich zum Beispiel die Konvention, für die lokale Testversion die TLD des öffentlichen Servers durch ".local" zu ersetzen.

Ok, selfhtml.org bevorzugt wohl ".test" was mir beides sinnvoll erscheint, ".local" vielleicht noch etwas mehr, aber egal es klappt ja wohl beides.

Danke nochmal

M.

[Beat]

_Das_ ist genau was ich _nicht_ will. Ich will keine server lokal laufen lassen _müssen_ (ich nutze kein php).

Dann akzeptiere, dass ein Browser bei file:/// immer ein Laufwerk als Docroot sieht. Das ist offensichtlich nicht, was du willst, wenn du absolute Pfade im HTML setzt.

mfg Beat

[tk]

Hallo,

Neben dem Gesagten:

Ok, da habe ich mich nicht eindeutig ausgedrückt. Bluefish hat keine eigene Vorschau, das geht immer über einen Browser. [...]

d.h. das Problem hat absolut nichts mit Bluefish zu tun, sondern das "Problem" liegt einzig und alleine an den Browsern. Problem in Anführungszeichen da der Browser ja garnicht wissen kann was du mit / meinst - aber du hast ja schon gemerkt, dass der Einsatz eines lokalen Apachen durchaus sinnvoll ist.

Gruß,
Tobias