Support » Allgemeine Fragen » Auf Server entwickeln, aber nicht öffentlich zugänglich

  • Gelöst loveparis

    (@loveparis)


    Hallo!

    Ich komme lokal mit WordPress schon gut zurecht, möchte aber lieber auf dem Server entwickeln, um die tatsächliche spätere Umgebung zu haben, in der ich z.B. mein Cashing-Plugin testen und Online-Performance-Tools nutzen kann.

    Ich will meine neue Website also auf dem Server erstellen, aber sie soll weder für menschliche Nutzer noch für Bots sichtbar sein, solange sie nicht fertiggestellt ist. Andererseits muss es mir möglich sein, Plugins zu installieren und sie auch up to date zu halten.

    Blöde Frage: Wie macht man das üblicherweise bei einer neu zu erstellenden Website?

    Ich habe mir schon mal Gedanken über 3 mögliche Lösungen gemacht, habe aber echt keine Ahnung, welche für mein o.g. Anliegen am besten geeignet sein könnte, bzw., welche Vor- u. Nachteile es jeweils geben könnte:

    – WP zum Erstellen in Unterverzeichnis installieren (für Suchmaschinen nicht freigeben) und dann nach Fertigstellung ohne Unterverzeichnis aufrufen, wie hier schön beschrieben

    – ein Plugin wie z.B. WP Staging nutzen und auf diesem Weg die Website aufbauen

    – Website hinter einem Coming-Soon-Plugin aufbauen

    Welche Methode nutzt ihr persönlich am liebsten bei einer neu zu erstellenden Website?

    Über Tipps und persönliche Erfahrungen würde ich mich sehr freuen, danke!

    • Dieses Thema wurde geändert vor 7 Monaten, 2 Wochen von loveparis.
Ansicht von 15 Antworten - 16 bis 30 (von insgesamt 33)
  • @pixolin, @hage
    Falls ich euch in euren Beiträgen oben richtig verstanden habe, dann zieht ihr es doch in den meisten Fällen vor, zunächst lokal zu entwickeln und erst in einem spät(er)en Stadium auf den Server zu migrieren. Da mir das grundsätzlich aufwändiger erscheint, als direkt auf dem Server zu entwickeln (habe allerdings mit letzterer Methode auch null Erfahrung), würden mich mal die Gründe interessieren, warum ihr die lokale Entwicklung vorzieht.

    Wie eben schon gegenüber @bscu erwänht, will ich nämlich meine aktuelle Idee von einer durch Performance-Tools begleiteten Live-Entwicklung nicht um jeden Preis durchboxen, sondern will erfahren, welche verschiedenen Methoden in der freien Wildbahn aus welchen Gründen genutzt werden, um so die für mich am besten geeignete zu finden.

    Mit den Entwicklertools des Browsers kann man ja schon auf die Performance achten. Zumeist reicht mir aber das Gefühl, ob die Seite schnell genug ist oder nicht.

    Geht mir genauso: Ich entwickle die Webseiten lokal, schaue sowieso in die Entwickler-Tools des Browsers und würde da extreme Performance-Bremsen bereits erkennen. Die Performance hast du laufend im Blick – keine überdimensionierten Bilder, Plugins nur soweit sinnvoll, abwägen, ob Multipurpose-Themes sinnvoll (einige haben da inzwischen ganz brauchbare Lösungen, um die Website z.B. nicht durch elend lange Stylesheets zu verlangsamen). Erst wenn die Website auf dem produktiven Server ist und nicht mehr zu viele Änderungen kommen, Cache-Plugins (auch von mir bevorzug: WP-Rocket, auch wenn es ein „paar Mark fuffzich“ kostet) einsetzen und abschließend testen. (Und dann kommt sowieso irgendwann der Kunde und haut ein 3MB großes Bild rein. 😉 )

    @loveparis
    … kann ich für mich nicht sagen: Entwicklung je nach Kunde in der Regel in einer subdomain. Aber Test von Plugins und/oder themes, die upgedatet werden müssen, führe ich zunächst auf einer lokalen Instanz und danach in einer Testumgebung durch. Erst wenn da augenscheinlich alles läuft, dann werden plugins und/oder themes bei uns in der Liveversion upgedatet. Vorher mache ich aber auf jeden Fall noch zusätzlich ein Backup.
    Diese Vorgehensweise hat sich bei uns bewährt.

    … würden mich mal die Gründe interessieren, warum ihr die lokale Entwicklung vorzieht.

    Einfach schon, damit es flotter geht. Ich nutze WP-CLI, setze damit in wenigen Minuten eine komplette Website auf, installiere Themes und Plugins … Wenn Kunden dann auf ihrem Shared Hosting bei S***to nicht mal SSH-Zugang haben, geht das nur lokal.

    Wenn du rasch ein eigenes Plugin schreibst, um eine Mini-Funktion einzubinden, kannst du Fehler auf deiner eigenen Festplatte leichter korrigieren, als erst wieder auf den Server zugreifen zu müssen. Versionskontrolle (Git ohne Schnickschnack) erleichtert mir die Wiederherstellung früherer Versionen, wenn ich mal einen nicht so guten Tag hatte. Cowboy-Coding (also direkte Änderungen an einem produktiven Server ohne Versionkontrolle) kommt sowieso nicht in Frage.

    @bscu

    Ich arbeite zu 99,9% mit Subdomains. Eine lokale Umgebung nutze ich nur zum Experimentieren.

    Also Live-Entwicklung auf der per htaccess geschützten Subdomain, richtig?

    Da schaltet man dann auch keine Under-Construction- oder Coming-Soon-Seite vor, oder?

    Macht Google nach dem evtl. langen htaccess-Schutz keine Schwierigkeiten beim Indexieren der späteren, fertigen Hauptdomain-Version?

    Eine Sache ist mir in deinen obigen Ausführungen noch nicht so richtig klar geworden, und zwar, inwiefern diese Aussage:

    Die Datenbank exportiere ich mit dem Plugin „Migrate DB“, kopiere alles Dateien aus der Subdomain in die Richtige Domain, importiere die Datenbank und korrigiere in der wp-config.php die Zugrifssdaten für die Datenbank.

    zu dieser passt (betreffend Vorteile Subdomain vs. SubFolder):

    Ja, denn ich nutze dann genau die Umgebung, die auch in der Endversion benutzt wird, mal abgesehen vom Domain-Namen. Ich hatte schon mal das ärgerliche Problem, dass ich auf einem Linux-Server entwickelt habe und hinterher auf einen Windows-Server umsteigen musste. Warum auch immer, da hatte ich dann einige Probleme.

    Sorry für die vielen Fragen, die Beantwortung eilt auch überhaupt nicht, aber bevor ich loslege, möchte ich schon ein bisschen klarer sehen und finde eure Antworten wirklich sehr, sehr hilfreich!

    @pixolin, @hage
    Danke euch vielmals für die sehr nützlichen Erläuterungen zu euren persönlichen Vorgehensweisen! Muss die vielen Infos erstmal verdauen und darf dann hoffentlich in diesem Thread auch nach und nach noch Rückfragen stellen!?

    Also Live-Entwicklung auf der per htaccess geschützten Subdomain, richtig?

    Das habe ich doch so geschrieben.

    Da schaltet man dann auch keine Under-Construction- oder Coming-Soon-Seite vor, oder?

    Warum sollte man das tun? Kommt doch sowieso niemand an die Seite.

    Macht Google nach dem evtl. langen htaccess-Schutz keine Schwierigkeiten beim Indexieren der späteren, fertigen Hauptdomain-Version?

    Wie sollte das passieren? google kennt die Subdomain nicht und selbst wenn kommt google nicht dran.

    inwiefern diese Aussage:
    zu dieser passt (betreffend Vorteile Subdomain vs. SubFolder):

    Bei der Subdomain habe ich die gleiche Server-, MySQL- und PHP-Version, also alles identisch bis auf den Namen der Datenbank und Domain.

    Von @hage

    Aber Test von Plugins und/oder themes, die upgedatet werden müssen, führe ich zunächst auf einer lokalen Instanz durch

    Von @pixolin

    Wenn du rasch ein eigenes Plugin schreibst, um eine Mini-Funktion einzubinden, kannst du Fehler auf deiner eigenen Festplatte leichter korrigieren, als erst wieder auf den Server zugreifen zu müssen.

    Genau das meinte ich mit

    Eine lokale Umgebung nutze ich nur zum Experimentieren.

    Also Live-Entwicklung auf der per htaccess geschützten Subdomain, richtig?

    Kann man so machen, allerdings hast du dann unter Umständen keinen SSH-Zugriff und musst auf Dinge wie Git oder WP-CLI verzichten.

    Da schaltet man dann auch keine Under-Construction- oder Coming-Soon-Seite vor, oder?

    Wofür verwendest du Coming-Soon-Plugins? Um den Zugriff auf die Inhalte auf einen eingeschränkten Benutzerkreis zu begrenzen. Das kannst du mit einem .htpasswd auch – der Effekt ist der selbe.

    Macht Google nach dem evtl. langen htaccess-Schutz keine Schwierigkeiten beim Indexieren der späteren, fertigen Hauptdomain-Version?

    Je nachdem was mit Kunden vereinbart wurde, gehört zum Auftrag auch eine Anmeldung der Website in der Google/BING Search Console. Dann stößt du, sobald die Website online ist, ein Crawling an (während die Seiten vorher mit einem „503 Service Unavailable“ und „noindex“ signalisiert, dass sie nicht indexiert werden soll). Wahrscheinlich hast du dann auch eine Sitemap, die bereits angibt, welche Inhalte vorhanden sind.

    … inwiefern diese Aussage: Die Datenbank exportiere ich mit dem Plugin „Migrate DB“ … zu dieser passt (betreffend Vorteile Subdomain vs. SubFolder): denn ich nutze dann genau die Umgebung, die auch in der Endversion benutzt wird

    Naja, du willst sie ja nicht ewig in der Subdomain lassen und da WordPress wegen SEO absolute URLs benutzt, musst du bei einem Umzug und eine Ersetzung der bisherigen URL in die neue an diversen Stellen vornehmen (geht mit WP-CLI übrigens auch prima). @bscu nimmt dafür eben das recht populäre Mitgrate DB.

    Ob du ein Backup mit einem Plugin machst oder die Dateien per FTP herunterlädst und einen Datenbank-Export machst … das Ergebnis ist das gleiche. Jeder hat sich da so seinen Weg zurecht gelegt, der persönlichen Vorlieben und auch dem Arbeitsumfeld entspricht. Im Team wirst du anders arbeiten als ein Freelancer, manche machen nur Implementation und brauchen keine Versionskontrolle, …

    @pixolin
    Danke dir für die zusätzlichen Erläuterungen!
    Werde mich später noch mal melden.

    An alle:
    Nochmal zur Abwägung „Subdomain oder Unterverzeichnis“, das ist mir noch nicht klar.

    Wenn @bscu schreibt:

    Frage von mir: Hat die Subdomain-Lösung in deinen Augen bestimmte Vorteile gegenüber der Unterverzeichnis-Lösung?

    Ja, denn ich nutze dann genau die Umgebung, die auch in der Endversion benutzt wird, mal abgesehen vom Domain-Namen. Ich hatte schon mal das ärgerliche Problem, dass ich auf einem Linux-Server entwickelt habe und hinterher auf einen Windows-Server umsteigen musste. Warum auch immer, da hatte ich dann einige Probleme.

    und

    Bei der Subdomain habe ich die gleiche Server-, MySQL- und PHP-Version, also alles identisch bis auf den Namen der Datenbank und Domain.

    gelten diese Argumente nicht ebenso für die Unterverzeichnis-Lösung?

    Falls ja, würde ich vom aktuellen Bauchgefühl her letztere vorziehen, weil die bequeme Bego-Lösung mir noch etwas einfacher erscheint als die Summe dieser Schritte:

    Die Datenbank exportiere ich mit dem Plugin „Migrate DB“, kopiere alles Dateien aus der Subdomain in die Richtige Domain, importiere die Datenbank und korrigiere in der wp-config.php die Zugrifssdaten für die Datenbank.

    Nochmal zur Abwägung „Subdomain oder Unterverzeichnis“, das ist mir noch nicht klar.

    Wenn dir das immer noch nicht klar, dann ist dir nicht mehr zu helfen.

    Du hast jetzt unterschiedliche Wege kennengelernt, jetzt musst du dich für einen entscheiden. Es gibt sehr oft mehrere Lösungsansätze, aber welcher für dich der bessere ist, musst du schon festlegen.

    @bscu

    Frage: Also Live-Entwicklung auf der per htaccess geschützten Subdomain, richtig?

    Das habe ich doch so geschrieben.

    Frage: Nochmal zur Abwägung „Subdomain oder Unterverzeichnis“, das ist mir noch nicht klar.

    Wenn dir das immer noch nicht klar, dann ist dir nicht mehr zu helfen.

    Nicht in dem Ton, @bscu, ich habe mich in diesem Thread höflich und dankbar verhalten, also ändere jetzt bitte nicht den angenehmen Ton hier! Dankeschön!

    • Diese Antwort wurde geändert vor 7 Monaten, 2 Wochen von loveparis.

    @loveparis
    Ich verkneife mir jetzt besser einen Kommentar.

    Viel Erfolg bei deinem Vorhaben, und Tschüss.

    Nochmal zur Abwägung „Subdomain oder Unterverzeichnis“, das ist mir noch nicht klar.

    Kurzgefasst: Jacke wie Hose. Die Chance, dass jemand nach Verzeichnissen oder Subdomains sucht (und dann dort „vor verschlossener Tür“ steht), ist ohnehin gering. Es kommt mehr darauf an, womit du dich wohler fühlst, aber das haben wir ja auch alles schon sehr ausführlich hier beschrieben.

    Der – durchaus freundlich gemeinte! – Hinweis „Du hast jetzt unterschiedliche Wege kennengelernt, jetzt musst du dich für einen entscheiden.“ geht in die gleiche Richtung.

    Nicht in dem Ton …

    Das war doch kein persönlicher Angriff. Viele beantworten hier Fragen, während im Hintergrund vielleicht gerade ein Skript läuft oder die Waschmaschine rattert. Da fällt ein Kommentar schon mal etwas knapp aus, ist aber nicht minder herzlich gemeint. Schade, dass du einen falschen Ton herausgehört haben willst, nachdem sich auch @bscu intentsiv mit deiner Frage beschäftigt hat. Aber schön, dass du „höflich und dankbar“ mitgelesen hast.

    Wo waren wir stehen geblieben? Probier einfach Sachen aus, bleib offen für neue Ideen, lies weniger, mach mehr – der Rest ergibt sich. Und immer locker bleiben. 😉

Ansicht von 15 Antworten - 16 bis 30 (von insgesamt 33)
  • Das Thema „Auf Server entwickeln, aber nicht öffentlich zugänglich“ ist für neue Antworten geschlossen.