Witryny bez certyfikatu SSL (czyli przedrostka https w adresie) mają gwałtownie obniżane pozycje w wynikach wyszukiwania Google.

Na skutek wdrożenia certyfikatu zmienia się adres strony z http:// na https:// i mimo wykonania odpowiednich przekierowań, spodziewany jest około 3-miesięczny spadek ruchu o około 15%, po którym witryna zapewne powróci do poprzedniego ruchu. Nie jednak reguły co do czasu lub wysokości spadku ruchu. Spadek może też nie wystąpić wcale lub być większy, bądź trwać dłużej.

Alternatywą jest brak certyfikatu SSL i całkowity, stopniowy spadek ruchu. Im wcześniej wykona się tą zmianę, tym lepiej.

Czytaj dalej o tym, jak kupić i wdrożyć certyfikat SSL oraz jakie zadania należy wykonać.

W WordPressie używając wtyczki Yoast w wersji 6 i wcześniejszych można było przekierować strony przedstawiające pojedyncze media (zdjęcia, filmy itp.) do stron, do których te media były “załączone” przy pomocy mechanizmu załączania dostępnego w galerii WordPressa.

Wyjaśnienie: WordPress dla każdego medium tworzy osobną podstronę, prezentującą to medium, co niekorzystnie wpływa na pozycjonowanie i zazwyczaj jest zupełnie zbędne.

Można było używać tego mechanizmu np. do robienia galerii obrazów z odnośnikami, które (po odpowiednim załączeniu i automatycznym przekierowaniu) kierowały pod pożądane adresy podstron. Wersja 7 wtyczki zmieniła zachowanie tego mechanizmu – teraz albo adresy stron załączników nie są ruszane (co jest niekorzystne dla pozycjonowania), albo są przekierowywane na adresy tych załączników (co jest dobre dla pozycjonowania, ale uniemożliwia np. stosunkowo proste tworzenie menu przy użyciu mechanizmu galerii).

Aby przywrócić wcześniejsze zachowanie, należy wyłączyć przekierowanie załączników w ustawieniach Yoast i wprowadzić poniższy kod do pliku functions.php:

  add_action( 'template_redirect', 'sukcesstrony_attachment_url_redirect' );
  
  function sukcesstrony_attachment_url_redirect(){
	global $post;
	
	if ( is_attachment() && isset($post->post_parent) && is_numeric($post->post_parent) && ($post->post_parent != 0) ){
		wp_redirect( get_permalink( $post->post_parent ), 301 );
		wp_reset_postdata();
		exit();
	}

  }

We frameworku Genesis z jakiegoś powodu używanie własnej pętli w home.php nie działa, tzn. druga i kolejne poza pierwszą strony paginacji dają błąd 404 not found.

Problem ten występuje często – jest wiele zapytań o niego w internecie, natomiast żadnych konkretnych rozwiązań. Przyczyna problemu nie jest znana. Ogólnie framework ten jest fatalny – niesamowicie komplikuje prosty i wydajny system szablonów WordPressa.

Najprostszym rozwiązaniem jest zastosowanie własnej strony błędu i usunięcie z ustawień WordPressa przypisania podstrony bloga w sekcji Ustawienia → Czytanie (należy ustawić na –Wybierz–).

Plik php z pętlą należy nazwać inaczej, niż home.php (np. page-artykuly.php) i w jego pierwszej linii wpisać:

<?php /* Template Name: Artykuly */

Następnie w ustawieniach podstrony Artykuły należy wybrać szablon o nazwie Artykuly. Wtedy paginacja powinna działać poprawnie.

Poniżej zamieszczam orientacyjny kod pliku page-artykuly.php (źródło).

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.

Hosting współdzielony DreamHost mimo, że bardzo dobry, ma swoje ograniczenia. Strony z czasem go przerastają. Efektem są błędy 500 internal server error lub 404 not found, ponieważ procesy httpd, które przekraczają limity RAMu lub czasu procesora, są zabijane w trakcie wykonywania, co owocuje takimi właśnie błędami.

Aby przekonać się, ile razy procesy były zabijane, można zapytać wsparcie techniczne o liczbę wykonań prockill. U nas sięgała już kilka tysięcy miesięcznie – tyle razy strony nie ładowały się poprawnie (choć w zdecydowanej większości przy ich administracji, ponieważ użytkownicy mają większość zasobów ładowanych z CloudFlare).

W takiej sytuacji najprościej jest przerzucić się na ich pakiet VPS, który różni się w praktyce tym, że można ustawiać pojemność pamięci RAM i monitorować czas zużycia procesora, co niweluje powyższe problemy. Można także zostawiać włączone na stałe procesy w pamięci, co może być bardzo przydatne dla informatyków.

Wykonaliśmy testy przed i po zmianie hostingu Shared na VPS dla witryny opartej o WordPressa.