8 powodów, dla których nie należy rozwijać WordPressa lokalnie

Tak, jedziemy tam. Chociaż nie porzuciliśmy całkowicie rozwoju lokalnego, wierzymy, że w dzisiejszym obecnym środowisku WordPress, online staging jest drogą do zrobienia.

Lokalny rozwój w WordPress jest naprawdę dobry-w teorii. Chociaż można wylewać listę jego zalet, można je łatwo odwrócić do wad.

Gotowy na dobrą debatę? Biorąc jeden punkt na raz, wyjaśnimy, dlaczego uważamy, że hosting online jest lepszą opcją w środowiskach rozwijających się.

Czytaj dalej, lub Skocz do przodu, korzystając z tych linków:

Przyjrzyjmy się szczegółom.

Warstwa podkładu

Po pierwsze, omówimy kilka definicji, ponieważ mogą być używane w inny sposób i chcemy ujednolicić kontekst.

Localhost jest używany przez większość ludzi, gdy odnoszą się do swojego komputera. Ale wszystkie tech z dostępem do Internetu ma localhost – od inteligentnych lodówek po hostowane serwery. Dla większej jasności użyjemy online versus lokalne.

Inscenizacja to kopia Twojej witryny, na której dokonujesz zmian / testów / zmian i tym podobnych.

Produkcja to Twoja strona NA ŻYWO.

Zarówno inscenizacja, jak i produkcja mogą być online lub lokalne.

Moglibyśmy zastanawiać się nad znaczeniem tych słów, ale uprzejmie rozważmy je tak, jak opisano powyżej, przynajmniej tak, jak odnosi się to do tego artykułu.

Przejdźmy do sedna sprawy.

Dekonstrukcja środowiska

Możesz zacząć korzystać z własnego środowiska w WordPress, korzystając z jednego z dwóch podejść: rozwoju lokalnego lub zdalnego rozwoju hostowanego (online).

Local or online dev
Rozwój lokalny (Twój komputer) a online (zdalny serwer hostowany).

Ponieważ zajmujemy stanowisko pro rozwój online w tym artykule przedstawimy następujące punkty, które wyrażają rozwój lokalny nie jest najlepszy sposób.

1. Ponton vs Cruiser

Jest znacznie bardziej prawdopodobne, że wystąpią problemy na własnym komputerze, w przeciwieństwie do serwera hostowanego online. Tak więc w przypadku rozwoju lokalnego istnieje większe ryzyko utraty postępów poczynionych podczas danej sesji, a nawet całej pracy.

W rozwoju online środowisko może być obsługiwane przez profesjonalistów z branży (niezawodny host), dzięki czemu możesz skupić się na samej pracy.

2. Szczelina Zasobów

Twój własny komputer rzadko równa się serwerowi online, co oznacza, że ten sam kod będzie działał zupełnie inaczej w każdym środowisku.

Ponieważ twój lokalny system może dać nieograniczony dostęp do zasobów, strona i Kod będą przetwarzać znacznie szybciej i z większą swobodą(tj. Nie tak na serwerze online, zwłaszcza przy niższych zasobach. Wyobraź sobie Komputer osobisty 64 GIGA vs plan hostingowy 1 Giga.

Z rozwojem online, staging jest prawie dokładnie taki sam jak środowiska produkcyjne, pod względem specyfikacji. Oznacza to, że możesz poprawnie przetestować swój kod i wiedzieć ze względną pewnością, że będzie działał tak samo w obu. Nie ma dla ciebie zamieszania w odniesieniu do tego, co działa, a co nie.

Aby być bardziej szczegółowym, możesz mieć 10 minut wykonania lokalnie, podczas gdy serwer może mieć wykonanie PHP 300S (np. 5 minut uruchomienia kodu). Jeśli się nie skończy, to się pomyli. Stąd ten sam kod będzie działał poprawnie lokalnie, ale nie będzie działać na serwerze produkcyjnym.

Może to wydawać się sprzeczne z argumentem, wskazując, że lokalne zasoby znacznie przewyższają zasoby serwerów internetowych, ale w tym przypadku nie chodzi o bardziej obszerne specyfikacje. Ważne jest, aby w inscenizacji (rozwoju) zawsze mieć równe lub mniejsze specyfikacje niż produkcja. W ten sposób możesz przetestować swój kod/witrynę/itp. i wiedz, że jeśli dobrze radzi sobie z mniejszymi zasobami (np. Serwer 1 GB), nie będzie miał problemów z większymi zasobami (np. komputer 64 GB). Tego samego nie można powiedzieć o odwrocie.

3. (Nie Han) Solo Setup

Na lokalnym musisz wszystko skonfigurować sam, co może szybko stać się poplątanym bałaganem, nawet w przypadku aplikacji 1-click. Jeśli nie jesteś zaawansowanym programistą/techiem, prawdopodobnie nie znajdziesz łatwych rozwiązań i prawdopodobnie spędzisz dużo czasu na próbach i błędach.

4. Igły w stogu siana … a dokładniej … kod w stosie Dev

Łatwiej jest po prostu edytować witrynę WP w środowisku tymczasowym, które jest wstępnie ustawione do pracy z serwerem, niż robić to lokalnie i próbować ręcznie wymieniać bazę danych między lokalnymi- > online.

Rozważ następujące … tworzysz nowy post na swojej stronie i dołączasz do niego obrazy 2. Oznacza to wiele plików (ponieważ WP generuje miniatury również z obrazów) i wiele wpisów bazy danych w różnych tabelach.

Musisz wiedzieć, co robisz, aby wprowadzić te zmiany z lokalnej witryny do witryny online, podobnie jak migracja. Albo wymieniasz całą witrynę od podstaw, albo musisz wskazać niezbędne zmiany za kulisami i przenieść je. Zwykle łatwiej jest po prostu utworzyć post online Ponownie, niż próbować poruszać się po tych zmianach. Po co podwoić twoje wysiłki?

5. Zagrożenia Tematyczne I Problemy Z Wtyczkami

To samo dotyczy motywów i wtyczek. Dlaczego po prostu nie wprowadzić zmian w środowisku online, a gdy to działa, zsynchronizować się z inscenizacją do produkcji w ciągu kilku sekund? Unikaj konieczności przesyłania wszystkich tych rzeczy i wykonuj całą konfigurację od zera. Uniknij prawdopodobieństwa zapomnienia o czymś w ponownej konfiguracji.

W środowisku lokalnym i tak nie można całkowicie zweryfikować. Nawet w przypadku prostych zmian motywu nie będziesz w stanie uruchomić skanowania GTMetrix bez wcześniejszego przepchnięcia go gdzieś online, a następnie uruchomienia testów. Ponownie, to nasuwa pytanie, dlaczego nie zrobić tego w środowisku online staging prosto z bramy, i usunąć dodatkowy krok?

6. Reguły Alternatywnego Dostępu I Przekierowania

Jak wspomniano wcześniej, konfiguracja lokalna może się bardzo różnić od hostowanej, online.

Na przykład: stosy AMP używają serwera Apache, podczas gdy inne hosty / serwery używają Nginx, LiteSpeed itp. Używają one różnych reguł przekierowywania poprzez .htaccess plik. Tak więc wszelkie wtyczki ustawione na lokalny Apache, nie będą działać poprawnie, gdy wypchniesz tę witrynę na serwer z Nginx, (lub LightSpeed, itp.). W tym przypadku, wszystkie muszą być ponownie ustawione.

Tylko z tego powodu lepiej jest rozwijać się online. Jeśli masz opcję inscenizacji, która jest zasadniczo zbudowana na tym samym (lub równym) systemie, będzie po prostu działać w produkcji, ponieważ jest w 100% kompatybilna. Wiesz dokładnie, jak twoja strona / wtyczki / motywy itp. będziemy się zachowywać.

7. (Nie Harry) Potter-ing Past

Dla niektórych ludzi rozwój lokalny jest pozostałością po erze powolnego wybierania melasy. Były niestabilne i kosztowne, co ułatwiło ustawienie up witryny lokalnie i push wszystko online za jednym zamachem. W dzisiejszych znacznie lepszych opcjach łączności tak już nie jest.

8. Epicki Ekosystem

Duże, ciężkie projekty mogą obejmować wszelkiego rodzaju rozwój. Rzadko są lokalne, prawie zawsze na 100% podobnym skopiowanym serwerze, który zawiera Git i inne narzędzia programistyczne―które są znacznie bardziej skomplikowane, jeśli nie jesteś w pełni zorientowany w nich.

Sparowane Platformy

Jest inna droga, którą możesz wybrać. Oznacza to, że za pomocą platformy związanej z dostawcą hostingu do rozwoju, takiej jak DevKinsta (>> Kinsta) lub lokalny (>> Koło zamachowe lub silnik WP).

Oferują one dużą łatwość użycia (nie wymaga intymnej wiedzy o kodowaniu) i działają na komputerze, w środowiskach online i localhost, aby dopasować się do Twoich preferencji.

Lokalne i DevKinsta są bezpłatne. Jednak poniesiesz koszty, jeśli użyjesz ich hostingu, gdy ostatecznie wdrożysz swoją witrynę. Jeśli zrezygnujesz z płacenia za ich usługi w miejsce innej firmy, prawdopodobnie napotkasz problemy ze zgodnością, o których rozmawialiśmy wcześniej, gdy będziesz gotowy do przejścia na produkcję. Jeśli jesteś zainteresowany użyciem koła zamachowego, jest to pomocny artykuł, który napisaliśmy o tym.

Zamiast tego możesz wybrać firmę hostingową, która oferuje proste rozwiązanie online staging-to-live. Na przykład WPMU DEV oferuje wygodę i łatwość hostowanej platformy staging na naszych serwerach, dzięki czemu możesz rozpracować wszystkie załamania, a następnie przejść na żywo z synchronizacją jednym kliknięciem.

wpmudev 1-click sync staging to production
Pick, click-slick! (Opisywany w opcjach hostingu WPMU DEV.)

(AMP) Le Coverage

Jeśli przeczytałeś cały artykuł, dziękujemy za wysłuchanie nas! Mamy nadzieję, że przedstawiliśmy jasny, przekonujący argument, dlaczego wolimy rozwój online (zamiast lokalnego), przy jednoczesnym poszanowaniu tych, którzy mogą wybrać tę ostatnią.

Zdajemy sobie sprawę, że istnieją przyzwoite zasoby dostępne do rozwoju lokalnego w WordPress. Masz darmowe stosy AMP (Apache-MySQL-PHP), takie jak XAMPP, MAMP i WAMP, które symulują to, co zarządzane hosty WordPress zapewniłyby ci na swoich serwerach internetowych.

WP AMP stack
Stosy AMP dla rozwoju lokalnego w WordPress.

Chociaż są one opracowane do pracy z wieloma innymi programami, narzędziami i systemami operacyjnymi, wymagają również samodzielnego instalowania, konfigurowania i aktualizowania. Jest to czasochłonne, ciągłe zadanie, znacznie większe, jeśli nie jesteś z nimi zaznajomiony.

Jeśli nadal masz ochotę na lokalną trasę, mamy na naszym blogu kilka przydatnych artykułów z cennymi informacjami na ten temat:

Są szanse, że masz wystarczająco dużo do zrobienia w budowaniu i zarządzaniu witrynami, bez dodatkowych kłopotów związanych z ustalaniem nieoczekiwanych wyników, które zwykle wiążą się z samodzielnym przejściem z lokalnego do online.

Jeśli Twoja witryna generuje przychody (dla ciebie osobiście lub Twoich klientów), prawdopodobnie i tak zdecydujesz się na wysokiej jakości usługę hostingową. Na początek warto użyć jednego, który zawiera rozwiązanie all-in-one, z płynną, czystą synchronizacją na etapie do produkcji.

Tworzenie stron internetowych może być radością lub trudem. W końcu powinieneś wybrać środowisko, które najlepiej pasujes twoje potrzeby i poziom umiejętności i łatwo synchronizuje się na niezawodnym serwerze.