• en
  • pl

PHP

wordpreslogo
WordPress – jak to ugryźć

Wbrew obiegowej opinii, istnieje wiele sposobów na WordPress’a.

Żeby było ciekawiej – wszystkie (lub duża część z nich), o ile zrealizowane spójnie i zgodnie ze sztuką – są poprawne. Dlaczego więc tak częste są przypadki, gdy klient, po otrzymaniu zamówionego produktu, nie jest zadowolony? Zawodzi, jak zwykle, komunikacja.

Potrzeby a ich realizacja

O ile wykonanie samej strony w oparciu o WordPress’a nie znajduje się na liście najtrudniejszych zadań stawianych przed programistami (i projektantami), o tyle wstrzelenie się dokładnie w potrzeby klienta, a później jeszcze w potrzeby jego klientów jest już zadaniem niełatwym. Stąd właśnie Ci którzy potrafią zrobić to za każdym razem dobrze, są tak poszukiwanymi wykonawcami, a ich stawki mogą czasem szokować.

Ilu programistów, tyle „najlepszych” rozwiązań

Czy istnieje zatem prosty przepis na poprawną realizację strony w oparciu o ten CMS, czy niestety trzeba odwoływać się do intuicji, zaufania, czy wręcz – szczęścia? Zapewne w dużym stopniu – tak. Na szczęście możemy zminimalizować ryzyko, przede wszystkim zdobywając trochę tak potrzebnej wiedzy, która pozwoli nam ocenić proponowane rozwiązanie.

Wśród najpopularniejszych metod na podejście do tematu, można znaleźć:


Szablon robiony pod wymiar,
treść oparta o ACF (Advanced Custom Fields)


Plusy

  • Zrobiony prawidłowo szablon z odpowiednią, nawet wstępną optymalizacją, będzie wyraźnie szybszy,
  • Pełna dowolność co do łączenia i ładowania plików zewnętrznych – css i js, dzięki czemu możemy oszczędzić nawet kilka sekund przy ładowaniu strony,
  • Treść odporna na nieprawidłowe zmiany,
  • Dowolny wygląd w oparciu o własny projekt graficzny,
  • Edycja treści całkowicie odseparowana od projektu graficznego,
  • Zmiany treści nie wymagają żadnej wiedzy czy doświadczenia z HTML/CSS.

Minusy

  • Możliwość edycji wyłącznie treści, które zostały założone jako edytowalne na etapie programowania,
  • Projekt graficzny zazwyczaj nie jest modyfikowalny w prosty i wygodny sposób,
  • Ewentualne większe modyfikacje z poziomu CSS raczej nie bedą współgrały ze stworzonym szablonem.

Kiedy takie podejście jest zalecane

  • Gdy dysponujemy stałym wsparciem programistów budujących to rozwiązanie,
  • Gdy wprowadzanie treści odbywa się często i jest wykonywane przez ludzi nieobeznanych nawet w podstawowym stopniu z budową i sposobem działania strony www.


Podstawowa instalacja WordPress,
wraz z edycją treści poprzez edytor blokowy,
WP Bakery Page Builder, Elementor, Divi


Plusy

  • Duża elastyczność treści, niezależnie od dostępności programistów,
  • Nie ma konieczności opierania się na przygotowanym wcześniej projekcie graficznym,
  • Rozwiązanie można łączyć z innymi, jako podstawowe lub uzupełniające,

Minusy

  • Wydajność takiej strony jest zauważalnie niższa – wszystkie wskaźniki będą na niekorzyść w porównaniu z innymi rozwiązaniami,
  • Istnieje możliwość nieprawidłowego ustawienia lub modyfikacji treści, co może nam łatwo zepsuć wcześniej budowany układ – nie obędzie się wtedy bez ingerencji programisty lub osoby obeznanej z tematem,
  • Dopasowanie takiego projektu odbywa się zazwyczaj ze sporym udziałem własnych styli Css i Javascriptu,
  • Edycja wymaga nawet pobieżnej znajomości używanego edytora. Zdobycie takiej wiedzy na szczęście nie jest czasochłonne.
  • Optymalizacja może wiązać się z dodatkowym, często niemałym kosztem.

Kiedy takie podejście jest zalecane

  • Gdy nie dysponujemy budżetem na ciągłą, comiesięczną opiekę nad stroną,
  • Gdy strona nie jest modyfikowana często, ale chcemy zachować możliwość edycji możliwie wszystkich elementów z poziomu interfejsu, bez ingerencji w kod,
  • Gdy wydajność strony nie jest priorytetem (czyli zdecydowanie niezalecane rozwiązanie w przypadku rozwiązań e-commerce z relatywnie dużym ruchem).


Szablon pod wymiar,
z podziałem na bloki,
zintegrowany z edytorem blokowym


Zdecydowanie najbardziej zaawansowane, a jednocześnie najbardziej czasochłonne rozwiązanie. Jak to działa? Wykonawca buduje dla klienta zestaw gotowych bloków, uwzględniając przygotowany wcześniej projekt graficzny. Dzięki temu można te bloki łączyć w dowolnej kombinacji, z pomocą interfejsu graficznego.

Plusy

  • Duża elastyczność edycji treści, niezależnie od dostępności programistów,
  • Można oprzeć się na dowolnym projekcie graficznym,
  • Zachowujemy wydajność strony i elastyczność budowy treści,
  • Nie mamy technologicznych ograniczeń co do wdrażanych rozwiązań,

Minusy

  • Duża czasochłonność i kompleksowość rozwiązania na poziomie projektu – co wpływa na koszt,
  • Zmiana projektu graficznego wiąże się z budową strony w zasadzie od zera,
  • Utrzymanie takiego rozwiązania wiąże się zazwyczaj z comiesięcznym kosztem,
  • Budowa takiego szablonu jest zadaniem wyłącznie dla sprawnych i dobrze zorientowanych w technologiach programistów, przejęcie takiego projektu stawia spore wymagania dla zespołu, jeśli np zdecydujemy się na przeniesienie odpowiedzialności na zespół in-house. Narzędzia użyte do budowy znajdują się zdecydowanie poza zakresem podstawowych umiejętności programistów PHP i wymagają obycia i doświadczenia, aby użyć ich prawidłowo.

Kiedy takie podejście jest zalecane

  • Gdy strona edytowana jest często, przez spory zespół ludzi, jednocześnie oczekujący możliwość budowy treści w elastyczny sposób, bez potrzeby ingerencji z zewnątrz,
  • Gdy wydajność strony jest kluczowa, lub przynajmniej bardzo istotna,
  • Gdy liczymy się z comiesięcznym kosztem utrzymania i rozwoju takiego rozwiązania,
  • Gdy mamy zaufanie co do zespołu który buduje nam stronę, co do dalszego wsparcia w przyszłości.
  • Gdy zależy nam na bezpieczeństwie wdrażanych rozwiązań,
  • Nie chcemy aby użytkownicy odczuwali aktualizacje i zmiany wprowadzane na stronie,
  • Gdy zależy nam na jakości wprowadzanych rozwiązań, przez co ścieżka wdrażania przewiduje wersje testowe i QA.

Jak widać elementów które trzeba brać pod uwagę jest cała gama. Prawidłowa odpowiedź? Niestety nie ma. Jednak posiadając tą cząstkę wiedzy zmniejszymy prawdopodobieństwo pomyłki przepalenia budżetu na rozwiązanie które nie zrealizuje w stu procentach naszych potrzeb. Oszczędzimy też tarć z wykonawcą, który często nawet działając w dobrej wierze, wybierze rozwiązanie nieadekwatne do naszych wymagań.


Masz wątpliwości? Bez obaw, pomożemy

facebook-icon
Jak połączyć sesję Javascript z PHP w Facebook SDK 4.0

SDk Facebooka nigdy nie grzeszyły ani stabilnością, ani rozbudowaną dokumentacją. Zespół developerów FB próbuje jednak tą dziurę łatać w kolejnych wersjach. Ostatnia, czwarta wersja SDK ma już znamiona używalnego. Wprowadza kilka zmian, które ułatwiają wiele elementów, jednak w pierwszym momencie można pogubić się co, jak i dlaczego. Spróbujemy przybliżyć zmiany na podstawie przypadku, kiedy użytkownik loguje się za pomocą SDK Javascriptowego, a następnie nasz program ma za zadanie wykorzystać ciastko otworzone w ten sposób do wykonywania zapytań z pomocą PHP.

//These need to be updated, obviously
$fb_app_id = "xxxxxxxxxxxxxxxxxxx";
$fb_app_secret = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";

require_once( 'Facebook/FacebookSession.php' );
require_once( 'Facebook/FacebookRedirectLoginHelper.php' );
require_once( 'Facebook/FacebookRequest.php' );
require_once( 'Facebook/FacebookResponse.php' );
require_once( 'Facebook/FacebookSDKException.php' );
require_once( 'Facebook/FacebookRequestException.php' );
require_once( 'Facebook/FacebookOtherException.php' );
require_once( 'Facebook/FacebookAuthorizationException.php' );
require_once( 'Facebook/GraphObject.php' );
require_once( 'Facebook/GraphSessionInfo.php' );
require_once( 'Facebook/FacebookSignedRequestFromInputHelper.php' );
require_once( 'Facebook/FacebookJavaScriptLoginHelper.php' );
require_once( 'Facebook\HttpClients\FacebookHttpable.php' );
require_once( 'Facebook\HttpClients\FacebookCurlHttpClient.php' );
require_once( 'Facebook\HttpClients\FacebookCurl.php' );
require_once( 'Facebook\Entities\SignedRequest.php' );
require_once( 'Facebook\GraphUser.php' );

use Facebook\GraphUser;
use Facebook\FacebookRequest;
use Facebook\FacebookRequestException;
use Facebook\FacebookSession;
use Facebook\FacebookSignedRequestFromInputHelper;
use Facebook\FacebookJavaScriptLoginHelper;
use Facebook\Entities\SignedRequest;
use Facebook\HttpClients\FacebookCurlHttpClient;
use Facebook\HttpClients\FacebookHttpable;
use Facebook\HttpClients\FacebookCurl;

FacebookSession::setDefaultApplication($fb_app_id, $fb_app_secret);
$session = null;

//Starting new session to remember the token
session_start();

/* checking if facebook session token is available */
if ( !empty( $_SESSION["fb_token"] ) ) {
    try {
        $session = new FacebookSession( $_SESSION["fb_token"] );
        $session->validate();
    } catch (FacebookAuthorizationException $ex) {
        $session = null;
        $_SESSION["fb_token"] = NULL;
    }
} else {
    // getting token from js api/sdk
    $helper = new FacebookJavaScriptLoginHelper();

    try {
        $session = $helper->getSession();

        // creating new, long lived session. Js returns shortly living token
        $session = $session->getLongLivedSession();

        // remembering token for further usage
        $_SESSION["fb_token"] = $session->getToken();

    } catch (FacebookRequestException $ex) {
        // When Facebook returns an error
        $_SESSION["fb_token"] = NULL;
        echo $ex->getMessage();
    } catch (Exception $ex) {
        echo $ex->getMessage();
    }
}

if ($session) {
    try {
        //getting user data
        $user_profile = (new FacebookRequest(
            $session, 'GET', '/me'
        ))->execute()->getGraphObject(GraphUser::className());

        //printing user data
        print_r( $user_profile );
    } catch (FacebookRequestException $e) {
        print_r($e->getMessage());
        return null;
    }
}

Sam kod powinien być zrozumiały, jedna trzeba zwrócić uwagę na kilka rzeczy. Token zwracany przez getLongLivedSession() nie jest zapisywany przez SDK, należy go zapamiętać własnoręcznie, i wykorzystać do utworzenia kolejne sesji. Inaczej przy kolejnym requescie tracimy możliwość wykonania zapytania do API facebooka.

Kod służący do zainicjowania SDK po stronie js wygląda następująco:

window.fbAsyncInit = function() {
	FB.init({
	  appId      : '<?php echo $fb_app_id; ?>',
	  xfbml      : true,
	  version    : 'v2.0',
	  cookie:true
	});
};

(function(d, s, id){
	 var js, fjs = d.getElementsByTagName(s)[0];
	 if (d.getElementById(id)) {return;}
	 js = d.createElement(s); js.id = id;
	 js.src = "//connect.facebook.net/en_US/sdk.js";
	 fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));

Zwracamy uwage na cookie:true, co tworzy ciastko po stronie serwera i daje nam dostęp do sesji z poziomu PHP.

Najnowsza wersja SDK wymaga PHP w wersji minimum 5.3.

Powodzenia!

Facebook SDK 4.0
https://developers.facebook.com/docs/reference/php/4.0.0

CONTACT-FORM-7
Contact form 7 – problem z wysyłaniem wiadomości

Jedna z najpopularniejszych wtyczek do tworzenia formularzy w WordPress czasem ma swoje humory. Zazwyczaj jednak są to problemy w konfiguracją, znacznie rzadziej błąd samej wtyczki.

Pierwszym krokiem jest zazwyczaj weryfikacja czy serwer/hosting obsługuje funkcję php mail(). Funkcja ta często jest niedostępna lub źle skonfigurowany jest serwer pocztowy.

Drugim krokiem do znalezienia problemu, jest instalacja wtyczki o nazwie WP Mail SMTP, która pozwala w pełni skonfigurować mechanizm wysyłania wiadomości w WordPressie. Zazwyczaj wymuszenie wysyłania wiadomości przez SMTP rozwiązuje problem (rozwiązuje również problem oznaczania wiadomości jako spam).

Zdarza się, że hosting nie pozwala na swobodne wysyłanie wiadomości od dowolnego użytkownika (pole FROM w formularzu). Często natomiast w formularzu używamy adresu e-mail użytkownika w polu nadawcy. Te dwa elementy powodują, że niemożliwe staje się wysłanie wiadomości – nadawca wiadomości zostanie przez serwer odrzucony. Łatwo tutaj o fałszywy wynik testu, jeśli podamy w formularzu adres który jest hostowany przez ten sam serwer, nasza wiadomość zostanie wysłana poprawnie, jednak każdy inny adres zostanie zablokowany.

Powodzenia!