RSS
RSS

Problem: WPML automatycznie ustawia lub przywraca niepoprawne tłumaczenie


Kategorie: Administracja, Tworzenie stron, WordPress, Wszystkie

0

W jednym z motywów napotkaliśmy następujący problem: po wykonaniu tłumaczeń w WPML dla WordPressa treści wpisywanych przez administratora w panelu, po kilku odświeżeniach niektóre z tych tłumaczeń losowo przywracały język oryginału lub wyświetlały się w niepoprawnym języku.

Czasami także oryginalny tekst do tłumaczenia był nieaktualny w sekcji “Tłumaczenia wyrażeń”, w stosunku do aktualnej treści ustawianej przez administratora w panelu.

Obydwa problemy dotyczyły prawdopodobnie tego, że WPML zapisał nieaktualną wersję oryginalnych tekstów do tłumaczenia i nie potrafił poradzić sobie ze zmianami oryginału w przyszłości.

Kroki ku rozwiązaniu problemu prezentujemy poniżej.

Sumujesz w Google Analytics tygodniami, przedstawiając każdą kropkę jako tydzień? Pewnie robisz to źle


Kategorie: Administracja, Kampanie reklamowe, Pozycjonowanie, Promocja, Wszystkie

0

Zadanie jest proste: chcemy porównać ruch w lipcu obecnego i lipcu ubiegłego roku.

Nic prostszego, prawda? Wchodzimy w statystyki odwiedzin i ustawiamy daty do porównania:

Ukazuje się poprawny wykres, na którym każda kropka reprezentuje domyślnie jeden dzień:

Jeśli jednak zmienimy sposób prezentacji tak, by każda kropka reprezentowała Tydzień, ukaże się dziwny, niepoprawny intuicyjnie wykres:

Zauważmy, że wykres dzienny wcale nie miał spadku pomarańczowej linii na samym początku. Na końcu zaś, linia ta wykracza poza niebieską. Porównujemy jednak dokładnie 31 dni tego samego miesiąca.

Skąd więc taka różnica?

Wyjaśniamy w dalszej części artykułu.

Statystyki Google Analytics błędnie liczą procentowe wzrosty ruchu


Kategorie: Administracja, Kampanie reklamowe, Pozycjonowanie, Promocja, Wszystkie

0

Większość pozycjonerów stosuje liczby z Google Analytics i nie są nawet świadomi, że obliczenia ich wzrostów lub spadków ruchu są skrajnie niepoprawne.

Jeśli w maju jednego roku mieliśmy 289 wizyt, a rok później już 1097, to o ile razy zwiększył się ruch?

Ponad 3 razy, prawda? Dokładniej, to 1097 / 289 = 3,7958 razy więcej, czyli po zaokrągleniu wzrost wynosił 380%.

Zgadza się?

Według Google Analytics – nie. Oto fragment statystyk, porównujący 2 okresy z dokładnie powyższymi liczbami odwiedzin:

Google Analytics - błąd

Jak widać, “zmiana” została obliczona jako 279,58%. Wynika z tego, że liczba mniejsza, niż 300, według Google nie mieści się nawet 3 razy w 1000. O co tu chodzi?

Domena nie działa po przeniesieniu? Problemy z DNSSEC


Kategorie: Administracja, Nowe technologie, Tworzenie stron, Wszystkie

8

Jeśli w firmie, u której domena jest utrzymywana, wdrożone jest zabezpieczenie DNSSEC i wykona się transfer tej domeny do innej firmy hostingowej (np. gdy zmienia się hosting), to domena może przestać działać przy próbie otworzenia strony z niektórych komputerów.

Problem objawia się zwyczajnym błędem sugerującym, że taka domena nie jest zarejestrowana, np.:

  • Witryna jest nieosiągalna
  • ERR_NAME_NOT_RESOLVED
  • Nie udało się znaleźć adresu IP serwera ze stroną

Problem ten występuje w szczególności po przeniesieniu domeny z firmy Nazwa do innej, która nie obsługuje zabezpieczenia DNSSEC (np. Zenbox).

Jednocześnie problem czasami występuje, a czasami nie – nawet odświeżając stronę z tego samego komputera, czasami załaduje się poprawnie, a czasami – wcale.

Aby omówić rozwiązanie problemu, musimy go najpierw wyjaśnić.

Ciekawy błąd PHP 7: Parse error: syntax error, unexpected end of file in the line…


Kategorie: Administracja, Nowe technologie, Tworzenie stron, WordPress, Wszystkie

1

Przełączając jeden z serwerów na PHP 7 z PHP 5.3 powstał ciekawy błąd 500 (internal server error), z następującą treścią:

Parse error: syntax error, unexpected end of file nazwa pliku, w tym przypadku functions.php WordPressa in the line numer ostatniej linii pliku

Pierwszą myślą jest niedomknięty nawias, średnik, przecinek itp… Okazało się jednak, że problem leżał gdzie indziej.

Otóż na serwerze konfiguracja PHP w wersji 7 miała domyślnie dyrektywę PHP short_open_tag ustawioną na Off, co powodowało, że użycie kodu <? do rozpoczęcia bloku PHP (zamiast alternatywnego <?php) owocowało właśnie rzeczonym błędem.

Tego skrótowego znacznika otwarcia kodu PHP używa mnóstwo projektów, zaś zlokalizowanie problemu okazało się dosyć trudne – treść błędu niczego konkretnego nie mówiła (wskazywała na ostatnią, pustą linię pliku), zaś wykrywacze błędów PHP nie zgłaszały pomyłek. Również narzędzia online nie pomagały – zazwyczaj błędów wcale nie sygnalizowały wcale, a jeśli już, to bez wskazywania, gdzie one występują i czemu.

Sam problem pojawiał się więc nawet przy użyciu kodu ?><?

Rozwiązanie problemu

Najprostszą metodą jest ustawienie w pliku php.ini dyrektywy na On:

short_open_tag = On ;

Nie zawsze jednak jest to możliwe. W tym przypadku dostawca serwera hostingowego zablokował możliwość edytowania ustawień PHP, także przez funkcję PHP: @ini_set('short_open_tag', 'On');

Pozostało więc żmudne zmienianie każdego wystąpienia otwierającego znacznika PHP <? na <?php

Niestety przy mnóstwie dodatków do systemu WordPress i jego aktualizacjach taka konfiguracja serwera oznacza, że w każdej chwili witryna może przestać działać.

Dlatego też tak istotne jest, by swoje strony umieszczać na profesjonalnym hostingu, a nie byle tańszym.

Dlaczego taka dyrektywa istnieje?

Znaki <? oznaczają także początek kodu języka XML. Jeśli więc w projekcie PHP używa się XMLa, to mogą powstać problemy z nieprawidłowym włączeniem interpretera PHP, gdy używany jest kod XML.

W praktyce takie sytuacje się raczej nie zdarzają i wiele ludzi stosuje skrótowe znaczniki otwarcia kodu PHP. Jak jednak widać po tym przykładzie, jednak należy stosować pełny zapis znacznika otwarcia.