Frage betreffend Installation vor Nameservereintrag

  • Folgendes:

    Ich habe im Moment ja schon eine bestehende Website: http://www.tascha.ch

    Nun habe ich den Host gewechselt und möchte zuerst natürlich das neue Layout einrichten, before ich die Nameserveränderung weiterleite.

    Ich bin mir nun aber nicht sicher, wie das gehen soll. Ich habe beim neuen Host ja im Moment einen hilfslink der von wordpress dann ja so übernommen wird. Das heisst, sobald der Nameservereintrag geändert wird, funktioniert dann nichts mehr, da wordpress überall einen anderen link drin hat?

    Ich glaub ich verstehe das ganze dahinter nicht so ganz...
    Kann mir da jemand einen typ geben, wie ich das ganze am besten anpacke?

    Danke schon mal ganz herzlich im Voraus :D

    • Anzeige

    Hallo!

    Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

    • ✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
    • ✔️ Deutsche Server & DSGVO-konform
    • ✔️ Persönlicher Support (kein 0815-Ticket-System)

    Mehr erfahren

  • Ich vermute mal, mit "Hilfslink meinst Du sowas wie "http://user1234.someserver.com/". Dann vermute ich mal, hast Du das auch in den WordPress-Optionen so eingetragen.

    Sollte es so sein, dann ist das überhaupt kein Problem. Du kannst nach dem Domainumzug, wenn Du die Datenbank und die Dateien transferiert hast, einfach die neue Domain via phpMyAdmin o.ä. setzen.

    Du solltest nur darauf achten, dass Du bei manuell angelegten internen Links eine relative und keine absolute URL angibst (also nicht "http://user1234.someserver.com/blabla/blubb" sondern "/blabla/blubb"). So sparst Du Dir ne Menge Arbeit.

    edit: Eine schöne Seite hast Du übrigens. Bist Du sicher, dass Du es noch besser machen kannst? ;)

    Einmal editiert, zuletzt von mastermind (5. April 2006 um 13:53)

  • Ja genau :)

    Und das heisst - ich müsste den Domainnamen mit suchen und ersetzen in der SQL Datei ändern, oder wie genau meinst du das?

  • Wenn Du mit SQL-Dumps arbeitest, ja. Aber das wirst Du vermutlich eh machen, wenn Du den Server wechselst.

    Es sind übrigens ganze zwei Einträge, die in der Tabelle "wp_options" zu ändern sind.

  • Das hat nun super geklappt danke :)
    Hatte trotzdem (und habe) ne Menge Arbeit, da ich leider meistens mit absoluten Links gearbeitet habe..

    Im Moment habe ich ein anderes php Problem.
    Seit ich beim neuen Host bin sehe ich diese Message, wenn ich meinee Seite zum ersten mal lade:

    PHP
    ob_start(): output handler 'ob_gzhandler' cannot be used after 'URL-Rewriter' in /*****/*****/*****/*****/*****.php on line 829


    Das hat mit der Kompression zu tun denke ich?
    Ich habe versucht die Message nicht anzeigen zu lassen, da ich sonst keine Fehler auf der Seite habe und das ganze sonst gut funktioniert.

    Sollte dieser code in der index.php die fehlermeldungen nicht unterdrücken?
    Oder mache ich da was falsch?

    PHP
    <?php ini_set ('display_errors', '0');
    ini_set ('error_reporting', '0'); ?>

    habe gerade eine antwort dazugefunden - danke - suche hilft!

    Einmal editiert, zuletzt von Tascha (7. April 2006 um 13:04)

  • Trotzdem eine Frage dazu:

    ich habe gzip nun deaktiviert und keine Fehlermeldung mehr. Aber die Seite lädt nun wieder viel langsamer in FF.
    Gibts da nicht eine Möglichkeit das ganze doch laufenzulassen und die Fehlermeldung auszublenden?

  • Also, Fehler zu "unterdrücken" halte ich grundsätzlich für keine so tolle Idee. Wie wär's mit einer Fehleranalyse?

    Vielleicht sollten wir zunächst mal schauen, ob Dein PHP überhaupt zlib-Untestützung hat. Kannst Du bitte mal aus der phpinfo-Ausgabe den Bereich "Configure command" posten? Und: hat Dein Apache das "mod_gzip" installiert?

  • Hier die Ausgabe:

    Zitat

    './configure' '--prefix=/usr/local/php4' '--with-layout=GNU' '--enable-versioning' '--enable-memory-limit' '--enable-discard-path' '--with-zlib-dir=/usr' '--with-regex=php' '--disable-all' '--disable-pear' '--enable-bcmath' '--with-bz2=/usr' '--enable-calendar' '--enable-ctype' '--with-curl=/usr/local' '--with-dom=/usr/local' '--with-dom-xslt=/usr/local' '--with-dom-exslt=/usr/local' '--enable-exif' '--enable-ftp' '--with-gd=/usr/local' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/local' '--with-t1lib=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-gettext=/usr/local' '--with-iconv-dir=/usr/local' '--with-mcrypt=/usr/local' '--with-mhash=/usr/local' '--with-mime-magic=/usr/share/misc/magic.mime' '--with-ming=/usr/local' '--with-mysql=/usr/local' '--with-ldap=/usr/local' '--with-openssl-dir=/usr' '--with-openssl=/usr' '--enable-overload' '--with-pdflib=/usr/local' '--with-pcre-regex=yes' '--enable-posix' '--enable-session' '--enable-sockets' '--enable-wddx' '--with-expat-dir=/usr/local' '--enable-xml' '--with-xmlrpc' '--enable-xslt' '--with-xslt-sablot=/usr/local' '--with-zip=/usr/local' '--with-zlib=yes' '--with-imap=/usr/local' '--with-imap-ssl=/usr/local'


    Betreffend Apache: Das weiss ich leider nicht, kann ich das wo nachschauen?
    Was ich in dem Zusammenhang gefunden habe war in Environment und php variables:

    _SERVER["HTTP_ACCEPT_ENCODING"]gzip,deflate und

    Einmal editiert, zuletzt von Tascha (7. April 2006 um 13:41)

  • Zitat von Tascha

    Hier die Ausgabe:
    [...]

    Also zlib-Support scheint drin zu sein. Dann hab ich zunächst auch keine Idee.

    Aber mal was anderes: Warum möchtest Du überhaupt über PHP komprimierte Inhalte ausliefern? Es belastet Server und Client unnötigerweise, und gerade *die* Inhalte, für die es auf Deiner Website am interessantesten wäre (nämlich die Bilder) komprimiert PHP eh nix. Außerdem sind JPEGs ja schon komprimiert, da ist also nicht viel zu holen.

    Zitat von Tascha

    Betreffend Apache: Das weiss ich leider nicht, kann ich das wo nachschauen?

    Das kommt auf Deine Linux-Distribution an. Standardmäßig in /etc/apache2/modules.d müsste eine Konfigurationsdatei für das Modul sein. Falls die nicht da ist, fehlt aller Wahrscheinlichkeit nach auch das Modul. Ein "locate mod_gzip" sollte ggf. das Modul selbst ausfindig machen.

    Worauf ich mit dem Apache hinaus will: Wenn Du unbedingt komprimieren willst, dann wäre es sinnvoller mit Apache. Denn der komprimiert *alles*, was er ausliefert, und es gibt keine Probleme mit instabilen gzip-Implementationen wie offenbar in WordPress.

  • Alles klar - vielen Dank für die Hilfe :)

    Ich werde mich mal erkundigen betreffend dem offensichtlich fehlenden Modul. Konnte keine solche Datei finden im etc

    Nun trotzdem noch zu meiner php code frage.
    Der Code, den ich versuchen wollte, war das was falsch? Zum Unterdrücken der Fehlermeldung im Browser.

  • Zitat von Tascha

    Ich werde mich mal erkundigen betreffend dem offensichtlich fehlenden Modul. Konnte keine solche Datei finden im etc

    Das Modul wird normalerweise separat installiert. Wenn Du magst, kannst Du in Deinem Paketmanager nachschauen, ob das Modul installiert ist. Wenn Du es installierst, wird es mit Sicherheit auch direkt aktiviert.

    Zitat von Tascha

    Nun trotzdem noch zu meiner php code frage.
    Der Code, den ich versuchen wollte, war das was falsch? Zum Unterdrücken der Fehlermeldung im Browser.

    Vielleicht hilft Dir folgende Seite (bevor ich sie ganz abschreibe ;)): http://de.php.net/error_reporting

  • Zitat von mastermind


    edit: Eine schöne Seite hast Du übrigens. Bist Du sicher, dass Du es noch besser machen kannst? ;)


    die tascha, jetzt in wordpress unterwegs, nice...

    ja, das design war auch vorher immer schon sehr ansprechend...
    besser machen muss sie nur den xhtml-code

    alt-attribute, nicht geschlossene tags etc.
    dann wirds perfect
    LG Frank

  • Zitat

    edit: Eine schöne Seite hast Du übrigens. Bist Du sicher, dass Du es noch besser machen kannst?


    Uups, das edit hatte ich gar nicht gesehen . Vielen Dank für das Kompliment und auch nochmals für all die Hilfe :)

    Zitat

    die tascha, jetzt in wordpress unterwegs, nice...

    ja, das design war auch vorher immer schon sehr ansprechend...
    besser machen muss sie nur den xhtml-code

    alt-attribute, nicht geschlossene tags etc.


    Oh wah, hallo? Kennen wir uns? :D
    Meine Seite ist schon eine ganze Weile wordpress kompatibel. An den Alts arbeite ich gerade und nicht geschlossene Tags, da bin ich mir nicht sicher, ist da nicht wordpress schuld? :p

    Nebenbei - blah soviele falsche Links nun. Das ist meine Strafe für eine total chaotische Filestruktur beim alten Server. Mache es nun besser, aber das heisst auch ne Menge Nacharbeit, vorallem da Switch viel zu schnell war :D

    Einmal editiert, zuletzt von Tascha (7. April 2006 um 18:55)

  • die Devbar hatte ich schon :)
    Nur leider sagen mir die Fehlermeldungen bei der XHTML Validierung nicht gerade viel.. :confused:
    Würde eigentlich die Fehler gerne korrigieren.

    Danke für die Nachricht Frankie :)

    Mastermind:
    das mod_gzip ist nun installiert. Das sollte nun von alleine laufen oder? Oder muss ich da nun was machen?

  • Zitat von Tascha

    Mastermind:
    das mod_gzip ist nun installiert. Das sollte nun von alleine laufen oder? Oder muss ich da nun was machen?

    Jep, das läuft schon:

    "Content-Encoding: gzip" ist das Zauberwort. ;) Das heißt Du kannst jetzt das PHP-gzip abschalten, wenn Du magst.

    Was das Validieren angeht: da wird sich einiges lichten, wenn erstmal die dämliche PHP-Fehlermeldung verschwunden ist.

    Einmal editiert, zuletzt von mastermind (10. April 2006 um 17:53)

  • dankeschön :)

    ich habe das gzip unter den options wieder herausgenommen bei WP.
    Irgendwie ist das mit gzip in Wordpress aber doch extrem viel schneller - zumindest mit Firefox.

  • Ich weiß nicht, ob das PHP-gzip auf Deiner Seite überhaupt richtig aktiviert war... vielleicht war es auch nur deshalb in Firefox schneller, weil zwar die Datenmenge größer war, diese jedoch nicht mehr dekomprimiert werden musste? Wenn Du z.B. eine schnelle Leitung, aber einen älteren Rechner hast, ist das sehr wahrscheinlich.

    Bei mir kommen Deine Inhalte jedenfalls nach wie vor flink an.

    (Aus diesem Grund finde ich übrigens, dass das Komprimieren von Webinhalten nicht immer von Vorteil ist.)

  • dann ist ja gut :) wenn die Seite nicht zu lang hat zum laden.
    Ich nutze eure Hilfsbereitschaft nun gleich nochmals aus (solange ich niemandem auf die Nerven gehe :D)

    Betreffend Validierung gibt er mir Fehler in Bezug auf meine Header links an.

    PHP
    a href="?page_id=2/&PHPSESSID=071c88941b1f9de8993cc3ab27a16ff9"

    ich weiss nicht, woher die phpsessid mit der nummer dahinter generiert wird, aber offenslichtlich hat der validierer mit dem = und dem & Mühe
    Die url im header sieht eigentlich ganz normal aus <a href="?page_id=2>blablah</a>

    wie kann ich diesen Fehler denn korrigieren und was genau läuft da schief?

  • Zitat von Tascha

    dann ist ja gut :) wenn die Seite nicht zu lang hat zum laden.
    Ich nutze eure Hilfsbereitschaft nun gleich nochmals aus (solange ich niemandem auf die Nerven gehe :D)


    Passt scho :)

    Zitat von Tascha

    wie kann ich diesen Fehler denn korrigieren und was genau läuft da schief?


    Har, har, har. Das Problem ist einfach zu beschreiben -- nur die Lösung könnte kompliziert werden.

    Das Problem ist folgendes: Im Quelltext müssen alle &-Zeichen als &amp; maskiert werden, auch in URLs. Das Problem bei Dir ist, dass Deine URLs offenbar automatisch generiert sind, und man sinnvollerweise auch automatisch die &-Zeichen konvertieren würde.

    Die Lösung könnte beispielsweise darin bestehen, dass man sich ein kleines Plugin zimmert, welches letztendlich alle nicht maskierten HTML-eigenen Zeichen konvertiert. (Darf ich evtl. fragen, welches Plugin (und wozu) Du verwendest, um einen Session-Handler in der URL zu haben?)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!