Tag: plugin

Edycja danych ‘inline’ dzięki Jeditable i jQuery

Jeditable to bardzo fajny plugin do jQuery dzięki któremu można stworzyć mega szybką i prostą edycję danych bez przeładowania. Działa to tak, że np. blok tekstowy objęty odpowiednim <div> po kliknięciu zamienia się w <textarea>, następnie tekst w nim zawarty można edytować i zapisać.

Instalacja i korzystanie z Jeditable jest banalne. Trzeba zaincludować bibliotekę jQuery, plugina Jeditable oraz nałożyć odpowiednią klasę na edytowalny tekst i to wszystko. Aby zmienione dane zapisywały się oczywiście trzeba odpowiednio zaprogramować back-end.

Przejdź na stronę Jeditable oraz zobacz podstawowe przykłady i zaawansowane przykłady.

FirePHP – przyjazne debug’owanie aplikacji internetowych

Debugowanie to poważny problem programistów

Bez względu na to jakimi dobrymi programistami jesteśmy nigdy nie ustrzeżemy się błędów. To normalne, błędy popełnia każdy, różnica pomiędzy dobrym programistą a złym polega m. in. na szybkości wykrycia błędnego kodu i naprawienia go.

Mówiąc o błędnym kodzie nie mam na myśli jedynie błędów syntaktycznych, ale również błędów logicznych, które nie powodują widocznych error’ów a jedynie błędne działanie aplikacji. Takie błędy są dużo trudniejsze do wykrycia.

Aby wykryć błędny kod niezbędne jest zdebugowanie zmiennych, obiektów, zasobów, które wykorzystywane są w tworzonej przez nas aplikacji. Brzmi banalnie, jednak w rzeczywistości nie jest to takie łatwe gdyż:

  • po pierwsze trzeba wstawić w odpowiednie miejsca funkcje var_dump() lub print_r()
  • po drugie funkcje te nie wyświetlają przejrzyste i łatwe do zinterpretowania dane
  • po trzecie debug’owanie na ekran może spowodować błędy aplikacji, a debugowanie do pliku jest niewygodne w odczycie (szczególnie w przypadku aplikacji flash’owych lub AJAX’owych)
  • po czwarte zdarza się, że format zwracanych danych uniemożliwia swobodne dodawanie własnych danych do debugowania (np. XML, JSon).
  • po piąge po skończeniu debugowania trzeba usunąć wszystkie instrukcje debugujące

Rozwiązaniem problemu debugowania jest FirePHP

Dużo tych wad… całe szczęście jest na to rozwiązanie. FirePHP to darmowa, open source’owa biblioteka, która wraz z pluginem do Firebug’a idealnie sprawdza się w roli debugera.

FirePHP debuguje dane w konsoli Firebug’a, informacje do debugowania są umieszczone w specjalnych nagłówkach HTTP przez co 'output’ aplikacji pozostaje w nienaruszonym stanie. Rewelacja prawda?

Instalacja firePHP

Wymagania FirePHP to PHP 5.2+, Firefox z pluginem Firebug.

  • Instalujemy plugina do firefox’a Firebug
  • Instalujemy plugina do Firebug’a FirePHP
  • Ściągamy źródła FirePHP, warto zauważyć, że na stronie dostępne są informacje, jak zintegrować bibliotekę z wieloma znanymi frameworkami (CakePHP, CodeIgniter, Drupal, Kohana, ExpressionEngine, PRADO, Symfony, TYPO3, Zend Framework).
  • Integrujemy FirePHP z naszą aplikacją
  • Odpalamy stronę aplikacji w Firefox z uruchomionymi plugin’ami Firebug i FirePHP
  • Klikamy na ikonę Firebug’a a następnie przechodzimy do konsoli. W konsoli powinny być zaprezentowane zdebugowane zmienne naszej aplikacji.
  • W przypadku problemów przydać się mogą: mini tutorial how to, forum dyskusyjne o FirePHP.

Przykład działania

Pod adresem http://blog.adiasz.pl/examples/firephp/ stworzyłem prosty skrypt AJAX’owy łączący się z bazą i wykonujący prościutkie operacje. Jest zintegrowany z FirePHP, zachęcam do testów. Naprawdę warto! (Oczywiście musicie najpierw zainstalować plugin FireBug i FirePHP). Wszystkie pliki wykorzystane w tym przykładzie dostępne są tutaj.

Przykład powinien zaprezentować coś w stylu:

Na koniec, bardzo ważna informacja: po opublikowaniu projektu musicie wyłączyć debugowanie FirePHP poprzez dyrektywę:

$fp = FirePHP::getInstance( true );
$fp->setEnabled ( false );

W przeciwnym razie każdy internauta posiadający zainstalowany ten plugin będzie miał dostęp do niebezpiecznych z punktu bezpieczeństwa danych. Najlepiej w konfigu aplikacji sterować to poprzez zmienną typu boolean $development = true/false. Samych instrukcji debugujących nie trzeba kasować gdyż nie wiadomo kiedy się jeszcze przydadzą.

ps. FirePHP dostępne jest także dla innych niż PHP języków programowania aplikacji webowych: ASP, Python, Ruby.

WP-Cache – rozwiązania problemów z semget i działaniem

WP-Cache to bardzo przydatny plugin do Word Press’a. Plugin ten zapisuje każdą wygenerowaną stronę w postaci statycznego pliku HTML na serwerze przez co znacznie zmniejsza obciążenie serwera i bazy danych. Długość cache, jak i reguły opisujące pliki/strony, które mają być cache’owane można ustawić z poziomu panelu WP.

Ostatnio zetknąłem się z dwoma problemami w użytkowaniu tego plugina, poniżej rozwiązania:

Problem 1:
Za każdym razem, gdy strona generowana jest po raz pierwszy pojawia się komunikat w górze strony:

Warning: semget() failed for key 0x152b: Permission denied in /XXX/wp-content/plugins/wp-cache/wp-cache-phase2.php on line 98

Rozwiązanie:
Trzeba zedytować plik: wp-content/plugins/wp-cache/wp-cache-phase2.php w linii 98:
zamienić:

$mutex = sem_get($sem_id, 1, 0644 | IPC_CREAT, 1);

na

$mutex = @sem_get($sem_id, 1, 0644 | IPC_CREAT, 1);

Znak @ przed funkcją php blokuje komunikaty o błędach, spowodowanych daną funkcją.

Alternatywą tego rozwiązania jest dopisanie

ini_set( 'display_errors', 0 );

w pliku wp-config.php W tym wypadku zablokujemy wyświetlania się komunikatów o błędach globalnie w całym Word Press’ie.

Problem 2:
WP-Cache jest poprawnie zainstalowane, włączone, jednak strony się nie cache’ują.

Sprawdz czy w katalogu wp-content znajduje się plik

!advanced-cache.php

Jeżeli tak to oznacza, że WP-Cache ma źle podlinkowany plik wp-cache-phase1.php

Rozwiązanie:
Najpierw należy skasować plik !advanced-cache.php.

Następnie przypadku gdy mamy dostęp ssh trzeba z poziomu katalogu wp-content wykonać polecenie unix’owe, które stworzy link symboliczny do tego pliku wykorzystywany przez skrypty WP:

ln -s   plugins/wp-cache/wp-cache-phase1.php advanced-cache.php

Gdy nie mamy ssh musimy zainstalować wtyczkę jeszcze raz (zdeaktywować i aktywować).

Amazon s3 – sposób na tani hosting plików aplikacji.

Amazon s3 (Simple Storage Service) jest usługą online, która umożliwia składowanie danych na przestrzeni dyskowej serwerów Amazon. W zależności od potrzeb, dane mogą być składowane w USA bądź też w Europie. Usługa s3 wyposarzona jest w API dzięki któremu w prosty sposób można operować na składowanych zasobach.

Usługa ta jest niesamowicie tania, opłaty pobierane są od:

  • zajmowanego miejsca – $0.18 za 1GB / miesiąć
  • zużytego transferu – $0.10 za 1GB transferu IN, $0.10 – $0.17 za 1GB transferu OUT
  • liczby request’ów – $0.012 za 1,000 request’ów PUT, POST, LIST, $0.012 za 10,000 requesty GET i wszelkie inne

Jak widać opłaty są śmiesznie niskie, w przypadku serwisu posiadającego duże ilości multimediów (zdjęcia, wideo etc..) i generującego spory ruch dużo taniej wyjdzie korzystanie z s3 niż korzystanie z jakiegokolwiek hostingu.

Dzięki kalkulatorowi możemy zaplanować i przewidzieć przyszłe koszta i tak możemy wyliczyć, że miesięczny koszt przetrzymywania 10GB i 100GB tranferu kosztować będzie w okolicach $17. Tanio prawda?

Dodatkowo korzystając z usługi Amazon nie trzeba martwić się o utratę danych, bądź ich czasową niedostępność. Infrastruktura s3 jest naprawdę znakomita, jak do tej pory nie było żadnych przypadków przerw w działaniu, a szybkość działania jest naprawdę imponująca.

Jak korzystać?

Aby zacząć korzystać z s3 należy utworzyć konto a następnie aktywować usługę poprzez autoryzację karty kredytowej. Polecam zaznajomić się z obszernym artykułem opisującym filozofie działania Amazon Web Services.

Powstało wiele bibliotek ułatwiających pracę z API s3, na wyróżnienie zasługuje class.s3.php.
Poniżej prościutki przykład użycia tej klasy:

//tworzymy obiekt klasy s3 przekazując identyfikatory naszego konta
$s3 = new S3($AMAZON_KEY, $AMAZON_PRIVATE_KEY);

//tworzymy folder
if( !$s3->bucketExists( 'FOLDER' ) ) {
	$result = $s3->createBucket( 'FOLDER' );
}

//wgrywamy plik
$result = $s3->putObject( 'FOLDER', 'DIST_FILE_NAME', 'PATH_TO_FILE', true );

//od tej chwili możemy się odwoływać do wgranego pliku poprzez http
//http://s3.amazonaws.com/FOLDER/DIST_FILE_NAME

//odczytujemy informacje wgranego obiektu
$objectData = $s3->getObjectInfo( 'FOLDER', 'DIST_FILE_NAME' );

if( !$result ) {
  print $s3->_error ;
}

//kasowanie elementow folderu
$s3->recursiveDelete( 'FOLDER', '' );

Uwaga, klasa ta wymaga dostępu do curl’a bash’owego.
W przypadku gdy funkcja shell_exec() jest zablokowana należy skorzystać z innej biblioteki np. phps3tk.

update 2008-12-19:
Znalazłem bardzo przydatny plugin do Firefox’a Amazon S3 Firefox Organizer(S3Fox), który umożliwia zarządzanie danymi na Amazon s3 z poziomu przeglądarki.

Plugin S3Fox umożliwia praktycznie wszystkie operacje na Amazon S3 jakie udostępnia API: przeglądanie, tworzenie/kasowanie/modyfikowanie folderów, wgrywanie i kasowanie zasobów oraz zarządzanie prawami dostępu do danych.

Dodatkowo generuje log z wykonanych czynności oraz wiele ułatwień. Dzięki niemu możemy przetestować poprawność naszych mechanizmów php’owych, oraz w przypadku jednorazowego upload’u zaoszczędzić czas na pisanie skryptów.

Strona domowa projektu S3Fox.

Działanie response w FireBug

Co to jest Firebug nie będę wyjaśniał, każdy webdeveloper powinien wiedzieć o co chodzi. W dwóch słowach: jest to bardzo przydatny plugin do Firefoxa umożliwiający m.in wyświetlenie wszystkich request-ów wygenerowanych przez wygenerowaną stronę. Dotyczy to zarówno żądań wygenerowanych przez odwołania do obrazków, css-ów jak i żądań wygenerowanych przez skrypty javascript-owe i flash-owe. (inspect->net-all)

Przy każdym requescie można podglądnąć 'response’ – czyli odpowiedź skryptu na wysłane żądanie. Jest to szczególnie przydatne w przypadku debugowania serwerowych skryptów aplikacji, które dostarczają dane skryptom działającym po stronie przeglądarki (np. javascript, flash).

Ale uwaga! Należy pamiętać, że w momencie gdy w Firebugu przy danym requescie klikniemy na response to prezentowany response niestety nie jest tym oryginalnym tylko skrypt, którego dotyczy jest wywoływany ponownie.

Wszystko byłoby fajnie gdyby nie to, że niektóre skrypty serwerowe wykonują operacje, które nie można powtórzyć (np. INSERTy, DELETy w bazie) i w takim przypadku kolejne wywołania zwrócą już błędne dane. W takim wypadku jedyna sensowną opcją debugowania pozostaje zapis do pliku. Nie jest to niestety zbyt przyjazna metoda, ale cóż…jedyna skuteczna.