Wiele osób narzeka na dosyć uciążliwy błąd w skrypcie WordPressa uniemożliwiający wylogowanie się z poprzez kliknięcie odpowiedniego linka w niektórych miejscach strony, takich jak panel administracyjny i formularz dodawania komentarza. Na oficjalnej stronie systemu, tudzież znajdujących się tam forach są pewne informacje na temat problemu, użytkownicy próbują sobie pomóc, jednak skuteczność rozwiązań [mierzona na podstawie wypowiedzi i nastrojów samych zainteresowanych] bynajmniej nie jest stuprocentowa. Nie lubię kiedy jakakolwiek funkcjonalność nie działa, nawet jeśli z niej nie korzystam - postanowiłem więc, że zrobię mały rekonesans, sprawdzę co dolega Wordpressowi i dowiem się jak to naprawić.

Wpisy dotyczące języka C++ pojawiają się dosyć rzadko na moim blogu, pomimo tego, iż uważam go za najwspanialszy język w jakim miałem okazję pisać kod [a trochę ich już poznałem]. Tym razem pomysł na kolejnego posta wpadł mi do głowy niepostrzeżenie podczas tradycyjnej, oczywiście nocnej, sesji programistycznej. Ze względu na czytelność [i jak zwykle wydajność ;]] produktu końcowego, zdecydowałem podczas projektowania, że będę korzystał z instrukcji switch zamiast serii else-if’ów. Zadowolony z upieczenia “dwóch pieczeni na jednym ogniu” przystąpiłem więc do konwersji moich pomysłów na formę binarną.

Tak jak, obiecałem [no dobra, trochę czasu już minęło ;]], opisuję dziś pierwszy z wymienionych wcześniej rodzajów systemów uprawnień w aplikacjach internetowych, pt. “typy użytkowników / obszary dostępu”. Jest to dosyć proste rozwiązanie, aczkolwiek sprawdza się bardzo dobrze w wielu przypadkach, ze względu na prostotę implementacji i łatwość w administrowaniu nawet bardzo dużymi bazami danych użytkowników. Polega ona na podzieleniu użytkowników strony na dwa typy:

• użytkownik - internauta przeglądający stronę, bez możliwości ingerencji w jej treść.
• administrator - użytkownik "uprzywilejowany", posiadający oprócz możliwości przeglądania także prawa edycji treści.

Klasycznym zastosowaniem są strony internetowe oparte o proste systemy zarządzania treścią [CMS] pozwalające na dodawanie i edycję podstron za pomocą jednego z popularnych edytorów WYSIWYG [FCKeditor, TinyMCE]. Z pomocą takiego systemu można stworzyć np. niezbyt skomplikowaną witrynę informacyjną lub własną wizytówkę internetową.

Na fali ogólnego zainteresowania nowym produktem Google, czyli platformą Wave, w Internecie zawrzało, ponieważ nagle każdy chciał mieć dostęp do tego serwisu, każdy chciał zobaczyć, dlaczego Internet, a szczególnie sposób komunikacji, jaki znamy dzisiaj, zostanie całkowicie przeobrażony, powodując, że wszystkie sposoby porozumiewania się w sieci, z których korzystaliśmy dotychczas, przestaną być już potrzebne. Początkowo podchodziłem dosyć sceptycznie do całego zamieszania, ale w końcu ciekawość przeważyła i korzystając z pomocy znajomych otrzymałem maila z zaproszeniem.

Parę dni temu wygrzebałem w sieci kolejny przykład ciekawego zastosowania [X]HTMLa, CSSa i JavaScriptu, otóż pewien programista postanowił wykonać zegarek cyfrowy, w którym elementy cyfr [“belki”] są wyświetlane za pomocą nie mieszczących się w swoich kontenerach elementów , a konkretnie za pomocą pasków przewijania które tworzą się przez rozciąganie ich w kontenerach. Co tu dużo mówić - trzeba zobaczyć. ;] Dla wnikliwych - polecam uruchomienie wtyczki WebDeveloper i wybranie opcji “Zaznacz” > “Zaznacz elementy blokowe”, widać wtedy dokładnie jak to wszystko działa, bez patrzenia do kodu można podziwiać geniusz tego pomysłu.

Wordpress jest bardzo przyjazną użytkownikowi i całkiem potężną platformą blogową, naprawdę do niewielu rzeczy można się w tym systemie “przyczepić”. Nie zmienia to jednak faktu, że pewne rzeczy wymagają dopracowania, a co najmniej ponownego przemyślenia. Jedną z takich “uciążliwości” jest zapisywanie postów do późniejszego sprawdzenia / przeredagowania / edycji. W momencie bezpośredniego zapisania poprzez użycie przycisku “zapisz szkic” [ang. “save draft”] i późniejszej publikacji [późniejszej, czyli co najmniej jeden dzień po napisaniu szkicu] ze zdziwieniem możemy stwierdzić - “a co to za dziwna data?”. Otóż, w momencie pierwszego zapisu data publikacji jest już ustawiona “na sztywno” w bazie danych i nie da się jej zmienić inaczej, niż przez edycję jednej z kolumn odpowiedniego rekordu w tabeli wp_posts. Przyznacie sami, że to zachowanie jest nieco nielogiczne, jednak twórcy uważają inaczej.

Parę dni temu miałem dosyć uciążliwy problem z wtyczką SyntaxHighlighter Evolved. Działała idealnie aż do momentu aktualizacji do wersji 2.3.0 - wtedy zaczęły dziać się dziwne rzeczy związane z wyglądem pokolorowanego kodu. Każda linia “utyła” w pionie o jakieś 70 pikseli, co powodowało rozciągnięcie niektórych artykułów zawierających dużo tego typu wstawek na kilkadziesiąt ekranów. Przygotowana “na gorąco” modyfikacja arkusza stylów CSS tymczasowo przywróciła wygląd do stanu przypominającego ten poprzedni, nie udało mi się jednak znaleźć na żadnych konkretnych informacji w internecie, które zawierałyby kompletne rozwiązanie.

Trafiłem dzisiaj na interesujący artykuł w serwisie SmashingMagazine, o bardzo zagadkowym tytule: “The death of the blog post”. Jest on poświęcony procesowi tworzenia i wyglądu treści na blogach, a konkretnie względnie małej kreatywności w tej dziedzinie, co autor uważa za nudne i odrzucające użytkowników od strony. Cóż, niełatwo byłoby się dostosować do zaleceń w stylu “oddzielny layout dla każdego wpisu”, niemniej jednak reszta tekstu jest bardzo pouczająca. Mój blog ma trochę inny charakter “pokazania się”, ponieważ wolałbym, jako programista zabłysnąć raczej tworzoną treścią, wartością merytoryczną wpisów, a nie wyglądem, chociaż wygląd też nie jest chyba taki zły, no, może trochę za mało kolorowy, ale wybraną kolorystykę już wyjaśniałem w jednym z poprzednich wpisów.

Ze względu na to, że jestem w trakcie tworzenia biblioteki która ma zamiar w przyszłości ujrzeć światło dzienne i powiedzieć “hello, world” na ekranie [mam nadzieję] wielu programistów i użytkowników końcowych, pomyślałem o tym, żeby w końcu zająć się napisaniem stosownej dokumentacji do projektu. Przez długi czas w moim kodzie funkcjonowały przeróżne komentarze opisujące mniej lub bardziej dokładnie “co się w danym miejscu dzieje”, ale były to bardziej opisy dla mnie, jako twórcy rozumiejącego cel i działanie poszczególnych elementów, niż dla kogoś, kto miałby w przyszłości korzystać z tego produktu. Pomyślałem więc [w “międzyczasie” zmuszając się do odrzucenia standardowego podejścia w stylu “dlaczego miałbym korzystać z rozwiązań zewnętrznych, skoro sam mogę stworzyć generator dopasowany do moich wymagań?”], że należałoby znaleźć dobre narzędzie pozwalające na stworzenie dokumentacji na podstawie kodu źródłowego w łatwy i w miarę przyjazny sposób.

Z kategorii “czego to ludzie nie wymyślą”: [ link ]. Pomysł jest genialnie prosty - na stronie umieszczone są dwa odtwarzacze wideo z YouTube oraz pole do wyszukiwania utworów w serwisie. Pomiędzy nimi znajduje się crossfader którym możemy regulować natężenie dźwięku pochodzącego z obu filmów. Skrypt JavaScript pobiera informacje o położeniu suwaka, przelicza stosunek lewy / prawy i ustawia odpowiednio głośność w każdym z odtwarzaczy. Kariera DJa stanęła własnie otworem przed milionami internautów.