Drupal nie ma jednego, stałego miejsca na wpisy blogowe. WordPress zawsze ma "wpisy"; Drupal ma tyle typów treści, ile ich kiedyś zbudował twórca strony, i każdy nazywa się tak, jak ten ktoś go nazwał. Dlatego nie zgadujemy: po zapisaniu danych odpytujemy Twoją stronę, sprawdzamy jakie typy treści naprawdę na niej są, i pokazujemy Ci nazwę tego, do którego trafi artykuł, zanim wyślemy choćby jedno zdanie.
Cały ruch idzie przez JSON:API, moduł, który jest w rdzeniu Drupala. Nie instalujesz niczego z internetu, nie wgrywasz żadnej wtyczki od nas i nie dajesz nam hasła do swojego konta administratora. Włączasz to, co i tak leży w Twojej instalacji, i zakładasz jedno osobne konto.
Nazwy pozycji w menu podajemy tak, jak brzmią w domyślnej, angielskiej instalacji, a obok nich adres strony w panelu. Jeśli Twój Drupal mówi po polsku, napisy będą przetłumaczone, ale adres po nazwie domeny jest zawsze ten sam, więc to on jest pewniejszym drogowskazem.
Zanim zaczniesz
Potrzebujesz czterech rzeczy. Jeśli którejś brakuje, dalsza część poradnika nie zadziała.
- Dostęp administratora do tej strony w Drupalu. Będziesz włączać moduły, zmieniać ustawienie usługi sieciowej i nadawać uprawnienia, a każda z tych trzech rzeczy jest zarezerwowana dla administratora. Jeśli to nie Ty, poproś osobę, która się stroną opiekuje.
- Adres główny strony, na przykład
https://przyklad.pl. Nie adres panelu, nie adres z/adminna końcu i nie adres z prefiksem językowym w rodzaju/pl. - Ważny certyfikat HTTPS. Łączymy się z Twoją stroną z włączonym sprawdzaniem certyfikatu i nie wyłączamy go na życzenie. Cudza domena z wygasłym albo samodzielnie podpisanym certyfikatem to dokładnie ten przypadek, w którym takie sprawdzanie ma sens.
- Typ treści, w którym trzymasz wpisy. Nie musisz znać jego nazwy systemowej, my ją znajdziemy, ale warto wiedzieć, który to na stronie, żeby rozpoznać go w naszym potwierdzeniu.
Całość zajmuje około piętnastu minut, jeśli hasło administratora masz pod ręką. Jeśli musisz o coś poprosić osobę, która opiekuje się stroną, zaplanuj to jako jedną krótką rozmowę: wszystkie trzy ustawienia z kroku pierwszego robi się na trzech ekranach, jedno po drugim.
Na których wersjach Drupala to działa
Działa na Drupalu 9, 10 i 11. Warunkiem jest JSON:API w rdzeniu, a jest on tam od wersji 8.7.
Zalecamy 10 albo 11, bo tylko te dostają jeszcze poprawki bezpieczeństwa. Wsparcie Drupala 9 skończyło się 1 listopada 2023, a Drupala 10 kończy się 9 grudnia 2026.
Na Drupalu 8.6 i starszym JSON:API nie ma w rdzeniu, a Drupal 7 nie ma go w ogóle i doszedł do końca wsparcia 5 stycznia 2025. W obu przypadkach odpowiedź jest ta sama i jest niewygodna: strona wymaga aktualizacji do Drupala 10 lub 11, zanim ją podłączymy. Nie jest to nasze ograniczenie, które moglibyśmy dla Ciebie znieść. Do instalacji, która od lat nie dostała poprawki bezpieczeństwa, nie będziemy się łączyć hasłem, bo to hasło jest tam dokładnie tak bezpieczne, jak cała reszta tej strony.
Jeśli jesteś na starszej wersji, napisz do nas mimo wszystko. Podłączenia nie zrobimy, ale powiemy wprost, na czym stoisz i czego wymaga aktualizacja, żebyś mógł to z kimś wycenić.
1. Włącz zapis przez JSON:API
To jest krok, na którym zatrzymuje się większość osób, więc jest opisany najdokładniej. JSON:API w świeżym Drupalu jest wyłączony, a po włączeniu potrafi tylko czytać. Do zapisu trzeba przestawić trzy rzeczy na trzech różnych ekranach i żadna z nich nie podpowiada, że pozostałe dwie istnieją.
To nie jest przeoczenie twórców Drupala, tylko decyzja: większość stron używa JSON:API wyłącznie do czytania, więc rdzeń wysyła go z ustawieniem "tylko odczyt" i każe świadomie je zmienić. Zmieniasz je raz i tylko dla tej jednej instalacji.
a) Włącz dwa moduły z rdzenia
- Wejdź na
/admin/modules, czyli pozycję Extend w górnym pasku administracyjnym. - W polu wyszukiwania na górze listy wpisz
json. - Zaznacz JSON:API. To on wystawia adres
/jsonapi, pod którym się z Tobą łączymy. - Wyczyść filtr, wpisz
basici zaznacz HTTP Basic Authentication. To on sprawia, że Drupal w ogóle czyta nazwę użytkownika i hasło, które mu wysyłamy. - Zjedź na dół strony i naciśnij Install.
Pominięcie HTTP Basic Authentication jest najpodstępniejszym błędem w całym tym poradniku, bo nie wygląda jak błąd. Drupal, który nie ma czym odczytać naszego logowania, nie odrzuca go: on je ignoruje i obsługuje nas jako gościa, odpowiadając "w porządku". Wygląda to jak działające połączenie, a każda próba publikacji kończy się odmową. Nasz test to wykrywa i mówi wprost, że to ten moduł, więc nie musisz się tego domyślać.
b) Pozwól JSON:API zapisywać
- Wejdź na
/admin/config/services/jsonapi, czyli Configuration, dalej Web services, dalej JSON:API. - W sekcji Allowed operations wybierz drugą opcję: Accept all JSON:API create, read, update, and delete operations.
- Zapisz.
Drupal ostrzega przy tym ustawieniu, żeby włączać wszystkie operacje tylko wtedy, gdy strona tego wymaga. Wymaga, bo o to właśnie chodzi w tym połączeniu: bez tego nikt, łącznie z nami, nie zapisze przez JSON:API ani jednego znaku. Zapisywać i tak będzie mogło tylko konto, które ma na to uprawnienia, a te nadajesz w następnym podpunkcie.
c) Nadaj uprawnienia roli, której będziemy używać
Uprawnienia w Drupalu wisi się na roli, nie na osobie. Za chwilę założysz osobną rolę i osobne konto, ale ekran jest ten sam, więc opisujemy go tu raz: /admin/people/permissions, czyli People, dalej zakładka Permissions. Każde uprawnienie to jedna kolumna dla roli i jeden wiersz dla uprawnienia.
Poniżej jest lista tego, co naprawdę zaznaczyć, i po co. Nie jest to komplet checkboxów do odklikania w ciemno: dwa ostatnie są opcjonalne, a bez nich artykuł i tak się opublikuje, tylko będzie uboższy.
| Uprawnienie | Do czego jest naprawdę potrzebne |
|---|---|
| Typ treści: Create new content na przykład "Article: Create new content" |
Jedyne uprawnienie, bez którego nie da się nic zrobić. To ono pozwala nam dodać artykuł. Bez niego Drupal odmawia, a nasz test połączenia pokazuje nazwę Twojego typu treści w komunikacie, żebyś wiedział, którego wiersza szukać. |
| View published content | Pozwala nam przeczytać jeden istniejący wpis tego typu, żeby zobaczyć, jak naprawdę nazywają się jego pola. To dzięki temu strona, na której pole treści nie nazywa się "body", też działa. Bez tego uprawnienia użyjemy nazw domyślnych Drupala i jeśli u Ciebie są inne, publikacja zakończy się odmową z nazwą pola. |
| Use the Basic HTML text format | Treść artykułu wysyłamy w formacie Basic HTML, tym samym, którego używa redaktor w Drupalu. Format ten dopuszcza nagłówki, akapity, listy, linki i obrazki, czyli dokładnie to, z czego zbudowany jest artykuł. Celowo nie prosimy o Full HTML, bo to uprawnienie pozwala wstawić na stronę dowolny kod i nie ma powodu, żeby integracja je miała. |
| Create and edit URL aliases opcjonalne, moduł Path |
Dzięki niemu artykuł zachowuje ładny adres, który dla niego przygotowaliśmy. Bez niego Drupal odmawia przyjęcia adresu, my ten fragment usuwamy i wysyłamy artykuł jeszcze raz bez niego, a wpis dostaje własny adres Drupala w rodzaju /node/123. Artykuł się ukazuje, tylko pod brzydszym adresem. |
| Typ treści: Edit own content opcjonalne |
Potrzebne tylko wtedy, gdy mamy móc później poprawić opublikowany artykuł, na przykład po jego odświeżeniu. "Own" wystarczy, bo Drupal przypisuje autorstwo temu kontu, którym się logujemy, więc poprawiamy wyłącznie własne wpisy. |
Czego nie zaznaczać: Administer content ani Bypass content access control. Są to uprawnienia, które dają władzę nad całą treścią strony, a my ich nie potrzebujemy. Nie ustawiamy pola autora, bo ustawienie go wymagałoby właśnie takiego uprawnienia; zamiast tego zostawiamy je puste i Drupal sam podpisuje wpis kontem, którym go wysłaliśmy. To jest zresztą prawda: to konto go opublikowało.
Jeśli chcesz, żebyśmy zostawiali artykuły jako szkice do Twojej akceptacji, dołóż jeszcze View own unpublished content, inaczej konto nie zobaczy tego, co samo zapisało.
Na obrazek wyróżniający nie ma osobnego uprawnienia. Wysyłamy go pod adres pola obrazka w tym samym typie treści i przechodzi on na tych samych prawach co sam artykuł.
2. Załóż konto, którego będziemy używać
Potrzebne nam są trzy rzeczy i nic ponadto: adres strony, nazwa użytkownika i hasło. Żadnego tokenu, żadnego OAuth, żadnego klucza do wygenerowania. Drupal w rdzeniu nie ma czym wystawić tokenu, a jedyny sposób, żeby go mieć, to doinstalowanie modułu, wygenerowanie pary kluczy na serwerze i zarejestrowanie aplikacji, czyli popołudnie pracy programisty. Zwykłe konto z wąskimi uprawnieniami jest tu rozwiązaniem uczciwszym, bo widzisz dokładnie, co ono może.
- Wejdź na
/admin/people/roles, czyli People, zakładka Roles, i dodaj nową rolę. Nazwij ją tak, żebyś za rok wiedział, co to jest, na przykład nazwą naszej usługi. - Wróć na
/admin/people/permissionsi zaznacz w kolumnie tej nowej roli uprawnienia z poprzedniego kroku. Nadaj je tej roli, a nie roli Authenticated user, bo tamta obejmuje każdego zalogowanego na stronie. - Wejdź na
/admin/people/create, czyli People, dalej Add user. - Wpisz nazwę użytkownika. Zapamiętaj ją dokładnie w tej postaci, bo to jej będziemy używać. Adres e-mail konta to co innego i nim się nie zalogujemy.
- Ustaw długie, losowe hasło. Nie używaj hasła, którym ktokolwiek loguje się gdzie indziej.
- W sekcji Roles zaznacz rolę utworzoną przed chwilą, i tylko ją.
- Zostaw status Active i zapisz.
Jeszcze raz, bo to najczęstsza pomyłka w całym poradniku: nazwa użytkownika, nie adres e-mail. Drupal odrzuci logowanie adresem e-mail, a komunikat, który wtedy zobaczysz, brzmi po prostu "nie przyjął nazwy użytkownika i hasła".
Jeśli Twoja strona wymusza uwierzytelnianie dwuskładnikowe albo stoi za modułem ochronnym, który blokuje logowanie po HTTP, to konto musi być z tego wyłączone. Logowanie nazwą i hasłem w nagłówku żądania nie ma jak przejść przez ekran z kodem jednorazowym.
3. Przekaż nam dane
Dane wklejasz u nas raz. Trzymamy je zaszyfrowane i nigdy ich potem nie pokazujemy, także sobie.
Podłączenie ustawiamy razem z Tobą przy starcie. Nie wklejasz tych danych 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 wpisać w które pole
- Adres strony: adres główny, bez ukośnika na końcu, na przykład
https://przyklad.pl. Niehttps://przyklad.pl/admin, niehttps://przyklad.pl/jsonapii nie adres z prefiksem językowym. - Nazwa użytkownika: dokładnie ta, którą wpisałeś w polu Username przy zakładaniu konta.
- Hasło: całe, od pierwszego do ostatniego znaku. Jeśli po drodze przeszło przez notatnik, sprawdź, czy nie doczepiła się do niego spacja albo złamanie wiersza.
- Typ treści: zostaw puste, jeśli nie masz pewności. Znajdziemy go sami i zapytamy tylko wtedy, gdy nie będziemy pewni. Jeśli jednak wiesz, wpisz nazwę systemową, na przykład
blog_post.
Są jeszcze trzy ustawienia, których prawie nikt nie rusza, a które można nam podać, jeśli Twoja strona odbiega od standardu: inny prefiks JSON:API niż /jsonapi (zmienia go tylko moduł JSON:API Extras), inny format tekstu niż Basic HTML, oraz tryb szkicu, w którym zostawiamy artykuły niepublikowane. Napisz, jeśli któreś z nich Cię dotyczy.
4. Sprawdź, że połączenie działa
Po zapisaniu danych naciśnij test połączenia. To dwa zapytania do Twojej strony i żadne z nich niczego na niej nie zmienia.
Pierwsze to zwykłe odczytanie spisu treści JSON:API. Drugie to celowo pusty formularz zapisu: dokument, z którego Drupal fizycznie nie może nic utworzyć, ale który przechodzi przez całą drogę zapisu, więc odpowiedź na niego mówi nam po kolei, czy tryb tylko do odczytu jest wyłączony i czy to konto ma prawo tworzyć treść. Nic nie powstaje, a wiemy wszystko.
Kiedy się udaje, dostajesz jedno zdanie z nazwą typu treści, do którego pójdą artykuły. Przeczytaj tę nazwę uważnie. To jest moment, w którym wychwytujesz pomyłkę, zanim zrobi to Twój czytelnik.
Połączono z Drupalem. Artykuły będą publikowane jako treść "article". Drupal nie ma katalogu produktów, więc synchronizacja produktów jest niedostępna.
Zdanie o produktach nie jest usterką. Drupal w rdzeniu po prostu nie ma sklepu, a sklep na Drupalu to osobny projekt z własnym modelem danych, którego na razie nie obsługujemy. Publikacja artykułów działa normalnie.
Po pierwszym artykule sprawdź go w dwóch miejscach: na liście treści pod /admin/content, gdzie pojawi się nowy wpis podpisany kontem, które przed chwilą założyłeś, oraz na samej stronie, pod adresem artykułu.
Do jakiego typu treści trafią artykuły
To jest ta część Drupala, która najczęściej zaskakuje, więc warto ją przeczytać do końca. WordPress zawsze ma "wpisy" i zawsze będzie je miał. Drupal ma tyle typów treści, ile ich zbudował twórca strony, a nazwa "article" to tylko ta, którą przypadkiem nosi typ z domyślnej instalacji. Twój blog może równie dobrze siedzieć w typie blog_post, news albo wpis, obok osobnego typu article, którego używasz do czegoś zupełnie innego.
Dlatego szukamy go, zamiast zakładać. Po kolei:
- Jeśli podałeś nam nazwę typu treści, używamy dokładnie jej. Przyjmujemy obie postaci,
articleinode--article. Jeśli takiego typu na stronie nie ma, mówimy to wprost i wypisujemy nazwy typów, które tam naprawdę są. - Jeśli strona wystawia przez JSON:API dokładnie jeden typ treści, to jest to ten. Nie ma tu o co pytać.
- Jeśli typów jest więcej, szukamy wśród nich nazwy, która oznacza blog, od najbardziej jednoznacznej:
article,blog_post,blog,post,news,artykul,wpis. - Jeśli żadna nie pasuje, zatrzymujemy się i pytamy, wypisując wszystko, co znaleźliśmy. Nie losujemy typu, bo artykuł trafiłby wtedy równie chętnie do typu, w którym trzymasz zespół albo lokalizacje.
Typ page, czyli strony statyczne z domyślnej instalacji, jest z tej listy celowo wykluczony. Wrzucenie datowanego artykułu do typu, w którym siedzi strona "O nas", nie było by drobną pomyłką, tylko złą odpowiedzią.
Skąd wiemy, jak nazywają się pola
Kiedy typ jest już wybrany, pobieramy z niego jeden istniejący wpis i odczytujemy z niego nazwy pól. Dzięki temu strona, na której pole treści nazywa się inaczej niż body, też działa, bez pytania Cię o cokolwiek.
Jeśli ten typ nie ma jeszcze ani jednego wpisu, czyli blog jest zupełnie nowy, używamy nazw domyślnych Drupala, body i field_image, i publikujemy mimo to. Odmowa opublikowania pierwszego artykułu tylko dlatego, że nie ma się na czym wzorować, była by absurdem.
Pole obrazka rozpoznajemy po nazwie, bo pusty wpis nie zdradza, do czego to pole prowadzi. Szukamy field_image, a potem pola field_*, w którego nazwie jest image, photo, picture, cover, zdjecie albo obrazek. Pomyłka nic nie kosztuje: adres do wysyłki pliku dla pola, które plikiem nie jest, po prostu nie istnieje, a artykuł ukazuje się bez obrazka zamiast nie ukazać się wcale.
Strony, na których obrazek wyróżniający jest odwołaniem do wpisu w bibliotece mediów, a nie zwykłym polem obrazka, nie dostaną obrazka wcale. To znane ograniczenie, a nie usterka: taki obrazek wymaga utworzenia po drodze osobnego wpisu medialnego, czego z pustego pola nie da się poprawnie odgadnąć. Artykuł publikuje się normalnie, tylko bez zdjęcia, a my zapisujemy powód tam, gdzie go zobaczysz.
Jeśli któreś z tych pól rozpoznamy źle, możesz nam je podać na sztywno. Podanie pustej nazwy pola obrazka jest sposobem na powiedzenie "ten typ nie ma zdjęcia, przestańcie próbować".
Co robimy, a czego nie zrobimy nigdy
Co robimy
- Odczytujemy listę typów treści, które Twoja strona wystawia.
- Odczytujemy jeden istniejący wpis wybranego typu, żeby poznać nazwy jego pól.
- Dodajemy nowe wpisy do tego jednego typu.
- Poprawiamy wpisy, które sami dodaliśmy, gdy odświeżamy artykuł.
- Wysyłamy obrazek wyróżniający do pola obrazka w tym samym typie.
Czego nie robimy nigdy
- Nie usuwamy niczego. Ani wpisów, ani pól, ani typów treści, ani plików.
- Nie dotykamy żadnego innego typu treści niż ten, który wskazałeś.
- Nie zmieniamy ustawień strony, modułów, motywu ani uprawnień.
- Nie ustawiamy pola autora, bo wymagało by to uprawnienia do zarządzania całą treścią.
- Przy poprawianiu artykułu nie wysyłamy ponownie ani statusu publikacji, ani adresu. Jeśli cofnąłeś wpis do szkicu albo zmieniłeś mu adres, zostaje tak, jak ustawiłeś. Poprawka dotyczy treści.
Kiedy coś nie działa
Poniżej są prawdziwe komunikaty, które możesz zobaczyć, i to, co za każdym z nich stoi.
| Co widzisz | Co się dzieje i co zrobić |
|---|---|
| Pod tym adresem nie odpowiedziało żadne JSON:API. | Najczęściej moduł nie jest włączony. Wejdź na /admin/modules, zaznacz JSON:API i naciśnij Install. Jeśli moduł jest włączony, sprawdź sam adres: musi to być adres główny strony, bez /admin i bez prefiksu językowego. |
| Drupal odpowiedział, ale zignorował nasze logowanie. | Włączony jest JSON:API, ale nie ma modułu HTTP Basic Authentication, więc Drupal nie ma czym odczytać nazwy użytkownika i hasła i traktuje nas jak gościa. Wejdź na /admin/modules, zaznacz go i naciśnij Install. To ten błąd, który bez tego komunikatu wygląda jak działające połączenie. |
| Drupal ma JSON:API w trybie tylko do odczytu. | To ustawienie domyślne w każdej świeżej instalacji. Wejdź na /admin/config/services/jsonapi, w sekcji Allowed operations wybierz Accept all JSON:API create, read, update, and delete operations. i zapisz. |
| Drupal nie przyjął tej nazwy użytkownika i hasła. | W dziewięciu przypadkach na dziesięć podany został adres e-mail zamiast nazwy użytkownika. Sprawdź ją w profilu konta w Drupalu. Pozostałe przyczyny: hasło skopiowane niekompletnie, spacja doklejona na końcu, albo konto zablokowane w międzyczasie. |
| Drupal zalogował nas, ale nie pozwala temu kontu tworzyć treści. | Roli tego konta brakuje uprawnienia Create new content dla tego typu treści. Nazwę typu podajemy w komunikacie, więc dokładnie tego wiersza szukaj na /admin/people/permissions. Sprawdź też, czy uprawnienie zostało nadane właśnie tej roli, a nie innej. |
| Drupal odrzucił artykuł i wskazał nazwę pola. | W Drupalu pole, które wskazuje na coś innego, na obrazek, kategorię albo osobę, wysyła się inaczej niż zwykły tekst: jako powiązanie, z typem i identyfikatorem tamtego czegoś. Wysłane jak zwykła wartość, kończy się właśnie taką odmową. My budujemy je poprawnie, więc jeśli mimo to ją widzisz, prawie zawsze znaczy to, że pole, które rozpoznaliśmy jako obrazek, jest u Ciebie polem innego rodzaju, albo że ten typ treści ma pole wymagane, którego nie umiemy wypełnić. Części opcjonalnych pozbywamy się same i wysyłamy artykuł ponownie bez nich; z polem wymaganym już tak nie można. Napisz do nas z nazwą pola z komunikatu, mamy w dzienniku pełną odpowiedź Twojej strony. |
| Nie potrafimy rozpoznać, który typ treści jest blogiem. | Zwyczajna sytuacja: typ treści z wpisami nie nazywa się "article", tylko jakoś inaczej, a innej rozpoznawalnej nazwy na tej stronie nie ma. Wypisujemy wszystkie typy, które znaleźliśmy. Podaj nam nazwę tego właściwego, a zapamiętamy ją na stałe. |
| Ta strona nie ma typu treści o takiej nazwie. | Podany przez Ciebie typ nie istnieje albo nazywa się inaczej, niż go zapamiętałeś. Potrzebna jest nazwa systemowa, ta z małych liter i podkreśleń, a nie etykieta widoczna na ekranie. W komunikacie wypisujemy nazwy, które strona naprawdę wystawia, więc wybierz z tej listy. |
| Strona stoi na starszym Drupalu, bez JSON:API w rdzeniu. | Drupal 7 nie ma JSON:API w ogóle, a Drupal 8.6 i starszy ma go tylko jako moduł doinstalowany z zewnątrz. Obie te wersje są od dawna po końcu wsparcia. Podłączenie wymaga aktualizacji strony do Drupala 10 albo 11. Napisz do nas, powiemy, co dokładnie sprawdziliśmy, żebyś mógł to komuś przekazać. |
| JSON:API działa, ale nie wystawia żadnego typu treści. | Zwykle robi to moduł, który celowo ogranicza JSON:API, na przykład JSON:API Extras z wyłączonymi zasobami. Sprawdź jego ustawienia, albo upewnij się, że strona ma w ogóle jakiś typ treści. |
| Drupal nie chce pokazać nam spisu swojego API. | Coś przed samą stroną blokuje adres /jsonapi: moduł ochronny, reguła w zaporze aplikacyjnej albo ustawienie hostingu. Osoba opiekująca się serwerem musi ten adres przepuścić. |
| Drupal odrzucił typ zawartości JSON:API. | Prawie zawsze pośrednik przed stroną, cache albo moduł bezpieczeństwa, przepisuje nagłówki naszych żądań. Sam Drupal jest tu w porządku, problem jest po drodze do niego. |
| Artykuł się ukazał, ale bez zdjęcia. | Powodów jest kilka: ten typ treści nie ma pola obrazka, jego obrazek jest odwołaniem do biblioteki mediów, plik okazał się za duży, źródłowy adres zdjęcia przestał odpowiadać, albo strona nie pozwoliła temu kontu wysłać pliku. Powód zapisujemy przy połączeniu, więc widać go bez zgadywania. Artykuł zawsze ukazuje się mimo to, bo zapłaciłeś za tekst. |
| Artykuł ma adres w rodzaju /node/123 zamiast ładnego. | Roli brakuje uprawnienia Create and edit URL aliases, więc Drupal odmówił przyjęcia adresu, a my usunęliśmy go i wysłaliśmy artykuł jeszcze raz bez niego. Dodaj to uprawnienie, a kolejne artykuły dostaną już właściwy adres. |
| Strona ogranicza nam liczbę zapytań. | Zwykle robi to hosting albo moduł chroniący przed nadmiernym ruchem. Czekamy i próbujemy ponownie, nic nie ginie. Jeśli zdarza się to bez przerwy, limit na tym hostingu jest za ciasny dla tempa publikacji. |
| Synchronizacja produktów jest niedostępna. | To nie jest błąd. Drupal w rdzeniu nie ma sklepu, a sklepu na Drupalu na razie nie obsługujemy. Artykuły publikują się normalnie, po prostu nie mają listy produktów, do której mogły by się odwołać. |
Jak nas odłączyć
Odcięcie nas trwa kilkanaście sekund i nie potrzebujesz do tego nas.
- Wejdź na
/admin/peoplei znajdź konto, które dla nas założyłeś. - Zablokuj je albo usuń. Zablokowanie wystarcza i jest odwracalne, więc zwykle jest lepszym wyborem.
- Jeśli wolisz zostawić konto, wystarczy zmienić mu hasło. Od tej chwili nasze przestaje działać.
Od tego momentu nie mamy do strony żadnego dostępu. Artykuły, które już opublikowaliśmy, zostają u Ciebie, bo są Twoje. Daj nam znać, żebyśmy przestali próbować i przestali zasypywać Cię powiadomieniami o zerwanym połączeniu.
Modułów JSON:API i HTTP Basic Authentication nie musisz wyłączać, ale możesz. Jeśli nic innego z nich nie korzysta, warto przy okazji wrócić na /admin/config/services/jsonapi i przestawić ustawienie z powrotem na tryb tylko do odczytu.