Design wird nicht geladen!

Das Problem ist, das über diese "Heimserver"-Dienste (wie no-ip.de; heimserver.de etc.pp.) in der Regel Deine Seite innerhalb eines Frames nach außen geladen wird. Das selbe Problem habe ich mit meinem eigenen Heimserver auch. Habe mir damit beholfen in den header.php eine ip-weiche einzubauen.

if($_SERVER('SERVER_ADDR') == $_SERVER['REMOTE_ADDR']) 
{
/* Hier folgt das normale html-link-Tag im Header um die CSS-Datei anzugeben. Man arbeitet lokal */ 
} else {
echo '<style=.....'; // Hier kommt der normale Tag zur Einleitung der ins HTML integrierten Style-Angaben hin
// jetzt mit geeigneten PHP-Befehlen die CSS-Datei auslesen und per Echo hier ausgeben.
echo '</style>'; // Das ganze muß innerhalb des Headers geschehen }

Detailierter kann ich jetzt nicht darauf eingehen, weil ich auf der Arbeit sitze.

vG

Arno

Hi Babbix,

sorry, dein "no-ip.info"-Dienst arbeitet etwas anders als "heimserver.de" (wo ich bin) und routet die Inhalte geradewegs durch, was auch besser so ist ;) Bei heimserver.de werden die Inhalte zunächst einmal abgefangen und dann weitergegeben, wodurch sich weitere Arbeiten, als das was ich gleich beschreibe, ergeben.

Du hast Deine Seite auf dem Localhost aufgesetzt, wodurch unter anderem in der Tabelle wp-options die beiden Einträge "siteurl" und "home" auf localhost eingetragen wurden.

Beim Aufruf aus dem Internet wird Dir zwar jetzt Dein Content, welcher aus den $_GET-IDs ermittelt wird, korrekt ausgegeben, alle anderen URL-Angaben werden jedoch aus der Datenbank generiert - auch die Urls für das Style-Sheet und für die auszugebenden Grafiken.

Um jetzt sowohl auf dem Localhost als auch aus dem Internet heraus arbeiten zu können, muß WordPress registrieren, von wo es denn nun aufgerufen wird, um die beiden oben genannten Einträge in der wp-options so einstellen zu können, das es einerseits vom Localhost und andererseits aus dem Internet heraus funktioniert.

Dazu ist 1. ein kleiner Hack in der /blog/wp-blog-header.php notwendig. Füge dafür ziemlich am Anfang der Datei zwischen

$wp_did_header = true;
 
$query_vars = array();

folgendes

require_once( dirname(__FILE__) . '/as-switch.php');

ein, so das diese Stelle nun so

$wp_did_header = true;
require_once( dirname(__FILE__) . '/as-switch.php');
$query_vars = array();

aussieht.

Der 2. Schritt:
In der WordPress-Root (Verzeichnis /blog/ setze ich jetzt hier mal vorraus, anderes mußt Du anpassen), in welcher auch die wp-blog-header.php liegt, legst Du jetzt eine Datei
as-switch.php an und fügst folgenden Quelltext ein:

<?php 
global $wpdb;
if($_SERVER['SERVER_ADDR'] != $_SERVER['REMOTE_ADDR'])
{
$erg = $wpdb->query("UPDATE $wpdb->options "
." SET option_value = 'http://babbix.no-ip.info/blog/'"
." WHERE option_name = 'siteurl'");
//echo $erg.'x siteurl auf heimserver.de gesetzt...</br>';
$erg = $wpdb->query("UPDATE $wpdb->options "
." SET option_value = 'http://babbix.no-ip.info/blog/'"
." WHERE option_name = 'home'");
//echo $erg.'x home auf heimserver.de gesetzt...</br>';
}
else
{
$erg = $wpdb->query("UPDATE $wpdb->options "
." SET option_value = 'http://localhost/blog/'"
." WHERE option_name = 'siteurl'");
//echo $erg.'x siteurl auf localhost gesetzt...</br>';
$erg = $wpdb->query("UPDATE $wpdb->options "
." SET option_value = 'http://localhost/blog'"
." WHERE option_name = 'home'");
//echo $erg.'x home auf localhost gesetzt...</br>';
}
?>

Dieses Coding prüft nun, ob Deine WebSite aus dem Internet oder Lokal von Deinem Rechner aufgerufen wird. Je nach dem von wo aus Deine Seite aufgerufen wird, werden nun die beiden oben genannten Einträge in Deiner Datenbank zwischen den Internet und dem Localhost hin und her geschaltet, so das auch die Urls für Grafiken und das Stylesheet dementsprechend angepasst werden.

Du siehst, es ist letztlich ein IP-Problem und kein Style-Problem ;)

vG

Arno

[edit]ein zuviel gepastetes require_once entfernt[/edit]

es kann sein, das die neuen Inhalte in der DB etwas zu spät "verfügbar" sind (caching), dann muß man nochmal per F5 refreshen. ich teste es auch gerade von 2 rechnern aus. dauert noch ein paar minuten.

vG

Arno

den effekt hatte ich auch. habe gerade mal nachgesehen, ob es einen besseren Ort für den hack als die wp-blog-header.php gibt und den gibt es.

nimm ihn dort heraus und setze ihn in die wp-settings.php. Ab Zeile 70 (WP1.5.2) findest Du dort folgendes Coding:

$wpdb->postmeta         = $table_prefix . 'postmeta';


if ( defined('CUSTOM_USER_TABLE') )

Dazwischen setzt Du jetzt das require_once:

$wpdb->postmeta         = $table_prefix . 'postmeta';


require_once( dirname(__FILE__) . '/as-switch.php');


if ( defined('CUSTOM_USER_TABLE') )

Du darfst aber nicht erwarten, vom selben Rechner aus via LocalHost _und_ via Internet auf Deine Seite zugreifen zu können, das geht nicht. Wenn Du am Localhost-Rechner bist, mußt Du via Localhost arbeiten und von anderen via Internet - auch wenn Du Dich in einem lokalen Netzwerk befindest! Andernfalls müßte die IP-Weiche noch so umgebaut werden, das Dein lokales Netzwerk Berücksichtigung findet und das ist nun doch für den Moment mit Kanonen auf Spatzen geschossen...

vG

Arno

PS und welchen Effekt erzielen wir durch das Umsetzen des Hacks?

Der Hack greift an einer früheren Stelle ein, nämlich unmittelbar nach Aufbau der Verbindung zur Datenbank, wenn noch keinerlei Links etc. generiert wurden. Dadurch stehen die neuen Daten jetzt früh genug in der DB um Einfluß auf die soeben gestartete Seite zu haben.

Ich war bis gerade eben noch fleißig und habe hier eine Zusammenfassung des ganzen eingestellt. Wird vielleicht für den ein oder anderen besser zu lesen sein, wenn er alle Änderungen im Zusammenhang sieht.

vG

Arno

Hallo zusammen

Ich habe dieses Thema mit grossem interesse durchgelesen und habe es gleich auf der Version 2.0 versucht, leider ohne erfolg:( .

Ich bräuchte allerdings eine lösung für ein internes Netztwerk 192.168.0.xxx, localhost und von extern (internet) über eine fixe ip 213.xxx.xxx.xxx

Da meine Tochter teilweise von ihrem Rechner im lokalen Netzwerk und unter der woche von der UNI aus daran arbeiten möchte währe dies eine tolle lösung.

Im moment behelfe ich mir mit ändern der IP im admin modul.

Herzliche Grüsse
Peter

Hallo babbix,
hallo Peter,

ich habe den Hack überarbeitet. Er steht jetzt unter o.g. URL in neuer Fassung (für 1.5.2 und für 2.0) auf meiner WebSite. Die Zusatzdatei hat eine gelinde Umstrukturierung für die neue Version erfahren - und ist für Bequeme als Download mit dabei.

Pet,

was das lokale Netzwerk angeht: Probiere es bitte (mit entsprechendem vorherigen Backup des Localhosts) aus und gib mir dann bescheid, wie das Ergebnis aussieht. Ich habe hier derzeit leider keine Möglichkeit das zu testen - einfach in Ermangelung eines funktionstüchtigen Netzwerks....

Wenn ich jemanden finden würde der mir hilft das zu Konfigurieren, wäre das schon'ne feine Sache.... Linux und ein passender Rechner für den Server/Router liegen bereit.... Leider habe ich nicht die Zeit mich komplett in alles von Grund auf einzuarbeiten....

vG

Arno

Hallo Arno

Herzlichen Dank für Deine Mühe, ich werde das gerne testen. Benötige dafür aber ein wenig Zeit. Ich melde mich auf alle fälle.

Herzliche Grüsse aus der Schweiz

Peter

Hallo Arno

Ich habe den hack gemäss deinen erläuterungen gemacht und es funktioniert so nicht. Vermutlich verstehe ich die Terminologie nicht. Hier was ich gemacht habe in as-switch.php

global $wpdb;
$local_host = 'http://localhost/meinverzeichnis/wp';
$extra_host = 'http://externeip/meinverzeichnis/wp';
$actual_host = $wpdb->get_var("SELECT option_value ".
" FROM $wpdb->options ".
" WHERE option_name = 'siteurl'");

Wenn ich nun so die seite von extern aufrufe dann läuft es dort auch so, ich kann ebenfalls ins admin menu und dort wird die externe IP unter optionen reingeschrieben auch wenn ich dort manuell z.B localhost eingebe, mit dem hack schreibt er mir das rein was unter $extra_host eingetragen ist, auf dem localhost funktioniert's dann nicht mehr.

Wenn ich das richtig interpretiere müsste doch $extra_host eben der zweite host sein oder sehe ich das falsch?

Herzliche Grüsse Peter

Bei allem Respekt vor diesem "MonsterHack",
versteh ich den Sinn nicht bzw. kann den enormen Aufwand nicht nachvollziehen.

Ich muss lediglich APACHE in der httpd.conf sagen wo es lang geht, zum Root-Verzeichnis.
Like this:

[FONT="Lucida Console"]
<VirtualHost *:80>
ServerName maschine
ServerAlias maschine *.maschine
DocumentRoot "C:/APACHE/xampp/htdocs/www/"
</VirtualHost>
[/FONT]

( Wobei "maschine" = Beispiel Rechnername )

Wenn Wordpress unter /htdocs/www/wordpress/ installiert wurde,
ist es jetzt unter der Adresse
http://maschine/wordpress/
erreichbar.

Zugriffe von aussen sofern vom LAN-Router unterstützt ( NAT/Virtueller Server/DYNDNS )
und man einen Account irgendeines DYN DNS Dienstes sein eigen nennt, dann so:
http://irgendeine_domain/wordpress/

Der Witz an der ganzen Sache sind die absoluten Pfadangaben von Wordpress im Admin-Bereich.
Werden diese durch relative Pfadangaben ersetzt, ist es völlig egal von wo aus ich Zugreife.
Ob nun von "aussen" http://irgendeine_domain/wordpress/ oder lokal unter http://maschine/wordpress/
die relativen Pfadangaben passen immer, auch das Stylesheet passt.

Weil nun das Root-Verzeichnis /htdocs/www/ ist, und man sich schon auf "höchster Ebene" befindet,
kommt man nicht mehr auf die lokale XAMPP-Seite, dafür wird einfach ein neuer ALIAS in der httpd.conf angelegt.

[FONT="Lucida Console"]Alias /xampp "C:/Apache/xampp/htdocs/xampp/"
<Directory "C:/Apache/xampp/htdocs/xampp">
AllowOverride None
Order allow,deny
Allow from all
</Directory>[/FONT]

Und die XAMPP-Seite ist wieder erreichbar : http://maschine/xampp/

Sehe ich das irgendwie verkehrt, habe ich was vergessen ?
So läufts bei mir problemlos ohne "Hack".

( btw.: Das, dass ganze bei einem DSL-Upload von 128 kbit / sec keinen Sinn macht, sei mal dahingestellt.
Spätestens wenn sich 3 User auf dem Virtuellen Server austoben wirds eng und man ist wieder bei MODEM-Speed. )

mag ja alles schön und richtig sein, was ich jetzt nicht teste, weil mein weg genausogut läuft ohne das ich die apacheconfig ändern müßte... und es geht (mir jedenfalls) nicht darum zu hause seinen server für andere zur verfügung zu stellen ;)

da mir der von dir oben erklärte weg nicht bekannt war, bin ich den weg des für mich geringsten wiederstands gegangen.... mich großartig in die konfiguration des apachen einzuarbeiten, habe ich weder zeit noch lust, sondern mache nur das was mir notwendig erscheint...

und soooo monstermäßig ist der hack auch nicht, immerhin wird nur an einer stelle eine bekannte zeile eingefügt, welche sich leicht wieder herstellen läßt, wenn man ein update oder sonstwas fährt....

ausserdem, was soll ich mir 2 potentielle fehlerquellen einhandeln, wenn nach meinem dafürhalten eine ausreicht ;)

vG

Arno

ps bei der geschwindigkeit kommts darauf an, was übertragen wird ;) in meinem fall sinds höchstens ein paar kb, weil das theme das ich von hier aus teste(n lasse) eigentlich keine grafiken enthält.....