WordPressowe Linki #7

7 przydatnych usprawnień przy zarządzaniu treściami w WordPressie

Kolekcja 7 wtyczek, które dodają drobne, ale bardzo wygodne usprawnienia przy zarządzaniu wpisami, podstronami etc. w kokpicie.

Query Monitor

Kolejna przydatna dla developerów wtyczka służąca do debugowania kodu.

Funkcjonalność Jetpacka bez Jetpacka

Kolekcja pluginów, będących alternatywą dla Jetpacka. Przydatne głównie dla osób, które nie chcą korzystać z wordpress.com.

Envato zmienia zasady dot. wsparcia dla IE8

Envato ogłosiło, że wsparcie dla IE8 od teraz w produktach oferowanych m.in. na Theme Forest jest opcjonalne – będzie można zaoszczędzić trochę życia przy przygotowywaniu motywów 😉

WP Snippets till Christmas

Podobnie jak w zeszłym roku, możemy się spodziewać kalendarza adwentowego z przydatnymi fragmentami kodu dla WordPressa.

Wprowadzenie do SQL Injection

Krótki artykuł o tym czym jest SQL Injection oraz jak przed nim chronić kod swoich wtyczek.

WordPressowe Linki #6

Ważna zmiana w regułach zatwierdzania motywów na wordpress.org

W wytycznych dotyczących dodawania nowych motywów na repozytorium wordpress.org zaszła istotna zmiana – od teraz przechodzenie przez motyw testu jednostkowego jest zalecane a nie wymagane.

Generator Yeoman dla WordPressa

Przydatna rzecz dla miłośników ułatwiania sobie życia i automatyzacji prac poprzez narzędzie Yeoman.

WordPress Core będzie korzystać z SASS-a

Wygląda na to, że kod CSS dla kokpitu, będzie tworzony z użyciem preprocessora CSS – SASS. Ma to na celu przede wszystkim łatwiejsze wprowadzanie zmian w wyglądzie panelu administracyjnego np. poprzez oferowane przez SASS zmienne.

5 głównych grzechów spotykanych w motywach dla WordPressa

Zestawienie pięciu poważnych błędów spotykanych często w motywach dla WordPressa. Dla osób planujących tworzenie motywów pozycja obowiązkowa. Swoją drogą spokojnie można by ją rozszerzyć o kilka innych istotnych błędów np. brak wsparcia dla Child Themes, brak filtrów i akcji wbudowanych w motyw itd.

WordPress.org vs. WordPress.com

Szczegółowe porównanie różnic pomiędzy WordPressem w wydaniu „*.org” i w wydaniu „.com”

Podsumowanie WordUpów w Łodzi i Krakowie

W ciągu ostatnich dwóch tygodni pojawiłem się na dwóch WordUpach: w Łodzi i Krakowie. Głównym celem tych spotkań było dla mnie lepsze zapoznanie się z lokalnymi społecznościami oraz zebranie feedbacku od użytkowników odnośnie widżetu News Show Pro. Po obu spotkaniach moja lista ToDo wypełniła się nowymi wyzwaniami i pomysłami, co mnie bardzo cieszy, bo dokładnie tego potrzebowałem – w tym miejscu chciałbym skierować szczególne podziękowania za szczere i słuszne uwagi oraz pomysły do: Marcina PietrzakaJakuba Milczarka oraz Wojciecha Bielaka. Niektóre z pomysłów i usprawnień już zaimplementowałem, a pozostałe zostaną zaimplementowane w najbliższej przyszłości.

Swoją drogą w obu wypadkach okazało się, że pojawiło się całkiem sporo osób, które dopiero zaczynają swoją przygodę z WordPressem i jest to ważny sygnał dla organizatorów – WordUpy powinny się zaczynać od prostych (a nawet bardzo prostych) tematów dla początkujących by później przejść do bardziej zaawansowanych zagadnień (bardziej zaawansowani użytkownicy po prostu mogliby przyjść później).

Wielkie podziękowania dla organizatorów obu imprez i do zobaczenia na kolejnych edycjach.

Moją prelekcję z obu WordUpów można obejrzeć tutaj.

Matt Mullenweg na Joomla! World Conference

Na ostatnim Joomla! World Conference swoją prezentację miał współtwórca WordPressa – Matt Mullenweg. Tego typu wydarzenia są moim zdaniem niesamowicie ważne dla społeczności open-source, gdyż mają na celu pokazanie, że najważniejsza jest współpraca i uczenie się od siebie nawzajem.

Bywając na polskich konferencjach poświęconych Joomla i WordPressowi spotkałem dużo osób, których zapatrzenie w jedną z tych platform nosi wręcz znamiona bycia fanatycznym zwolennikiem. Jako developer z doświadczeniem w obu tych platformach mam zawsze jeden przekaz dla takich osób: ograniczanie się do jednego CMSa szkodzi Wam i Waszym klientom.

Wynika to z prostego faktu – jedni zaciągają Joomla! do zbyt prostych projektów, a drudzy biorą WordPressa do zbyt skomplikowanych zadań. W efekcie klient otrzymuje narzędzie (CMS) zastosowane nieadekwatnie do swoich potrzeb.

Dodatkowo taka monotonia w doborze narzędzi szkodzi też developerowi – nie ukrywam, że przynajmniej dla mnie uczenie się czegoś nowego to zawsze podróż w nieznane i dlatego lubię to robić.

Dla wszystkich tych, którzy nie boją się wyjść poza strefę swojego CMS-owego komfortu, polecam serię WordPress vs. Joomla, która ma na celu przybliżenie różnic pomiędzy tymi CMSami. Niebawem pojawią się nowe wpisy z tej serii.

WordPressowe Linki #5

Podsumowanie obecnego stanu wzdrożenia nowych funkcjonalności WordPressa 3.8

Dla tych, którzy lubią być na bieżąco – powyższy artykuł krótko podsumowuje obecną sytuację funkcjonalności rozwijanych jako wtyczki. Ważną informacją jest też fakt możliwego przesunięcia wydania motywu Twenty Fourteen do czasu wydania WordPressa 3.9.

Widżety w personalizacji motywu

Wtyczka Widget Customizer dodaje możliwość edycji i podglądu widżetów w panelu personalizacji motywu. Główny problem jaki rzuca mi się w oczy to konieczność dostosowania panelu opcji widżetu do szerokości panelu bocznego widocznego na stronie personalizacji.

10 najczęściej spotykanych problemów z WordPressem oraz ich rozwiązania

Zgrabne podsumowanie 10 często spotykanych błędów/problemów – idealne jako baza gotowych odpowiedzi dla nietechnicznych klientów, panikujących na widok białej strony 🙂

Jesienny WordUp w Krakowie

15 Listopada odbędzie się jesienna edycja WordUpa w Krakowie. Pojawię się tam też ja i będę opowiadać o możliwościach naszego widżetu GK News Show Pro.

Własne filtry obrazu (sepia, greyscale) w WP_Image_Editor

Standardowo implementacja klasy WP_Image_Editor nie udostępnia nam żadnych filtrów dla obrazów takich jak sepia czy skala odcieni szarości (greyscale). Na szczęście klasa ta została zaimplementowana w bardzo elastyczny sposób, przez co umożliwia dodanie własnych metod. Pokażę więc w jaki sposób można stworzyć własne filtry obrazu.

Idea stojąca za WP_Image_Editor

Klasa WP_Image_Editor jest klasą abstrakcyjną – czyli najprościej mówiąc służy za wzór dla innych, bardziej szczegółowych implementacji operacji na obrazie z wykorzystaniem różnych bibliotek graficznych. Stąd też w WordPressie znajdziemy takie klasy jak WP_Image_Editor_Imagick czy WP_Image_Editor_GD. Obie wspomniane klasy odpowiadają za implementację operacji na obrazie z użyciem dwóch popularnych bibliotek graficznych: ImageMagick i GD. Trzeba o tym pamiętać gdyż fakt ten ma bardzo ważną implikację – implementując jakiś efekt powinniśmy zadbać o jego wsparcie w obu wypadkach (no chyba, że robimy projekt na własne potrzeby i pod konkretną konfigurację serwera).

Implementacja nowych metod operujących na obrazie

Jak można dodać własne metody operujące na obrazie? Trzeba stworzyć klasy potomne dla klas WP_Image_Editor_Imagick i WP_Image_Editor_GD. Poniżej znajduje się moja implementacja metod dziudek_greyscale i dziudek_sepia:

class Dziudek_Imagick_Filters_Editor extends WP_Image_Editor_Imagick {
  public function dziudek_sepia($arg = 100) {
    $this->image->sepiaToneImage($arg);
    return true;
  }
  public function dziudek_greyscale() {
    $this->image->modulateImage(100,0,100);
    return true;
  }
}
class Dziudek_GD_Filters_Editor extends WP_Image_Editor_GD {
  public function dziudek_sepia() {
    imagefilter($this->image, IMG_FILTER_GRAYSCALE);
    imagefilter($this->image, IMG_FILTER_COLORIZE, 90, 60, 40);
    return true;
  }

  public function dziudek_greyscale() {
    imagefilter($this->image, IMG_FILTER_GRAYSCALE);
    return true;
  }
}

Jak widać stworzyliśmy dwie klasy potomne. Teoretycznie mógłbym metody nazwać sepia i greyscale ale niedługo wyjaśni się czemu lepiej zastosować prefiks.

Najprawdopodobniej będziemy musieli też dołączyć wszystkie potrzebne klasy do naszego pliku z nowymi klasami potomnymi:

require_once(ABSPATH . WPINC . '/class-wp-image-editor.php');
require_once(ABSPATH . WPINC . '/class-wp-image-editor-imagick.php');
require_once(ABSPATH . WPINC . '/class-wp-image-editor-gd.php');

Mamy już prawie wszystko czego nam potrzeba – pora sprawić, żeby nasz kod był dostępny w WordPressie w metodzie wp_get_image_editor – w tym celu wykorzystamy filtr wp_image_editors:

function dziudek_add_image_filters_editors( $editors ) {
  array_unshift( $editors, 'Dziudek_Imagick_Filters_Editor' );
  array_unshift( $editors, 'Dziudek_GD_Filters_Editor' );

  return $editors;
}

add_filter( 'wp_image_editors', 'dziudek_add_image_filters_editors' );

Powyższa funkcja spowoduje dodanie naszych klas potomnych do listy dostępnych edytorów obrazu.

Pora użyć naszego kodu

Wyprodukowaliśmy już sporo kodu, zatem pora z niego zrobić użytek 🙂

Aby wykorzystać nasze własne klasy, musimy skorzystać z drugiego parametru metody wp_get_image_editor:

$img_editor = wp_get_image_editor( 
    $path_to_file, 
    array( 'methods' => array( 'dziudek_sepia', 'dziudek_greyscale' ) ) 
);

Pierwszy argument to oczywiscie ścieżka do pliku na którym będziemy działać, natomiast ten drugi argument pozwala nam określić jakich dodatkowych metod oczekujemy po edytorze obrazu. Słowo klucz to „oczekujemy” – może się okazać, że żaden z dostępnych edytorów obrazu nie oferuje pożądanej przez nas funkcjonalności – wtedy zmienna $img_editor będzie zawierać obiekt klasy WP_Error z informacją „No image editor”. W naszym wypadku jednak wszystko powinno zadziałać i WordPress powinien zwrócić instancję klasy Dziudek_GK_Filters_Editor lub Dziudek_Imagick_Filters_Editor zależnie od tego, która z tych bibliotek zainstalowana jest u nas na serwerze.

Dzięki temu będziemy mogli wykonać następujący kod:

$img_editor->dziudek_greyscale();

lub:

$img_editor->dziudek_sepia();

Wracając do prefiksów w nazwach tych metod. Teoretycznie dla skrócenia kodu można by je pominąć, ale pamiętajmy – autor jakiejś wtyczki może dodać własne funkcjonalności różniące się efektami od naszych i wtedy pojawi się problem, gdyż taka implementacja może zostać wczytana zamiast naszej jako edytor obrazu ze względu na spełnienie naszych potrzeb odnośnie funkcjonalności (polecam w tym miejscu analizę metody _wp_image_editor_choose). Zatem osobiście polecam jednak używać prefiksów w nazwach metod lub używanie bardziej wyszukanych nazw metod 🙂

Podsumowanie

Jak widać implementacja klasy WP_Image_Editor jest bardzo elastyczna i pozwala na łatwe dodawanie funkcjonalności. Z mojego punktu widzenia najwygodniejsze jest to, że nie muszę się martwić o wykrywanie poszczególnych bibliotek graficznych – kod WordPressa robi to za mnie. Polecam własne eksperymenty z filtrami obrazu 🙂

WordPressowe Linki #4

Prezentacje z WordCampa w Bostonie

Na WordCampie w Bostonie było poruszanych wiele różnych tematów. Osobiście spodobały mi się dwie z nich „Wicked Fast WordPress” oraz „Anatomy of a WordPress Hack„.

Jak właściwie używać Transient API

Ciekawy artykuł, ładnie podsumowujący na co należy uważać korzystając z Transient API.

Instalowanie pluginów WordPressa z Githuba

Github to niesamowicie popularna usługa dla programistów – nic dziwnego, że znalazło się na nim mnóstwo pluginów dla WordPressa (sam tak robię). Artykuł opisuje jak łatwo dostać się do dużych zasobów kodu zgromadzonych na githubie.

Gdyby ktoś potrzebował listy wszystkich funkcji wprowadzonych w WordPressie 3.7

Pięknie wylistowane wszystkie dodane funkcje – idealne dla developerów, którzy chcą znać wszystkie nowinki wprowadzone w nowym WordPressie.

Wyłączanie automatycznych aktualizacji w WordPress 3.7

Dla tych, których przeraża nowa funkcjonalność WP 3.7 (a raczej fakt iż wiele rzeczy może w trakcie jej działania pójść nie tak)  – kompletny i szczegółowy poradnik od developerów WordPressa.


Background Update Tester

Dla tych, którzy chcą się upewnić, że automatyczne aktualizacje zadziałają na ich serwerze polecam wtyczkę Background Update Tester, która sprawdza czy serwer oraz konfiguracja WordPressa umożliwa działanie automatycznych aktualizacji wprowadzonych w WordPressie 3.7.