Tytuł oryginału: Building Web Apps with WordPress: WordPress as an Application Framework, 2nd Edition
Tłumaczenie: Agnieszka Górczyńska ISBN: 978-83-283-6925-2
© 2021 Helion SA
Authorized Polish translation of the English edition of Building Web Apps with WordPress 2E ISBN 9781491990087 © 2020 Brian Messenlehner and Jason Coleman
This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher.
Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji.
Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli.
Autorzy oraz Helion SA dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autorzy oraz Helion SA nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce.
Helion SA
ul. Kościuszki 1c, 44-100 Gliwice tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl
WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/wordp2
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.
Printed in Poland.
• Kup książkę
• Poleć książkę • Księgarnia internetowa
• Lubię to! » Nasza społeczność
Spis treści
Przedmowa ... 19 Wprowadzenie ... 21 1. Tworzenie aplikacji internetowych w WordPressie ... 27
Czym jest witryna internetowa? 27
Czym jest aplikacja? 27
Czym jest aplikacja internetowa? 27
Funkcje aplikacji internetowej 28
Aplikacje mobilne 30
Progresywne aplikacje internetowe 30
Dlaczego WordPress? 31
Jesteś już użytkownikiem WordPressa 31
Zarządzanie treścią w WordPressie jest łatwe 31
Łatwe i bezpieczne zarządzanie użytkownikami w WordPressie 32 Wtyczki 32
Elastyczność ma duże znaczenie 33
Częste uaktualnienia zabezpieczeń 33
Koszt 34 Odpowiedź na często pojawiającą się krytykę wybranych aspektów WordPressa 34
Kiedy nie używać WordPressa? 37
Planujesz licencjonować lub sprzedawać technologię witryny internetowej 37 Inna platforma szybciej doprowadzi Cię do celu 38
Elastyczność jest bez znaczenia 38
Aplikacja musi działać w czasie rzeczywistym 39
WordPress jako framework aplikacji 39
WordPress kontra frameworki MVC 40
Anatomia aplikacji internetowej WordPressa 42
Czym jest SchoolPress? 43
SchoolPress działa w sieci zawierającej wiele witryn WordPressa 43
Model biznesowy SchoolPressa 43
Poziomy członkostwa i role użytkowników 44
Klasy są grupami BuddyPress 44
Zadanie to przykład CPT 44
Rozwiązania zadań są podtypami CPT zadań 44
Semestry to taksonomie dla CPT klasy 45
Wydział to taksonomia dla CPT klasy 45
Aplikacja SchoolPress ma jedną główną niestandardową wtyczkę 45 Aplikacja SchoolPress używa kilku innych niestandardowych wtyczek 46 Aplikacja SchoolPress używa motywu Memberlite 46
2. Podstawy WordPressa ... 47
Struktura katalogu WordPressa 47
Katalog główny 48
/wp-admin 48 /wp-includes 48 /wp-content 48
Struktura bazy danych WordPressa 50
wp_options 50 Funkcje zdefiniowane w /wp-includes/option.php 50 wp_users 53 Funkcje zdefiniowane w plikach /wp-includes/pluggable.php
i /wp-includes/user.php 53
wp_usermeta 57 wp_posts 61 Funkcje zdefiniowane w /wp-includes/post.php 61 wp_postmeta 66 Funkcje zdefiniowane w /wp-includes/post.php 66 wp_comments 70 Funkcje zdefiniowane w /wp-includes/comment.php 71 wp_commentsmeta 75 Funkcje zdefiniowane w /wp-includes/comment.php 76 wp_terms 78 Funkcje zdefiniowane w /wp-includes/taxonomy.php 78 wp_termmeta 82 wp_term_taxonomy 84 Funkcje zdefiniowane w /wp-includes/taxonomy.php 85 wp_term_relationships 86
Zaczepy — akcje i filtry 87
Akcje 88 Filtry 88
Środowiska programistyczne i hostingowe 90
Praca lokalna 90
Wybór hostingu 91
Środowiska robocze i produkcyjne 92
Rozszerzanie WordPressa 92
3. Stosowanie wtyczek WordPressa ... 95
Licencja GPLv2 96
Instalowanie wtyczek WordPressa 96
Utworzenie własnej wtyczki 97
Struktura plików we wtyczce 98
/adminpages/ 99 /classes/ 99 /css/ 99 /js/ 101 /images/ 101 /includes/ 102 /includes/lib/ 102 /pages/ 102 /services/ 103 /scheduled/ 103 /schoolpress.php 104
Dodatki dla istniejących wtyczek 104
Przypadki użycia i przykłady 104
Pętla WordPressa 105
Zmienne globalne WordPressa 105
Wtyczki bezpłatne 115
Admin Columns 115
Advanced Custom Fields 115
BadgeOS 116
Posts 2 Posts 116
Members 117
W3 Total Cache 117
Yoast SEO 117
Wtyczki premium 118
Gravity Forms 118
BackupBuddy 118
WP All Import 118
Wtyczki społecznościowe 119
BuddyPress 119
4. Motywy ... 131
Motyw kontra wtyczka 131
Gdzie umieścić kod podczas tworzenia aplikacji? 131
Kiedy opracować wtyczkę? 132
Gdzie umieszczać kod podczas tworzenia motywu? 133
Hierarchia szablonu 133
Szablony strony 135
Przykładowy szablon strony 135
Stosowanie zaczepów do kopiowania szablonów 137
Kiedy należy używać szablonu motywu? 138
Funkcje WordPressa powiązane z motywem 139
Stosowanie funkcji locate_template() w motywach 140
Plik style.css 141
Wersjonowanie plików CSS motywu 142
Plik functions.php 143
Motywy i niestandardowe typy postów 144
Popularne frameworki motywów 144
Frameworki motywów WordPressa 144
Frameworki motywów przeznaczone nie tylko dla WordPressa 146
Tworzenie motywu potomnego dla Memberlite 146
Wykorzystanie frameworka Bootstrap w motywie aplikacji 147
Menu 148
Menu nawigacyjne 148
Menu dynamiczne 149
Responsywny układ strony 150
Wykrywanie urządzenia i ekranu za pomocą CSS 150 Wykrywanie urządzeń i funkcji za pomocą kodu JavaScript 152
Wykrywanie urządzenia w PHP 154
Słowo końcowe na temat wykrywania przeglądarki WWW 157
5. Niestandardowe typy postów, metadane postów i taksonomie ... 159
Domyślne i niestandardowe typy postów 159
Strona 159 Post 159 Załącznik 159 Wersja 160
Element menu nawigacyjnego 160
Niestandardowe style CSS 160
Changeset 160
Bufor oEmbed 160
Żądania użytkowników 161
Bloki kodu wielokrotnego użycia 161
Definiowanie i rejestrowanie niestandardowych typów postów 161
register_post_type( $post_type, $args ); 162
Co to jest taksonomia i jak należy z niej korzystać? 171
Taksonomie kontra metadane posta 171
Tworzenie niestandardowych taksonomii 173
register_taxonomy( $taxonomy, $object_type, $args ) 173 register_taxonomy_for_object_type( $taxonomy, $object_type ) 177 Stosowanie niestandardowych typów postów i taksonomii
we własnych motywach i wtyczkach 177
Szablony stron archiwum i pojedynczego posta w motywie 177 Stare dobre komponenty WP_Query i get_posts() 178
Metadane w niestandardowych typach postów 181
add_meta_box( $id, $title, $callback, $screen, $context, $priority, $callback_args ) 182 Stosowanie elementów obsługi metadanych w edytorze bloków 184 Opakowania klas dla niestandardowych typów postów 185 Rozszerzanie klasy WP_Post kontra opakowanie obiektu tej klasy 187
Po co używać klasy opakowania? 188
CTP i taksonomie będą w jednym miejscu 188
Definiowanie kodu w klasie opakowania 189
Klasa opakowania jest czytelniejsza 191
6. Użytkownicy, role i uprawnienia ...193
Pobieranie danych użytkownika 194
Dodawanie, uaktualnianie i usuwanie użytkowników 196
Zaczepy i filtry 199
Czym są role i uprawnienia? 200
Sprawdzanie ról i uprawnień użytkownika 200
Tworzenie niestandardowych ról i uprawnień 202
Rozszerzanie klasy WP_User 203
Dodanie właściwości rejestracji i profilu 205
Dostosowanie do własnych potrzeb tabeli użytkowników w panelu głównym 209 Wtyczki 211
Theme My Login 211
Ukrycie paska administracyjnego przed użytkownikami
niebędącymi administratorami 212
Paid Memberships Pro 212
Paid Memberships Pro Register Helper 212
Members 213
WP User Fields 213
7. Praca z API WordPressa, obiektami i funkcjami pomocniczymi ... 215
API skrótów 215
Atrybuty skrótu 216
Skróty zagnieżdżone 217
Usunięcie skrótu 217
Inne użyteczne funkcje powiązane ze skrótami 218
API widżetów 219
Zanim zaczniesz dodawać własny widżet 220
Dodawanie widżetu 220
Definiowanie obszaru widżetu 223
Osadzanie widżetu poza dynamicznym paskiem bocznym 225
API widżetów w panelu głównym WordPressa 226
Usunięcie widżetu panelu głównego 227
Dodawanie własnego widżetu panelu głównego 228
API ustawień 231
Czy naprawdę potrzebna jest strona ustawień? 231 Czy zamiast ustawień można użyć zaczepu lub filtru? 232 Stosowanie standardów podczas dodawania ustawień 233 Ignorowanie standardów podczas dodawania ustawień 233
API przepisywania adresów URL 234
Dodawanie reguły przepisywania adresu URL 235
Usuwanie reguły przepisywania adresu URL 236
Inne funkcje przepisywania adresów URL 237
WP-Cron 239
Definiowanie niestandardowego odstępu czasu 241
Tworzenie harmonogramu dla pojedynczych zdarzeń 241
Wywoływanie zadań mechanizmu cron z serwera 242
Stosowanie zadań mechanizmu cron jedynie po stronie serwera 243
WP Mail 244
Wysyłanie ładniejszych wiadomości e-mail za pomocą WordPressa 245
API nagłówka pliku 246
Dodawanie nagłówków plików do własnych plików 248 Dodawanie nowych nagłówków do wtyczek i motywów 249
API Heartbeat 250
8. Bezpieczny WordPress ... 255
Dlaczego bezpieczeństwo jest ważne? 255
Podstawy zapewnienia bezpieczeństwa 256
Regularnie uaktualniaj oprogramowanie 256
Nie używaj nazwy użytkownika admin 256
Używaj silnych haseł 256
Przykłady beznadziejnych haseł 257
Przykłady dobrych haseł 257
Zabezpieczenie WordPressa 258
Nie zezwalaj administratorowi na edycję wtyczek lub motywów 258
Zmień domyślny prefiks tabel bazy danych 258
Przenieś wp-config.php 259
Ukryj komunikaty błędów logowania 259
Ukryj numer wersji WordPressa 260
Uniemożliw logowanie poprzez stronę wp-login.php 260 Dodaj niestandardowe reguły .htaccess w celu zabezpieczenia strony wp-admin 261
Certyfikaty SSL i HTTPS 262
Instalacja certyfikatu SSL w serwerze 262
Stosowanie szyfrowania SSL na stronach logowania i administracyjnych 265
Debugowanie problemów związanych z HTTPS 266
Zapobieganie błędom dzięki „opcji nuklearnej” 266
Twórz kopię zapasową całości! 268
Skanuj, skanuj i skanuj! 269
Użyteczne wtyczki zapewnienia bezpieczeństwa 269
Wtyczki związane z blokowaniem spamu 269
Wtyczki związane z tworzeniem kopii zapasowej 270 Wtyczki związane z zaporą sieciową i skanowaniem 270
Wtyczki związane z logowaniem i hasłami 271
Tworzenie bezpiecznego kodu 271
Sprawdzenie uprawnień użytkownika 272
Niestandardowe zapytania SQL 273
Weryfikacja danych, ich oczyszczanie i stosowanie znaków sterujących 273
Jednokrotnie używana liczba 278
9. Frameworki JavaScript ...285
Co to jest ECMAScript 286
Co to jest ES6 286
Co to jest ES9 287
Co to jest ESNext 287
Co to jest AJAX 287
Co to jest JSON 287
jQuery i WordPress 287
Dodawanie innych bibliotek JavaScript 288
Gdzie umieszczać niestandardowy kod JavaScript 289
Wywołania AJAX za pomocą WordPressa i jQuery 290
Zarządzanie wieloma żądaniami AJAX 295
API Heartbeat 296
Ograniczenia WordPressa związane z przetwarzaniem asynchronicznym 301
Frameworki JavaScript 302
Backbone.js 302 React 303
10. API REST WordPressa ... 305
Czym jest API REST? 305
API 305 REST 306 JSON 306 HTTP 306
Dlaczego warto używać API REST WordPressa 309
Używanie wersji drugiej API REST WordPressa 311
Odkrycie 311 Uwierzytelnianie 311
Trasy i punkty końcowe 316
Żądania 317 Odpowiedź 320
Dodawanie własnych tras i punktów końcowych 321
register_rest_route( $namespace, $route, $args, $override ); 321 Konfiguracja wtyczki Single Sign-On w WordPressie 322
Dodanie trasy /wp-sso/v1/check 322
Stosowanie uwierzytelniania prostego w omawianej wtyczce 323 Używanie zdefiniowanego punktu końcowego do sprawdzenia danych
uwierzytelniających użytkownika 324
Popularne wtyczki używające API REST WordPressa 325 WooCommerce 325 BuddyPress 327
Paid Memberships Pro 328
11. Projekt Gutenberg, bloki i niestandardowe typy postów ... 333
Edytor WordPressa 334
Wtyczka Classic Editor 335
Używanie bloków podczas tworzenia treści i projektu 335
Używanie bloków do tworzenia funkcjonalności 335
Tworzenie własnego bloku 335
Przykład minimalnego bloku 336
Używanie bloków niestandardowych do tworzenia aplikacji 337 Włączenie edytora bloków w niestandardowych typach postów 338
Kategorie bloków 338
Bloki Homework 339
Ograniczenie bloków do określonych CPT 339
Ograniczenie CPT do określonych bloków 340
Szablon bloku 341
Zapisywanie danych bloku w metadanych posta 342
Podpowiedzi 343
Włączenie WP_SCRIPT_DEBUG 343
Używanie wywołania filemtime() dla wersji skryptu 344
Więcej podpowiedzi 344
Poznaj dokładnie JavaScript, Node.js i React 344
12. Sieć witryn internetowych WordPressa ...347
Dlaczego sieć witryn internetowych 347
Dlaczego nie należy korzystać z sieci witryn 348
Alternatywy dla sieci witryn 349
Wielu autorów lub kategorii w tej samej witrynie WordPressa 349
Niestandardowe typy postów 349
Oddzielne witryny internetowe 349
Używanie usługi konserwacji WordPressa 349
Wielodostępność 350
Przygotowanie sieci witryn 350
Zarządzanie siecią witryn WordPressa 352
Panel główny 353
Witryny internetowe 353
Użytkownicy 353 Motywy 354 Wtyczki 354 Ustawienia 355 Uaktualnienia 356
Struktura bazy danych sieci witryn 356
Tabele o zasięgu sieci 356
Tabele poszczególnych witryn 358
Współdzielone tabele witryny internetowej 359
Mapowanie domeny 360
Wtyczki użyteczne w sieci witryn internetowych 360
Gravity Forms User Registration Add-On 361
Dodatek Member Network Sites dla wtyczki Paid Memberships Pro 361
Multisite Global Media 361
Multisite Plugin Manager 361
Multisite Robots.txt Manager 361
NS Cloner — Site Copier 362
WP Multi Network 362
Podstawowa funkcjonalność sieci witryn WordPressa 362
$blog_id 362 is_multisite() 363 get_current_blog_id() 363
switch_to_blog( $new_blog ) 363
restore_current_blog() 364 get_blog_details( $fields = null, $get_all = true ) 364 update_blog_details( $blog_id, $details = array() ) 366
get_blog_status( $id, $pref ) 366
update_blog_status( $blog_id, $pref, $value ) 367 get_blog_option( $id, $option, $default = false ) 367
update_blog_option( $id, $option, $value ) 367
delete_blog_option( $id, $option ) 368
get_blog_post( $blog_id, $post_id ) 368
add_user_to_blog( $blog_id, $user_id, $role ) 369
wpmu_delete_user( $user_id ) 369
create_empty_blog( $domain, $path, $weblog_title, $site_id = 1 ) 370
Funkcje niewymienione w tym podrozdziale 370
13. Lokalizacja aplikacji WordPressa ... 371
Czy w ogóle zachodzi potrzeba lokalizacji aplikacji 371 Jak lokalizacja jest przeprowadzana w WordPressie 372
Definiowanie lokalizacji w WordPressie 372
Domeny tekstu 373
Definiowanie domeny tekstu 373
Przygotowanie ciągów tekstowych za pomocą funkcji tłumaczeń 375
__( $text, $domain = "default" ) 375
_e( $text, $domain = "default" ) 376
_x( $text, $context, $domain = "default" ) 376 _ex( $title, $context, $domain = "default" ) 377 Jednoczesne tłumaczenie tekstu i stosowanie znaków sterujących 377
Tworzenie i wczytywanie plików tłumaczeń 377
Struktura pliku do lokalizacji 378
Generowanie pliku .pot 379
Utworzenie pliku .po 380
Utworzenie pliku .mo 381
GlotPress 381 Używanie narzędzia GlotPress dla wtyczek
i motywów umieszczanych w repozytorium WordPress.org 381
Utworzenie własnego serwera GlotPress 381
14. Optymalizacja i skalowanie WordPressa ...383
Terminologia 383
Źródło kontra krawędź 385
Testowanie 385
Co będzie testowane 386
Pasek debugowania w Chrome 388
Narzędzie Stan witryny WordPressa 390
Apache Bench 390
Siege 397
W3 Total Cache 397
Ustawienia Page Cache 398
Minimalizacja 400
Buforowanie bazy danych 401
Buforowanie obiektów 401
Sieć CDN 402
Kompresja GZIP 402
Hosting 402
Hosting przygotowany z myślą o WordPressie 403
Utworzenie własnego serwera 403
Buforowanie selektywne 416
API Transient 416
Elementy tymczasowe dla wielu witryn internetowych 419 Używanie JavaScriptu do poprawy wydajności działania 420
Tabele niestandardowe 421
Pominięcie WordPressa 423
15. E-commerce ...425
Wybór wtyczki 425
WooCommerce 426
Paid Memberships Pro 428
Easy Digital Downloads 429
Bramki płatności 432
Konto sprzedawcy 432
Konfigurowanie modelu Saas przy użyciu wtyczki Paid Memberships Pro 434
Model SaaS 434
Etap 0. — ustalenie sposobu pobierania opłaty za korzystanie z aplikacji 434 Etap 1. — instalowanie i aktywowanie wtyczki Paid Memberships Pro 435
Etap 2. — ustalenie poziomu członkostwa 435
Etap 3. — konfiguracja stron 437
Etap 4. — wybór ustawień płatności 437
Etap 5. — wybór ustawień wiadomości e-mail 439
Etap 6. — wybór ustawień zaawansowanych 440
Etap 7. — uniemożliwianie dostępu do stron 441
Etap 8. — dostosowanie wtyczki Paid Memberships Pro do własnych potrzeb 443
16. Aplikacje mobilne na bazie WordPressa ... 449
Przypadki użycia aplikacji mobilnych 449
Natywne i hybrydowe aplikacje mobilne 450
Co to jest natywna aplikacja mobilna 450
Co to jest hybrydowa aplikacja mobilna 451
Dlaczego lepiej wybrać aplikację hybrydową zamiast natywnej 451 Cordova 452
Framework Ionic 457
Opakowanie aplikacji 458
AppPresser 459
17. Biblioteki PHP, integracje usług sieciowych, migracje platform ... 475
Biblioteki PHP 475
Generowanie i przetwarzanie obrazów 476
Generowanie dokumentu PDF 478
Geolokalizacja i geotargetowanie 483
Kompresja i archiwizowanie plików 485
Narzędzia programistyczne 489
Zewnętrzne API i usługi sieciowe 491
Elasticsearch 491
ElasticPress firmy 10up 491
Google Vision 492
Mapy Google 492
Tłumacz Google 493
Twilio 493
Inne popularne interfejsy API 494
Migracje 495
Migracja hosta 496
Migracja platformy 497
Utworzenie przewodnika mapowania danych 499
18. Przyszłość ... 501
Jak to było wcześniej 501
API REST 502
Wtyczki WordPressa będą bardziej skoncentrowane na API 502
Headless WordPress 502
GraphQL 503
Projekt Gutenberg 504 Interfejs administracyjny zostanie przeniesiony do rozwiązania
opartego na React i Gutenberg 504
Gutenberg zapewni obsługę edycji we frontendzie WordPressa 504
Szablon bloku zastąpi motyw 504
Bloki zastąpią wtyczki 505
Udział WordPressa w rynku będzie się zmieniał 505
WordPress stanie się znacznie popularniejszą platformą
do tworzenia aplikacji mobilnych 506
WordPress wciąż będzie użyteczny
podczas tworzenia różnych aplikacji internetowych 506
ROZDZIAŁ 1.
Tworzenie aplikacji internetowych w WordPressie
Ta książka pomoże Ci utworzyć w WordPressie witrynę internetową, motyw, wtyczkę, usługę sie- ciową i aplikację internetową. Zdecydowaliśmy się skoncentrować na aplikacjach internetowych, ponieważ można je postrzegać jako superwitryny internetowe pozwalające wykorzystywać wszystkie techniki przedstawione w tej książce.
Wiele osób jest przekonanych, że WordPress nie ma wystarczających możliwości do tworzenia aplikacji internetowych lub nie został opracowany w tym celu. Do tego tematu jeszcze powrócimy w dalszej części rozdziału. Od wielu lat tworzymy aplikacje internetowe WordPressa i wiemy, że doskonale nadaje się on do budowania skalowalnych aplikacji.
W tym rozdziale zaczniemy od zdefiniowania aplikacji internetowej, a następnie wyjaśnimy, dla- czego WordPress to doskonały framework przeznaczony do jej tworzenia. Zaprezentujemy rów- nież kilka wybranych sytuacji, w których użycie WordPressa nie będzie najlepszym rozwiązaniem podczas tworzenia aplikacji internetowej.
Czym jest witryna internetowa?
Doskonale wiesz, czym jest witryna internetowa: to jedna lub więcej stron internetowych zawie- rających informacje i dostępnych za pomocą przeglądarki WWW.
Czym jest aplikacja?
Lubimy definicję zamieszczoną w Wikipedii (en.wikipedia.org/wiki/Application_software): „apli- kacja to oprogramowanie zaprojektowane do wykonywania grupy powiązanych ze sobą funkcji, zadań lub czynności, które oferują pewną korzyść użytkownikowi”.
Czym jest aplikacja internetowa?
Aplikacja internetowa to po prostu aplikacja uruchomiona w przeglądarce WWW.
Zwróć uwagę na to, że w przypadku niektórych aplikacji internetowych technologia przeglądarki WWW pozostaje ukryta — np. podczas integracji aplikacji internetowej z natywną aplikacją sys- temu iOS lub Android, podczas uruchamiania witryny internetowej jako aplikacji w Google Chrome, a także podczas uruchamiania aplikacji w środowisku Adobe AIR. Jednak wewnątrz tych aplikacji nadal znajduje się system przetwarzający dane w HTML, CSS i JavaScripcie.
Aplikację internetową można traktować także jako witrynę internetową wraz z dodatkami przy- pominającymi aplikację. Nie istnieje wyraźna granica, po której przekroczeniu witryna interneto- wa staje się aplikacją internetową. To jest przykład jednej z tych sytuacji, w których zobaczywszy witrynę internetową, od razu będziesz wiedzieć, że masz do czynienia z aplikacją internetową.
Natomiast można wyjaśnić pewne funkcje aplikacji internetowej, przedstawić przykłady i spró- bować zaprezentować skróconą definicję, aby Czytelnik ogólnie wiedział, co mamy na myśli, gdy w tekście książki stosujemy wyrażenie „aplikacja internetowa”.
Podczas lektury książki będziesz napotykać odwołania do SchoolPressa. Jest to aplika- cja internetowa, którą budujemy, aby pomóc szkołom i nauczycielom w zarządza- niu uczniami i programem nauczania. Wszystkie przykładowe fragmenty kodu zo- stały przygotowane z myślą o funkcjonalności, która może istnieć w SchoolPressie.
Więcej informacji na temat ogólnych koncepcji stojących za aplikacją SchoolPress znajdziesz w dalszej części rozdziału.
Funkcje aplikacji internetowej
W tej sekcji wymieniamy typowe funkcje powiązane z aplikacjami internetowymi i ogólnie z apli- kacjami. Im więcej tych funkcji znajdziesz w witrynie internetowej, tym bardziej odpowiednie jest nazywanie jej aplikacją internetową1.
Elementy interaktywne
Typowa witryna internetowa oznacza poruszanie się między tworzącymi ją stronami, wczy- tywanie tych stron, przewijanie treści i klikanie łączy. Aplikacja internetowa również może mieć łącza i wymagać przewijania, ale zwykle wykorzystuje inne metody umożliwiające poru- szanie się po aplikacji.
Witryny internetowe wraz z formularzami oferują możliwość obsługi transakcji. Przykładem może być formularz kontaktowy w witrynie internetowej lub formularz aplikacji na stronie zawierającej oferty pracy w danej firmie. Formularze pozwalają użytkownikom pracować z witryną za pomocą czegoś więcej niż tylko kliknięć.
Aplikacje internetowe oferują jeszcze bardziej interaktywne elementy interfejsu użytkownika.
Do przykładów zaliczamy paski narzędzi, elementy typu „przeciągnij i upuść”, edytory boga- tego tekstu i paski przewijania.
1Wiele idei przedstawionych w tej sekcji zostało zainspirowanych następującymi postami z blogów: „What is a Web Application?” napisany przez Dominique Hazae’l-Massieux i opublikowany na stronie http://people.w3.org/~dom/
archives/2010/08/what-is-a-web-application/ oraz „What is a Web Application?” napisany przez Boba Baxleya i opublikowany na stronie http://boxesandarrows.com/what-is-a-web-application/.
Zadania zamiast treści
Pamiętaj, że aplikacje internetowe są „zaprojektowane, aby pomóc użytkownikowi w wyko- nywaniu określonych zadań”. Mapy Google dostarczają użytkownikom wskazówki ułatwiające dotarcie pod wskazany adres. Użytkownicy usługi Gmail tworzą wiadomości e-mail. Użyt- kownicy serwisu Trello zarządzają listami. Użytkownicy serwisu SchoolPress komentują zdarze- nia zachodzące w klasie.
Część aplikacji nadal koncentruje się na treści. Typowa sesja w aplikacji Facebook lub Twitter obejmuje 90% czasu czytania. Jednak same aplikacje zapewniają możliwość przeglądania treści w inny sposób niż w przypadku tradycyjnej witryny internetowej.
Loginy
Loginy i konta pozwalają aplikacji internetowej zapisywać informacje o użytkownikach. Te in- formacje są później używane podczas wykonywania głównych zadań aplikacji i dla zapew- nienia trwałego przechowywania danych. Po zalogowaniu się użytkownik serwisu School- Press widzi, których tematów nie przeczytał. Otrzymuje również nazwę użytkownika określającą jego aktywność w aplikacji.
Aplikacja internetowa może też mieć grupy użytkowników. W przypadku aplikacji School- Press istnieją administratorzy nadzorujący wewnętrzny sposób działania aplikacji, nauczy- ciele tworzący klasy oraz uczniowie biorący udział w dyskusjach prowadzonych w klasach.
Wykorzystanie możliwości urządzeń
Aplikacja internetowa uruchomiona w smartfonie może uzyskać dostęp do aparatu fotogra- ficznego, książki adresowej, wewnętrznego magazynu danych, dostarczanych przez GPS in- formacji o położeniu itd. Z kolei aplikacja internetowa uruchomiona w tradycyjnym kom- puterze może mieć dostęp do kamery internetowej i dysku twardego. Ta sama aplikacja internetowa może reagować odmiennie w zależności od urządzenia, w którym została uru- chomiona. Aplikacja internetowa dostosuje się do wielkości ekranu, rozdzielczości i możli- wości urządzenia.
Praca w trybie offline
Gdy jest to możliwe, dobrym rozwiązaniem jest zapewnienie aplikacji możliwości działania w trybie offline. Oczywiście interaktywność internetu jest tym, co definiuje „internetową” część aplikacji. Jednak witryna internetowa, działająca, gdy jedziesz samochodem w tunelu, będzie przypominała bardziej aplikację.
W przypadku serwisu Gmail wiadomość e-mail można tworzyć w trybie offline. Evernote po- zwala na tworzenie notatek w trybie offline, a następnie ich synchronizację z internetem po przywróceniu połączenia.
Mashupy
Istnieje możliwość połączenia jednej lub więcej aplikacji internetowych. Aplikacja interneto- wa może wykorzystywać różne usługi sieciowe i API w celu przekazywania i pobierania danych.
Możesz mieć aplikację internetową pobierającą dane o położeniu, np. długość i szerokość geograficzną, z serwisu Twitter lub Foursquare i przekazującą je do serwisu Mapy Google.
Aplikacje mobilne
Wydanie pierwsze tej książki zostało opublikowane w 2012 roku — od tamtej chwili jesteśmy świadkami gwałtownego rozwoju aplikacji internetowych, w szczególności aplikacji mobilnych.
W większości witryn internetowych urządzenia mobilne wyprzedziły tradycyjne komputery i generują najwięcej ruchu sieciowego (źródło: Perficient Inc., https://www.perficientdigital.com/insights/
our-research/mobile-vs-desktop-usage-study).
W 2012 roku typowa aplikacja internetowa wyglądała jak Basecamp, oprogramowanie menedżera projektu dostępne w komputerze za pomocą przeglądarki WWW. Natomiast w 2019 roku typowa aplikacja internetowa wygląda jak Twitter, aplikacja komunikacyjna dostępna za pomocą smart- fona działającego pod kontrolą systemu iOS lub Android.
Ponieważ w większości przypadków duża część użytkowników uzyskuje dostęp do witryny inter- netowej i aplikacji za pomocą urządzeń mobilnych, podczas projektowania i tworzenia aplikacji internetowych stosowane jest podejście „najpierw wersja mobilna”. Temat natywnego urucha- miania aplikacji WordPressa zostanie omówiony w rozdziale 16. Natomiast podstawy projektu re- sponsywnego i przygotowanie witryny internetowej do prawidłowego wyświetlania na ekranie o każdej wielkości dokładniej omówimy w rozdziale 4.
Progresywne aplikacje internetowe
Progresywne aplikacje internetowe (ang. progressive web apps, PWA) to witryny internetowe, które wy- korzystują zalety funkcji nowoczesnych przeglądarek WWW umożliwiające działanie tych witryn jak natywnych aplikacji w systemach iOS, Android oraz w tradycyjnych komputerach. W szczegól- ności witryny internetowe używające tzw. usług roboczych do funkcjonowania w trybie offline mają plik manifestu aplikacji internetowej, który pozwala zdefiniować aplikację w systemie opera- cyjnym oraz spełnić kilka innych wymagań, aby możliwe było uruchamianie takiej aplikacji bez- pośrednio z przeglądarki WWW.
Orędownikiem progresywnych aplikacji internetowych był zespół Google Chrome, a teraz te aplikacje są obsługiwane także w systemie iOS oraz w większości nowoczesnych przeglądarek WWW. Do- stępna jest wtyczka (https://wordpress.org/plugins/pwa/) oferująca obsługę podstawowych funkcji PWA w WordPressie. Dzięki tej wtyczce można witrynę internetową WordPressa zmienić w aplikację PWA. Wprawdzie to jest dobry pomysł, ale w rzeczywistości tworzenie kodu PWA jest bardziej związane z nastawieniem niż z faktyczną konwersją. Podobnie jak w przypadku przedstawionych wcześniej „funkcji aplikacji internetowej” strona główna PWA w serwisie Google (https://web.dev/
progressive-web-apps/) zawiera listę m.in. następujących funkcji oczekiwanych od większości aplikacji typu PWA (https://web.dev/pwa-checklist/):
witryna korzysta z protokołu HTTPS;
strony są responsywne w tabletach i innych urządzeniach mobilnych;
wszystkie adresy URL aplikacji działają po jej przejściu do trybu offline;
dostarczone są metadane pozwalające dodać witrynę do ekranu głównego urządzenia;
pierwsze wczytanie witryny jest szybkie nawet w przypadku połączenia 3G;
witryna działa w każdej przeglądarce WWW;
przejścia między stronami nie blokują sieci;
każda strona ma adres URL.
Poza wymienionymi tutaj podstawowymi funkcjami istnieje także lista rzeczy do sprawdzenia dla
„wzorowych” aplikacji typu PWA obejmujących UX i wydajność działania. Narzędzie Lighthouse firmy Google (https://developers.google.com/web/tools/lighthouse/) oferuje testy zautomatyzowane i raporty dotyczące spełniania kryteriów PWA. Nawet aplikacje w pełni natywne lub utworzone dla przeglądarki WWW mogą czerpać korzyści z pewnych sugestii zamieszczonych na liście rze- czy do sprawdzenia PWA oraz w raportach Lighthouse.
Dlaczego WordPress?
Żaden język programowania lub narzędzie nie będzie odpowiednim wyborem do wykonania każdego zadania. Wkrótce się dowiesz, dlaczego nie należy wybierać WordPressa, teraz natomiast chcemy się skoncentrować na sytuacjach, w których wykorzystanie WordPressa do utworzenia aplikacji internetowej jest dobrym rozwiązaniem.
Jesteś już użytkownikiem WordPressa
Jeżeli już używasz WordPressa do udostępnienia głównej witryny internetowej, dodanie niezbędnej funkcjonalności będzie wymagało niewiele pracy. WordPress oferuje ogromny wybór wtyczek dla e-commerce (WooCommerce), forów (bbPress), witryn obsługi użytkowników (Paid Member- ships Pro), funkcjonalności związanej z serwisami społecznościowymi (BuddyPress) i gamifikacją (BadgeOS).
Budowa aplikacji internetowej na podstawie istniejącej witryny internetowej WordPressa pozwoli na dużą oszczędność czasu i ułatwi pracę jej użytkownikom. Dlatego jeśli aplikacja jest dość pro- sta, można utworzyć dla witryny WordPressa własną wtyczkę zawierającą funkcjonalność nie- zbędną dla aplikacji internetowej.
Jeżeli jesteś zadowolony z użycia WordPressa w istniejącej witrynie, nie martw się, słysząc, że mu- sisz uaktualnić coś jeszcze, aby dodać określoną funkcjonalność do witryny. Prawdopodobnie to nieprawda. Nie musisz pozbywać się wykonanej dotąd pracy w WordPressie, a wcześniej zdobyte doświadczenie to doskonały powód, by pozostać przy wyborze tej właśnie platformy.
Zarządzanie treścią w WordPressie jest łatwe
Na początku WordPress opracowano jako platformę przeznaczoną do publikacji blogów. Na przestrzeni lat ewoluował i wraz z wprowadzeniem niestandardowych typów postów (ang. custom post types, CPT) w wydaniu 3.0 WordPress zyskał w pełni funkcjonalny system zarządzania treścią (ang. content management system, CMS). Każda strona lub post mogą być edytowane przez admini- stratorów za pomocą panelu głównego (ang. dashboard), do którego dostęp odbywa się za pomo- cą przeglądarki WWW. Więcej informacji na temat pracy z CPT znajdziesz w rozdziale 5.
WordPress ułatwia dodawanie i edytowanie treści dzięki edytorowi działającemu w trybie WY- SIWYG (ang. what you see is what you get), więc nie musisz się zwracać do projektanta interne- towego za każdym razem, gdy chcesz wprowadzić prostą zmianę w witrynie internetowej. Po- nadto możesz tworzyć własne menu i elementy nawigacyjne dla witryny nawet bez tworzenia jakiegokolwiek kodu.
Jeżeli aplikacja internetowa koncentruje się na treści (np. podstawowe funkcje aplikacji School- Press to zlecanie zadań i dyskusje), to omówione w rozdziale 5. API CPT dla WordPressa pozwala na łatwe i szybkie przygotowanie treści dla użytkowników i zarządzanie nią.
Nawet w przypadku aplikacji bardziej ukierunkowanych na zadania zwykle istnieje kilka stron zawie- rających informacje, dokumentację i inne dane, np. związane ze sprzedażą. Użycie WordPressa do utworzenia aplikacji internetowej oznacza, że aplikacją i jej całą treścią możesz zarządzać w jednym miejscu.
Łatwe i bezpieczne zarządzanie użytkownikami w WordPressie
WordPress zawiera wszystko to, co jest potrzebne w celu dodawania użytkowników administra- cyjnych i końcowych do witryny internetowej.
Poza kontrolą dostępu do treści system ról i możliwości w WordPressie jest rozszerzalny oraz po- zwala kontrolować, które akcje są dostępne dla poszczególnych grup użytkowników. Na przykład domyślnie użytkownik w roli o nazwie contributor może dodawać nowe posty, ale nie może ich publikować. Podobnie można tworzyć nowe role i definiować nowe możliwości, aby w ten sposób zarządzać dostępem do własnego systemu funkcjonalności.
Wtyczki takie jak Paid Membership Pro rozszerzają wbudowane możliwości zarządzania użyt- kownikami i pozwalają na desygnowanie członków na różnych poziomach i kontrolowanie treści, do której użytkownicy mają dostęp. Przykładowo można utworzyć poziom zapewniający dostęp do treści dodatkowej witryny WordPressa tym użytkownikom, którzy wykupili taką możliwość.
Wtyczki
W repozytorium WordPressa istnieje ponad 55 000 bezpłatnie dostępnych wtyczek (https://wordpress.
org/plugins/). Znacznie większa liczba wtyczek, zarówno płatnych, jak i bezpłatnych, jest dostępna w innych witrynach internetowych. Gdy wpadniesz na pomysł, by utworzyć rozszerzenie dla wi- tryny internetowej, istnieje duże prawdopodobieństwo, że taka wtyczka została już wcześniej opracowana, co pozwala zaoszczędzić czas i pieniądze.
W repozytorium znajdziesz wiele niezastąpionych wtyczek, które ostatecznie znajdą zastosowanie w każdej tworzonej przez Ciebie witrynie internetowej i aplikacji internetowej.
W praktycznie każdej tworzonej witrynie internetowej będziesz chciał m.in. zastosować buforo- wanie danych wyjściowych (co pozwala przyspieszyć operacje przeglądania stron), wykorzystać narzędzia takie jak Google Analytics do śledzenia odwiedzających, utworzyć mapę witryny, dosto- sować ustawienia strony w taki sposób, aby stała się przyjazna technikom optymalizacji dla wyszuki- warek internetowych (ang. search engine optimization, SEO).
Istnieje wiele doskonałych wtyczek przeznaczonych do wykonywania wymienionych funkcji.
W książce przedstawimy nasze ulubione, a pełną ich listę znajdziesz w witrynie poświęconej książce (https://web.archive.org/web/20191103020221/https://bwawwp.com/plugins/).
Elastyczność ma duże znaczenie
WordPress to w pełni wyposażony framework oferujący naprawdę potężne możliwości. Został zbudowany w oparciu o technologie PHP, JavaScript i MySQL, więc to, co można utworzyć za pomocą PHP i MySQL (czyli praktycznie wszystko), można także dość łatwo zrobić w aplikacji WordPressa.
Ogólnie rzecz biorąc, WordPress oraz PHP i MySQL to nie jest doskonałe rozwiązanie dla każde- go zadania, choć to połączenie sprawdza się w wielu różnych przypadkach. Wykorzystanie jednej platformy rozwijającej się wraz z firmą pozwala na szybsze działanie i dostosowywanie się do zmian.
Oto typowy proces rozwoju i rozbudowy witryny w przypadku witryny internetowej startupu zbudowanej w WordPressie:
1. Zaprezentowanie startupu za pomocą witryny internetowej składającej się z jednej strony.
2. Dodanie formularza umożliwiającego gromadzenie adresów e-mail.
3. Dodanie bloga.
4. Skoncentrowanie się na technikach SEO i optymalizacji całej treści.
5. Przekazywanie postów bloga do serwisów Twitter i Facebook.
6. Dodanie forum.
7. Użycie wtyczki Paid Membership Pro, aby umożliwić użytkownikom wnoszenie opłat za dostęp do treści witryny internetowej.
8. Dodanie niestandardowych formularzy, narzędzi i funkcjonalności aplikacji dla użytkowni- ków płacących za dostęp do treści.
9. Uaktualnienie interfejsu użytkownika za pomocą frameworków i technik JavaScriptu.
10. Dostosowanie witryny internetowej i serwera do skalowania.
11. Lokalizacja witryny internetowej i aplikacji dla różnych krajów i języków.
12. Dodanie obsługi progresywnej aplikacji internetowej.
13. Przygotowanie opakowań iOS i Android dla aplikacji internetowej.
Pozytywnym aspektem przejścia przez ten proces jest to, że na każdym etapie masz do dyspozycji tę samą bazę danych użytkowników i korzystasz z tej samej platformy programistycznej.
Częste uaktualnienia zabezpieczeń
Fakt wykorzystywania WordPressa przez witryny internetowe powoduje, że stanowi on cel dla hakerów próbujących złamać jego zabezpieczenia. W przeszłości części hakerów to się udało, na szczęście programiści tworzący WordPressa dość szybko reagują na znalezione luki w zabezpie- czeniach i wydają usuwające je poprawki. Można to porównać do sytuacji, w której miliony osób nieustannie testują i poprawiają oprogramowanie, ponieważ dokładnie z tym mamy do czynienia.
Architektura stojąca za WordPressem powoduje, że stosowanie uaktualnień to proces szybki i bezproblemowy, nawet dla użytkowników dopiero rozpoczynających pracę z tą platformą. Jeżeli potrafisz zainstalować i uaktualnić WordPress do najnowszej dostępnej wersji, wówczas dla wi- tryny internetowej masz do dyspozycji znacznie bezpieczniejszą platformę niż jakakolwiek inna aktualnie dostępna. Tematem zapewnienia bezpieczeństwa zajmiemy się w rozdziale 8.
Koszt
WordPress jest bezpłatny, PHP jest bezpłatny, MySQL jest bezpłatny i większość wtyczek Word- Pressa jest bezpłatnych.
Wprawdzie serwery i hosting wymagają opłat, ale w zależności od wielkości aplikacji internetowej i natężenia generowanego przez nią ruchu sieciowego ten koszt może być względnie niewielki. Jeżeli wymagasz funkcjonalności niedostępnej w żadnej istniejącej wtyczce, wtedy będzie trzeba zatrudnić programistę i zlecić mu utworzenie odpowiedniej wtyczki. Jeżeli sam jesteś programistą, nie mu- sisz ponosić tego kosztu i wystarczy, że poświęcisz trochę czasu na opracowanie wtyczki.
Odpowiedź na często pojawiającą się krytykę wybranych aspektów WordPressa
Dość często można spotkać się z opinią, że WordPress nie jest dobrym frameworkiem do tworze- nia aplikacji internetowych lub nawet że w ogóle nie jest frameworkiem. Szanując prawo innych do wypowiedzi, w tym miejscu chcielibyśmy wyjaśnić, dlaczego nie zgadzamy się z takimi opiniami.
W kolejnych punktach odniesiemy się do często pojawiającej się krytyki.
WordPress jest przeznaczony tylko do tworzenia blogów
Spora grupa osób jest przekonana, że jeśli WordPress powstał w celu tworzenia blogów, to sprawdza się dobrze tylko w tym zakresie.
Takie stwierdzenia mogły być prawdziwe kilka lat temu. Jednak ostatnio w WordPressie zaim- plementowano oferującą dość potężne możliwości funkcjonalność CMS, więc platforma stała się użyteczna także dla innych witryn internetowych skoncentrowanych na treści. Obecnie Word- Press to najpopularniejszy system zarządzania treścią, a jego udział w rynku szacuje się na 60%2. Na rysunku 1.1 możesz zobaczyć slajd z prezentacji „State of WordPress”, przygotowanej przez Matta Mullenwega na konferencję WordCamp San Francisco 2013. Widoczny po lewej stronie trójkąt skierowany do dołu przedstawia WordPress z mniej więcej 2006 roku, gdy większość kodu tworzącego ten framework była przeznaczona do obsługi aplikacji bloga, a tylko niewielka część dla systemu CMS i kodu platformy. Z kolei widoczny po prawej stronie trójkąt przedstawia aktu- alny stan platformy WordPress, w której większość kodu jest związana z samą platformą wraz ze znajdującą się nad nią warstwą CMS, aplikacja bloga zaś działa na warstwie CMS. Obecnie WordPress to znacznie stabilniejsza platforma niż kilka lat temu.
2Na stronie W3Tech pod adresem https://w3techs.com/technologies/overview/content_management dostępne są aktualne dane dotyczące użycia różnych systemów zarządzania treścią.
Rysunek 1.1. Wykresy przygotowane przez Matta Mullenwega w 2013 roku na potrzeby prezentacji
„State of WordPress”. WordPress nie zawsze był stabilny
API CPT można wykorzystać do usprawnienia instalacji WordPressa i zapewnienia obsługi ty- pów treści innych niż posty bloga lub strony internetowe. Więcej informacji na ten temat znaj- dziesz w rozdziale 5.
WordPress jest przeznaczony tylko dla stron z treściami
Podobnie jak w przypadku stwierdzenia „tylko dla bloga”, część osób twierdzi, że WordPress jest przeznaczony tylko dla witryn internetowych skoncentrowanych na treści.
Po pierwsze, jeżeli WordPress byłby przeznaczony tylko dla skoncentrowanych na treści witryn internetowych i aplikacji, to i tak oznacza ogromną liczbę aplikacji. Na ekranie głównym smart- fona prawdopodobnie masz wiele aplikacji koncentrujących się na treści, np. Netflix, Twitter, Face- book, Reddit, Evernote. To są przykłady bardzo popularnych aplikacji opracowanych przez ogromne firmy. Oczywiście nie sugerujemy, że powinny one działać w oparciu o WordPress, na- tomiast sugerujemy, że aplikacje o podobnym sposobie działania można zbudować, wykorzystując do tego framework WordPress.
Po drugie, jak się dowiesz z lektury niniejszej książki, WordPress to doskonały framework prze- znaczony także do tworzenia bardziej interaktywnych aplikacji internetowych. Podstawową funk- cją pozwalającą na wykorzystanie WordPressa jako frameworka jest API wtyczek, które umożli- wia sprawdzenie domyślnego sposobu działania WordPressa i jego zmianę. Nie tylko masz dostęp do tysięcy wtyczek znajdujących się w repozytorium WordPressa i na różnych stronach w inter- necie, ale również za pomocą API wtyczek możesz przygotować własne wtyczki przeznaczone do wykonywania wszelkich zadań, które są możliwe do zrealizowania z użyciem PHP i MySQL.
WordPress się nie skaluje
Niektórzy będą wskazywać na domyślną instalację WordPressa uruchomioną w usłudze hostingu o małych możliwościach i zwracać uwagę na spowolnienie działania witryny internetowej lub jej awarie w przypadku dużego obciążenia i na tej podstawie wyciągać wniosek, że WordPress się nie skaluje.
Być może uśmiałbyś się, gdybyś usłyszał o możliwości zbudowania witryny typu Facebook za pomocą WordPressa.
W rzeczywistości wiele witryn internetowych notujących ogromny ruch sieciowy zbudowano w oparciu o WordPress. Witryna wordpress.com została zbudowana w dokładnie taki sam sposób jak każda inna korzystająca z WordPressa i jest jedną z najczęściej odwiedzanych witryn interne- towych na świecie.
Jeżeli masz zamiar utworzyć aplikację internetową na miarę Facebooka, nie jest to odpowiednia książka dla Ciebie. Zapytaj CTO, jaki odsetek wielomiliardowego bu- dżetu jest przeznaczony na potrzeby związane z utworzeniem aplikacji i zatrudnie- niem inżynierów z firm Google i Amazon, którzy będą potrzebni do pracy nad tą niestandardową aplikacją internetową.
Wraz ze wzrostem poziomu użycia aplikacji internetowej konieczne będzie uaktualnianie i wy- mienianie poszczególnych komponentów, aby sprostać tej skali. Problemy związane ze skalowa- niem WordPressa są dokładnie takie same jak podczas skalowania każdej innej aplikacji: buforo- wanie stron i danych, znacznie szybsza obsługa zapytań do bazy danych i poprawienie wydajności działania sieci. Ogromne witryny takie jak wordpress.com, TechCrunch i blogi New York Timesa są skalowane w WordPressie. Podobnie większość wniosków wyciągniętych ogólnie ze skalowa- nia aplikacji PHP i MySQL ma zastosowanie dla WordPressa. Tematem skalowania zajmiemy się w rozdziale 14.
WordPress nie zapewnia bezpieczeństwa
Podobnie jak w przypadku innych produktów typu open source także WordPress wiąże się z pewny- mi kompromisami w zakresie zapewnienia bezpieczeństwa.
Z jednej strony ogromna popularność WordPressa oznacza, że będzie on celem hakerów szukają- cych luk w zabezpieczeniach. Skoro kod źródłowy został udostępniony jako open source, poten- cjalne luki w zabezpieczeniach są łatwiejsze do znalezienia.
Z drugiej strony, ponieważ kod źródłowy WordPressa jest właśnie typu open source, dość szybko dowiesz się o znalezionych lukach w zabezpieczeniach, a ktoś inny prawdopodobnie usunie je za Ciebie.
Czujemy się znacznie bezpieczniej, wiedząc, że choć wiele osób próbuje wykorzystać luki w za- bezpieczeniach, inne starają się zabezpieczyć WordPressa przed wykorzystaniem tych braków.
Nie wierzymy w „zapewnienie bezpieczeństwa przez niejawność”, chyba że jest ona stosowana ja- ko dodatkowy środek. Zamiast tego wolimy, aby znalezione luki w zabezpieczeniach oprogramo- wania wychodziły na światło dzienne, niż pozostały nieujawnione aż do najgorszego z możliwych momentów.
W rozdziale 8. znacznie dokładniej zajmiemy się omówieniem kwestii zapewnienia bezpieczeń- stwa — m.in. przedstawimy listę najlepszych praktyk w zakresie zabezpieczania instalacji Word- Pressa, a także podpowiemy, jak tworzyć bezpieczniejszy kod.
Wtyczki WordPressa są beznadziejne
API wtyczek w WordPressie oraz tysiące dostępnych wtyczek opracowanych z wykorzystaniem tego API to tajna broń i według nas podstawowy powód, dla którego WordPress zyskał tak ogromną popularność i odniósł duży sukces jako platforma dla witryn internetowych.
Można się spotkać ze stwierdzeniem typu „oczywiście, że są dostępne tysiące wtyczek, ale więk- szość z nich jest kiepska”. W porządku, część wtyczek na pewno jest kiepska.
Jednak istnieje naprawdę wiele wtyczek, które zdecydowanie są użyteczne — wśród nich znajduje się AppPresser opracowana przez jednego z autorów tej książki, Briana Messenlehnera. Jeżeli używasz WordPressa do zarządzania treścią pisaną lub sklepem internetowym, wówczas wtyczka AppPresser i platforma to najszybszy sposób na otrzymanie tej treści lub sklepu internetowego w aplikacji mobilnej.
Paid Memberships Pro opracowana przez drugiego autora książki, Jasona Colemana, również za- licza się do użytecznych wtyczek. Pozwala ona obsługiwać rachunki wystawiane użytkownikom witryny internetowej, dzięki czemu można się skoncentrować na podstawowej funkcjonalności aplikacji zamiast zmagać się z integracją witryny z bramkami płatności.
Wiele wtyczek wykonuje bardzo proste zadania (np. ukrycie paska administracyjnego dla użyt- kowników niebędących administratorami), działa zgodnie z oczekiwaniem i naprawdę trudno je uznać za kiepskie.
Motywy i wtyczki znajdujące się w repozytorium WordPressa są przez wolontariuszy sprawdzane pod kątem zapewnienia bezpieczeństwa i jakości kodu. Proces Theme Review Team (https://make.
wordpress.org/themes/handbook/review/required/) jest coraz bardziej rygorystyczny i rozbudowa- ny niż pozostałe. Projekt Tide (https://make.wordpress.org/tide/) ma na celu opracowanie testów zautomatyzowanych do sprawdzania repozytoriów wtyczek i motywów, co powinno zapewnić dostęp do wysokiej jakości wtyczek i uaktualnień, a jednocześnie pozwolić na szybsze wykrywanie problemów związanych z zachowaniem zgodności i zapewnieniem bezpieczeństwa.
Nawet słaba wtyczka może zostać poprawiona, utworzona na nowo lub stanowić punkt wyjścia do opracowania kolejnej, która będzie działała lepiej. Czasami okazuje się, że utworzenie wtyczki od nowa jest łatwiejsze niż poprawienie kiepskiej. Mimo to i tak jesteś w znacznie lepszej sytuacji, niż gdybyś musiał zupełnie od początku tworzyć wszystko to, co jest potrzebne do działania bu- dowanej aplikacji internetowej.
Nikt nie zmusza Cię do stosowania wtyczek WordPressa bez ich wcześniejszego sprawdzenia. Jeżeli budujesz poważną aplikację internetową, kod wtyczki powinieneś dokładnie sprawdzić samodzielnie i poprawić go w taki sposób, aby spełniał Twoje standardy, a dopiero potem przejść do następnego zadania.
Kiedy nie używać WordPressa?
WordPress na pewno nie jest rozwiązaniem dla każdej aplikacji. W tym podrozdziale przedsta- wimy kilka sytuacji, w których nie należy używać WordPressa do budowania aplikacji internetowej.
Planujesz licencjonować lub sprzedawać technologię witryny internetowej
WordPress jest dostępny na licencji GPLv2, która nakłada pewne ograniczenia związane ze spo- sobem rozpowszechniania oprogramowania utworzonego za pomocą narzędzi na tej licencji. Przede wszystkim nie można ograniczać sposobów wykorzystania oprogramowania po jego sprzedaży lub dostarczeniu.
Wprawdzie to jest złożony temat, ale podstawowa idea polega na tym, że jeśli tylko sprzedajesz lub zapewniasz dostęp do aplikacji, nie musisz się przejmować GPLv2. Jeżeli jednak sprzedajesz lub rozpowszechniasz kod źródłowy aplikacji, wówczas licencja GPLv2 ma zastosowanie dla roz- powszechnianego kodu.
Przykładowo jeśli na własnym serwerze prowadzisz hosting aplikacji SchoolPress i sprzedajesz konta zapewniające dostęp do aplikacji, nie jest to uznawane za rozpowszechnianie i licencja GPLv2 nie ma tutaj znaczenia.
Jeżeli chcesz umożliwić instytucjom edukacyjnym instalowanie oprogramowania i uruchamianie go na własnych serwerach, wówczas musisz im udostępnić kod źródłowy. To jest uznawane za dystrybucję. Klient będzie mógł legalnie i bezpłatnie przekazać dalej ten kod źródłowy, nawet jeśli musiał zapłacić za oprogramowanie. Konieczne jest użycie licencji GPLv2, która nie zezwala na ograniczenie tego, co użytkownik może zrobić z kodem źródłowym po jego pobraniu.
Inna platforma szybciej doprowadzi Cię do celu
Jeżeli masz zespół doświadczonych programistów języka Ruby, aplikację internetową powinieneś utworzyć właśnie w tym języku. Jeżeli istnieje platforma, framework lub paczka zawierająca 80%
funkcji niezbędnych dla Twojej aplikacji internetowej, a WordPress nie oferuje niczego podobne- go, wówczas prawdopodobnie powinieneś skorzystać z innej platformy.
Elastyczność jest bez znaczenia
Jedną z najważniejszych zalet witryny internetowej opartej na WordPressie jest możliwość szybkiej zmiany jej poszczególnych komponentów, aby lepiej pasowała do Twoich potrzeb. Przykładowo jeśli „polubienia” na Facebooku przestaną być użyteczne, można odinstalować wtyczkę Facebook Connect i zainstalować wtyczkę zapewniającą obsługę serwisu Pinterest.
Ogólnie rzecz biorąc, uaktualnianie motywu lub zastępowanie wtyczek witryny WordPressa bę- dzie odbywało się szybciej niż samodzielne opracowywanie danej funkcjonalności zupełnie od początku na innej platformie. Jeżeli jednak optymalizacja i wydajność działania mają dużo większe znaczenie niż możliwość szybkiego uaktualniania aplikacji, wtedy opracowanie aplikacji natywnej lub programowanie bezpośrednio w PHP będzie lepszym rozwiązaniem.
Jeżeli aplikacja będzie wykonywać jedno proste zadanie, powinna zostać utworzona na niższym poziomie. Przykładowo serwer licencji wtyczki Paid Membership Pro to w zasadzie pojedynczy plik JSON informacji dodatkowych oraz mały skrypt sprawdzający klucze licencji i dostarczający spa- kowane pliki. Jason zbudował serwer licencji bezpośrednio w kodzie PHP i w ogromnym stopniu wy- korzystał buforowanie. Ten serwer działa na kosztującym 10 USD miesięcznie DigitalOcean Sroplet i obsługuje ponad 80 000 witryn internetowych wraz z działającą wtyczką Paid Membership Pro.
Podobnie jeśli masz zasoby dostępne dla Facebooka, możesz pozwolić sobie na samodzielne zbu- dowanie czegokolwiek, wykorzystanie własnych kompilatorów PHP do C, a także natywnych komponentów iOS w celu skrócenia o kilka milisekund czasu wczytywania witryny internetowej i aplikacji.
Aplikacja musi działać w czasie rzeczywistym
Jedną z potencjalnych wad WordPressa, na której temat więcej dowiesz się z dalszej części książki, jest oparcie na typowej architekturze serwera WWW. W typowej konfiguracji WordPressa użyt- kownik przechodzi pod określony adres URL, co powoduje nawiązanie komunikacji z serwerem WWW (takim jak Apache) za pomocą protokołu HTTP, uruchomienie skryptu PHP generujące- go stronę, która następnie zostaje zwrócona użytkownikowi.
Jest wiele sposobów na poprawę wydajności działania tej architektury za pomocą technik bufo- rowania i/lub optymalizacji konfiguracji serwera. Istnieje możliwość asynchronicznego działania WordPressa dzięki wywołaniom w technologii AJAX lub dostępu do bazy danych za pomocą al- ternatywnych klientów. Jeżeli jednak aplikacja musi działać w czasie rzeczywistym i być w pełni asynchroniczna (przykładem może być aplikacja czatu internetowego lub gra wieloosobowa), wówczas masz nasze błogosławieństwo i możesz dobrze się zastanowić, czy na pewno chcesz sko- rzystać z WordPressa.
Wielu programistów WordPressa, w tym także Matt Mullenweg — założyciel i przywódca du- chowy tej platformy, zdaje sobie sprawę ze wspomnianego ograniczenia. Coraz więcej funkcjonalności jest przenoszonych do języka JavaScript pozwalającego na przeprowadzanie obliczeń w przeglą- darce WWW oraz do frameworków takich jak React zapewniających wysoką interaktywność aplikacji internetowej. Nowy edytor Gutenberg, dodany w WordPressie 5.0, jest najlepszym przy- kładem tego trendu i wskazuje kierunek, w którym podąża platforma. Jednak na razie trzeba się zmagać z drogą pod górę, aby zapewnić asynchroniczne działanie WordPressa z wydajnością po- równywalną do aplikacji natywnej, utworzonej całkowicie w Node.js lub za pomocą innych tech- nologii przeznaczonych specjalnie dla aplikacji działających w czasie rzeczywistym.
WordPress jako framework aplikacji
Systemy zarządzania treścią takie jak WordPress, Drupal i Joomla są często wykluczane z dyskusji związanych z frameworkami. Jednak w rzeczywistości WordPress (szczególnie) to doskonały przykład pokazujący, do czego są przeznaczone frameworki: do szybkiego tworzenia aplikacji.
W ciągu zaledwie kilku minut można skonfigurować WordPressa i otrzymać w pełni funkcjonal- ną aplikację wraz z obsługą użytkowników, zarządzaniem sesją, zarządzaniem treścią oraz pane- lem głównym przeznaczonym do monitorowania aktywności witryny internetowej.
Różne API, obiekty i funkcje pomocnicze omówione w książce umożliwiają bardzo szybkie two- rzenie skomplikowanych aplikacji, bez konieczności zajmowania się kwestiami związanymi z in- tegracją tej aplikacji z systemami działającymi na niższym poziomie.
Na rysunku 1.2 pokazaliśmy trójkąt pochodzący z przedstawionej w 2013 roku prezentacji „State of WordPress”. Na podstawie tego rysunku WordPress jawi się jako platforma wraz z umieszczo- ną na niej warstwą CMS, na której z kolei znajduje się aplikacja bloga.
Rzeczywistość jest taka, że większość obecnej bazy kodu obsługuje platformę aplikacji. Każde wydanie WordPressa należy traktować jako framework aplikacji połączony z przykładową aplikacją bloga.
Rysunek 1.2. Platforma WordPress
WordPress kontra frameworki MVC
Model – widok – kontroler (ang. model-view-controller, MVC) to wzorzec projektowy używany w wielu frameworkach przeznaczonych do tworzenia oprogramowania. Najważniejszą korzyścią wynikającą z użycia architektury MVC jest możliwość wielokrotnego użycia kodu i rozdzielenia zadań. WordPress nie stosuje architektury MVC, ale ma własny sposób zachęcający do wielo- krotnego użycia kodu i separacji zadań.
Tutaj pokrótce wyjaśnimy architekturę MVC i sposób jej mapowania na proces programowania w WordPressie. Jeżeli masz doświadczenie w pracy z frameworkami MVC, to informacje przed- stawione w tym punkcie powinny pomóc w zrozumieniu podejścia, które w WordPressie pozwoli programować w sposób podobny jak w przypadku MVC.
Na rysunku 1.3 pokazaliśmy typową aplikację zbudowaną na podstawie wzorca MVC. Użytkow- nik końcowy korzysta z kontrolera przeprowadzającego operacje wpływające na stan aplikacji za pomocą modelu, który następnie uaktualnia widok wyświetlany użytkownikowi. Przykładowo w apli- kacji bloga użytkownik może patrzeć na stronę ostatnio opublikowanych postów (widok). Następnie może kliknąć tytuł posta, co spowoduje przejście pod nowy adres URL (kontroler), co z kolei oznacza wczytanie danych posta (model) i wyświetlenie pojedynczego posta (inny widok).
Rysunek 1.3. Sposób działania architektury MVC
Architektura MVC obsługuje wielokrotne użycie kodu i umożliwia współpracę modelom, widokom i kontrolerom. Przykładowo widok, zarówno ostatnio opublikowanych postów, jak i wyświetlają- cy treść pojedynczego posta, może do wyświetlania danych posta używać tego samego modelu.
Z kolei te same modele można wykorzystać we frontendzie do wyświetlania postów, w backendzie zaś do ich edycji. Architektura MVC obsługuje separację zadań przez umożliwienie projektantom koncentracji na widokach, a programistom — na modelach.
Możesz spróbować użyć architektury MVC w WordPressie. Istnieje wiele projektów, które mają w tym pomóc. Jednak uważamy, że próba stosowania architektury MVC w WordPressie może prowadzić do problemów, o ile oficjalna obsługa MVC nie zostanie wprowadzona w jądrze Word- Pressa. Dopóki tak się nie stanie, sugerujemy zastosowanie podejścia „zgodnego z WordPressem”, które zostało omówione w tej książce.
Jeżeli mimo to wciąż jesteś zainteresowany podejściem MVC w WordPressie, zwróć uwagę na wtyczkę WP MVC (https://wordpress.org/plugins/wp-mvc/), która jest aktywnie rozwijana i po- zwala stosować framework MVC podczas tworzenia wtyczek WordPressa. Jeżeli nie chcesz lub nie potrzebujesz pełnej architektury MVC, istnieje kilka sposobów mapowania procesu MVC na WordPressa.
Modele = wtyczki
We frameworku MVC kod przechowujący struktury danych i logikę biznesową znajduje się w mode- lach. To na tworzenie modeli programiści poświęcają najwięcej czasu.
W WordPressie wtyczka to odpowiednie miejsce na przechowywanie nowych struktur danych, złożonej logiki biznesowej oraz niestandardowych typów postów.
Jednak takie porównanie jest nie najlepsze z kilku powodów. Po pierwsze, wiele wtyczek dodaje funkcjonalność przypominającą widok i zawiera elementy projektowe — rozważ np. wtyczkę do- dającą widżet umieszczany na stronach internetowych. Po drugie, formularze i inne komponenty projektowe używane w panelu głównym WordPressa są, ogólnie rzecz biorąc, obsługiwane przez wtyczki.
Jednym ze sposobów na zapewnienie bardziej wyraźnie zarysowanej separacji zadań podczas do- dawania przypominających widoki komponentów do wtyczek WordPressa jest utworzenie kata- logu templates lub pages i umieszczenie w nim kodu frontendu. Często stosowana praktyka po- zwala szablonom nadpisywać szablony wykorzystane przez wtyczkę. Przykładowo gdy używasz wtyczki Paid Membership Pro, katalog paid-memberships-pro/pages można umieścić w aktyw- nym motywie, aby w ten sposób nadpisać domyślne szablony stron. (Dokładniejsze omówienie tej techniki nadpisywania szablonów wtyczki znajdziesz w rozdziale 4.).
Widoki = motywy
We frameworku MVC kod odpowiedzialny za wyświetlanie danych użytkownikowi zostaje umiesz- czony w widokach. To właśnie na ich tworzenie projektanci i programiści frontendu poświęcają najwięcej czasu.
W WordPressie motywy to odpowiednie miejsce na umieszczenie kodu i logiki szablonów.
Warto przypomnieć ponownie, że przedstawione tutaj porównanie nie jest do końca prawidłowe.
Mimo to stwierdzenie widoki = motywy to dobry punkt wyjścia.
Kontrolery = procedury wczytujące szablony
We frameworku MVC kod odpowiedzialny za przetwarzanie danych wejściowych użytkownika (w postaci adresów URL lub danych $_GET bądź $_POST) oraz ustalający, które z modeli i widoków będą obsługiwały dane żądanie, jest przechowywany w kontrolerach. Kod kontrolera jest, ogólnie rzecz biorąc, obsługiwany przez programistę, a po pierwotnym utworzeniu często pozostaje za- pomniany. Sedno programowania w aplikacji MVC odbywa się w modelach i widokach. Jednak pomimo tego kontrolery to komponenty odgrywające ważne role w sposobie działania aplikacji.
W przypadku aplikacji WordPressa wszystkie żądania stron (o ile nie dotyczą buforowanych plików .html) przechodzą przez plik index.php i są przetwarzane przez WordPressa zgodnie z hierarchią szablonów. Procedura wczytująca szablon ustala, który plik szablonu powinien zostać użyty do wy- świetlenia strony użytkownikowi końcowemu. Przykładowo plik search.php jest używany do po- kazania wyników wyszukiwania, plik single.php do wyświetlenia pojedynczego posta itd.
To zachowanie domyślne można zmodyfikować za pomocą API WP_Rewrite (jego dokładne omówienie znajdziesz w rozdziale 7.) oraz innych zaczepów i filtrów. Informacje dotyczące hie- rarchii szablonów (https://developer.wordpress.org/themes/basics/template-hierarchy/) znajdziesz w książce WordPress Theme Handbook. W niniejszej książce temat hierarchii szablonów będzie dokładniej omówiony w rozdziale 4.
Jeżeli chcesz lepiej zrozumieć sposób działania frameworków MVC, to na stronie frameworka PHP o nazwie Yii (https://www.yiiframework.com/doc/guide/1.1/en/basics.best-practices) znajduje się doskonałe wyjaśnienie, jak najlepiej używać architektury MVC3.
Więcej informacji na temat tworzenia aplikacji internetowych za pomocą frameworka WordPress znajdziesz w dalszej części tej książki.
Anatomia aplikacji internetowej WordPressa
W tym podrozdziale przedstawimy aplikację, która będzie budowana w książce: SchoolPress. Za- prezentujemy funkcjonalność aplikacji SchoolPress, sposób jej działania i użytkowników, dla któ- rych została przeznaczona. Co najważniejsze z pespektywy czytelnika tej książki, dokładnie poka- żemy, jak każdy fragment tej aplikacji został utworzony w WordPressie.
Nie przejmuj się, jeśli nie będziesz rozumieć znaczenia pewnych pojęć w stosowanej tutaj termi- nologii. W dalszych rozdziałach książki powrócimy do omówienia aplikacji SchoolPress i przed- stawimy wszystko znacznie dokładniej. Gdy tylko będzie to możliwe, będziemy starać się wska- zywać rozdział zawierający dokładniejsze omówienie danej funkcjonalności.
Celem tej książki nie jest pokazać krok po kroku, jak utworzyć aplikację School- Press. Gdy ma to sens, fragment aplikacji SchoolPress został użyty w przykłado- wych fragmentach kodu prezentowanych w książce. Dzięki temu nie musisz po- święcać czasu na próbę zrozumienia każdego z przedstawionych przykładów.
3Yii to oparty na architekturze MVC framework PHP. Wprawdzie inne frameworki PHP, takie jak Laravel (https://laravel.com/), są popularniejsze wśród programistów WordPressa i ogólnie społeczności PHP, ale doty- cząca MVC dokumentacja w witrynie Yii została doskonale napisana.
Czym jest SchoolPress?
SchoolPress to aplikacja internetowa ułatwiająca nauczycielom pracę z uczniami poza klasą w szkole.
Nauczyciel może tworzyć klasy i zapraszać do nich uczniów. Każda klasa ma przypisane forum przeznaczone na dyskusje, a bardziej strukturalny system dla nauczycieli umożliwia im publiko- wanie zadań, które muszą być wykonywane przez uczniów.
Działanie aplikacji SchoolPress możesz zobaczyć w witrynie internetowej https://schoolpress.me/.
Kod źródłowy aplikacji znajduje się w archiwum dostępnym pod adresem ftp://ftp.helion.pl/
przyklady/wordp2.zip.
SchoolPress działa w sieci zawierającej wiele witryn WordPressa
SchoolPress to działająca wersja WordPressa składająca się z wielu witryn. Witryna główna za- pewnia obsługę bezpłatnych kont pozwalających nauczycielom zapisać się do systemu i rozpocząć tworzenie klas. Obsługuje również wszystkie informacje marketingowe dla witryn poszczególnych szkół w sieci, łącznie ze stronami przeznaczonymi m.in. do zapisywania się do płatnych usług.
Szkoły mogą tworzyć unikatowe poddomeny przeznaczone dla klas organizowanych przez na- uczycieli z danej szkoły. Takie podejście zapewnia dokładniejszą kontrolę i raportowanie infor- macji dla wszystkich klas w szkole. Szczegóły dotyczące używania sieci zawierającej wiele witryn internetowych WordPressa znajdziesz w rozdziale 12.
Model biznesowy SchoolPressa
Aplikacja SchoolPress używa wtyczek Paid Memberships Pro, PMPro Register Helper i PMPro Network w celu dostosowania do własnych potrzeb procesu rejestracji oraz akceptowania płatno- ści kartami kredytowymi za korzystanie z serwisu.
Szkoła może wykupić dla siebie unikatową poddomenę za roczną opłatą. Inni użytkownicy Scho- olPressa nie muszą płacić za dostęp do serwisu. Gdy administrator szkoły zapisze się do aplikacji, może podać nazwę szkoły i usług dla jej poddomeny, np. <nazwa_szkoły>.schoolpress.me. Dla szkoły zostaje utworzona nowa witryna w sieci, a szkole jest zapewniony dostęp do uproszczonej wersji panelu głównego WordPressa przeznaczonego dla danej witryny internetowej.
Następnie administrator szkoły rozpoczyna zapraszanie uczniów do systemu. Nauczyciele mogą również żądać zaproszenia do szkoły, które musi być zaakceptowane przez administratora danej szkoły. Nauczyciel może zapraszać uczniów do utworzonej przez siebie klasy. Z kolei uczniowie mogą żądać zaproszenia do klasy, które musi być zaakceptowane przez tworzącego ją nauczyciela.
Nauczyciele mogą bezpłatnie zapisywać się do serwisu SchoolPress i organizować w nim klasy.
Strony wyświetlane w poddomenie klasy mogą zawierać reklamy lub stosować inne rozwiązania pozwalające zarabiać pieniądze. Szczegóły związane z konfiguracją e-commerce za pomocą Word- Pressa będą dokładnie omówione w rozdziale 15.
