Tematyka wystąpienia

Tematem wystąpienia były frameworki motywów WordPressa - co to takiego i jakie mają zastosowanie w kontekście WordPressa, kiedy warto z nich korzystać, jakie są ich zalety i wady? Plus garść przemyśleń z tworzenia stron na bazie frameworka Genesis.

Prezentację można także pobrać w wersji tekstowej.

Filmy z wystąpienia

Całe wystąpienie zostało podzielone na trzy filmy więc utworzyłem z nich listę odtwarzania:

Inne wystąpienia

Jednocześnie zachęcam do obejrzenia innych wystąpień z WordCamp Poznań 2011.

Podobne artykuły

• Rozwiązanie konkursu! 5 wejściówek na WordCamp Poznań 2011 (5)
• Konkurs! 5 wejściówek na WordCamp Poznań 2011 (30)
• Paweł Ludwiczak na spytkach czyli co nieco o organizacji WordCamp Poznań (60)
• Rozwiązanie konkursu! „Wtyczka, bez której nie wyobrażam sobie swojego bloga to…” (21)
• Konkurs! „Wtyczka, bez której nie wyobrażam sobie swojego bloga to…” (49)
• Wrażenia po WordCamp Polska 2010 (27)
• WordCamp Polska 2010 (26)

Tytułem wstępu

Niezorientowanym podpowiadam - Wacław Jacek to autor oficjalnego, polskiego tłumaczenia WordPressa, które istnieje od końca 2008 roku. Nie licząc małego poślizgu na samym początku, polską wersję mogliśmy pobierać najpóźniej w parę dni po światowej premierze.

Pech jednak chciał, że na przełomie 2011/2012 roku, czyli po publikacji wersji 3.3, polska edycja zaliczyła dosyć spore, bo prawie dwumiesięczne, opóźnienie co wywołało niemałe zamieszanie wśród zainteresowanych.

Udało mi się namówić Wacława na krótki wywiad w tej sprawie i przy okazji poruszyć parę innych kwestii związanych z tłumaczeniem. Niestety tych, którzy oczekiwali wyjaśnienia powodów opóźnienia muszę zmartwić - wszystko rozeszło się o sprawy osobiste, których szczegóły autor chciałby zachować dla siebie.

Zaczniemy więc od drugiej, ale wcale nie mniej ważnej kwestii:

Czy podjąłeś jakieś kroki żeby uniknąć tego typu sytuacji w przyszłości?

Tak - podczas kiedy tłumaczenie się nie pojawiało, zgłosiło się do mnie parę osób, które wyraziły chęć pomocy przy tłumaczeniu i przetłumaczyły trochę tekstu. Ponadto zamierzam opublikować na blogu pl.wordpress.org apel o pomoc w tłumaczeniu i może jakiś poradnik dla tych, którzy chcą w tym pomóc.

Jak zareagowałeś na fakt opublikowania w międzyczasie alternatywnych wersji tłumaczeń?

Bardzo fajnie, że ktoś się tym zajął, kiedy nie wychodziło spolszczenie. Zapraszam autorów tych tłumaczeń do współpracy! :)

W jaki sposób zwykli użytkownicy mogą pomóc w tłumaczeniu?

W tej chwili tłumaczenie odbywa się przy pomocy GlotPressa - oprogramowania napisanego przez ludzi z Automattic, które działa tak, że każdy zarejestrowany może proponować tłumaczenia, a osoby, które mają rolę „validatora” - akceptować je i dodawać swoje bez moderacji.

Chciałbym, aby było jak najwięcej validatorów tłumaczeń na polski i w tej chwili mam taki plan, że póki co będę przeglądał proponowane tłumaczenia, a osoby, które będą wysyłały dobre tłumaczenia (proszę nie zrozumieć mnie źle - nie uważam siebie za jakiś autorytet, tylko chodzi mi o zachowanie jakiegoś poziomu na tyle, na ile potrafię, i konwencji, np. żeby „posty” nie były tłumaczone w jednym miejscu jako „wpisy”, a gdzie indziej - „posty”).

Jeśli ktoś już teraz chce pomóc w tłumaczeniu, tutaj można wysyłać propozycje tłumaczeń, a tutaj znajduje się (na razie dość ubogi) spis przyjętych konwencji, który zamierzam stopniowo poszerzać (i umożliwić też nadsyłanie własnych propozycji).

Może uda mi się namówić ludzi od GlotPressa, żeby możliwość prowadzenia takiego spisu została do niego dodana (chyba nawet ktoś inny już z taką propozycją wyszedł).

Czy zajmujesz się również polskimi wersjami bbPressa i BuddyPressa?

W tej chwili tak, ale chętnie powierzę te role komuś innemu. Najważniejszym projektem wydaje mi się WordPress, bo najwięcej dobra można przy jego pomocy zrobić, więc najbardziej zależy mi na tym, żeby z nich wszystkich to właśnie on był przetłumaczony.

Co w tłumaczeniu WordPressa sprawia Ci największe trudności?

Hmm, trudno powiedzieć, ale chyba najtrudniej jest mi poradzić sobie z tekstami, w których mowa jest o rzeczach, które po angielsku mają swoje (czasem bardzo fajne) nazwy, a po polsku nie, np. wtyczki działają tak, że „przyczepiają się” do jednego z udostępnianych im miejsc, wykonując w tym miejscu określone działanie, i po angielsku nazywa się to „hook” (czyli „hak”). Polskiego odpowiednika chyba nie ma (co nie znaczy, że nie można jakiegoś wprowadzić :)).

Czy jest to bardzo czasochłonne zajęcie?

Nie jakoś strasznie, ale trzeba nad tym przysiąść, a że nikt nikomu za to nie płaci i w końcu każdy ma bardziej potrzebne rzeczy do zrobienia na co dzień, trzeba wygospodarowywać sobie na to czas.

Czy można wesprzeć Twoją pracę za pomocą dotacji?

Bardzo mi miło, naprawdę dziękuję! :) Mam taki pomysł - proszę może lepiej wpłacić te pieniądze na konto kogoś, kto robi coś naprawdę dobrego, np. na Caritas. Im się przyda. :)

Dodatkowe pytania?

Zgodnie z życzeniem autora przekazuję także pozdrowienia:

Jeśli mogę, to chcę pozdrowić moją dziewczynę, Kasię, i Michała Olszewskiego, który też bloguje na WordPressie.

Jeśli chcielibyście zadać Wacławowi jeszcze inne pytania lub podyskutować na temat udzielonych już odpowiedzi, to zapraszam do komentarzy poniżej.

Podobne artykuły

• Rozmowa z Wacławem Jackiem, autorem oficjalnego, polskiego tłumaczenia WordPressa (14)
• Paweł Ludwiczak na spytkach czyli co nieco o organizacji WordCamp Poznań (60)
• Oficjalne polskie forum dyskusyjne o WordPressie (15)
• Koniec z autorskimi tłumaczeniami WordPressa? (22)

Pierwsze wrażenie

Muszę przyznać, że książka „WordPress. Tworzenie własnych motywów” zrobiła na mnie bardzo dobre wrażenie, ale tylko na początku.

Proste, ale zgrabne zdania, świetna typografia i miłe dla oka kolory to zdecydowanie jej najmocniejsze atuty. Podobnie jak bogaty spis treści, który wydawał się być istną encyklopedią o tworzeniu motywów. Nawet przeczytanie paru akapitów tu czy tam nie wzbudziło we mnie żadnych podejrzeń.

Niestety kiedy zacząłem dokładnie analizować treść strona po stronie, pierwsze, dobre wrażenie zaczęło blednąć a wraz z ilością przeczytanych kartek przerodziło się w duże rozczarowanie.

Oto 5 powodów, dla których nie polecam wspomnianej pozycji:

1. Mylący tytuł

Zastanawiałem się nad tym długo, ale do tej pory nie mam zielonego pojęcia co autorzy mieli na myśli wstawiając słowo „własny” w tytule. Z treści wynika bowiem, że motywu nie budujemy dla siebie tylko na sprzedaż i już na pewno nie „od zera” bo na bazie frameworka Thematic (czyli po prostu na podstawie innego motywu).

Masz projekt graficzny i chcesz go nałożyć na WordPressa? Źle trafiłeś.

2. Zbyt duża rozpiętość tematyczna

Wydaje mi się, że książka jest świetnym potwierdzeniem przysłowia, że „jeśli coś jest do wszystkiego to faktycznie jest do niczego”. Odniosłem wrażenie, że autorzy poruszają zbyt wiele tematów traktując je bardzo pobieżnie zamiast omówić tylko część z nich, ale za to w wyczerpujący sposób.

Efektem tego naprawdopodobniej będzie sytuacja, w której początkujący będą zmuszeni do ciągłego szukania konkretów w zewnętrznych źródłach podczas gdy osoby bardziej wtajemniczone będą po prostu znudzone.

Dlatego też było mi bardzo trudno określić do kogo tak właściwie jest skierowana ta pozycja.

3. Trudności w odbiorze

Książka została napisana przez czterech autorów i niestety w niektórych momentach da się to wyraźnie odczuć. Zaryzykowałbym stwierdzenie, że poszczególne rozdziały potrafiłyby się obronić, ale zestawienie ich razem zaowocowało masą niespójności oraz nagłych przejść.

Nie przekonuje mnie również podejście autorów, którzy rzucają czytelnika na głęboką wodę serwując mu na starcie frameworka, z którego tak naprawdę nie da się efektywnie korzystać bez znajomości podstaw.

Przypuszczam, że z tych dwóch powodów osoba rozpoczynająca swoją przygodę z motywami WordPressa może czuć się zagubionaia i zniechęcona do dalszej nauki.

4. Niespójności w przekazie

Właściwie mówiłem już o tym we wcześniejszych punktach, ale warto to podkreślić - z jednej strony książka zachęca nas do tworzenia motywu przeznaczonego na sprzedaż a z drugiej opisuje jedynie tworzenie motywu potomnego.

Szkoda, że słowem nikt nie wspomniał, że sprzedaż motywów potomnych mija się z celem i rodzi bardzo dużo problemów od kwestii licencji po użytkowanie.

Myślę, że dużo lepszym pomysłem byłoby zaprezentowanie Hybrid Core, który jest frameworkiem stanowiącym jedynie część motywu. Wtedy faktycznie miało by to sens.

5. Nieaktualne informacje

Książka ukazała się we wrześniu 2010 roku nakładem wydawnictwa SitePoint a na polskie półki trafiła dokładnie rok później dzięki Helionowi. Jak można się dowiedzieć z treści, aktualną wówczas wersją WordPressa była ta oznaczona numerkiem 3.0.4. Od tamtej pory pojawiły się trzy duże wydania - 3.1, 3.2 i 3.3, które wprowadziły sporo zmian i nowych funkcji.

Trudno zatem oczekiwać żeby zawartość książki była nadal aktualna.

Podsumowanie

Przyznaję się bez bicia, że nie kupiłem wspominanej książki tylko dostałem ją w prezencie od wydawnictwa Helion wraz z prośbą o przejrzenie i napisanie recenzji. Z tego też powodu było mi dosyć ciężko przedstawić ją w takim a nie innym świetle.

Niemniej, niektóre rozdziały są całkiem sensowne i zawierają cenne spostrzeżenia i wartościowe informacje. Najbardziej podobały mi się „Planowanie motywu” oraz „Handel motywami”, ale to zdecydowanie zbyt mało.

Moim zdaniem książkę należy traktować bardziej jako ciekawostkę niż faktyczny podręcznik do tworzenia motywów a już na pewno nie jako wyrocznię.

Podobne artykuły

• Kiedy warto zastąpić plik functions.php wtyczką funkcjonalną i jak to zrobić? (18)
• Zmień edytor wizualny WordPressa w prawdziwy WYSIWYG (31)
• Konkurs! Stwórz unikatowy motyw do WordPressa i zgarnij książki z Heliona (31)
• wp_head i wp_footer – dwie funkcje, o których zawsze powinieneś pamiętać (23)
• Yahoo! podpowiada jak poprawić wydajność (2)

Plik functions.php a wtyczka funkcjonalna

Wprawdzie plik functions.php nie jest konieczny do działania szablonu, ale w praktyce trudno zleźć skórkę, która by go nie zawierała. Plik ten funkcjonuje tak jak wtyczka, a dla działania kodu nie ma znaczenia czy znajduje się w nim czy we wtyczce. Różnica polega na tym, że plik functions.php jest związany bezpośrednio z szablonem, w którym się znajduje, w związku z czym uruchamiany jest tylko, gdy dany szablon jest aktywny. Wtyczka natomiast działa jeśli tylko jest włączona, niezależnie od tego, z jakiego szablonu akurat korzystamy.

Celem tego artykułu nie jest przekonanie Ciebie, że nie potrzebujesz już pliku functions.php. Tak naprawdę zarówno wtyczka funkcjonalna jak i plik functions.php mają swoją rację bytu. Chcę Cię jednak zachęcić do oddzielenia kodu związanego z wyglądem szablonu od kodu odpowiedzialnego za funkcjonalność bloga. Dzięki temu unikniesz problemów i oszczędzisz sobie pracy przy zmianie lub aktualizacji szablonu.

Co powinno się znaleźć we wtyczce funkcjonalnej a co w pliku functions.php?

Aby zdecydować, gdzie powinien trafić dany fragment kodu, odpowiedz sobie na jedno pytanie. Czy dany kod dodaje do Twojego bloga funkcjonalność, którą chciałbś zachować również przy zmianie szablonu? Jeśli tak, to kod powinien trafić do wtyczki, a jeśli nie, do pliku functions.php.

Przykładowo, do wtyczki należało by przenieść kod związany z:

• własnymi typami wpisów (custom post types),
• dodanymi na potrzeby strony shortcodes,
• modyfikacjami panelu administracyjnego (np. zmiana logo na stronie logowania),
• własnymi taksonomiami.

Co pozostawić w pliku functions.php?

• definicje rozmiarów miniatur,
• definicje obszarów sidebar,
• definicje menu,

oraz wszystko to, co związane jest z wyglądem i poprawnym wyświetlaniem danego szablonu.

Jak stworzyć własną wtyczkę funkcjonalną?

Wbrew pozorom nie jest to nic trudnego i nawet osoby ze znikomą znajomością PHP powinny dać sobie z tym radę. Cała praca zasadniczo polega na kopiowaniu kodu pomiędzy plikiem functions.php a plikiem wtyczki.

Utwórz nowy plik php i wklej na początek poniższy fragment, dzięki któremu WordPress rozpozna go jako wtyczkę. Plik możesz nazwać dowolnie, ale najlepiej aby nazwa nie była całkiem przypadkowa, przykładowo nazwabloga-functions-plugin.php.

<?php
/*
Plugin Name: Wtyczka funkcjonalna bloga MojBlog.pl
Description: Funkcjonalność bloga, niezwiązana z wyglądem.
Version: 0.1
License: GPL
Author: Imię i nazwisko
Author URI: http://mojblog.pl
*/
?>

Teraz wystarczy, że skopiujesz do pliku wtyczki cały kod odpowiedzialny za dodatkową funkcjonalność na Twoim blogu.

Przykładowo, załóżmy że w pliku functions.php masz zdefiniowany:

• własny domyślny awatar dla użytkowników oraz
• własny przycisk w edytorze wizualnym

Zakładając, że zależy nam na zachowaniu tej funkcjonalności również przy zmianie szablonu, całe fragmenty kodu przenosimy do pliku nowo utworzonej wtyczki:

<?php
/*
Plugin Name: Wtyczka funkcjonalna bloga MojBlog.pl
Description: Funkcjonalność bloga, niezwiązana z wyglądem.
Version: 0.1
License: GPL
Author: Imię i nazwisko
Author URI: http://mojblog.pl
*/
 
/**
* własny domyślny awatar
*/
 
add_filter('avatar_defaults', 'custom_avatar');
 
function custom_avatar ($avatars) {
   $custom_avatar_url = get_bloginfo('template_url').'/img/nazwa-pliku.gif';
   $custom_avatar_title = "Nazwa awatara";
   $avatars[$custom_avatar_url] = $custom_avatar_title;
   return $avatars;
}
 
/**
* własny przycisk w wizualnym edytorze
*/
 
add_shortcode('css_button', 'generate_css_button');
 
function generate_css_button($atts, $content = null){
   $result = extract(shortcode_atts(array(
   'to' => '#'
   ), $atts));
   return "<a class='css_button_blue' href='$to'>$content</a>";
}
?>

W ten sam sposób należy postąpić z pozostałym kodem z pliku functions.php kierując się wspomnianą wcześniej zasadą.

Instalacja wtyczki funkcjonalnej

Kiedy już uporasz się z kopiowaniem kodu do pliku wtyczki, pozostaje Ci tylko instalacja.
Tutaj masz dwie opcje.

• Metoda 1. Katalog wp-content/plugins

  Jest to standardowa procedura, która polega na umieszczeniu pliku wtyczki w katalogu wp-content/plugins, a następnie aktywacji z poziomu panelu administracyjnego.

  

  Wtyczka umieszczona w katalogu wp-content/plugins

  Zapewne do tej pory właśnie w ten sposób postępowałeś ze wszystkimi wtyczkami. Jest jednak jeszcze jeden sposób, o którym warto wspomnieć.

• Metoda 2. Katalog wp-content/mu-plugins

  Osoby które miały okazję pracować z WordPress w wersji MU (Multi User), zapewne pamiętają katalog mu-plugins, do którego wgrywało się wtyczki, aby automatycznie były aktywne na wszystkich blogach w ramach sieci.

  Jednak nazwa tego katalogu – mu-plugins to skrót od „must use”, a nie „multi user”, jak mogłoby się wydawać. W związku z tym również w pojedynczej instalacji WordPress (od wersji 2.8) można utworzyć taki katalog w folderze wp-content, a w rezultacie wrzucone do niego wtyczki będą działać, bez konieczności aktywacji.

  To rozwiązanie ma również tę zaletę, że eliminuje ryzyko przypadkowego wyłączenia wtyczki, która jest kluczowa dla działania bloga.

  Wracając do naszej wtyczki funkcjonalnej - jeśli nie masz katalogu mu-plugins w swojej instalacji, wystarczy że utworzysz go ręcznie w folderze wp-content, a następne skopiujesz tam plik wtyczki. Jeśli teraz wejdziesz do panelu administracyjnego, oto co powinieneś zobaczyć w sekcji „Wtyczki”:

  

  Wtyczka umieszczona w katalogu wp-content/mu-plugins

  Tak jak wspominałam, w tym wypadku nie ma konieczności aktywacji wtyczki. Oznacza to jednak również, że nie ma możliwości jej wyłączenia - aby przestała działać, trzeba ją fizycznie usunąć z katalogu.

  Warto również wiedzieć, że do katalogu mu-pugins można wrzucać jedynie pojedyncze pliki (tak jak w naszym przypadku, gdzie cała wtyczka znajduje się w jednym pliku).

  Więcej informacji na temat roli katalogu mu-plugins znajdziesz w oficjalnej dokumentacji.

Co dalej?

Opisaną w artykule metodę można zgeneralizować i zamiast jednej wtyczki funkcjonalnej stworzyć ich kilka, wydzielając poszczególne funkcje. Na pewno warto o tym pomyśleć, gdy dodajemy funkcjonalność, z której korzystamy często również na innych stronach.

Przykładowo, jeśli w nowo tworzonych serwisach powtarzamy ten sam standardowy zestaw modyfikacji panelu administracyjnego (np. ukrywanie widgetów w kokpice, ukrywanie powiadomień o aktualizacji, modyfikacje tekstu w stopce itd.), warto zastanowić się, czy nie zasługuje on na odrębną wtyczkę.

Postępując w ten sposób, można znacznie przyspieszyć i ułatwić sobie pracę nad kolejnymi projektami.

Podsumowanie

Jednym z powodów, dla którego rozszerzanie funkcjonalności bloga poprzez dodawanie kodu do pliku functions.php jest tak popularne, jest prostota tego rozwiązania. Mam jednak nadzieję, że po przeczytaniu tego artykułu, będziesz świadomie decydował, gdzie powinien trafić określony fragment kodu.

Podobne artykuły

• „WordPress. Tworzenie własnych motywów” – recenzja książki (44)
• Zmień edytor wizualny WordPressa w prawdziwy WYSIWYG (31)
• wp_head i wp_footer – dwie funkcje, o których zawsze powinieneś pamiętać (23)

Szczegóły aktualizacji

Zmiany w stosunku do poprzedniej wersji (3.3):

• Wersja 3.3.1 została wydana głównie ze względu na wykrycie dziury umożliwiającej przeprowadzenie ataku typu XSS przy wykorzystaniu formularza dodawania komentarzy i przeglądarki Internet Explorer.
• Przy okazji wprowadzono też 15 innych poprawek, które uzbierały się do tej pory.

Podobne artykuły

• WordPress 3.3 (33)
• WordPress 3.2 (21)
• Powiadamianie mailem o aktualizacji WordPressa, motywów i wtyczek (10)
• WordPress 3.1 (62)
• WordPress 3.0 (61)
• WordPress 2.9.2 (30)
• WordPress 2.9.1 (15)

WordPress 3.3 - ważniejsze nowości

O ile wersja 3.2 nastawiona była na poprawę szybkości i wydajności, to teraz przyszła kolej na komfort pracy w panelu administracyjnym. Niektóre ze zmian wydają się kosmetyczne, ale trzeba przyznać, że diabeł tkwi w szczegółach a autorzy coraz lepiej zdają sobie z tego sprawę.

Pora na parę smakołyków, które wybrałem z całego worka:

• informacje dotyczące korzystania z panelu administracyjnego

  Tuż po zalogowaniu do świeżo zainstalowanego WordPressa zobaczymy ekran z podstawowymi wskazówkami dotyczącymi poruszania się po panelu administracyjnym:

  

  ekran powitalny wraz z podstawowymi wskazówkami

  Opcja ta z pewnością przypadnie do gustu tym użytkownikom, którzy dopiero rozpoczynają swoją przygodę z WordPressem.

  Przy okazji odświeżono wygląd pomocy kontekstowej, która zamiast straszyć w końcu nadaje się do czytania (przycisk „pomoc” w prawym górnym rogu ekranu):

  

  odświeżona pomoc kontekstowa

• informacje dotyczące zmian w nowej wersji

  Aktualizacja WordPressa chyba nigdy nie była równie przyjemna.  Tuż po wykonaniu operacji przywita nas ekran z listą najważniejszych zmian, jakie zostały wprowadzone:

  

  ekran z informacjami o wprowadzonych zmianach (fragment)

  Koniec z przedzieraniem się przez anglojęzyczną dokumentację w celu sprawdzenia co nowego udało się tym od WordPressa zmajstrować.

  Dodatkowo, kiedy wejdziemy na stronę, która będzie oferowała nową funkcję zostaniemy o tym poinformowani specjalnym dymkiem wraz ze szczegółowym opisem tak, aby nic ważnego nie umknęło naszej uwadze:

  

  wskazówki dotyczące nowych funkcji

• uproszczone dodawanie załączników

  Dotychczasowe cztery przyciski, za pomocą których mogliśmy dodawać do wpisu załączniki (obrazki, filmy, dźwięki i inne) zastąpiono jednym, który automatycznie wykrywa typ pliku.

  Zamieniono także bebechy (SWFUpload na Plupload) dzięki czemu możemy teraz wgrywać pliki w bardziej cywilizowany sposób (tj. metodą przeciągnij i upuść):

  

  wgrywanie plików metodą przeciągnij i upuść

• zmiany w wyglądzie panelu administracyjnego

  Menu w panelu administracyjnym nie rozwija się już w dół po kliknięciu tylko w bok i to od razu po najechaniu na daną etykietę. Przyspiesza to nawigację a lista elementów nie zajmuje już kilometrów miejsca:

  

  rozwijane menu w panelu administracyjnym

  Sam panel dostosowuje się teraz bardziej inteligentnie do rozmiarów okna przeglądarki. Szału nie ma, ale w kolejnej odsłonie ma być to zrobione dużo lepiej.

  Nieznacznym modyfikacjom uległ także wygląd i zawartość paska administracyjnego. Jest on teraz bardziej spójny z resztą elementów panelu a jego usuwanie, mimo iż banalnie proste, powoli zaczyna tracić sens.

• optymalizacja schematu odnośników

  Wśród propozycji schematu bezpośrednich odnośników pojawiła się opcja zawierająca wyłącznie adres strony wraz z tytułem wpisu:

  

  nazwa wpisu w odnośniku jako sugerowana opcja

  Związane jest to z przeprowadzoną optymalizacją szybkości wczytywania strony przy takim ustawieniu. Świetnie bo używam go od ponad trzech lat…

• zapamiętywanie ustawień widgetów

  Jedną z bardziej denerwujących rzeczy w WordPressie było resetowanie ustawień widgetów przy zmianie motywu. Teraz zostało to poprawione i możemy zmieniać wygląd bez obaw.

• nowe funkcje wp_editor i is_main_query

  Spośród nowych funkcji warto wymienić wp_editor oraz is_main_query. Pierwsza ułatwia tworzenie kolejnych pól edytora TinyMCE w panelu administracyjnym a druga umożliwia manipulowanie główną pętlą.

• aktualizacja skryptów JavaScript

  Uaktualniono zewnętrzne skrypty do najnowszych wersji a w tym jQuery (1.7.1) oraz jQuery UI (1.8.16). Warto zaznaczyć, że ten drugi został dodany w pełnej, a nie jak dotychczas okrojonej, wersji.

WordPress 3.3 - polska wersja językowa

Niestety, w tym momencie nie ma jeszcze polskiej wersji WordPressa 3.3.

Bez obaw - z informacji, które otrzymałem od Wacława wynika, że prace są w toku a oficjalnego tłumaczenia możemy się spodziewać za 1-2 tygodnie. Opóźnienie zaś związane jest po prostu z nawarstwieniem się dużej ilości pracy.

Miłośnikom polskiego interfejsu pozostaje trenować cierpliwość albo posiłkować się wersją przygotowaną przez Konrada.

Inni mogą spokojnie instalować wersję anglojęzyczną - nie będą z tego powodu wynikały jakiekolwiek komplikacje a nieprzetłumaczone frazy dotyczyć będą głównie opisanych powyżej, nowych funkcji.

WordPress 3.3 - Twoje wrażenia

Jakie jest Twoje zdanie o najnowszej wersji WordPressa?

Podobne artykuły

• WordPress 3.3.1 (22)
• WordPress 3.2 (21)
• Powiadamianie mailem o aktualizacji WordPressa, motywów i wtyczek (10)
• WordPress 3.1 (62)
• WordPress 3.0 (61)
• WordPress 2.9.2 (30)
• WordPress 2.9.1 (15)

Obrazki dla wpisów, stron i własnych typów wpisów

Omówiona wtyczka działa na bardzo podobnej zasadzie co funkcja „ikony wpisu”.

Dla przypomnienia - jest to ficzer dodany w WordPress 2.9, który umożliwia powiązanie konkretnego pliku graficznego z dowolnym wpisem. Obrazek taki można później wyświetlić np. obok wpisu i tym samym zwiększyć jego atrakcyjność.

Zainteresowanych tematem polecam fajny artykuł na Vivee lub dokumentację techniczną.

Obrazki dla kategorii, tagów i własnych taksonomii

Wtyczka nazywa się Taxonomy Images i jest autorstwa Michaela Fieldsa, człowieka który obecnie pracuje w Automattic i zajmuje się kwestiami związanymi z motywami.

Po instalacji możemy wybrać, która taksonomia (tagi, kategorie lub własne) ma mieć możliwość przypisywania zdjęć - w tym celu wystarczy otworzyć zakładkę „ustawienia / taxonomy images” i odznaczyć te pozycje, które nas nie interesują:

Wybieranie, która taksonomia ma mieć obsługę obrazków

Od tej pory, strona zarządzania taksonomią zostanie wzbogacona o dodatkowe opcje umożliwiające w równie prosty i przyjemny sposób dodawanie obrazków jak to ma miejsce przy „ikonach wpisu”. Przykładowo - po wejściu w „kategorie” zobaczymy poniższy obrazek:

Strona taksonomii z możliwością dodawania obrazków

Jeśli przyjrzycie się powyższemu obrazkowi to zauważycie pod obrazkami dwa małe przyciski, które umożliwiają szybkie dodawanie i usuwanie obrazka. Akcja dzieje się na tej samej zasadzie co przy „ikonach wpisów” czyli po kliknięciu otwiera się nowe okienko gdzie możemy wgrać nowy plik graficzny wprost z naszego komputera lub wybrać już istniejący z biblioteki mediów.

Wyświetlanie obrazków na stronie

Autor daje nam parę możliwości wyświetlenia obrazka w zależności od tego gdzie i w jaki sposób i w jakiej formie chcemy ją pokazać.

Przykładowo, jeśli jesteśmy na stronie taksonomii (czyli np. stronie kategorii wpisu) to możemy wyświetlić obrazek za pomocą poniższego filtra:

print apply_filters( 'taxonomy-images-queried-term-image', '' );

Korzystając z dodatkowych parametrów możemy kontrolować takie szczegóły jak wymiary obrazka, zawartość atrybutu alt oraz title czy elementy HTML, które mają znaleźć się tuż przed lub po.

Możemy też pobrać sam adres obrazka za pomocą poniższej funkcji:

$image_url = apply_filters( 'taxonomy-images-queried-term-image-url', '', array( 'image_size' => 'full' ) );

Pomysły na wykorzystanie

Wtyczkę można wykorzystać na wiele sposobów. Mi do głowy wpadły poniższe pomysły, ale jestem pewien, że jest ich dużo więcej:

• miniaturka w spisie kategorii,
• podmiana obrazka w nagłówku (np. w motywie TwentyTen czy TwentyEleven),
• podmiana tła strony.

Podobne artykuły

• Page Tagger – świetna wtyczka do tagowania stron (6)

Zwycięzcy konkursu

Lista szczęśliwców, którzy otrzymają wejściówki na WordCamp Poznań 2011 wygląda następująco:

• Marcin #
• Tomek #
• Szymon Barczak #
• Zacol #
• Maciej #

Dla potwierdzenia zamieszczam także zrzut z redakcyjnej maszyny losującej:

Wyniki losowania

Gratulacje i do zobaczenia na WordCampie! Ze zwycięzcami skontaktuję się mailowo.

Podobne artykuły

• Konkurs! 5 wejściówek na WordCamp Poznań 2011 (30)
• Rozwiązanie konkursu! „Wtyczka, bez której nie wyobrażam sobie swojego bloga to…” (21)
• Konkurs! „Wtyczka, bez której nie wyobrażam sobie swojego bloga to…” (49)
• „Frameworki WordPressa…” – moje wystąpienie na WordCamp Poznań 2011 (22)
• Paweł Ludwiczak na spytkach czyli co nieco o organizacji WordCamp Poznań (60)
• Konkurs! Stwórz unikatowy motyw do WordPressa i zgarnij książki z Heliona (31)
• Wrażenia po WordCamp Polska 2010 (27)

Nagrody

Nagrodami w konkursie jest 5 wejściówek na WordCamp Poznań 2011 - konferencję poświęconą w 101% WordPressowi, która odbędzie się w dniach 9-10 grudnia w Poznaniu.

Rok temu było świetnie a teraz zapowiada się genialnie! Oczywiście, na spotkaniu będzie można przybić piątkę m.in. z WPNinja :).

Zasady

Żeby wziąć udział w konkursie wystarczy:

1. Podzielić się linkiem do tego artykułu na dowolnym serwisie społecznościowym typu Facebook, Google+, Twitter, Blip itp.
2. W komentarzu pod artykułem zamieścić link zwrotny do opublikowanego statusu.

Komentarze można zamieszczać do 26. listopada do godziny 12:00. Spośród nadesłanych odpowiedzi wylosuję 5 zwycięskich, których autorzy otrzymają odemnie nagrodę w postaci wejściówki. Lista zwycięzców zostanie ogłoszona w osobnym wpisie.

Podobne artykuły

• Rozwiązanie konkursu! 5 wejściówek na WordCamp Poznań 2011 (5)
• Rozwiązanie konkursu! „Wtyczka, bez której nie wyobrażam sobie swojego bloga to…” (21)
• Konkurs! „Wtyczka, bez której nie wyobrażam sobie swojego bloga to…” (49)
• „Frameworki WordPressa…” – moje wystąpienie na WordCamp Poznań 2011 (22)
• Paweł Ludwiczak na spytkach czyli co nieco o organizacji WordCamp Poznań (60)
• Konkurs! Stwórz unikatowy motyw do WordPressa i zgarnij książki z Heliona (31)
• Wrażenia po WordCamp Polska 2010 (27)

Edytor w trybie wizualnym / HTML a WYSIWYG

Pisząc „edytor wizualny / HTML” mam na myśli to okienko, w które wpisujemy treść główną wpisu lub strony. Wygląda ono następująco:

• tryb wizualny:

  

  edytor w trybie wizualnym

• tryb HTML:

  

  edytor w trybie HTML

Tryb WYSIWYG?

Tryb wizualny często określany jest jako WYSIWYG. Jest to angielski skrót, który można przełożyć jako „dostajesz to co widzisz”. Gdyby było tak naprawdę to widok w trybie wizualnym powinien w 100% pokrywać się z ostateczną, opublikowaną wersją. Najczęściej wygląda to tak, że tryb wizualny to jedno a ostateczna wersja to zupełnie inna bajka:

Wygląd wpisu po opublikowaniu

Na szczęście WordPress daje nam narzędzia aby z trybu wizualnego zrobić prawdziwy WYSIWYG tak jak to jest w przypadku domyślnych motywów TwentyTen czy TwentyEleven.

Tyle tytułem wstępu. Teraz zabierzmy się do pracy.

Krok 1: Dedykowany arkusz CSS

Wygląd strony zdefiniowany jest w arkuszu stylów, czyli w pliku style.css, który mieści się w katalogu głównym motywu. Plik ten, poza zapisami definiującymi wygląd wpisów i stron zawiera również wiele reguł niepotrzebnych z punku widzenia edytora wizualnego. Dlatego też potrzebujemy stworzyć odrębny arkusz stylów, który nazwiemy editor-style.css. Podobnie jak plik style.css, umieścimy go w katalogu głównym naszej skórki.

Samo stworzenie dedykowanego arkusza nie wystarczy. Musimy jeszcze „powiedzieć” WordPressowi, że powinien z niego korzystać. W tym celu edytuj plik functions.php w swoim motywie, i dopisz linijkę:

add_editor_style();

Funkcja add_editor_style pojawiła się dopiero w WordPress 3.0, więc zanim zabierzesz się do pracy, upewnij się że korzystasz z odpowiedniej wersji. Możesz również wymyślić własną nazwę dla pliku CSS edytora. W takim wypadku do pliku functions.php wstawiasz nieco zmodyfikowany kod:

add_editor_style('moj-styl.css');

Krok 2: Definiowanie reguł CSS

Na tym etapie Twój edytor wizualny korzysta już z własnego arkusza stylów. Teraz czas uzupełnić go odpowiednimi regułami. Nie będzie to trudne zadanie, ponieważ zaczerpniemy je z pliku style.css.

Pierwsza reguła, którą dodamy do pliku editor-style.css będzie definiować szerokość treści strony. Domyślnie edytor wizualny rozciąga treść na całą dostępną szerokość, podczas gdy w praktyce w większości szablonów, ilość przestrzeni przeznaczona na treść jest ściśle określona w pikselach. Potrzebujemy zatem ustalić, jaką szerokość ma element HTML, który jest kontenerem treści, a następnie wstawić poniższą linijkę na sam początek pliku editor-style.css (podmieniając 584 na właściwą wartość).

html .mceContentBody {
   max-width: 584px;
}

Jak już wspominałam, arkusz editor-style.css powinien zawierać tylko te reguły, które odnoszą się do treści wpisów i stron. W praktyce nasze zadanie polegać będzie na kopiowaniu określonych fragmentów z pliku style.css. Cały proces pokażę na przykładzie szablonu TwentyEleven. Poniżej znajduje się kilka linijek zaczerpniętych z pliku style.css.

.entry-content h1, .entry-content h2, .comment-content h1, .comment-content h2 {
   color: #000;
   font-weight: bold;
   margin: 0 0 .8125em;
}
 
.entry-content h3, .comment-content h3 {
   font-size: 10px;
   letter-spacing: 0.1em;
   line-height: 2.6em;
   text-transform: uppercase;
}

W tym wypadku musimy skopiować reguły dla nagłówków H1, H2 i H3 usuwając po drodze wszystkie wystąpienia .entry-content, ponieważ w edytorze ta klasa nie występuje. W efekcie powyższy fragment kodu powinniśmy przekształcić do postaci:

h1, h2 {
   color: #000;
   font-weight: bold;
   margin: 0 0 .8125em;
}
 
h3 {
   font-size: 10px;
   letter-spacing: 0.1em;
   line-height: 2.6em;
   text-transform: uppercase;
}

Powyższy fragment powinien trafić do pliku editor-style.css. Tym sposobem nagłówki w edytorze będą wyglądać identycznie jak na stronie. Cały proces należy powtórzyć dla pozostałych elementów (p, blockquote, ul, li itd.), aż do momentu, gdy wpisy w edytorze wizualnym będą wyglądać tak samo jak na stronie.

Krok 3: Różne style dla różnych typów wpisów i stron

W praktyce może zdarzyć się tak, że układy dla stron i dla różnych typów wpisów będą się nieco różnić między sobą. Przykładowo, załóżmy że dla wpisów wyświetlany jest sidebar, który nie występuje na stronach. W takim wypadku prawdziwy edytor WYSIWYG powinien uwzględnić różnicę w szerokości treści dla stron i wpisów.

Rozwiązanie w takiej sytuacji, polega na przygotowaniu osobnych arkuszy stylów na użytek edytora, np. editor-style-post.css oraz editor-style-page.css. Arkusze te de facto będą się różnić tylko pierwszą deklaracją:

html .mceContentBody {
   max-width: 584px;
}

Musimy jeszcze zmodyfikować kod w pliku functions.php tak, aby edytor wczytywał odpowiedni arkusz w zależności od tego, czy edytujemy wpis czy stronę.

<?php
add_action('admin_head', 'editor_style_switcher');
function editor_style_switcher() {
   global $current_screen;
   switch ($current_screen->post_type) {
      case 'page':
      add_editor_style('editor-style-page.css');
      break;
   case 'post':
      add_editor_style('editor-style-post.css');
      break;
   }
}
?>

Jeśli na swoim blogu korzystasz z dodatkowych typów wpisów, których układ jest inny niż ten dla stron i standardowych wpisów, wystarczy że rozwiniesz powyższy kod, dodając kolejną pozycję. Oczywiście musisz pamiętać również o stworzeniu osobnego arkusza stylów.

Podsumowanie

W zależności od tego, jak zbudowany jest plik style.css w Twoim szablonie, stworzenie odrębnego arkusza stylów dla edytora może się okazać mniej lub bardziej czasochłonnym zadaniem. Aby ułatwić sobie pracę, możesz skorzystać z wtyczki Firebug dla Firefox, lub podobnego narzędzia tego typu w innej przeglądarce. Myślę, że z taką pomocą, nawet osoby mało obeznane z HTML i CSS dadzą sobie radę.

Powodzenia i nie zapomnij dać znać jak Ci poszło!

Podobne artykuły

• „WordPress. Tworzenie własnych motywów” – recenzja książki (44)
• Kiedy warto zastąpić plik functions.php wtyczką funkcjonalną i jak to zrobić? (18)
• WordPress – własny przycisk w wizualnym edytorze (25)
• wp_head i wp_footer – dwie funkcje, o których zawsze powinieneś pamiętać (23)