WordPress ma wszystko, czego potrzebujemy, w samym rdzeniu. Nie instalujesz niczego z internetu, nie wgrywasz żadnej wtyczki od nas i nie dotykasz plików na serwerze. Cała robota po Twojej stronie to jeden ekran w profilu użytkownika i jedno kliknięcie.
Nie prosimy o hasło do Twojego konta. Prosimy o hasło aplikacji, które generujesz sam, które jest przypisane do jednego konta i do jednej integracji, i które unieważniasz jednym kliknięciem, nie pytając nas o zgodę i nie psując sobie przy tym logowania do panelu.
To jest jedno połączenie dla WordPressa i dla WooCommerce, a nie dwa osobne. Jeśli na stronie stoi sklep WooCommerce, to samo połączenie potrafi dodatkowo czytać katalog produktów. Jeśli sklepu nie ma, nic się nie psuje: strona jest podłączona poprawnie, a my zapisujemy po prostu, że tej jednej możliwości ta strona nie ma.
Nazwy ekranów i pozycji w menu podajemy tak, jak brzmią w domyślnej, angielskiej instalacji. Jeśli Twój panel mówi po polsku, będą przetłumaczone, ale to angielskie brzmienie powtarza nasz komunikat o błędzie, więc łatwiej po nim trafić. Panel administracyjny WordPressa stoi pod adresem Twojej strony z /wp-admin na końcu.
Zanim zaczniesz
Potrzebujesz czterech rzeczy. Jeśli którejś brakuje, dalsza część poradnika nie zadziała.
- Konto w WordPressie z rolą Editor albo Administrator. Tę rolę wymienia wprost nasz komunikat o błędzie, kiedy strona odmawia: konto musi móc dodawać wpisy i wgrywać pliki do biblioteki mediów, bo obie te rzeczy robimy.
- Adres główny strony, na przykład
https://przyklad.pl. Nie adres panelu z/wp-adminna końcu i nie adres z/wp-json. Ukośnik na końcu nam nie przeszkadza, sami go obcinamy. - Ważny certyfikat HTTPS. Sprawdzamy certyfikat Twojej domeny i nie wyłączamy tej weryfikacji. Certyfikat przeterminowany, podpisany samodzielnie albo wystawiony na inną nazwę zatrzyma połączenie, zanim cokolwiek wyślemy. Na własnych serwerach robimy inaczej, ale cicha zgoda na dowolny certyfikat na cudzej domenie nie jest ustawieniem, które chcemy wysyłać w świat.
- Działające REST API WordPressa pod adresem
/wp-json. W standardowej instalacji jest włączone i nie ma tam nic do klikania. Bywa jednak wyłączane przez wtyczki bezpieczeństwa i przez reguły zapory po stronie hostingu, a wtedy nie dostaniemy się do strony w ogóle.
Piąta rzecz jest opcjonalna: jeśli masz WooCommerce i chcesz, żebyśmy czytali katalog, przygotuj też klucz API sklepu. Opisujemy go niżej, w sekcji o WooCommerce, i możesz go dodać później, bez ruszania reszty połączenia.
Całość zajmuje około dziesięciu minut. Hasło aplikacji generuje się na jednym ekranie, a klucz WooCommerce, jeśli w ogóle go potrzebujesz, na drugim. Jeśli musisz o to poprosić osobę, która opiekuje się stroną, zaplanuj to jako jedną krótką rozmowę.
Na których wersjach WordPressa to działa
Nie sprawdzamy numeru wersji Twojego WordPressa i nigdzie go nie odczytujemy. Sprawdzamy to, co strona naprawdę potrafi, a nie to, co ma napisane na metryczce. Liczą się trzy warunki i każdy z nich widać w panelu gołym okiem:
- REST API odpowiada pod
/wp-jsoni ma w sobie przestrzeńwp/v2, czyli standardowe adresy wpisów i mediów. - W profilu użytkownika jest sekcja Application Passwords. To ona daje hasło, którym się przedstawiamy.
- Konto, którego użyjesz, ma prawo dodać wpis i wgrać plik do biblioteki mediów.
WordPress 5.6 lub nowszy. Ten próg bierze się z jednej rzeczy: hasła aplikacji trafiły do rdzenia WordPressa w wersji 5.6, w grudniu 2020, a bez nich nie ma czym się uwierzytelnić. Starsza strona nie zablokuje się na numerze wersji, tylko po prostu nie pokaże sekcji Hasła aplikacji w profilu, i wtedy nie ma czego wkleić.
Sprawdzanie zdolności zamiast numeru ma prostą zaletę: mocno przerobiona albo obudowana wtyczkami strona bywa opisana jedną wersją, a zachowuje się jak inna. Jeżeli te trzy warunki są spełnione, połączenie działa, a jeżeli nie są, nasz test powie wprost, którego z nich zabrakło, zamiast odbić się od numeru.
Jeśli któregoś z tych trzech warunków nie ma i nie wiesz dlaczego, napisz do nas. Powiemy wprost, co sprawdziliśmy i jaką odpowiedź dostaliśmy od Twojej strony, żebyś mógł to z kimś wycenić.
1. Utwórz hasło aplikacji
Hasło aplikacji to osobne hasło, które WordPress tworzy dla jednej integracji. Nie da się nim zalogować do panelu, przez formularz logowania ono po prostu nie działa. Działa wyłącznie w REST API i wyłącznie w imieniu tego jednego konta, a Ty możesz je unieważnić w każdej chwili, nie ruszając swojego prawdziwego hasła.
- Zaloguj się do panelu i otwórz Users, a tam Profile. Jeśli chcesz użyć innego konta niż własne, wejdź w Users, All Users i otwórz je do edycji.
- Przewiń stronę do samego dołu, do sekcji Application Passwords.
- W polu New Application Password Name wpisz nazwę, po której poznasz to hasło za rok. Wystarczy nazwa naszej usługi. Nazwa jest tylko dla Ciebie, my jej nie widzimy.
- Kliknij Add New Application Password.
- WordPress pokaże wygenerowane hasło jeden jedyny raz. Skopiuj je w całości, razem ze spacjami.
To najważniejsze zdanie w całym poradniku: spacje w tym haśle są jego częścią. WordPress wypisuje hasło w grupach po cztery znaki i dokładnie w takiej postaci je przyjmuje. Nie usuwaj spacji, nie porządkuj hasła i nie sklejaj go w jeden ciąg. My obcinamy tylko to, co jest przed pierwszym i za ostatnim znakiem, a spacji w środku nie ruszamy, bo należą do hasła.
Kopiuj hasło prosto z pola, w którym je widzisz. Jeśli po drodze przeszło przez notatnik albo wiadomość, sprawdź, czy nie doczepił się do niego znak nowej linii. Hasło krótsze o jeden znak wygląda dokładnie tak samo jak hasło błędne.
Jeśli zamkniesz ten ekran, zanim skopiujesz hasło, nie da się go odzyskać. Nikt go już nie zobaczy, także WordPress. Skasuj wtedy ten wpis i wygeneruj nowe, to zajmuje kilkanaście sekund.
Zapisz sobie też login tego konta, bo podajesz go razem z hasłem. Chodzi o login, a nie o adres e-mail i nie o nazwę wyświetlaną. Znajdziesz go w tym samym profilu, w polu Username.
Hasło aplikacji otwiera API w imieniu tego konta, więc traktuj je jak hasło: nie wysyłaj zwykłą wiadomością i nie zostawiaj w pliku, do którego zagląda pół firmy. Różnica na Twoją korzyść jest taka, że unieważniasz je jednym kliknięciem, nie psując sobie logowania do strony.
Drobiazg wspomniany tylko po to, żeby nie zaskoczył Cię w logu serwera: każde nasze zapytanie przedstawia się nazwą BytePressConnector. Robimy tak dlatego, że zapory sieciowe przed WordPressem odrzucają błędem 403 zapytania bez takiej nazwy. Nie ma tu nic do zrobienia po Twojej stronie, ale jeśli ktoś przegląda ruch na stronie, to właśnie tego szuka.
2. Przekaż nam dane
Dane wklejasz u nas raz. Trzymamy je zaszyfrowane i nie pokazujemy ich później ponownie, także sobie.
Podłączenie ustawiamy razem z Tobą przy starcie. Nie wklejasz hasła aplikacji w formularz na stronie: przesyłasz je nam bezpiecznie, a my podpinamy witrynę i potwierdzamy, że publikacja działa. Napisz na kontakt@agentshub.pl albo odezwij się z panelu.
Co wpisujesz w które pole
- Adres strony: adres główny, na przykład
https://przyklad.pl. Niehttps://przyklad.pl/wp-admini niehttps://przyklad.pl/wp-json, tę końcówkę dokładamy sami. - Login: login konta WordPressa, dla którego wygenerowałeś hasło aplikacji. Nie e-mail i nie nazwa wyświetlana.
- Hasło aplikacji: cały ciąg z sekcji Application Passwords, razem ze spacjami w środku.
- Klucz i sekret WooCommerce: para pól opcjonalnych. Zostaw je puste, jeśli nie masz sklepu albo nie chcesz, żebyśmy czytali katalog. Skąd je wziąć, opisujemy niżej.
- Tryb roboczy: włącz go, a będziemy zapisywać artykuły jako szkice, czekające na Twoją akceptację. Domyślnie publikujemy od razu.
Jest jeszcze jedno ustawienie, którego prawie nikt nie dotyka. Walutę sklepu odczytujemy z samego WooCommerce, ale można ją nam podać na sztywno. Ma to sens tylko wtedy, gdy sklep z jakiegoś powodu nie chce jej podać, a Ty wiesz, jaka jest.
3. Sprawdź, że połączenie działa
Kiedy dane są zapisane, naciśnij test połączenia. To co najwyżej dwa zapytania do Twojej strony i żadne z nich niczego na niej nie zmienia.
Pierwsze pyta o konto, którego danych użyliśmy, czyli sprawdza, czy login i hasło aplikacji zostały przyjęte i czy to konto ma w ogóle wstęp do REST API. Drugie prosi WooCommerce o jeden produkt, i to nie po to, żeby cokolwiek z nim zrobić, tylko żeby ustalić, czy sklep w ogóle na tej stronie jest.
Kiedy działa, dostajesz jedno zdanie. Zaczyna się zawsze tak samo, a kończy w zależności od tego, co zastaliśmy po stronie WooCommerce.
Connected to WordPress as jan. WooCommerce answered too, so product catalogue sync is available.
Connected to WordPress as jan. WooCommerce is not installed on this site, so product catalogue sync is unavailable. Everything else works.
Drugie z tych zdań nie jest błędem i test kończy się na zielono. Strona jest podłączona, artykuły będą się publikować normalnie, a my zapisujemy sobie tylko, że jednej możliwości ta strona nie ma. Jedyna rzecz, która potrafi zamienić działającego WordPressa w test zakończony niepowodzeniem, to klucz WooCommerce, który wpisałeś, a którego sklep nie przyjął.
Po pierwszym artykule sprawdź go w panelu pod Posts, All Posts. Zobaczysz nowy wpis, ze statusem, o który prosiłeś, i z miniaturą zdjęcia, jeśli zdjęcie doszło.
Nie pokażemy Ci publicznego adresu opublikowanego wpisu i nie jest to przeoczenie. Z odpowiedzi WordPressa odbieramy wyłącznie numer wpisu, bo tylko on jest nam potrzebny, żeby wrócić do tego samego artykułu przy poprawce. Artykuł znajdziesz na liście w panelu.
Test możesz powtarzać, ile chcesz. Nie tworzy niczego na stronie i nie zostawia po sobie śladu poza wpisem w logu serwera.
WooCommerce: katalog produktów
To jest ta część, dla której warto podłączyć sklep. Artykuł, który wymienia Twoje produkty z nazwy i linkuje do stron, które naprawdę istnieją, jest wart więcej niż artykuł mówiący o produktach z tej kategorii.
Nie podłączasz WooCommerce osobno. To jest ta sama strona, ten sam adres i to samo połączenie, tylko z dołożoną jedną dodatkową możliwością. Dlatego u nas nie ma pozycji WooCommerce obok pozycji WordPress: jest jedna pozycja, która sama sprawdza, czy sklep tam stoi.
Jak sprawdzamy, czy sklep tam jest
Przy każdym teście połączenia wysyłamy jedno tanie zapytanie o jeden produkt. Odpowiedź na nie mówi nam wszystko, czego potrzebujemy: czy sklep w ogóle istnieje i czy wolno nam go czytać.
Sprawdzamy to na żywo, przy każdym teście, a nie raz przy podłączeniu. Powód jest prozaiczny: WooCommerce można zainstalować albo usunąć nazajutrz po podłączeniu strony, a zapisany kiedyś znacznik kłamałby od tego dnia.
Kiedy sklepu nie ma, WordPress odpowiada nam, że nie zna takiego adresu. Zapisujemy to jako możliwość, której ta strona nie ma, i na tym koniec. Blog kancelarii prawnej nie ma WooCommerce i nigdy nie będzie synchronizował produktów, a jest przy tym całkowicie poprawnie podłączonym klientem.
O braku sklepu mówimy w komunikacie testu i tylko tam. Błędem staje się on wyłącznie wtedy, gdy coś już po drodze próbuje czytać katalog, czyli po tym, jak wcześniej powiedzieliśmy, że sklep jest. Wtedy komunikat mówi wprost, że WooCommerce nie ma na tej stronie, a nie że połączenie jest zepsute.
Klucz API sklepu
Do czytania katalogu WooCommerce ma własną parę danych: klucz i sekret. Generujesz je w panelu WordPressa, w WooCommerce, Settings, Advanced, REST API. Dokładnie tę ścieżkę wymienia nasz komunikat, kiedy sklep odrzuci klucz.
Ustaw uprawnienie na Read, czyli tylko do odczytu. Nic nie zapisujemy w sklepie i nie ma powodu, żebyś dawał nam taką możliwość. Sekret, tak samo jak hasło aplikacji, WordPress pokaże jeden raz.
Klucza możesz nie podawać wcale. Wtedy o katalog pytamy tym samym hasłem aplikacji co o wpisy, bo WooCommerce przyjmuje je dla konta z uprawnieniem manage_woocommerce. To właśnie dzięki temu potrafimy odróżnić brak sklepu na stronie od sklepu, do którego nie zapisano klucza, jeszcze zanim wpiszesz jakikolwiek klucz.
Klucz, który wpisałeś i którego sklep nie przyjął, to jedyny przypadek, w którym test kończy się niepowodzeniem mimo działającego WordPressa. Traktujemy to poważnie, bo to jedyny błąd w tej sekcji, który zrobił człowiek, a nie strona.
Drobiazg, o którym wspominamy tylko dla porządku: część hostingów wycina nagłówek autoryzacji, zanim dotrze on do PHP. Kiedy sklep odmówi nam z tego powodu, powtarzamy zapytanie raz, przekazując klucz i sekret w adresie, dokładnie tak, jak sama dokumentacja WooCommerce to przewiduje. Nie ma tu nic do zrobienia po Twojej stronie.
Co dokładnie czytamy
- Czytamy wyłącznie produkty opublikowane. Produkt roboczy albo ukryty nie ma strony w sklepie, a martwy link jest gorszy niż brak linku.
- Z każdego produktu bierzemy nazwę, adres, cenę, symbol SKU, rodzaj produktu, stan dostępności, pierwsze zdjęcie i pierwszą kategorię.
- Cenę zapisujemy jako liczbę całkowitą w groszach, nigdy jako ułamek, bo ułamki w cenach prędzej czy później się rozjeżdżają. Zakładamy przy tym dwa miejsca po przecinku, co pokrywa każdą walutę, w której handlują nasi klienci.
- Walutę bierzemy z ustawień sklepu. Jeśli nie uda się jej odczytać, produkty trafiają do nas bez cen, a nie z cenami bez waluty. Cena bez waluty to liczba, którą można źle zacytować klientowi, więc wolimy jej nie mieć.
- Czytamy wszystkie kategorie produktów, po sto na raz, i zapamiętujemy, która jest w której. Lista jest płaska, ale każda kategoria niesie numer swojej nadrzędnej, więc drzewo da się z tego odtworzyć.
- Adres kategorii bierzemy z samego sklepu, jeśli go poda. Jeśli nie poda, składamy go ze standardowej końcówki
/product-category/. Sklep, który tę końcówkę przestawił, dostanie wtedy link, który się przekieruje, i to jest świadomy wybór: link, który po jednym przeskoku dochodzi, jest lepszy niż brak linku. - Kategorie czytamy najwyżej z pięćdziesięciu stron po sto. Sklep z dłuższą listą kategorii to zwykle skutek nieudanego importu, a nie sklep, i wolimy pokazać, co znaleźliśmy, niż czytać w nieskończoność.
W sklepie nie zapisujemy niczego. Nie zakładamy produktów, nie ruszamy cen, stanów magazynowych, zamówień ani ustawień. Czytanie katalogu jest dokładnie czytaniem i niczym więcej, i dlatego prosimy o klucz tylko do odczytu.
Zdjęcie w artykule i limit rozmiaru
Artykuł przychodzi do Ciebie ze zdjęciem. Plik wgrywamy do biblioteki mediów Twojej strony i ustawiamy jako obrazek wyróżniający, i robimy to zanim powstanie wpis, żeby żaden czytelnik nie zobaczył wersji bez obrazka.
Robimy to dlatego, że na Twoim WordPressie nie stoi żadna nasza wtyczka, która dokładałaby zdjęcie przy wyświetlaniu strony. Jeżeli nie wgramy pliku my, artykuł pojawi się bez żadnego obrazka i nic w dalszej części nie jest w stanie tego naprawić.
Nieudane zdjęcie nigdy nie zatrzymuje artykułu
To jest reguła bez wyjątków. Artykuł bez zdjęcia jest gorszym artykułem, ale artykuł, który się nie ukazał, bo nie wgrało się zdjęcie, to żaden artykuł, a zapłaciłeś za tekst. Każdy możliwy sposób, w jaki zdjęcie może nie dojść, kończy się publikacją artykułu bez zdjęcia, a nie brakiem publikacji.
Powód zapisujemy przy połączeniu, w miejscu, w które człowiek zajrzy, i wpisujemy go do logu. Nie zgadujesz więc, dlaczego zdjęcia nie ma, tylko to czytasz. Zapis znika sam przy pierwszym wgraniu, które się powiedzie, żeby panel nie marudził o problem już naprawiony.
Limit rozmiaru pliku
Największe zdjęcie, jakie w ogóle zaproponujemy Twojej stronie, ma 8 MB. Dokładnie 8 388 608 bajtów.
Nie jest to liczba wzięta z sufitu. Hostingi współdzielone zwykle ustawiają własny limit wgrywanych plików gdzieś między 2 a 8 MB, a na plik ponad limit odpowiadają uciętym błędem 413, stroną błędu w HTML-u albo po prostu zrywają połączenie. Żadna z tych trzech odpowiedzi nikomu niczego nie mówi, także nam. Dlatego to my odmawiamy pierwsi i mówimy wprost, o co chodziło.
Zdjęcie ponad limit kosztuje artykuł zdjęcie, nigdy publikację. Artykuł ukazuje się normalnie, bez obrazka, a przy połączeniu zapisujemy powód mówiący o zbyt dużym pliku, razem z rzeczywistym rozmiarem pliku i z limitem, o który się otarł.
Limit jest ustawieniem po naszej stronie, a nie prawem natury. Jeśli Twój hosting przyjmuje większe pliki i naprawdę tego potrzebujesz, napisz do nas i podniesiemy go dla Twojego połączenia.
Wgrywamy pliki typu JPEG, PNG, GIF, WebP i AVIF. Inny typ obrazka też podamy stronie, i to ona zdecyduje, czy go przyjmie. Nie wgrywamy natomiast pliku, który serwer zdjęcia odda nam jako stronę HTML, bo to prawie zawsze strona błędu, ściana logowania albo zabezpieczenie przed podlinkowaniem, a nie zdjęcie. Taki plik w bibliotece mediów byłby śmieciem.
Nazwę pliku składamy z adresu artykułu, bo to jego własne słowa i najlepsza możliwa nazwa pliku pod kątem wyszukiwarek. Skracamy ją do osiemdziesięciu znaków, bo WordPress ma na wewnętrzny adres załącznika ograniczoną długość pola, a zbyt długa nazwa potrafi po cichu zgubić obrazek.
Na tym etapie zdjęcia nie wybieramy. Wybrane zostało wcześniej, w silniku, i tutaj jest już tylko przewożone. To rozróżnienie ma znaczenie, kiedy zdjęcie Ci się nie podoba: rozmowa jest wtedy o doborze zdjęć, a nie o połączeniu.
Twoje hasło aplikacji nigdy nie trafia do serwisu, z którego pobieramy zdjęcie. Po plik idziemy bez żadnych danych logowania, a uwierzytelniamy się dopiero przy wgrywaniu go na Twoją własną stronę.
Co robimy, a czego nie zrobimy nigdy
Co robimy
- Pytamy o konto, którego danych używamy, żeby sprawdzić, że login i hasło aplikacji działają.
- Zakładamy nowe wpisy na Twojej stronie.
- Przy zakładaniu ustawiamy tytuł, treść, adres wpisu, zajawkę z opisu meta i status.
- Wgrywamy zdjęcie artykułu do biblioteki mediów i ustawiamy je jako obrazek wyróżniający.
- Poprawiamy treść wpisów, które sami założyliśmy, kiedy artykuł jest odświeżany.
- Czytamy opublikowane produkty i kategorie produktów, jeśli na stronie jest WooCommerce.
- Zapisujemy przy połączeniu powód, dla którego zdjęcie nie doszło, żeby był widoczny, a nie zgadywany.
Czego nie zrobimy nigdy
- Nie kasujemy niczego. Ani wpisów, ani stron, ani plików, ani produktów.
- Nie ruszamy cudzych wpisów, stron, wtyczek, motywu, ustawień strony ani użytkowników.
- Przy poprawce nie wysyłamy ponownie statusu publikacji. Jeśli cofnąłeś artykuł do szkicu albo odwrotnie, zostaje tak, jak ustawiłeś. Poprawka dotyczy tekstu.
- Nie ustawiamy kategorii ani tagów wpisu. Nie wysyłamy żadnej kategorii, więc wpis trafia tam, gdzie Twój WordPress odkłada wpis, który żadnej nie wskazuje.
- Nie zapisujemy niczego w WooCommerce. Nie zakładamy produktów, nie zmieniamy cen, stanów magazynowych ani zamówień.
- Nie pomijamy sprawdzenia certyfikatu Twojej domeny. Nie ma ustawienia, którym można to u nas wyłączyć.
Kiedy coś nie działa
Poniżej są rzeczywiste sytuacje, które możesz zobaczyć, i to, co za każdą z nich stoi. Wiersze dotyczące zdjęcia są rozpisane osobno, bo połączenie rozróżnia te przypadki i zapisuje każdy pod własną nazwą, więc powód, dla którego zdjęcia nie ma, zawsze da się odczytać, a nie trzeba go zgadywać.
| Co widzisz | Co się dzieje i co z tym zrobić |
|---|---|
| To połączenie nie ma jeszcze zapisanego adresu, loginu ani hasła aplikacji. | Któregoś z tych trzech pól brakuje. Test nie wysyła wtedy do Twojej strony żadnego zapytania, bo nie ma dokąd i nie ma czym. Wróć do ekranu połączenia, uzupełnij wszystkie trzy i zapisz ponownie. |
| Nie udało nam się dotrzeć pod ten adres. | Strona w ogóle nie odpowiedziała. Sprawdź, czy działa, oraz czy podany adres to adres główny, a nie adres panelu. Na odpowiedź czekamy trzydzieści sekund, więc bardzo wolny hosting też potrafi wyglądać w ten sposób. Tak samo wygląda nieważny certyfikat, bo połączenie nie dochodzi wtedy do skutku. |
| WordPress nie przyjął tego loginu i hasła aplikacji. | Najczęstsza przyczyna jest jedna i banalna: hasło zostało wklejone bez spacji albo z uciętym znakiem. Spacje w haśle aplikacji są jego częścią. Druga możliwość to hasło już unieważnione. Wygeneruj nowe w Users, Profile, sekcja Application Passwords, i wklej je razem ze spacjami. Sprawdź też, czy podałeś login, a nie adres e-mail. |
| To konto WordPressa nie ma prawa korzystać z REST API. | Hasło jest dobre, brakuje uprawnienia. Nadaj temu kontu rolę Editor albo Administrator. Jeśli rola się zgadza, a odmowa zostaje, sprawdź wtyczkę bezpieczeństwa: blokowanie REST API dla integracji jest jej częstym ustawieniem domyślnym. |
| Pod tym adresem nie odpowiada żadne REST API WordPressa. | Sprawdź dwie rzeczy. Po pierwsze, czy adres to adres główny strony, a nie adres z /wp-admin albo /wp-json na końcu. Po drugie, czy REST API nie zostało wyłączone przez wtyczkę albo przez regułę zapory po stronie hostingu, bo to najczęstsza przyczyna, kiedy adres jest poprawny. |
| Strona ogranicza nam liczbę zapytań. | Robi to zwykle hosting albo moduł chroniący przed nadmiernym ruchem. To jedyny przypadek odmowy, który uznajemy za przejściowy: czekamy tyle, ile strona każe, i próbujemy ponownie, a nic nie przepada. Jeśli zdarza się stale, limit na tym hostingu jest za ciasny jak na tempo publikacji. |
| Strona odpowiedziała błędem serwera. | Numer błędu podajemy w komunikacie. To nie jest problem z hasłem ani z uprawnieniami: coś się wywróciło na Twoim WordPressie albo na hostingu. Spróbuj za kilka minut, a jeśli utrzymuje się dłużej, zajrzyj do logu błędów samej strony. |
| WordPress odmówił połączenia z jakimś innym numerem błędu. | Zbiorczy przypadek dla wszystkiego, czego nie da się przypisać do jednej przyczyny. Numer podajemy w komunikacie. Zacznij od adresu i hasła aplikacji, a jeśli oba są w porządku, napisz do nas z tym numerem, bo pełną odpowiedź Twojej strony mamy w logu. |
| Strona nie odpowiedziała na czas. | Czekamy trzydzieści sekund na odpowiedź i dziesięć na samo nawiązanie połączenia. Przekroczenie tego czasu traktujemy jako sytuację przejściową i próbujemy ponownie. Jeśli powtarza się przy każdej publikacji, hosting jest po prostu zbyt wolny i warto to zmierzyć od strony samej witryny. |
| Strona odpowiedziała błędem 419. | To odmowa z powodu zabezpieczenia przed fałszywymi żądaniami albo źle ustawionej trasy REST po stronie strony. Ponawianie nic nie da, więc nie ponawiamy. Najczęściej stoi za tym wtyczka bezpieczeństwa albo warstwa pośrednicząca przed WordPressem, a nie sam WordPress. |
| WordPress odrzucił sam artykuł. | Odmowa dotyczy zawartości zapytania, a nie logowania. Najczęściej oznacza to, że ta instalacja wymaga od wpisu pola, którego nie wypełniamy, albo że wtyczka sprawdzająca treść odrzuciła ją po swojemu. Ponawianie nic tu nie zmieni. Odpowiedź Twojej strony mamy w logu, więc napisz do nas, a powiemy, o co konkretnie chodziło. |
| WordPress przyjął artykuł, ale nie podał numeru wpisu. | Zdarza się, kiedy między nami a WordPressem stoi coś, co przerabia odpowiedź: warstwa buforująca, moduł optymalizujący albo zapora. Bez numeru nie mamy do czego wrócić przy poprawce, więc nie udajemy, że się udało. Sam wpis mógł jednak powstać, więc zanim spróbujesz ponownie, zajrzyj na listę wpisów. |
| Artykuł już tam był. | WordPress potrafi odmówić założenia wpisu, mówiąc, że taki już istnieje, i podać jego numer. Wtedy nie tworzymy drugiego, tylko przyjmujemy ten numer i dalej pracujemy na istniejącym wpisie. Jeżeli jednak WordPress odmówi w ten sposób, ale numeru nie poda, zatrzymujemy się i mówimy o tym wprost, bo wpis, którego numeru nie znamy, byłby dla nas potem niewidoczny. |
| Poprawka nie przeszła, bo wpisu już nie ma. | Wpis został skasowany w WordPressie, a my mieliśmy go odświeżyć. Nie zakładamy go ponownie, bo skasowanie było czyjąś decyzją, a nie usterką. |
| Artykuły przychodzą na stronę jako szkice. | Jeśli włączyłeś tryb roboczy, wszystko działa dokładnie tak, jak ustawiłeś, a artykuł czeka na Twoją akceptację pod Posts, All Posts. Jeśli go nie włączałeś, napisz do nas: status wysyłamy przy zakładaniu zawsze wprost, więc szkic oznacza wtedy, że po stronie połączenia ustawiony jest tryb roboczy. |
| Synchronizacja katalogu jest niedostępna, bo nie ma WooCommerce. | To nie jest błąd i test kończy się powodzeniem. Strona po prostu nie ma zainstalowanego WooCommerce, więc nie ma czego czytać. Publikowanie artykułów działa normalnie. Jeśli sklep zainstalujesz później, wystarczy powtórzyć test, bo sprawdzamy to na żywo za każdym razem. |
| WooCommerce odrzucił klucz i sekret. | To jedyny przypadek, w którym działający WordPress daje test zakończony niepowodzeniem, bo to jedyny, w którym ktoś wpisał dane, a sklep ich nie przyjął. Wygeneruj nowy klucz tylko do odczytu w WooCommerce, Settings, Advanced, REST API i wklej obie połówki. Sekret pokazuje się jeden raz, więc częstą przyczyną jest wklejona połowa pary. |
| WooCommerce jest, ale nie zapisano do niego klucza. | Sklep na stronie stoi, tylko nie mamy czym o niego pytać, a hasło aplikacji nie ma na tym koncie uprawnienia do zarządzania sklepem. To nie jest błąd, tylko niedokończone ustawienie. Jeśli chcesz, żebyśmy czytali katalog, wygeneruj klucz tylko do odczytu i dopisz go do połączenia. Jeśli nie chcesz, zostaw tak, jak jest. |
| Nie potwierdziliśmy, czy WooCommerce jest dostępne. | Sklep odpowiedział błędem w chwili, gdy o niego pytaliśmy. Nie zakładamy wtedy niczego w żadną stronę: możliwość jest niepotwierdzona, a nie odebrana. Powtórz test za kilka minut. Publikowanie artykułów działa przez ten czas normalnie. |
| Artykuł ukazał się bez zdjęcia. | Artykuł zawsze się ukazuje, nawet jeśli zdjęcie nie doszło, i tak ma być. Powodu nie musisz zgadywać: zapisujemy go przy połączeniu razem z datą i numerem artykułu. Kolejne wiersze tej tabeli opisują wszystkie powody, jakie mogą się tam pojawić. |
| Powód zapisany przy połączeniu: plik za duży. | Zdjęcie waży więcej niż 8 MB, czyli więcej niż nasz limit. Odmawiamy sami, zanim wyślemy plik, bo hosting współdzielony na taki plik odpowiada uciętym błędem albo zerwanym połączeniem i nikt się potem nie dowiaduje, co się stało. Ten sam powód zapisujemy, kiedy to WordPress odmówi z powodu rozmiaru albo braku miejsca. Jeśli Twój hosting przyjmuje większe pliki, napisz do nas. |
| Powód zapisany przy połączeniu: typ pliku odrzucony. | Strona nie przyjmuje plików tego typu. Najczęściej dotyczy to WebP albo AVIF na starszej instalacji, albo listy dozwolonych typów zawężonej przez wtyczkę bezpieczeństwa. Rozszerz listę dozwolonych typów albo napisz do nas, a dobierzemy inny format. |
| Powód zapisany przy połączeniu: brak prawa do wgrywania. | Konto, którego używamy, nie może wgrywać plików do biblioteki mediów, albo wgrywanie jest na tej stronie wyłączone w ogóle. Nadaj temu kontu rolę Editor lub Administrator i sprawdź wtyczki, które ograniczają bibliotekę mediów. Sam artykuł publikuje się przez ten czas normalnie. |
| Powód zapisany przy połączeniu: nie udało się pobrać pliku. | Adres, spod którego pobieramy zdjęcie, przestał odpowiadać. To najczęstszy z powodów i zwykle nie ma nic wspólnego z Twoją stroną: część serwisów ze zdjęciami wystawia adresy, które wygasają po kilkunastu godzinach, a publikacja, która ruszyła później, trafia już na pustkę. Twoja strona nie zrobiła tu nic złego. |
| Powód zapisany przy połączeniu: to nie było zdjęcie. | Spod adresu zdjęcia przyszła strona HTML, a nie plik graficzny. Prawie zawsze jest to strona błędu, ściana logowania albo zabezpieczenie przed podlinkowaniem. Nie wgrywamy tego na Twoją stronę, bo w bibliotece mediów zostałby po tym plik ze śmieciem. |
| Powód zapisany przy połączeniu: strona nie podała numeru załącznika. | WordPress odpowiedział powodzeniem, ale nie podał numeru wgranego pliku, więc nie ma czego podpiąć pod wpis. Zwykle stoi za tym warstwa buforująca albo optymalizująca, która przerabia odpowiedź po drodze. Zajrzyj do biblioteki mediów: plik mógł tam trafić mimo wszystko. |
| Powód zapisany przy połączeniu: błąd serwera przy wgrywaniu. | Strona odpowiedziała błędem serwera w trakcie wgrywania pliku. Artykuł ukazał się bez zdjęcia. Kolejne artykuły spróbują normalnie, a zapis przy połączeniu zniknie sam przy pierwszym wgraniu, które się powiedzie. |
| Produkty przyszły bez cen. | Nie udało się odczytać waluty sklepu. Zapisujemy wtedy produkty bez cen, zamiast zapisywać cenę bez waluty, bo liczba bez waluty daje się źle zacytować klientowi. Walutę można też podać nam na sztywno, jeśli sklep z jakiegoś powodu nie chce jej podać. |
| Linki do kategorii produktów przekierowują. | WooCommerce nie podaje adresu kategorii przy jej odczycie, więc składamy go ze standardowej końcówki /product-category/. Sklep, który tę końcówkę przestawił, dostaje wtedy link przekierowujący. Docelowa strona jest właściwa, tylko dochodzi się do niej o jeden przeskok dłużej. |
Jak nas odłączyć
Odcięcie nas zajmuje kilkanaście sekund i nie potrzebujesz nas do tego.
- Wejdź w Users, Profile, albo otwórz do edycji konto, którego dla nas użyłeś.
- W sekcji Application Passwords znajdź wpis o nazwie, którą nadałeś przy generowaniu, i kliknij Revoke. Od tej chwili to hasło nie działa, a Twoje własne hasło do panelu zostaje nienaruszone.
- Jeśli podałeś też klucz WooCommerce, skasuj go w WooCommerce, Settings, Advanced, REST API. To osobna lista i osobne kliknięcie.
Od tego momentu nie mamy do strony dostępu w ogóle. Artykuły, które już opublikowaliśmy, i zdjęcia, które już wgraliśmy, zostają u Ciebie, bo są Twoje. Daj nam znać, żebyśmy przestali próbować i przestali zasypywać Cię powiadomieniami o zepsutym połączeniu.
Jeśli konto powstało wyłącznie dla nas, możesz je zamiast tego zablokować albo skasować. Zablokowanie wystarczy i da się cofnąć, więc zwykle jest lepszym wyborem.