Wiele błędów programistów WordPressowych wynika z ich ścieżki uczenia się. Poznają system wyrywkowo, nie mają pełnej świadomości tego, jak działa, które rzeczy są kosztowne, które zalecane, które bezpieczne. Nie maja świadomości całości. Używają pierwszego narzędzia jakie im wpadnie w rękę. Pragmatyzm WordPressa sprawia, że większość rzeczy można zrobić na wiele sposobów, jednak to nie oznacza, że wszystkie te sposoby są dobre.
Po dłuższej, kilkumiesięcznej przerwie usiadłem do pisania kolejnego poradnika i oczywiście po raz kolejny mi się TO zdarzyło – zamiast kliknąć „Zapisz szkic” opublikowałem niedokończoną wersję. Tym razem skłoniło mnie to jednak do poszukania wtyczki, która następnym razem złapie mnie za rękę. Taką wtyczką jest właśnie Confirm Publishing Actions.
WordPress jest napisany bardzo pragmatycznie i ścieżka uczenia się go nie jest stroma. Dlatego dla wielu osób stanowi początek drogi do programowania. Taka, niezbyt systematyczna nauka, metodą prób i błędów, ma swój urok, ale powoduje, że serwisy wordpressowe tworzą często programiści, którzy nie mieli skąd nabyć dobrych nawyków. Nie znają programistycznych „zasad BHP” – bo co prawda programista nie musi chodzić w kasku, ale przez swoją niefrasobliwość, może narazić siebie i innych na poważne kłopoty.
Kiedy jesteśmy zalogowani do serwisu opartego na WordPressie przy górnej krawędzi przeglądarki widzimy pasek administratora (Toolbar, dawniej Admin bar). Zawiera on linki, a czasem informacje, które warto zawsze mieć pod ręką, również wtedy kiedy przeglądamy strony serwisu, a nie strony administracyjne. Do tego paska łatwo możemy dodawać własne przyciski, a nawet całe menu, niektóre z nich możemy obsługiwać AJAXem.
Są zagadnienia w WordPressie, do których napisano dziesiątki wtyczek, a mimo to czasem warto oprogramować je po swojemu. Czasem tak jest po prostu łatwiej, bardziej wydajnie i masz do dyspozycji znacznie większe możliwości. Oczywiście pod warunkiem, że potrafisz programować. Jednym z takich zagadnień jest wyświetlanie różnych sidebarów (różnych zestawów widgetów) na różnych stronach serwisu.
WordPress załatwia za nas masę spraw automatycznie. W zależności od szablonu strony, który programujemy, zaczytywane są wpisy właściwego typu, formatu, z odpowiedniego zakresu dat, odpowiednio posortowane. Najczęściej tego właśnie potrzebujemy, czasem jednak chcemy coś zmienić. Nieocenionym hakiem jest w takich wypadkach pre_get_posts.
Kiedy wychodził WordPress 3.1 niezwykłą popularność uzyskały serwisy mikroblogowe, wznosiła się wielka fala Facebooka, ogromną popularność uzyskał serwis Thumblr, który starał się łączyć blogowanie z mikroblogowaniem, a wszyscy przepowiadali (po raz kolejny) zbliżający się koniec blogowania w starym stylu.
Nie mogę się nadziwić jak wiele osób na co dzień tworzących serwisy internetowe, albo nie słyszało nigdy o Responsive Web Design, albo zignorowało go jako jedną z wielu nowinek o przeciętnym znaczeniu. Tymczasem to jeden z najważniejszych konceptów jakie się pojawiły w ostatnich latach i coś, czego niewątpliwie wszyscy będą musieli się nauczyć.
Kiedy tworzymy własną wtyczkę, zwykle będzie ona miała jakieś strony ustawień. Jeśli są skomplikowane, a sama strona jest wypełniona opcjami, lepiej nie zaśmiecać jej przesadną ilością opisów. Powinniśmy wykorzystać nowe możliwości, które pojawiły się w WordPressie 3.3. Nowa klasa WP_Screen umożliwia tworzenie zgrabnych ekranów pomocy oraz opcji ekranowych.
Pojawił się już WordPress 3.4 RC2, czyli drugi kandydat do wersji finalnej. Na początku przyszłego tygodnia planowane jest jej wydanie. Dokonano jeszcze kilkudziesięciu zmian, głównie poprawek. To ostatnia chwila dla developerów wtyczek i motywów aby sprawdzili kompatybilność swojej pracy z nową wersją WordPressa.
