poniedziałek, 25 maja 2015

[APACHE][mod_rewrite] Reguły, warunki i atrybuty - tworzymy pierwsze praktyczne przekierowania

TRUE
3468871533248841170
W poprzedniej części, czyli we wstępie określiliśmy sobie czym jest mod_rewrite, na co mniej więcej pozwala i jak wygląda przykładowa reguła przepisywania adresu. W tym odcinku nauczymy się tworzyć bardziej zaawansowane reguły, które pozwolą już na w pełni określone działanie naszych adresów. Przy okazji opiszę tutaj kilka standardowych problemów wraz z rozwiązaniami jak sobie z nimi radzić, gdyż mod_rewrite do poprawnego działania wymaga kilku "tricków". Nauczymy się też testowania stworzonych reguł oraz przeanalizujemy atrybuty reguł oraz dostępne w mod_rewrite zmienne.

Na początek małe przepomnienie - reguły określone w pliku .htaccess działają na folder, w którym plik ten się znajduje oraz na wszystkie jego podfoldery (o ile w danym podfolderze nie umieścimy kolejnego .htaccess nadpisującego reguły z pliku nadrzędnego). Na potrzeby tego poradnika nasz .htaccess umieszczamy w katalogu głównym naszego serwera. Przy okazji mały tip: nazwę pliku .htaccess można zmienić na inną dowolną, np. na "config" - określa się to w konfiguracji Apache'a, radzę jednak pozostać przy domyślnej nazwie, żeby trzymać się standardów.

Środowisko testowe

Na potrzeby nauki powinniśmy przygotować sobie jakieś środowisko testowe.
Moją propozycją jest utworzenie wirtualnego hosta na naszym lokalnym serwerze, tak abyśmy do testowanej strony mieli dostęp z poziomu subdomeny:

[code]rewrite.localhost[/code]

Głównym katalogiem (DocumentRoot) dla vhosta niech będzie np.
[code]/NASZ_GŁÓWNY_KATALOG_Z_WWW/rewrite/[/code]
i to na niego przekierujemy subdomenę 'rewrite'.
Jak stworzyć vhosta opisałem w tym artykule.

niedziela, 24 maja 2015

[APACHE][mod_rewrite] Wstęp do przepisywania URL-i

TRUE
5422605052919904069
Mechanizm przepisywania URL-i za pomocą modułu rewrite z początku może wydawać się nieco skomplikowany. O ile nauczenie się podstawowych regułek przepisywania i wykorzystanie ich w praktyce nie stanowi zbyt dużego problemu, to niestety, ale prędzej, czy później natrafimy na kilka problemów związanych z regułami przekierowań, na pewno też nie raz i nie dwa "zapętlimy się" przy co bardziej rozbudowanej hierarchi regułek. W artykułach tutaj postaram się przedstawić najczęstsze problemy z jakimi prawie na pewno spotkamy się podczas tworzenia plików .htaccess. Omówię też same podstawy tworzenia takich przekierowań. Zacznijmy więc może od początku - czym jest mod_rewrite? Jest to moduł serwera Apache, ktory za pomocą odpowiednio określonych warunków (conditions) wywołuje zadaną przez nas regułę (rule), która w dany, określony sposób dokonuje przekierowania z jednego URL-a na inny, zdefiniowany przez nas. Reguły takie określamy w specjalnym pliku o nazwie '.htaccess', który umieszczamy w folderze, dla którego zawarte w nim reguły mają obowiązywać (będą też obowiązywać dla jego podfolderów). Plik '.htacccess' ma ściśle określoną strukturę, składającą się z kilku sekcji. Omówimy je kilka akapitów niżej. Na razie omówmy samą zasadę przepisywania URL-i, a więc - na czym to wszystko polega?

Wyobraźmy sobie, że mamy przygotowaną w PHP aplikację, np. sklep internetowy.
W aplikacji tej posiadamy system kategorii i podkategorii naszych produktów, listę tych produktów, oraz odpowiednie sekcje odpowiadające za wyświetlanie informacji o zadanym produkcie.
Po sklepie tym poruszamy się w jakiś określony sposób definiujący nam np. gdzie obecnie się znajdujemy (czy np. w widoku listy kategorii, czy produktów) oraz jaką kategorię lub produkt obecnie wyświetlamy. Informacje takie przekazujemy zazwyczaj jako parametry w adresie, np.
[code]http://nasz_sklep.com/index.php?action=category&id=20[/code]
lub
[code]http://nasz_sklep.com/index.php?action=product_info&id=45[/code]

Brzydkie prawda? A i niezbyt chętnie indeksowane przez wyszukiwarki.
O wiele ładniej wygladałoby to, gdyby linki przedstawiały się np. tak:
[code]http://nasz_sklep/kategorie/telewizory[/code]
lub
[code]http://nasz_sklep/produkt/Samsung_Smart_LED_J6200.html[/code]

[PHP] Namespaces - przestrzenie nazw w PHP

TRUE
2394048099834356901
Zapewne spotkaliśmy się już z dziwnie wyglądającymi nazwami klas w PHP, np. podczas pracy z frameworkami, takimi jak Symfony. Przykładowa nazwa klasy mogła wyglądać np. tak: 'Bundle\HelloBundle\Controller\HelloController'. Nie ma tu jednak żadnej pokręconej magii, a jedynie przestrzeń nazw. Klasa w tym przypadku to 'HelloController', a wszystko to co znajduje się przed nią to jej przestrzeń nazwowa. Korzystanie z przestrzeni nazw znacznie usprawnia pracę z kodem, a także eliminuje problem kolizji, gdzie dwie klasy mogą mieć identyczne nazwy. Pozwalają one również na stworzenie bardzo fajnej i przejrzystej hierarchi naszego kodu. W tym krótkim tutorialu dowiemy się czym są i jak  poprawnie używać przestrzeni nazw w PHP. Funkcjonalność ta niczym nie różni się od tego samego rozwiązania stosowanego od zarania dziejów w językach takich jak C, czy Java. Przestrzenie nazw w PHP zostały dodane w wersji 5.3.

Przestrzeń globalna

Jest główną przestrzenią nazw. Zauważmy, że bardzo często piszemy sobie jakieś klasy, czy też funkcje, bądź też korzystamy z tych wbudowanych w silnik PHP.
Korzystamy np. z funkcji 'header()' służacej do ustawienia nagłówka, funkcji 'strip_tags()' służącej do obcięcia tagów HTML i wielu innych. Nazewnictwo tych funkcji jest proste i składa się z jednego członu określającego nazwę funkcji. Funkcje takie istnieją w domyślnej przestrzeni nazw i są dostępne wszędzie w naszym kodzie. Podobnie jest z klasami, ich metodami i właściwościami. Nie wymagają poprzedzania ich nazwy nazwą przestrzeni w jakiej występują, gdyż globalna przestrzeń jest tą domyślną, bazową. Wyobraźmy sobie teraz, że tworzymy własną klasę, np. niech to będzie klasa o nazwie:

[code]MyClass {}[/code]

sobota, 23 maja 2015

[TiP] Problem z "powiększonymi" stronami pod Firefoxem

TRUE
1141583650387242569
Używając Firefoxa od wersji 22 może się wydarzyć, że strony internetowe stają się nagle nienaturalnie powiększone. CTRL-0 nic nie pomaga w takich przypadkach, a problem wynika z ustawień systemowych, konkretnie z ustawień DPI przy większych rozdzielczościach ekranu, mniej więcej od FullHD 1080p wzwyż. Zauważyłem już narzekania ludzi, gdy okazywało się, że ich strona pomimo poprawnych CSS-ów nagle u kogoś innego wygląda jak kobyła. Jak temu zaradzić? Rozwiązanie jest proste: musimy wejść w "about:config" i znaleźć opcję "layout.css.devPixelsPerPx", a następnie ustawić jej wartość na "1.0" (domyślnie jest tam: "-1.0"). W Operze występuje podobne zjawisko, gdy mamy w systemie DPI większe niż 100%. W przypadku Opery, przy założeniu, że systemowo mamy 125%, ustawiamy domyślnego zooma na 75%. Wyświetli to realną wielkość strony.

piątek, 22 maja 2015

[GIT] Klonowanie repozytorium, zdalne repozytoria i klucze SSH

TRUE
7463796078999611238
Prawdziwą magią Gita jest możliwość współdzielenia kodu i praca zespołowa. W poprzedniej części nauczyliśmy się tworzyć własne repozytorium na lokalnym komputerze i pracy z nim, a teraz nauczymy się aspektów pracy z repozytoriami udostępnianymi przez innych programistów. Nauczymy się także w jaki sposób pracować na zdalnym repozytorium, hostowanym np. w serwisie GitHUB. Dowiemy się również na czym polega uwierzytelnianie i w jaki sposób tworzyć i korzystać z kluczy RSA, które będą wymagane np. do pracy z GitHUB-em.

1) GIT clone - czyli klonowanie repozytorium

Zapewne spotkaliśmy się z terminem "sklonuj repozytorium"
Wiele projektów/aplikacji udostępnianych na licencji Open Source udostępnia swój kod w serwisach takich jak GitHUB (GIT), czy Google Code (SVN).
Wiele z takich projektów jest również w taki sposób rozwijanych, gdzie każdy chętny może dodawać swoje własne funkcjonalności, czy poprawki do czyjegoś kodu. Na czym polega sklonowanie repozytorium? W skrócie polega ono na sklonowaniu go ;) A dokładniej - na naszym dysku tworzona jest LOKALNA KOPIA repozytorium, na której możemy dowolnie pracować, a po skończonej pracy możemy wrzucić wszystkie stworzone lokalnie zmiany do oryginalnego, głównego repozytorium na serwerze, z którego dokonaliśmy sklonowania - jeśli oczywiście posiadamy takie uprawnienia.

Co jeśli takich uprawnień nie mamy? Bo przecież zapewne domyślamy się już, iż żaden programista nie pozwoli nam na dowolną modyfikację jego kodu bez jego zgody. Jak więc to wygląda w praktyce? Otóż - jeśli pracujemy na nie swoim repozytorium, to wszelkie zmiany, które dokonamy w kodzie lokalnie możemy osobie zarządzającej wysłać i zasugerować. Właściciel repozytorium, lub osoba uprawniona dostaje wtedy informację z żadaniem/prośbą dołączenia naszego kodu, np. z poprawkami do głównej gałęzi repozytorium. Może taką prośbę zignorować, albo zaakceptować zmiany jakie wprowadziliśmy i dołączyć naszą proponowaną gałąź do gałęzi głównej projektu.

czwartek, 21 maja 2015

[GIT] Podstawy i praca z repozytorium

TRUE
6335671948737500847
Git to obok Subversion drugi najpopularniejszy system wersjonowania kodu. Pozwala na bardzo przyjemną i przejrzystą organizację kodu zarówno dla pojedyńczego programisty, jak i w projektach wieloosobowych. Podstawy obsługi Gita są łatwe do ogarnięcia - wystarczy nauczyć się logiki działania takiego podejścia do wersjonowania projektu oraz zaznajomić się z kilkoma pojęciami, jakie spotykać będziemy podczas codziennej pracy z Gitem. W artykule tym postaram się w skrócie wyjaśnić na czym polega praca z repozytorium Gita i jak efektywnie wykorzystywać możliwości jakie daje on programiście. Artykuł pisany jest pod kątem pracy pod Windowsem, ale pod Linuxem składnia poleceń Gita jest identyczna, jedynie sposób instalacji jest inny.

Największą zaletą Gita jest to, iż zawsze pracujemy na lokalnej roboczy kopii naszego kodu, a nie na nim samym bezpośrednio. Jest to niesamowite rozwiązanie, bo po pierwsze pozwala na pracę "offline", po drugie sprawdza się to świetnie w pracy zespołowej, (o pracy w teamie i o tym jak to wygląda napiszę po krótce w innym tekście).
Jak więc działa Git? Zasada działania z początku może wydawać się zagmatwana, ale po zrozumieniu jej wyda się Wam banalnie wręcz prosta. W Gicie pracujemy z naszymi plikami w folderze roboczym. Pliki te mogą być śledzone przez Gita, lub nie. A co to znaczy "śledzone"?
Znaczy to, że Git będzie je uwzględniał w swoim repozytorium i analizował wszelkie ich modyfikacje. Znaczy to też to, że pliki do repozytorium muszą być przez nas dodane.

Przyjrzyjmy się poniższemu diagramowi, który przedstawia możliwe statusy w jakich może znaleźć się każdy z plików naszego projektu:




[PHP][cURL] Podstawy cz.5 - obsługa przekierowań

TRUE
4123571317394950562
Bardzo często odwołując się do danego zasobu zostajemy przekierowani w inne miejsce często nawet tego nie zauważając. W przypadku takim wysyłany jest przez serwer kod statusu z klasy 3xx, mówiący o typie danego przekierowania. Przekierowania takie często sami tworzymy, w PHP wywołując funkcję header("Location: /przekierowanie/do/pliku"). Przekierowanie takie zwraca kod statusu '302 Found', zamiast '200 OK'. Kod '200 OK' wysyłany jest dopiero po nastąpieniu przekierowania do wywoływanego w 'Location:' pliku.  Biblioteka cURL domyślnie nie podąża za takimi przekierowaniami, a odbiera jedynie nagłówek informujący o istnieniu przekierowania. Aby zmienić zachowanie cURL-a i nakazać mu podążanie za takimi przekierowaniami, musimy ustawić następującą opcję:
[code]curl_setopt ($ch, CURLOPT_FOLLOWLOCATION, 1);[/code]

Przetestujmy to na przykładzie, najpierw z nieustawionym podążaniem za przekierowaniem, a potem z ustawionym. W folderze na serwerze, gdzie trzymamy nasze przygotowane w części pierwszej pliki 'client.php' i 'server.php' stwórzmy jeszcze jeden plik o nazwie:
[code]redirected.php[/code]

środa, 20 maja 2015

[PHP][cURL] Podstawy cz.4 - cookies

TRUE
8097816399849509347
Wysyłanie cookies może odbywać się dwukierunkowo, tj. serwer może w odpowiedzi zażądać utworzenia pliku ciasteczka w przeglądarce, jak i przeglądarka/cURL może wysłać do serwera informacje o ciasteczkach jakie są ustawione dla danej domeny. Ciasteczka oczywiście możemy preparować sami, a odbywa się to za pomocą stworzenia prostego ciągu z nazwami i wartościami naszych ciasteczek, a nastepnie wysłaniu żądania na serwer. Spójrzmy więc jak to wygląda w praktyce.

Przygotowanie ciasteczek

W najprostrzej możliwej postaci musimy przygotować ciąg o następującej strukturze:
[code]$cookies = "cookie1=".urlencode("wartość1")."; cookie2=".urlencode("wartość2");  // i tak dalej[/code]Pamiętajmy o średniku i spacji po nim rozdzielając ciasteczka. Nastepnie taki ciąg ustawiamy jako opcję w cURL-u za pomocą:
[code]curl_setopt($ch, CURLOPT_COOKIE, $cookies);[/code]

i całość wysyłamy na serwer.

[PHP][cURL] Podstawy cz.3 - żądania POST i wysyłanie plików

TRUE
484552077121779142
Wysyłanie żądań metodą POST nie jest trudne. Sprowadza się to do przygotowania jednej tablicy oraz ustawienia odpowiedniej opcji za pomocą funkcji curl_setopt(). Dzięki możliwości wysyłania żądań POST możemy za pomocą cURL-a zasymulować akcję przesłania formularza. Dodatkowo - dzięki metodzie POST możemy również wysyłać na serwer pliki. Jest to również bardzo prosta procedura, przyjrzyjmy się więc jak to działa w praktyce.

Przygotowanie żądania POST - CURLOPT_POSTFIELDS

Na początek musimy przygotować tablicę, w której umieścimy wszystkie pola, które mają być wysłane jako zmienne $_POST.
Tablica taka wyglądać będzie tak:
[code]
$post['nazwa_pola1'] = 'wartość pola1';
$post['nazwa_pola2'] = 'wartość pola2';
$post['nazwa_pola3'] = 'wartość pola3';
[...][/code]

Po przygotowaniu tablicy dołączamy ją do naszego żądania za pomocą opcji:
[code]curl_setopt($ch, CURLOPT_POSTFIELDS, $post);[/code]

[PHP][cURL] Podstawy cz.2 - nagłówki HTTP i pierwsze połączenie poprzez cURL

TRUE
1141251523631684398
Aby dobrze zrozumieć jak wygląda połączenie "od środka" przygotowaliśmy w poprzednim artykule dwa pliki - server.php i client.php. W tym tekście omówimy zasadę ich działania oraz ogólną procedurę połączenia po protokole HTTP. Jest to ważne, aby to dokładnie zrozumieć, gdyż bez znajomości tej podstawowej sprawy dalsza zabawa z cURL-em byłaby bezcelowa. Oczywiście bylibyśmy w stanie wykonać połączenie i je wykorzystać, ale byłaby to wiedza "na sucho". Zrozumienie działania "od podstaw" pozwoli nam na o wiele głębszą zabawę z biblioteką cURL.

Jak wygląda "formalnie" połączenie z serwerem?

Wchodząc na daną stronę internetową poprzez protokół HTTP, przeglądarka wysyła na serwer, który udostępnia stronę nagłówek (header) z żądaniem dotyczący pobrania jej zawartości. W nagłówku tym przeglądarka wysyła serwerowi kilka informacji o sobie, podaje np. swoją nazwę, swoją wersję, czy też wartość plików cookie, które mamy zapisane dla danej strony. Wszystkie te informacje wysyłane są na serwer w nagłówku. Serwer następnie otrzymuje taki nagłówek i wedle życzenia odpowiada na niego. Odpowiedź taka może być różna. Jeśli strona, o którą prosimy istnieje na serwerze, w odpowiedzi serwer wysyła tym razem swój nagłówek z kodem odpowiedzi, w tym przypadku "200 OK", oznaczający, że strona została odnaleziona. Wraz z nagłówkiem zwracana jest też do przeglądarki treść strony (body). Jeśli jednak strona nie zostanie odnaleziona, serwer może odesłać nam kod np. "404 Not Found", oznaczający, że zasób, do którego się odwołujemy nie istnieje. Możemy też dostać odpowiedź z kodem z zakresu 3xx, które to kody informują o przekierowaniach i zmianie adresu danej strony. Wszystkie te informacje przesyłane są w nagłówkach pomiędzy stroną (serwerem), a przeglądarką (klientem) na zasadzie:

 1. żądanie (request) >> 
 2. << odpowiedź (response)

Obrazuje to ta grafika:
źródło: https://cdn.tutsplus.com/net/uploads/legacy/511_http/http_diagram.png

Wiemy już zatem, że komunikacja taka odbywa się w obie strony za pomocą nagłówków HTTP.
Co jednak dokładnie zawierają w sobie takie nagłówki? Pierwszą i najważniejszą rzeczą jest kod odpowiedzi HTTP.
Kod taki jest przesyłany na pierwszym miejscu nagłówka, a jego wartość informuje przeglądarkę o statusie żądania.
Kody te dzielą się na 5 kategorii:

 - kody 1xx (np. 110 Connection Timed Out) - są to kody informacyjne,
 - kody 2xx (np. 200 OK) - są to kody powodzenia,
 - kody 3xx (np. 301 Moved Permamently) - informują o przekierowaniach
 - kody 4xx (np. 404 Not Found) - są kodami błędu po stronie klienta
 - kody 5xx (np. 502 Bad Gateway) - są to wewnętrzne błędy serwera

Pełną listę kodów znaleźć można np. tutaj:
http://pl.wikipedia.org/wiki/Kod_odpowiedzi_HTTP

Poza kodem odpowiedzi w nagłówkach przesyłane są oczywiście dodatkowe dane.
Przykładowe nagłówki otrzymane w odpowiedzi od serwera wyglądać mogą np. tak:

[code]
HTTP/1.1 200 OK
Date: Wed, 20 May 2015 17:19:37 GMT
Server: Apache/2.4.9 (Win64) PHP/5.5.12
Set-Cookie: PHPSESSID=ap0a54qaoafbarksjj48i279n1; path=/
Content-Length: 4174
Content-Type: text/html
[/code]

[PHP][cURL] Podstawy cz.1 - przygotujmy sobie środowisko testowe

TRUE
8689737018389349288
Biblioteka cURL to bardzo potężne narzędzie, które można wykorzystać do wykonania praktycznie każdego połaczenia. Aby dobrze ją zrozumieć trzeba wiedzieć co tak naprawdę się dzieje w momencie połączenia, jakie nagłówki są przesyłane, w jaki sposób i jakie dane w wyniku tego są zwracane. Stworzymy sobie zatem do tego na localhoście coś w rodzaju środowiska testowego składającego się z dwóch plików - jednego imitującego serwer, drugiego - imitującego klienta, który się z nim łączy. Do tego celu przygotowałem dwa pliki: server.php, oraz client.php. Oba pliki wrzucimy na localhosta. Omówię je za chwilę, na razie je stwórzmy.

1) server.php

Pierwszy z plików będzie udawał stronę na serwerze.
Przeklejmy poniższy kod i zapiszmy plik jako "server.php":
[code]<?php
session_start();
function showVariables($aVars) {  
    if (count($aVars) == 0) {
        echo "  ---";
    } else {
        foreach ($aVars as $name => $value) {
          if(!is_array($value))
          {
                 echo "  <b>".$name."</b> = ".str_replace(";", "; ", $value)."<br />";
          } else {
            var_dump($value);
          }
        }
    }
}
?><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>server.php</title><style>
body,td,th { font-family: Verdana, Geneva, sans-serif; font-size: 10px; color: #000; }
body { background-color: #fff; }
h1 { background-color: #000; color: #fff; }
.response_client,.response_client h1,.response_client table tr,.response_client table tr td {  color: #188517;  background-color: #edf5ed; }
.response_client table {  border: 2px solid #188517; }
.response_client div {  border: 5px solid #188517; }
</style></head><body><h1><i>cURL test:</i> server.php</h1><hr />
<div class="response_client">
  <b>Request from client.php:</b>
  <table border="1"><tr><td>$_GET</td><td><?php showVariables($_GET); ?></td></tr>
    <tr><td>$_POST</td><td><?php showVariables($_POST); ?></td></tr>
    <tr><td>$_FILES</td><td><?php showVariables($_FILES); ?></td></tr>
    <tr><td>$_COOKIE</td><td><?php showVariables($_COOKIE); ?></td></tr>
    <tr><td>Headers</td><td><?php showVariables(getallheaders()); ?></td></tr>
    <tr><td>$_SESSION</td><td><?php showVariables($_SESSION); ?></td></tr>
    <tr><td>$_SERVER</td><td><?php showVariables($_SERVER); ?></td></tr></table>
</div></body></html>[/code]

[TiP] PHP - pola "created_at" i "updated_at" w bazie danych

TRUE
5416158824467879060
Przygotowując bazę danych dla aplikacji w dobrym tonie jest, aby pola przechowujące czas utworzenia i edycji rekordu miały nazwy odpowiednio: created_at oraz updated_at, były typu INT i przechowywały czas jako timestamp, czyli jako linuxową wartość sekund. Dlaczego tak? Bo to pewien standard - biblioteki do mapowania bazy na obiekty takie jak Propel i Doctrine, a co za tym idzie również i frameworki takie jak Zend, czy Symfony używają takich właśnie pól do automatycznego przechowywania czasu. Jest to również przyjemne rozwiązanie dla innych programistow, którzy będą korzystać, lub rozbudowywać nasz kod stworzony z wykorzystaniem takiego, a nie innego nazewnictwa, które praktycznie utarło się już jako standard.

wtorek, 19 maja 2015

[UPGRADE][Blogger] Kolorowanie składni kodu - Google Code Prettify

TRUE
5633298314763569632
Jak widać na tej stronie, wszystkie listingi z kodem są ładnie pokolorowane. Blogger oczywiście nie oferuje tego domyślnie, trzeba zatroszczyć się o to samemu. Pokażę tutaj jak tego dokonać. Wykorzystałem do tego celu popularny skrypt do kolorowania składni kodu udostępniany za darmo przez wujka G, czyli Google Code Prettify. Oczywiście skryptów tego typu jest cała masa, ja jednak wybrałem ten od Google, gdyż wydaje mi się najszybszy i najbardziej odporny na wszelkie różne dziwne konstrukcje znakowe. Opiszę też mój sposób na automatyczne kolorowanie kodu ubranego w znaczniki bezpośrednio w edytorze wizualnym Bloggera - takie podejście jest o wiele bardziej wygodne, nic dodawanie ręcznie znacznika <pre> dla każdego listingu.

Dołączenie skryptu .js

Pierwsze co musimy zrobić to wejść w edycję szablonu i w nagłówku <head> załaczyć link do skryptu:
[code]<script src="https://google-code-prettify.googlecode.com/svn/loader/run_prettify.js"></script>[/code]

[UPGRADE][Blogger] Losowy post z danej kategorii pobierany z feeda

TRUE
6923652971032030257
Jak rozwiązałem wyświetlanie losowego "tipa" na górze strony? Bardzo prosto, choć trzeba było co nieco pokombinować. Po pierwsze z pomocą przychodzi generowany przez Bloggera kanał RSS. Jak wiemy, możemy pobierać wpisy po etykietach za pomocą specjalnie spreparowanego linku. W tym przypadku pobieramy zestawienie postów z etykietą QUICKTIPS za pomocą linka:
[code]/feeds/posts/summary/-/QUICKTIPS?alt=json[/code]
gdzie jako parametr alt podajemy oczywiście json, gdyż chcemy otrzymać dane w formacie JSON, a nie w XML. I tutaj pojawia się mały myk - ścieżkę do feeda musimy podać relatywną, lub pobrać poprzez javascript wartość location.hostname i dołączyć do ścieżki.

[UPGRADE][Blogger] Robimy system kategorii cz.4 - finał

TRUE
4728963745578807098
To już ostatnia część poradnika do stworzenia systemu kategorii w Bloggerze. Mając już przygotowane wszystkie niezbędne funkcje dochodzimy zatem do ostatniej części tutoriala, w której złożymy wszystko w całość i uruchomimy. Wykorzystamy tutaj oczywiście bibliotekę jQuery i zdarzenia ready(). Na samym końcu wpisu znajdzie się również cały przeanalizowany do tej pory kod.
[code]var postLabels = ''; var inPost = false;[/code]
Na samym początku deklarujemy domyślnie 2 zmienne:
postlabels - do której pobierzemy etykiety wyświetlanego posta,
inPost - przyjmująca TRUE/FALSE w zależności od tego czy oglądamy całość posta, czy listę postów

I teraz malutki trick, który pozwoli na "powiedzenie" javascriptowi, czy znajdujemy się w całości posta, czy na liście postów.
Za pomocą jQuery odwołujemy się do DIV-a o przypisanej klasie 'inPost'. DIV-a tego ukryłem w szablonie bloga w bloku, który odpowiada za wyświetlenie szablonu treści PEŁNEGO posta. Do DIV-a przypisany jest z CSS styl 'display: none', nie jest więc renderowany na stronie, a mimo to istnieje jako element drzewa DOM. Dodatkowo w DIV-ie zawarty jest ciąg znaków 'TRUE', czyli wygląda to tak:

[code]<div class='inPost'>TRUE</div>[/code]

[UPGRADE][Blogger] Robimy system kategorii cz.3 - dynamicznie generowany nagłówek

TRUE
6980526829644944639
W części tej zajmiemy się wyświetleniem spreparowanego nagłówka dla posta. Dzięki naszemu kodowi nazwa kategorii i subkategorii pojawi się nad postem w postaci linka. Umożliwi to bardzo wygodną nawigację po naszej strukturze kategorii. Dodatkowo wyświetlimy tam liczbę wpisów znajdujących się w danej kategorii. Wszystko odbywać się będzie automatycznie za pomocą przygotowanego przez nas tutaj kodu. Przygotujmy zatem kilka nowych funkcji, które do tego wykorzystamy.

Kolejne funkcje

Funkcja phpeGetSubcatName() zwraca tytuł etykiety podkategorii za pomocą jej indexu w tablicy. Pobiera najpierw NAZWĘ KLUCZA TABLICY Z ETYKIETĄ o indexie = catIndex, a następnie za pomocą tego klucza zwraca resztę, np. wywołanie phpeGetSubcatName(4) zwróci z tablicy ciąg "Wyrażenia regularne", wg zasady działania:

  1. tmpkey = counterNames[4] = PHP_wyrazenia_regularne
  2. phpeSubcategories['PHP_wyrazenia_regularne'] = new Array(4, 0, 'Wyrażenia regularne');
  3. return phpeSubcategories['PHP_wyrazenia_regularne'][2] = 'Wyrażenia regularne'

[code]
function phpeGetSubcatName(catIndex)
{
var tmpKey = counterNames[catIndex];
return phpeSubcategories[tmpKey][2];
}[/code]

[UPGRADE][Blogger] Robimy system kategorii cz.2 - dynamicznie generowane menu

TRUE
3865585716171268360
W tej części przygotujemy dynamiczne menu, taie jak widać tutaj, na górze strony. Będzie to wymagało kilka zabiegów i utworzenia paru funkcji, które automatycznie pobiorą nam informacje o kategoriach na stronie i policzą posty w nich zawarte. Konieczna będzie też mała modyfikacja szablonu w celu dodania do niego odpowiedzialnych za menu styli CSS.

DIV-a z naszym menu wklejamy w szablonie w miejsce tam, gdzie chcemy aby nasze menu się wyświetliło, najlepiej przed </header>:

[code]
<div id='contact-links'>
    <div id='menu-container'>
        <nav id='neat-menu'></nav>      
        <div id='menu-search'>
          <form method='get' action='/search'>
                <input autocomplete='off' name='q' placeholder='szukaj...' type='text' value=''/>
            </form>
        </div>
    </div>
</div>
[/code]

[UPGRADE][Blogger] Robimy system kategorii cz.1 - kategorie i podkategorie

TRUE
4284684279824674327
Jak widać na przykładzie tego bloga, istnieje tutaj system kategorii i podkategorii.
Blogger domyślnie nie oferuje niczego takiego, więc musiałem wymyślić taki system po swojemu i posłużyć się do tego kilkoma trickami. W tutorialu tym opiszę krok po kroku jak tego dokonałem. Wiedza zdobyta tutaj pozwoli Wam na przygotowanie własnego systemu kategorii i podkategorii na stronie Bloggera. Opiszę dokładnie cały kod jaki napisałem na potrzeby tej strony i pokażę jak wykorzystać to w praktyce. Do całości wykorzystamy tutaj javascriptową bibliotekę jQuery oraz kanały RSS jakie Blogger generuje dla swoich postów. Oczywiście nasze posty oznaczać będziemy odpowiednimi etykietami, tak aby trafiały do odpowiednich kategorii.

Zaczynamy

Na samym początku zdefiniujmy kilka zmiennych i tablic.

[code]
var counter = []; // tablica zawierająca ilość postów w podkategorii
var counterCats = [];  // tablica zawierająca ilość postów w kategorii
var counterIndex = 0;  // index aktualnie przetwarzanej podkategorii
var counterCatIndex = 0;  // index aktualnie przetwarzanej kategorii
var phpeSubcategories = [];  // tablica z listą podkategorii
var phpeCategories = [];  // tablica z listą kategorii nadrzędnyh
var global_label = 'start';  // globalna zmienna przechowywująca aktualną kategorię
var global_sublabel = 'start';  // globalna zmienna przechowywująca aktualną podkategorię
var menuRendered = false;  // zmienna pomocnicza do renderowania menu
[/code]

poniedziałek, 18 maja 2015

[UPGRADE][Blogger] Podstawy rozbudowy Bloggera

TRUE
1644964982246149070
Blogger jak wiadomo nie oferuje dostępu do kodu uruchamianego po stronie serwera, co jest zresztą logiczne, lecz tym samym blokuje nam to możliwość jego rozbudowy jeśli chodzi o nowe funkcjonalności. Mamy za to jednak dostęp do trzech elementów, które nam na jako takie modyfikacje kodu pozwolą. Pierwszym z elementów jest kod samego szablonu, który możemy według własnych potrzeb dowolnie modyfikować, drugim jest dostęp do kanałów RSS generowanych przez Blogggera, z których to kanałów możemy pobierać dane w formacie JSON, trzecim natomiast jest widźet o nazwie "HTML/Javascript". Zestawienie tych trzech możliwości pozwoli nam na co nieco zabawy z upgradem Bloggera. Na początek jednak przeprowadzić będziemy musieli kilka modyfikacji.

jQuery

1) Do bloga dołączyć musimy bibliotekę jQuery, o ile oczywiście jeszcze jej nie dołączyliśmy.
Wchodzimy w panelu w "Szablon --> Edytuj kod HTML" i otwieramy okno wyszukiwania "CTRL - F". Wpisujemy frazę:

</head>

następnie zaraz przed "</head>" wklejmy poniższy kod:

[code]<script src='https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js' type='text/javascript'/>[/code]

niedziela, 17 maja 2015

[TiP] Google Drive jako hosting dla plików .js i .css

TRUE
6203016219442009518
Może nie każdy wie, ale Dysk Google można wykorzystać do hostowania załączanych do strony plików takich jak skrypty JS, czy arkusze CSS. To bardzo przydatna sprawa, a żeby z niej skorzystać trzeba dokonać małego tricku. Na początek musimy plik, który chcemy hostować oflagować jako "Publiczne w internecie – każda osoba w internecie może znajdować i wyświetlać."
Możemy to zrobić klikając na nim na Dysku prawym przyciskiem myszy, następnie > Udostępnij > Uzyskaj link do udostępniania > Zaawansowane.

Dostaniemy link postaci:

https://drive.google.com/file/d/0B4Mb4UIYUBbkREhHaGM0MDFhZ0k/view?usp=sharing

z takiego linku jednak żadnego pliku do strony nie załączymy, musimy zmienić ścieżkę na:

https://googledrive.com/host/0B4Mb4UIYUBbkREhHaGM0MDFhZ0k

czyli pozbywamy się z linku ciągu /view?usp=sharing, a ścieżkę https://drive.google.com/file/d/ zamieniamy na https://googledrive.com/host/
Od tej chwili plik jest dostępny bezpośrednio, co za tym idzie możemy załączyć go bezpośrednio do strony, jeśli jest to np. .js albo .css.