Blog programistów Programa.pl

ModRewrite – przyjazne adresy na stronach www

Programiści mają to do siebie, że o wiele łatwiej jest im zapamiętać ciąg zmiennych, rozdzielonych ampersandami niż ciąg logicznych wyrazów. Na szczęście – bądź też nieszczęście – większość ludzi woli jednak wyrazy swojego ojczystego języka. W ten sposób postała koncepcja zamiany adresów www na tzw. friendly URL, którymi mam zamiar zająć się dziś.

Początki

Jeszcze kilka dni temu sądziłem, że sprawa jest beznadziejna, że moje umiejętności nie wystarczą. Ale cóż – w środowisku IT jest presja, by wszystko ułatwiać i trzymać się trendów. A, można chyba powiedzieć, że przyjazne adresy są standardem dla każdej liczącej się firmy na rynku. Nauczenie się więc tworzenia portali, które korzystają z tego wynalazku jest doskonałą inwestycją w siebie.

Czego mi trzeba?

Tak de facto – niczego. Wystarczy Apache z modułem mod_rewrite i trochę wolnego czasu na doczytanie szczegółów dokumentacji. Nasza strona może nadal działać tak samo. Naszym zadaniem jest stworzenie dodatkowych dwóch fragmentów kodu, które będą pozwalały na zamianę adresów: plik .htaccess z regułami zamiany adresów z krótkich, na normalne i kod php, ktory generuje te krótkie adresy.

Reguły RewriteRule

Przepisywanie adresów okazuje się łatwe, jeżeli nasz portal jest dobrze skonstruowany, Każda reguła RewriteRule to pojedyncza linijka:

RewriteRule wyrażenie_regularne wynik_przepisywania

I tyle. Wystarczy „powiedzieć” modułowi mod_rewrite jakie adresy ma tłumaczyć na jakie.  W ten sposób wykonane jset tłumaczenie na naszej stronie firmowej. Budując odpowiednie reguły uzyskaliśmy adresy URL w językach użytkownika, prowadzące do odpowiednich wersji językowych podstron. W naszym wypadku reguły tworzone były ręcznie – mieliśmy ku temu powody – ale równie dobrze można napisać skrypt, który plik .htaccess będzie generować na bieżąco w pełni automatycznie, lub zdecydować się na adresy skonstruowane trochę inaczej, ale cechujące się większą regularnością.

Generowanie krótkich adresów po stronie PHP

Tutaj sprawa wygląda trochę inaczej. Sposób generowania adresów jest zależny ad tego jak wyglądają docelowe adresy. Najprostszym sposobem (ale najmniej automatycznym)  jest tworzenie tych URLi podczas tworzenia podstron i dodawanie ich do bazy danych w osobnych polach. Przy małych stronach można oczywiście „zaszyć” nowe adresy bezpośrednio w kodzie strony. Jeśli do tej pory były tak zaszyte – zakładam, że układ strony jest niezmienny, strona nie jest rozbudowywana i zmieniana – to umieszczenie nowych adresów w tym samym miejscu nie powinno stanowić problemu.

Nie jest to kurs tworzenia przyjaznych adresów, a jedynie zachęta do własnych poszukiwań. Nie ma jednej skutecznej,  metody. Wiele metod jest dobrych, trzeba znaleźć taką, która nam odpowiada i zacząć ją stosować. Uważam, że to kwestia czasu, zanim wszyscy będą używać przyjaznych adresów przy tworzeniu nowych witryn. Czy możemy sobie pozwolić na zostanie za konkurencją?

Udostępnij innym

Kontrola pozycji słów kluczowych – Free Monitor for Google

Prowadząc swoją stronę internetową warto, a nawet należy kontrolować statystyki jej ruchu.  Google Analytics daje nam możliwość sprawdzenia jak użytkownicy nas szukają, nie udostępnia jednak funkcjonalności, która pozwalałaby sprawdzić na jakiej pozycji w Google znajduje się nasza witryna pod danym słowem kluczowym. Posiadając kilka słów kluczowych można oczywiście szybko wpisać je w Google i zanotować wyniki, ale co gdy pozycjonujemy stronę pod większą ilością fraz i chcemy na bieżąco kontrolować wyniki tego, za co płacimy?

Free Monitor for Google

Z pomocą przychodzi narzędzie, które jest do pobrania za darmo ze strony http://www.cleverstat.com/en/ Obsługa tej aplikacji jest banalnie prosta, wybieramy stronę którą chcemy monitorować, dodajemy słowa kluczowe, które nas interesują i czekamy, aż zostaną zwrócone wyniki. Niewątpliwą zaletą jest prostota obsługi i możliwość kontrolowania wielu witryn. Program zapamiętuje również najlepszy osiągnięty wynik danej frazy i porównuje obecną pozycję z poprzednią – można w ten sposób np testować różne metody pozycjonowania, czy też sprawdzać skuteczność abonamentu, który opłacamy.

Warto wspomnieć jeszcze o minimalnej konfiguracji (Options -> Preferences) gdzie należy wybrać kraj, który nas interesuje. Google automatycznie dopasowuje wyniki wyszukiwania do preferencji językowych, dlatego zmiana tej opcji jest bardzo istotna. Można również zmienić ilość sprawdzanych rezultatów – zwiększenie tej liczby spowoduje przeszukiwanie większej ilości wyników, jednak zwiększy również czas oczekiwania na rezultaty.

Pozycje słów kluczowych, a polskie znaki

Zarówno sprawdzając pozycję słów w powyżej opisanym narzędziu (czy też standardowo na Google.pl) jak i prowadząc kampanię Google Ad-Words warto zwrócić uwagę, że Poznań i poznan to dwa różne ciągi znaków, które w połączeniu z innymi słowami kluczowymi tworzą frazy o różnych pozycjach w wyszukiwarce czy też różnych kosztach za kliknięcie w kampanii reklamowej.

Czy wyniki w Free Monitor for Google są prawdziwe?

Czasami można zauważyć, że wyniki uzyskane przez Free Monitor for Google różnią się od tych uzyskanych w wyszukiwarce. Zazwyczaj różnica będzie minimalna i spowodowana jest tylko i wyłącznie faktem, że Google ma ogromną bazę serwerów, na których to bazy danych w danej chwili mogą się nieznacznie różnić, przez co mogą zwracać różne wyniki zapytań.

A co z PageRankiem? – PaRaMeter

Na pewno nie jest to miejsce, aby tłumaczyć co to jest PageRank – możecie o tym przeczytać na Wikipedii albo bezpośrednio w Googlach. Chciałbym tutaj jednak napisać kilka zdań o narzędziu, które znalazłem pisząc dla Was ten post. Na stronie Clever Stat (http://www.cleverstat.com/en/) poza narzędziem opisanym wcześniej, za darmo możemy znaleźć jeszcze PaRaMeter – czyli bardzo podobny soft, tym razem jednak do sprawdzania PageRanka.

Idea działania jest identyczna jak w poprzednim przypadku – dodajemy adresy stron, które nas interesują i rozpoczynamy wyszukiwanie. Należy pamiętać, że PageRank strony głównej to nie wszystko – podstrony też go mają. W pasku narzędzi znajdziemy opcję wyszukiwania adresów w naszej witrynie (Tools -> Extract Urls) co zaoszczędzi nam czasu na ręczne wklepywanie wszystkich naszych podstron.

Dzięki opisanym narzędziom możemy w prosty i łatwy sposób, całkiem za darmo uzyskać bardzo istotne informacje na temat naszej witryny. Clever Stat udostępnia te narzędzia bez pobierania żadnych opłat, a działają one wyśmienicie. Może więc warto wydać parę dolarów na pozostałe ich propozycje?
Korzystając z okazji tematyki tego postu zapraszam wszystkich do odwiedzenia bloga naszego dobrego kolegi na temat Optymalizacji, użyteczności i mierników WWW: www.arekskuza.pl

Udostępnij innym

XML, HTML, XHTML – jeden pies?

Zawsze sądziłem, że język HTML jest rozpoznawany przez ludzi. Okazuje się, że nie wszyscy go znają. Co gorsza, nawet wielu programistów nie zna różnic między HTMLem i XHTMLem, czy nawet XMLem. Postanowiłem więc opisać najważniejsze różnice.

XML

Z trzech wyżej wymienionych jest to to język,  o którym wiem dość sporo, ale używam go najrzadziej. Nie będę tłumaczyć jak wygląda szkielet dokumentu, czy skąd język się wziął – takie informacje serwuje Wikipedia. Ja chciałbym tylko zauważyć, że XML jest doskonałym nauczycielem pokory i dokładności – żadna przeglądarka nie otworzy niepoprawnie sformatowanego dokumentu XML! Poprawność jest tutaj kluczowa. Z drugiej strony, często dokumenty XML mają swój schemat DTD, z którym muszą być zgodne. To również powoduje, że musimy być pewni, co piszemy.
Z drugiej strony, XML jest językiem, który opisuje całą zawartość – wiemy co tam jest i jak się to nazywa. Przecież tag <title>Mały Książę</title> mówi sam o sobie – Mały Książę jest tytułem.

HTML

Najpopularniejszy i najsłabszy z  tych języków. Doczekał się już wersji 4.01, ale nadal jest ona słaba. Pełna specyfikacja i opis języka dostępne są w sieci. Łatwo też znaleźć kursy HTMLa. Osobiście uważam, że język niewart jest nawet tego akapitu, jednak nie jestem tu autorytetem. Będzie wersja 5.0, zamiast przejścia na XHTML 2.0

XHTML

W sumie jest to hybryda XMLa i HTMLa. Język, który tak jak HTML udostepnia pewien okrojony zestaw znaczników, ale który wzorem XMLa musi być well-formed. Każdy dokument XHTML jest poprawnym dokumentem XML. Na dodatek, wszystkie nowe przeglądarki internetowe (poza IE) potrafią wyświetlać XHTML jako HTML.

Uważam, że z tej trójki XHTML jest czymś, co każdy web-developer musi znać. Posiada zalety HTMLa i XML. Szkoda, że W3c zrezygnowało z rozwijania XHTMLa. Więcej na ten temat, można poczytać w wielu miejscach w sieci, ale ja podam przykładowy adres. Mam tylko nadzieję, że kiedyś stwierdzą, że jednak popełnili błąd i powrócą do XHTMLa, którego używam nagminnie.

Udostępnij innym

ETag – co to jest i z czym to się je

Nie czuję się specjalistą z dziedziny nagłówków HTTP. Jednak nie udało mi się znaleźć żadnej dobrej strony po polsku, która omawiałaby czym są Entity Tags. Postanowiliśmy więc podzielić się wiedzą, jaką sami uzyskaliśmy przeszukując sieć oraz poprawiając nasze strony www.

Definicja

ETag to specjalny znacznik wysyłany wraz z dokumentem przez serwer www. Jego zadanie jest proste – ma informować o tym, czy dokument uległ zmianie i czy jest konieczność jego ponownego pobrania z serwera.

Jak tworzone są ETagi

ETag tworzony jest zazwyczaj przez serwer www na podstawie rozmiaru, czasu ostatniej modyfikacji czy sumy kontrolnej pliku. Jest oczywiście możliwość ręcznego dodawania takich tagów, np. dzięki skryptom PHP. Moim zdaniem, nie warto zajmować się tym samemu, gdy Apache może zrobić to za nas.

Jak my to robimy

Dla programistów Programy optymalizacja jest sprawą bardzo ważną. Dlatego nie zadowoliliśmy się informacją, że ETagi istnieją – zaczęliśmy je wykorzystywać, poprawiając osiągi tworzonych przez nas stron www. W katalogu głównym strony www umieszczamy plik .htaccess, będący instrukcją dla serwera www. Jego treść wygląda następująco:

FileETag MTime Size

Te kilka znaków pozwala zaoszczędzić sporo transferu. Instrukcje te mówią: kiedy wysyłasz plik z serwera, dodaj do niego ETag pliku (FileETag) używając do jego budowy daty ostatniej modyfikacji tego pliku (MTime) i rozmiaru tego pliku (Size). Przeglądarka zapamiętuje ten znacznik. Kiedy następnym razem poprosi o ten sam plik doda jego ETag do żądania. Jeśli plik nie uległ zmianie serwer zamiast wysyłać kod 200 OK, odpowiem kodem 304 Not Modified. Oznacza to, że przeglądarka posiada najnowszą wersję dokumentu i może odczytać ją z cachu, bez konieczności pobierania z serwera.

Takie „dobre praktyki programistyczne” świadczą o kunszcie profesjonalisty. Ktoś, kto używa tylko narzędzi WYSWIG, a nie potrafi optymalizować tej strony, nie może twierdzić, że tworzy strony www. Jeśli chcesz mówić o sobie profesjonalista – zacznij używać ETagów.

Udostępnij innym

Walidacja HTML i XHTML – to podstawa!

Przemierzając witryny www często widzimy tylko jedno oblicze – ta strona w naszej ukochanej przeglądarce wygląda wspaniale! Albo odwrotnie – strona się „rozjeżdża”, nie wygląda zupełnie tak, jak powinna. W czym rzecz? Przecież HTML powinien zawsze być publikowany tak samo!

Poprawność

HTML i XHTML są językami tagów. Oznacza to, że cała treść umieszczona jest w specjalnym drzewie znaczników. Dlaczego więc większość developerów zapomina o tym, że te tagi często trzeba zamykać? Jeśli piszemy program w języku kompilowanym, to kompilator wskaże nam nasze błędy. Tutaj do kompilacji nie dochodzi. Kiedy kod strony jest poprawny, każda przeglądarka powinna wyświetlić ją tak samo (są pewne różnice, ale nie mamy na nie wpływu). Jednak kiedy strona www jest niepoprawnym dokumentem przeglądarka przechodzi z trybu strict (zgodność ze standardami) w tryb quirks. W tym trybie przeglądarka próbuje „domyślić się” co mieliśmy na myśli, tworząc dokument. Często jej się udaje. Ale nie zawsze.

Parser HTML/XHTML?

Jak sprawdzić, czy nasza strona jest zgodna ze standardami? Najłatwiej skorzystać z usług The World Wide Web Consortium (W3C). Na ich stronie www możemy przeczytać sporo o standardach, a także znaleźć adresy narzędzi zwanych walidatorami. Te narzędzia właśnie pozwalają na sprawdzenie, gdzie w naszym dokumencie HTML są błędy.

Czy warto?

Oczywiście, że tak! Uważam, że walidacja dokumentów to absolutne minimum! Nie wyobrażam sobie, jak ktoś, kto mówi o sobie „profesjonalista”, może oddawać ludziom stronę www, która nie jest poprawnie zbudowana! Jeśli ktoś się uczy, zawsze może poprosić o pomoc w poprawieniu błędów, przeczytać opisy standardów itd.

A co z XMLem?

Używając języka XML nie mamy wyjścia – jeśli dokument nie jest poprawnie sformatowany, to przeglądarka nie wyświetli go wcale! Tylko dokumenty poprawne, tzn. well-formed są wyświetlane. I tylko takie użytkownik zobaczy. Więc może używanie XMLa jest rozwiązaniem? Możliwe. Ale to już chyba materiał na kolejny wpis i długą dyskusję.

Walidacja stron www oraz ich arkuszów stylów jest pierwszą rzeczą, jaką sprawdzam oceniając stronę www. Jeśli strona ma niewiele błędów, to można uznać je za przypadek, efekt niedawnych zmian czy świadczyć o pracy nad stroną. Oczywiście najlepiej, gdy waldiator odpowie, że strona jest zgodna ze standardami. Jeśli jednak walidator zrezygnuje ze sprawdzania poprawności po setnym błędzie, moja ocena strony drastycznie spada. Jeśli coś robisz  – rób to dobrze.

Udostępnij innym