Przykład wdrożenia nowych funkcjonalności i nowej szaty graficznej na stronie opartej o WordPress Multisite

W maju miałem przyjemność uczestniczyć w kolejnym spotkaniu miłośników WordPressa, podczas 4 edycji wrocławskiego WordUpa. W czasie swojej prezentacji mówiłem o tym, czy WordPress Multisite mocno komplikuje wdrożenia i jak w takiej konfiguracji sprawuje się wtyczka Advanced Custom Fields. Poniżej znajdziesz slajdy z tej prezentacji, wraz z krótkim streszczeniem.

Prezentacja

(jeżeli nie widzisz prezentacji to znajdziesz ją też tutaj)

Stara strona

Projekt, jaki otrzymałem do realizacji, to zmiana szaty graficznej i dodanie nowych funkcjonalności na stronie opartej o WordPressa w wersji Multisite. Sieć składała się z ponad 150 witryn, każda po kilkanaście/kilkadziesiąt stron. Najważniejsze elementy wizualne każdej z nich to menu główne, wspólne dla wszystkich witryn w ramach sieci, slider oraz dodatkowe menu z obrazkami na dole strony. Do tego dochodziły także blogi z aktualnościami korzystające z widgetów (nie tylko tych standardowych).

Poprzednia wersja strony

W samym panelu aktualny szablon nie wprowadzał wielu modyfikacji. Jedna dodatkowa pozycja w menu z ustawieniami plus ciekawe rozwiązanie polegające na oparciu slidera o natywny mechanizm WordPressa  do wgrywania nagłówków. Pomysł ciekawy, ale praktycznie niemożliwy do rozbudowy i daleki od ideału jeżeli chodzi o użyteczność.

Nowy projekt

Nowy projekt graficzny w układzie był podobny do istniejącego rozwiązania, rozszerzając je o nowe funkcjonalności.

Nowy projekt graficzny - WordPress Multisite

Najważniejsze elementy, które wymagały zmiany to:

  • Slider – zamiast zwykłych obrazków pojawiła się opcja dodawania także tekstów (trzy typy slajdów).
  • Sekcja boksów – możliwość dowolnego kreowania układu boksów przez administratorów poszczególnych witryn wchodzących w skład sieci (osiem typów boksów).
  • Sekcja tweetów.
  • Duże menu na dole strony, wspólna dla wszystkich witryn, wchodzących w skład sieci.

Wraz z projektem otrzymaliśmy krótki brief z wymaganiami. Jednym z nich był podział wdrożenia na dwie części. Pierwsza (wersja 1.1) miała obejmować tylko zmianę wyglądu strony, bez dodawania nowych funkcjonalności. Nowy slider, boxy, tweety itd. miały być dodane podczas drugiej rundy.

Wdrożenie 1.1

W teorii wydawało się, że wystarczy zmienić plik CSS, aby zakończyć pierwszą część wdrożenia. Tyle teoria. Po sprawdzeniu kodu HTML generowanego przez aktualny motyw, okazało się, że nie da się na nim oprzeć prawidłowego CSS dla nowego wyglądu, i w  związku z tym musieliśmy przygotować nową strukturę i przejrzeć oraz zmodyfikować wszystkie pliki motywu.

Przygotowanie plików CSS

Bardzo dużo czasu zajęło znalezienie stron, które korzystały z tego czy innego szablonu, aby sprawdzić czy wszytko wyświetla się prawidłowo po zmianach.

Po przygotowaniu nowej wersji motywu pojawiło się pytanie: Czy aktywujemy go jako nowy motyw czy podmieniamy pliki w istniejącym?

Tutaj po raz pierwszy dał znać o sobie WordPress Multisite. Wgrywając nowy motyw, jako administrator całej sieci, możemy go tylko włączyć, innymi słowy udostępnić administratorom poszczególnych witryn. A dopiero oni, tak jak na zwykłej stronie opartej o WordPressa, muszą go aktywować. Nie da się wymusić zmiany motywu na wszystkich witrynach wchodzących w skład sieci.

Dodatkowo trzeba pamiętać o tym, że przy każdej aktywacji nowego szablonu, niezależnie czy jest to WordPress Multisite czy pojedyncza instalacja, odpinają nam się widgety i menusy, które następnie trzeba przypiąć w nowym szablonie na odpowiednie miejsca.

Niekatywne widgety po zmianie szablonu

Pozostało więc nam zamienić pliki w istniejącym motywie. Przy takim rozwiązaniu nie należy zapominać o cache przeglądarki i wymusić przeładowanie wszystkich plików css i javascript, aby uniknąć sytuacji w której załaduje się nowy kod HTML a CSS zostanie pobrany z pamięci podręcznej przeglądarki. Bałagan na stronie gwarantowany :)

Wdrożenie 2.0

Prace nad wersją 2.0, zostały poprzedzone analizą różnych rozwiązań, które moglibyśmy zastosować do obsługi nowych funkcjonalności (od Custom Post Types, poprzez różne wtyczki aż do napisania całej obsługi od podstaw).

Z racji tego, że wcześnie bardzo często korzystałem z pomocy wtyczki Advanced Custom Fields i tym razem postanowiłem spróbować. Przejrzałem informacje w sieci i niestety nigdzie nie znalazłem potwierdzenia, że wtyczka zadział z WordPressem Multisite. Na stronie autora była tylko informacja, że nie testował jej  z taką konfiguracją, więc nie gwarantuje,  że będzie działała prawidłowo.  W teorii, jeżeli zastanowić się, jak wtyczka przechowuje dane, a z drugiej strony jak działa WordPress Multisite (każda witryna ma swój własny zestaw tabel), to teoretycznie powinno działać. Teoretycznie :)

Wtyczka Advanced Custom Fields i WordPress Multisite

Po serii testów okazało się, że… jednak działa:)

Pojawiło się za to kilka dodatkowych pytań:

  1.  Jak ukryć interfejs wtyczki w panelu administratora przed użytkownikami? Nie chcemy przecież, aby wchodzili do definicji pól a następnie coś zmieniali bo mogłoby się to źle odbić na działaniu strony (a jak widać, że coś jest dostępne to korci :)
  2. Jak dodać definicje własnych typów pól na 150 witrynach? Wchodzenie do panelu każdej witryny i „wyklikiwanie” konfiguracji to praca na kilka miesięcy.
  3. Jak będzie wyglądała w przyszłości możliwość zmiany tych definicji?

Okazało się, że wtyczka ACF zawiera wszytko czego potrzebujemy i wykorzystując natywne rozwiązania, takie jak stała ACF_LITE oraz opcje eksportu definicji pól do kodu PHP, udało się rozwiązać wszystkie problemy.

Podsumowanie

  1. WordPress Multisite, w przypadku tego konkretnego wdrożenie, nie był taki straszy i tylko w niektórych sytuacjach wymagał dodatkowej uwagi.
  2. Okazało się, że wtyczka Advanced Custom Fields działa w środowisku Multisite bez problemu.
  3. Trzeba pamiętać o takich rzeczach jak cache przeglądarki, odpinanie widgetów, menusów bo inaczej można narobić bałaganu podczas wdrożenia.

A Wy jakie macie doświadczenia z WordPressem Multisite?

2 Comments Przykład wdrożenia nowych funkcjonalności i nowej szaty graficznej na stronie opartej o WordPress Multisite

  1. SpeX

    Rozumiem iż z poziomu MS nie da się wymusić zmiany wyglądu szablonu na wszystkich stronach, ale czy przypadkiem nie da się tego zrobić jakoś z poziomu zapytania SQL?

    Reply
    1. Paweł Wawrzyniak

      W sumie to nigdy nie próbowałem zmiany szablonu z poziomu bazy danych. Patrząc jednak na to, co się dzieje w funkcji switch_theme, widać, że na jednym update by się nie skończyło. Ale sam pomysł zastosowania SQL ciekawy, dzięki:)

      Reply

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *