Na początku chce zauważyć, iż sami używamy „kochanego” WordPress’a. Jako platforma blogowa sprawia się bardzo dobrze o ile na rynku są potrzebne wtyczki. Jeżeli ich nie ma to zaczynają się schody niestety.
Ostatnio miałem przyjemność pisania kilku modyfikacji i jednej wtyczki. Niestety strasznie zniechęciłem się. Zaczniemy od spraw technicznych.
W tabeli comments istnieje kolumna comment_author_IP, której typem jest varchar(100). Jak się domyślacie rozchodzi się o jej typ i długość. W czasach kiedy nie było IPv6 wystarczał varchar(15) i też nie do końca było to prawdą. Dlaczego? Ano dlatego, że optymalnie i wygodnie jest trzymać tą informacje w postaci int! Dla przykładu w MySQL wystarczy UNSIGNED INT + ip2long() i sprawa załatwiona.
Lecimy dalej odnośnie źle zaprojektowanej bazy danych jednej z największych dostępnych platform blogowych na świecie. W tabeli posts mamy kolumnę post_status. Z tego co mi wiadomo może ona przyjąć jedną z kilku możliwych opcji: draft, publish, pending, future oraz private. Całkowicie nie rozumiem dlaczego jej typem jest varchar(20). Np. w MySQL udostępniony jest specjalny typ ENUM() idealnie nadający się do takich sytuacji. Kolejną sprawą jest dokumentacja. Oceniam ja na 6,5 w dziesięciostopniowej skali.
Z poziomu edytora szablonu chciałem zobaczyć do czego służy funkcja get_template_part() i zostałem przeniesiony tutaj zamiast do prawidłowego adresu czyli tutaj.
Apropo dokumentacji to spróbujcie znaleźć w dokumentacji miejsce, w którym jest fragment kodu odpowiedzialny za filtrowanie i ustawianie menu dla funkcji wp_list_pages(). Mowa o argumencie exclude. Jeżeli występuję to w następstwie tego zostanie „wykonany telefon” do funkcji apply_filters(), której pierwszym parametrem będzie ciąg wp_list_pages_excludes. W API nie ma nigdzie mowy gdzie można kod tego filtru znaleźć. Literówki w tłumaczeniach pomijam bo zostały zgłoszone i obiecano mi, że zostaną poprawione.
Teraz drodzy czytelnicy wyjaśnijcie mi jak osoby niewidome mają skorzystać z możliwości ustawienia widgetów opartej na mechanizmie drag and drop? Nie widzę innej możliwości niż pomoc zewnętrznej osoby. To samo tyczy się ostatnio wprowadzonego wp_nav_menu()!
Według mnie powinna zostać udostępniona alternatywna metoda zarządzania takimi menu podobna do mechanizmu zarządzania kategoriami na forach dyskusyjnych typu phpBB, IPB, etc. Teraz wyobraźcie sobie sytuacje, w której klient żąda sortowanego według jego widzimisię. Ponadto wszystkie inne kategorie, w których się nie znajduje maja być zwinięte. Właśnie dlatego musiałem pisać wtyczkę. Nie wiem dlaczego brakuję parametru exclude w wyżej wymienionej funkcji. Najwyraźniej autorzy WP maja zbyt płytką wyobraźnię.
Ponadto mechanizm obrabiania danych przychodzących z interfacu zarządzania menu jest strasznie wolny i mocno obciąża maszynę! Wystarczy 300 pozycji w menu i trwa to wieczność… Dodawanie nowych pozycji do menu jest totalnie zbugowane w Operze. Dla przykładu paska przewijania nie da się ruszać jeżeli nie używamy strzałek. Ponadto search input blokuję się jeżeli dodaliśmy coś z checkbox listy. Postaram się na dniach nagrać film. Jeżeli komuś jest mało, to wspomnę tylko, że przy 300 elementach mechanizm drag and drop strasznie laguje w Operze. W innych przeglądarkach jest nieco płynniej natomiast zajmuje on stanowczo za dużo pamięci!
Wracając do kwestii IP. Nie wiem czy wiecie ale w WP jest mechanizm antyfloodowy i jeżeli dodamy zbyt dużo komentarzy z jednego IP to przez jakiś okres czasu nie będziemy mogli z niego dodać IP. Osobiście jak spotkam ciekawy blog to lubię komentować od góry do dołu wszystkie wpisy. Niestety ten bajer mi tylko utrudnia. Pół biedy jeżeli byłaby możliwość konfigurowania ilości komentarzy z danego IP przez określony czas. Niestety takiej opcji nie ma.
Na koniec wspomnę tylko, że aktualnie defaulowym szablonem proponowanym przez WP jest twentyeleven. Wszystko byłoby w porządku gdyby nie posiadał on kilku usterek powodujących błąd validatora. Grunt to pokazać się od złej strony.
Na koniec napomknę tylko o kilku różnych standardach kodowania. Można to zaobserwować jak obrabia się argumenty w starych i nowych plikach. Całkiem inny styl pisania. Jak się ustala standardy kodowania to powinny być jednolite dla każdego pliku i tego powinno się trzymać.
Ciężko się nie zgodzić z tym co napisałeś w tym wpisie. Gdy brałem się za wordpress myślałem, że skoro jest taki popularny to musi to być jakaś perełka programistyczna. Pierwszy plik który przejrzałem to był plik instalacyjny i przyznaję, że byłem zaskoczony kilkoma sprytnymi rozwiązaniami. Niestety dalej to już była jakaś tragedia, jakieś dziwne funkcję wp_head , wp_footer, get_head, get_footer. Wszędzie jakieś funkcję które się wzięły nie wiadomo skąd. W połowie funkcji jakieś dziwne parametry, często trzeba je podawać w zserializowanej postaci itp. No i mieszanie kodu html z php 🙁
Może taka budowa jest dobra dla ludzi którzy nie ogarniają OOP w połączeniu z MVC. Ale tak jak dla mnie to ja w tym pracować nie potrafię – a przynajmniej nie szybko 🙂
O ile mieszanie PHP z HTML’em nie jest złe to resztę można zaliczyć do złych nawyków. Oczywiście musimy rozgraniczyć logikę aplikacji od warstwy widoku. Mówiąc stricte o PHP to nic nie może być szybsze od niego (mam na myśli systemy szablonów). Dodajmy do tej receptury cache i niektórym można zrobić niezły kogel-mogel w mózgu. Ja nie jestem przeciwnikiem łączenia PHP z HTML’em o ile dane mamy już przygotowane i przekazane np. w tablicy bądź obiekcie.
Nie będę pisał dłuższego opowiadania o WP, Joomla, IPB, phpBB i tak dalej 🙂 Liczy się progres jaki jest wypracowywany.
Nie podoba mi się przerost formy nad treścią i na siłę wciskanie MVC tam gdzie jest on niepotrzebny. Jest tyle pięknych wzorców (np. MVP, MVVC i tak dalej). Na forumweb.pl prowadziliśmy poniekąd ciekawe dyskusje na ten temat.
Ja już to dawno temu mówiłem i powiem jeszcze raz. W celu zwiększenia wydajności potrzebna jest prekompilacja rzeczy, które w skrypcie się nie zmieniają.
Cały ten temat jest na kilka godzin rozważania 🙂