Beiträge von helix

    Das ist eine gute und evtl. zielführende Frage. Also: ich weiß es nicht. Aber …

    … wenn es an deinem Redirect-Befehl liegen würde, dann müsste das System konsequent immer den Slash hinter der tld „fressen“.

    Also würde ich eher danach suchen, ob du ein Muster findest, in welchen Fällen der Slash verschwindet – und was an diesen Links anders ist, was WordPress da anders macht / anders ausgibt …

    Oder ist dir beim Anpassen der Domains in der Datenbank der eine oder andere Slash abhanden gekommen? (Alles nicht schlimm, Fehler sind dazu da, gemacht zu werden.)

    Gruß
    helix

    Hallo Bilalkass,

    habe nun das ganze hinbekommen mit dem redirect! aber geht man nun auf domain A , kommt man auf Domain A , klickt man dann aber rum, kommt man wie gewollt auf domain B..

    Aber wieso funktioniert es nicht dierekt, das man auf domain A klickt und sich sofort domain B öffnet. ?

    Das ist genau das, was ich gestern beschrieben habe. Und deswegen hatte ich ganz zu Beginn vorgeschlagen:

    Die neue Domain auf den Ordner routen, in dem WordPress liegt. (Und in der Datenbank vom WordPress müssen selbstverständlich die Adressen geändert werden etc.)
    Die alte Domain dann entweder auf einen anderen Ordner routen, in dem die passende htaccess (mit entsprechendem 301-redirect) liegt. Oder direkt in der Webspace-Verwaltung per 301-redirect auf die neue Domain umleiten. <= Auf die Schnelle habe ich jetzt nix gefunden, dass das bei Strato so direkt in der Webspace-Verwaltung gehen würde. Aber vielleicht kennt sich da ja jemand besser aus …

    Anders herum: Wenn du eine Weiterleitung innerhalb der Strato-Webspaceverwaltung nicht mit saubererm r301 von der alten auf die neue Domain machen kannst, dann route besser die alte Domain auf einen eigenen Ordner, in dem eine htaccess liegt, die nur den Redirect von alter Domain auf neue Domain macht.

    Mit noch ein bisschen Hintergrund: Die gewöhnliche Weiterleitung (von Strato und anderen) bewirkt erstmal nur, dass die Inhalte der Domain, auf die weitergeleitet wird, auch unter der weitergeleiteten Domain erreichbar sind. Also nix anderes als das Routing auf einen ausgewählten Ordner, nur anders adressiert.
    Dass nicht alle Unterseiten unter beiden Domains erreichbar sind, verhindert WordPress, weil es mit absoluten Links arbeitet.

    Und wie Hille schon geschrieben hat, der 301-Redirect („moved permanently“) macht nicht nur die Weiterleitung vollständig und sofort auf die neue Seite, sondern „sagt“ es auch Google und anderen automatisierten Systemen.

    Gruß
    helix

    Dann hängt es ziemlich sicher an diesem Cache-PlugIn, das, wenn ich das richtig verstehe, nicht deaktiviert war, als du den Umzug probiert hast.

    Ich würde: PlugIn jetzt deaktivieren. Browsercache leeren, Seite aktualisieren, schauen, ob es funzt.
    Wenn net: Datenbank überprüfen, ob wirklich überall die neue Domain drinsteht.

    Wenn es dann immer noch nicht geht (vielleicht hast du das auch schon alles?), sehen wir weiter.

    Gruß
    helix

    Also, nochmal langsam, damit klar ist, welcher Schritt wofür gut ist.

    Ausgangspunkt ist: du hast Webspace bei Strato, du hast Domain A wie Alte Domain und Domain B wie beue, äh neue Domain. Beide Domains sind dem gleichen Webspace / Webpaket zugeordnet.
    Außerdem hast du auf deinem Webspace einen Ordner, in dem WordPress liegt (und bereits läuft).

    Bisher war Domain A auf den WordPress-Ordner geroutet.

    Um die Domainänderung zu bewerkstelligen, routest du dann zusätzlich auch Domain B auf den WordPress-Ordner.

    Solange du innerhalb deines WordPress, d.h. in der Datenbank, die Domain noch nicht geändert hast, kannst du unter Domain B dein WordPress aufrufen – mindestens die Startseite –, aber sobald du innerhalb des WordPress einen Link klickst, dich anmeldest oder sonstwas, bist du wieder auf Domain A.

    Um also WordPress wirklich unter Domain B erreichbar zu machen, müssen alle Einträge der alten Domain in der Datenbank durch die neue Domain ersetzt werden. Wenn das vollständig gemacht ist, gibt es keine Probleme, alle Navigationsmenüs funktionieren richtig, anmelden im Admin-Bereich etc.

    Wenn das gemacht ist, musst du dich um Domain A kümmern. Denn jetzt hast du das Phänomen, dass du die Seite unter Domain A zwar erreichst, aber wirklich auf Domain B landen die Besucher erst, wenn sie mal die Navigation benutzt haben. Das ist Durcheinander. Und außerdem wolltest du wahrscheinlich auch, dass die Suchmaschinen lernen, dass dein Blog unter einer neuen Domain erreichbar ist.
    => Deswegen Domain B jetzt auf einen anderen Ordner routen, in dem die htaccess mit dem passenden r301-Befehl liegt.

    Gruß
    helix

    Wenn ich das selbst mache brauche ich einfach nur 3-4 Eingabefelder (Datum, Uhrzeit, Ort, Inhalt) und das reicht, die Ausgabe auf der Seite ist ja auch dann recht einfach - und wie gesagt ich habe auf alles Einfluss.

    Dafür heißt das Zauberwort „benutzerdefinierte Felder“ bzw. „custom fields“.

    Sind out of the box im WordPress schon da. Noch schöner und übersichtlicher wird es, wenn du über die functions.php eigene benutzerdefinierte Felder anlegst, die du mit Benennung und Erklärung versehen kannst. Für die, die sich hinterher drin zurechtfinden sollen.

    ---

    Ich finde aber den Hinweis von Tubedesigner mit dem Shortcode fürs PlugIn im eigenen Template auch sehr interessant, durchaus beachtenswert – und wahrscheinlich „für Anfänger“ dann doch einfacher und schneller zum Ziel führend.

    Gruß
    helix

    Wichtig ist für mich z.B. auch, dass ich auf die Darstellung Einfluss nehmen kann.

    Das hatte ich vermutet. Und deswegen die Fährte zu Beiträgen gelegt, weil ich persönlich finde, dass damit der direkte Einfluss auf die Darstellung viel schneller und einfacher herzustellen geht, als sich in die Styling-Logik eines PlugIn-Anbieters reinzudenken. (Wenn nicht das PlugIn von Haus aus eine Optik mitbringt, mit der ich leben kann und mag.)

    Wie ich in einem anderen Thread schon geschrieben habe, war ich es bisher immer gewohnt, solche Dinge via PHP und MySQL selbst zu erstellen gepaart mit der Gewohnheit, direkt auf alles Einfluss zu haben und alles an die Bedürfnisse anpassen zu können.

    Steht das nicht im Widerspruch zu dem:

    Ich denke das wird für unversierte Nutzer aber zu aufwendig.

    Oder meintest du, für die, die den Content pflegen sollen, wenn du das Ding eingerichtet und übergeben hast?

    Naja, das ist die nächste große Herausforderung, nachdem man es geschafft hat, die Webseite mit WordPress so aussehen (und funktionieren) zu lassen, wie man sich das vorstellt, – dann auch den Admin-Bereich so einzurichten, dass das, was an WordPress so smart ist, erhalten bleibt: die intuitive Bedienbarkeit …

    Ich denke, dass, worauf Du hinaus willst, wäre eine Darstellung wie bei den Blog-Artikeln, oder? Das würde das ganze dann auch weniger kompakt erscheinen lassen.

    Genau. Und wenn das alles seine eigene Kategorie hat, kannst du für die Ausgabe der Blog-Artikel dieser Kategorie dein leichtes und schlichtes Outfit zur Anwendung bringen.

    ---

    Wenn du nicht geschrieben hättest, dass du Kenntnisse und Erfahrung mit PHP hast, würde ich mit meinen Tipps nicht so vorpreschen. Aber so, wie ich dich bis jetzt einschätze, denke ich, dass du mittel- bis langfristig zufriedener wirst, wenn du die out-of-Core-Funktionen von WordPress nutzst und für deine Bedürfnisse anpasst.

    Wie ist dein Englisch? Wenn du damit auch nur einigermaßen zurechtkommst, ist der WordPress-Codex richtig richtig gxxx.

    Freundliche Sonntagsgrüße (nein: nicht das Wort zum …)
    von helix

    Hm, das sind hier alles nicht wirklich WordPress-Probleme, sondern es ist die Frage, sich intensiver (als bisher) mit CSS auseinanderzusetzen.

    WordPress bzw. WordPress in Kombination mit „fertigen“ Themes stattet seine Elemente von Haus aus mit so vielen IDs und Klassen aus – im Sidebar-Widget schon gleich drei Mal –, dass man alles einzeln mit CSS definieren kann.

    Ich will jetzt hier gar nicht als der große Schlaumeier auftreten, lerne da selber dauernd noch dazu, aber die Stylesheets heißen aus gutem Grund „Cascading“ …

    … und nein, es wäre nicht einfacher, für ein Stückerchen Inhalt zwei html-Elemente ausgeben zu lassen, sondern logischer Unsinn – oder habe ich das jetzt falsch verstanden … und sollte das Listen-Element einfach nur mindestens zwei Klassen haben? Hat es bestimmt … mindestens …
    Nein: warum nicht das li-Element auf 100% definieren und für die Einrückung ein Padding? Dafür ist beides da …

    Gruß
    helix

    Ob es einfach ist, weiß ich nicht: eine Kategorie Termine anlegen, für zeitlich gesteuerte Veröffentlichung und auch-wieder-rausnehmen gibt es PlugIns – weiß nicht, wie gut und wie aktuell die sind, aber das könnte den Ansatzpunkt liefern, es vielleicht auch selber hinzubekommen …

    Gruß
    helix

    So wie ich das sehe, ist es eher eine Frage des Domainrouting.

    Die neue Domain auf den Ordner routen, in dem WordPress liegt. (Und in der Datenbank vom WordPress müssen selbstverständlich die Adressen geändert werden etc.)
    Die alte Domain dann entweder auf einen anderen Ordner routen, in dem die passende htaccess (mit entsprechendem 301-redirect) liegt. Oder direkt in der Webspace-Verwaltung per 301-redirect auf die neue Domain umleiten. <= Auf die Schnelle habe ich jetzt nix gefunden, dass das bei Strato so direkt in der Webspace-Verwaltung gehen würde. Aber vielleicht kennt sich da ja jemand besser aus …

    Gruß
    helix

    Doch, solltest du können: Mach dich auf die Suche, wo die Schrift referenziert ist, Stylesheet-Datei oder im Header. Woher versucht das System die Schrift zu laden, vielleicht vom alten Server? Liegt die Schrift vielleicht schon an enstprechender Stelle bei dir aufm Server (und du hast nur den Link nicht angepasst, weil du nicht wusstest, dass du darauf auch noch achten musst …)? Oder andere URL? Gibt es die Schrift dort noch?

    Gruß
    helix

    Bis vor 2 Monaten wurden alle meine Seiten von Google indexiert.
    jetzt werden es immer weniger. Inzwischen sind es nur noch 12 von 68.

    Woher nimmst du das?

    Ich habe mal testweise bei Tante Gugl „site:kaffee-doktor-trier.de“ eingegeben:
    Es gibt also noch mehr als 145 indizierte Seiten …

    Woran kann es liegen??

    Sorry, ich finde gerade meine Glaskugel nicht, aber ich vermute, dass du Tante Gugl nur nach deinem persönlichen üblichen Suchbegriff gefragt hast. Für „Kaffee Trier“ könnte es z.B. sein, dass die Konkurrenz größer geworden ist und deswegen jetzt nicht mehr so viele deiner Seiten als relevant eingestuft werden. Könnte …

    Gruß
    helix