Už deginimą

Kada FeedBurner naudingas?

• Jeigu esi labai pasišventęs ir nori matuoti savo lankytojų reakcijas. (NB: lankytojų reakcijas, o ne matuotis organais). Jeigu daug rašai, jeigu turi daug ištikimų subskraiberių, jeigu nori sekti kaip jie reaguoja į pasikeitimus stiliuje, išvaizdoje, rašymo dažnume, kokybėje – statistiniai duomenys yra labai pravartūs, bei padeda siekti tobulybės. Tačiau kai didžiausi Lietuvos blog’ai (iš tų kurie matuojasi) teturi kelis šimtus subskraiberių – ar tikrai svarbu žinoti, kad per mėnesį srautas išaugo 5 proc? T.y. 5 žmonėmis? Yra geresnių vertinimo būdų.
• Jeigu pardavinėji reklamą savo blog’e ir privalai matuoti – bet kuris reklamos davėjas norės sužinoti apie galimą auditoriją. Jeigu paprastų lankytojų kiekius išmatuoti gana lengva, kad ir naudojant Google Analytics, tai su subskraiberiais yra šiek tiek sudėtingiau – FeedBurner savo skaičiavimo metodologiją yra ištobulinę ir yra patikimas nepriklausomas vertintojas. Ar aš pardavinėsiu reklamą savo blog’e? Ar mano tikslas yra tiesiogiai iš blog’o uždirbti pinigus? Ne! Be to, natūralus klausimas – kiek tiksli yra ta statistika? Patys FeedBurner šiek tiek atkreipė dėmesį į šį klausimą dar prieš metus.
• Jeigu subskraiberių srautas yra Labai Didelis ir tenka spręsti apkrovimo problemas. 5000 subskraiberių, tikrinančių feed’ą kelis kartus per dieną, gali sukurti gana nemažą apkrovą. Manau. Ar man tai gręsia artimu metu? Ne! Ar problema įmanoma spręsti alternatyviais būdais? Taip!
• Kartais kaip argumentas pateikiama tai, kad atsitiktinis lankytojas, pastebėjęs, kad kažkieno blog’as yra gana populiarus, nusprendžia pats jį sekti. Čia jau asmeninių nuostatų klausimas, tačiau man tokie lankytojai nereikalingi – jie yra beverčiai. Be to tokius lankytojus galima labai nesunkiai pritraukti alternatyviais apgaulingais būdais.

Ar galite pavardinti daugiau priežasčių, apie kurias nepagalvojau? Statistiką juk iš tikro galima susekti ir kitais būdais (žr. žemiau). O apkrovos problemas taipogi galima spręsti alternatyviais būdais – jeigu turėsiu bent 1000 pastovių skaitytojų – manau nebus bėda, nei finansiškai, nei kaip kitaip, įsidiegti elementaraus feed failų cache’inimo ir/arba proxy sprendimus.

Prieš deginimą

Nors FeedBurner naudojimas pats savaime lyg ir nepagadina reikalo, bet jis nieko ir nesukuria. Tai ir bus pagrindinis argumentas – jeigu jis nieko nesukuria – tai kokio velnio jis man reikalingas? Kodėl aš turėčiau prarasti Pilną Kontrolę ir atiduoti ją Google? Nepaisant to, kad žaviuosi jais kaip kompanija, ir kad jie trimituoja “nebūk blogis” – mano feedas liks mano valdžioje. Galbūt to pasigailėsiu, kai jie užkariaus pasaulį ir mane nuteis kaip disidentą, tačiau šiuo metu FB lyg ir neturi tikrai rimto konkurento – reiškias yra niša, kurią galima užpildyti taip, kad manęs neerzintų.

Kitas, šiek tiek paprastesnis argumentas yra vistik FB ribotumas ir nepatogumas. WP suteikia galimybę turėti feed’us vos ne kiekvienam turinio elementui – puslapiams, prisegtiems failams, įrašams – taigi realiai, be abejo, 99% žmonių naudos pagrindinį, ir galbūt komentarų feed’ą, tačiau likęs 1% retkarčiais panaudos ir kitus. Kurie liks neužfiksuoti statistikose! Aš pats gana dažnai bent kelias dienas seku įdomesnių įrašų komentarus, kol diskusija išsenka. FB skaičiuoti tokios statistikos nesuteikia paprastų galimybių – reiškias turime dar vieną nišą.

Plug-in’as

Ir vistik, kiek žmonių skaito mano blogą žinoti ir stebėti norisi – net jeigu neketinu šių duomenų skelbti viešai. Sprendimas yra – Chris Finke sukurtas Feed Statistics pluginas Wordpressui. Tiesa, jis nėra tobulas – greičiausiai dėl ne visai teisingo algoritmo, tačiau man ne tiek svarbus klausimas “kiek žmonių mato mano straipsnių pavadinimus savo readeriuose”, kiek kitas klausimas – kiek žmonių skaito tai ką aš parašau? Šį klausimą pluginas atsako gana nesunkiai, ir beje pačiu elementariausiu būdu – paslėptas tracking paveiksliukas. Jis, be abejo, neatsako į klausimus “ar jie tikrai perskaito” ir “ar jie pamatytų (paslėptą) reklamą”, tačiau jis yra vienintelis man aktualus ir naudingas skaičius.

Kiekvieno teisė rinktis. Šiuo metu blogeriams, rašantiems “Lietuvos rinkai”, FeedBurner tikrai nereikalingas. Aš renkuosi nepirkti (ar neparsiduoti?) FeedBurner teikiamos iliuzijos (produktas, kuris nieko nedaro, bet reikalingas visiems).

Sugalvojus pricipą, išplėtojus idėją ir apibrėžus taisykles galima žiūrėti dar konkrečiau. Turint omeny mano visus princesiškus įgeidžius, WordPress šiaip jau nėra bloga sistema, nors kodo kiekis skirtas adresų generavimui ir jų apdorojimui yra stulbinantis (ir netgi isteriškai juokingas). Tačiau čia jau jų pačių problema, kylanti iš to, kad siekiama patenkinti kuo didesnį vartotojų ratą. Tačiau liaudies išmintis teigia ką kitą – kartais kas tinka viskam – netinka niekam. Na bent jau man tikrai netinka masinio vartojimo produktas, kuris netenkina mano poreikių. Tačiau WP yra atviro kodo ir šiaip jau tiesiog prašosi laužomas ir “pritaikomas” – kaina viso to be abejo yra tai, kad ateityje mano “perrašymai” gali nebeveikti ir teks prie jų padirbėti sulig kiekvienu WP relyzu, tačiau vieną kartą pasidarius taip kaip aš noriu – turėčiau būti patenkintas gana ilgai, net su sena WP versija – don’t fix it, if it ain’t broken.

Užduotis

Mano tikslas yra priversti WP atpažinti adresus, pagal mano struktūrą, priversti jį generuoti adresus pagal mano struktūrą ir priversti jį padaryti 301 redirektą, kai adresas netenkina struktūros. Kadangi nežinau iki galo visų galimybių, kurias naudosiu, be to ir laikas ribotas – kol kas užteks sutvarkyti šitaip:

• Turinys (content):
  • /2007/ – mėnesių sąrašas [Archyvas, 2007]
    • 01-12/ – post’ų sąrašas [Archyvas, 2007, mėnuo]
      • postas-numeris-vienas.html
      • postas-numeris-vienas.(rss|atom|rdf|rss2).xml
      • postas-numeris-vienas.trackback
  • /pavadinimas.html – paprastas puslapis (analogiškai postams – rss ir tb)
  • /attachments/2007/11/pavadinimas.html – prisegto failo aprašymas (analogiškai postams – rss ir tb)
• Archyvai:
  • kategorijos/ – kategorijų sąrašas
    • pavadinimas[/subpavadinimas].html – paskutiniai X įrašų kategorijoje
    • pavadinimas[/subpavadinimas].(rss|atom|rdf|rss2).xml – kategorijos feed’as
  • tagai/ – tagų debesėlis
    • pavadinimas.html
    • pavadinimas.(rss|atom|rdf|rss2).xml
• Visa kita – filtruojasi per standartinius WP GET parametrus, kreipiantis į /search. Visą /search tuo pačiu įdedame į noindex, nes ten bus dinamiškas, pasikartojantis ir visaip kitaip paieškos robotams nenaudingas turinys – pažangūs vartotojai patys susigaudys kaip išgauti tai ko nori.

Kur ieškoti?

WordPress filosofija leidžia filtruoti beveik visą įmanomą išvedimą – tai bene labiausiai palengvina mano darbą. Problema aišku ta, kad visi tie filtrai gana prastai dokumentuoti ir nėra patogios naming convention, todėl teks verstis su elementaria paieška kode.

Perrašymas susideda iš trijų dalių – turinio atpažinimo iš URL, nuorodų generavimo ir nuorodų kanonizavimo. Atpažinimą susitvarkyti gana paprasta – reikia detaliai išsianalizuoti wp-includes/rewrite.php failą ir ką jis veikia, po to sukurti savo regular expressions. Nuorodų generavime beveik visur (išskyrus puslapiavimą paieškoje ir pan.) yra naudojami apply_filter – per visą WP source’ą paleidus paieškas _link( ir _url(, po to truputį padirbėjus galima susirinkti visus reikalingus filtrus (nes dokumentacija pasitikėti kažko sunku).

Kanonizavimas yra iš esmės paprastas – jeigu rodomas objektas (puslapis, archyvas, pan.) yra kviečiamas ne su kanonine nuorodą – darom 301 redirektą. Panašiai elgiasi standartinė WP kanonizacija (wp-includes/canonical.php), tačiau ji neveikia su feed’ais ir (pagal mano reikalavimus) neperkelia lankytojų į “/search” neindeksuojamą sritį – teks jį išjungti ir daryti savo.

Rezultatas

12 valandų galvos trankymo į sieną, eureka šūksnių, keiksmų, verkimo, testas su Google Sitemaps pluginu, pergalės šokis ir canonizer plugin’as paruoštas. Iš esmės niekam nerekomenduoju jo naudoti – tačiau peržvelgti kodą, pažiūrėti kaip veikia mano blog’as ir galbūt dalį to pritaikyti sau – visada prašom. Į egzistuojantį blog’ą jo kelti nederėtų dėl jau minėtos adresų pasikeitimo priežasties – nesivarginau daryti backwards compatibility su visomis įmanomomis WP instaliacijomis, todėl jūsų senos nuorodos gali paprasčiausiai nustoti veikti. Be to plugin’as tikisi keletos nustatymų – visų pirma permalink struktūra turėtų būti /%year%/%monthnum%/%postname%.html; taipogi pirmasis puslapis turėtų būti įrašų sąrašas (netikrinau ar veikia kitu atveju). Na ir šiaip jis nėra pakankamai ištestuotas – laikas parodys.

Nepaisant to, kas yra skonio reikalas, svarbiausios veikimo detalės:

• add_action('init',array('Dominykas_Canonizer','init'));

  Užsikraunam, pasileidžiam, važiuojam, žiūrim į klasės init() metodą

• init() viduje nematome nieko ypatingo – inicializuojami keli kintamieji ir nustatomi filtrai:
  • f_rr_*() – filtruojam perrašymo taisykles. Grąžinam asiociatyvų masyvą, kurį naudoja $wp_rewrite. f_rr() tuo pačiu dar šiek tiek pravalo tai kas man neįdomu.
  • f_url_*() – filtruojam sugeneruotus adresus. Kiekviena funkcija labai skirtinga ir su skirtingais parametrais – bet galbūt vieną dieną WP viduje įsivyraus tvarka ir gyventi bus paprasčiau… f_url() ištaiso puslapiavimą (kabinamės ant clean_url, nes kito būdo nėra) – šitą funkciją reikės perrašyti, kai apsispręsiu dėl gražios puslapių struktūros (tinkamos SEO).
  • redirect_canonical – perkeliam lankytoją į Teisingą Adresą
• Dar viduje randame keletą pagalbiniu funkcijų:
  • query_allowed_only() – sutikrinam ar turime tiksliai tokius ir tik tokius parametrus kaip reikalinga kanoniniam adresui
  • rebuild_url() – quick-n-dirty hackas atstatyti adresą, kurį sugriovėme su parse_url()

Dalis funkcijų dokumentuota, dalis gimė copy-paste būdu, o Windows kažkodėl ištrina visus komentarus iš clipboard’o (tikrai tikrai!)

Kas toliau?

Galbūt vieną dieną WP išaugs į padorų OO dizainą. Galbūt vieną dieną visas nuorodų generavimas bus viename faile. Tada bus galima tiesiog pakeisti $wp_rewrite ir pvz. $wp_links objektus į savo parašytus/išplėstus ir nukris dalis vargo (performance’o atžvilgiu turėtų tikrai būti efektyviau, nei du kartus atlikinėti tą patį darbą). Artimiausias dalykas though – sutvarkyti į padorią PHP5 objektinę sintaksę (static funkcijos), bei sutvarkyti, kad nuorodų atpažinimo regexpų kešas nebūtų generuojamas kas kartą ($wp_rewrite->flush_rules();. Vėliau jau bus galima žiūrėti šiek tiek plačiau, kad padengti daugiau WP funkcijų ir pritaikyti didesniam ratui lankytojų. Pirmas žingsnis į išleidimą viešumon, būtų permalink nustatymų pakeitimas, t.y. WP options turėtų būti galima pasirinkti ar naudoti WP permalinkus, ar naudoti šio plugino sistemą – tada jau tektų kurti ir konfigūracijos opcijas. Jeigu kas nors norite tuo užsiimti – prašau! Kodo turbūt nerašysiu, bet į klausimus kiek sugebėsiu – atsakysiu.

O tęsiant WP hackinimo temą, natūralus posūkis yra link skinų laužymo ir templeitų pritaikymo.

Turinio nuorodos

Atsižvelgiant į tai, kas yra “blog’as”, manau galima drąsiai pasakyti, kad vienintelis tikras turinys jame yra patys įrašai. Atsižvelgiant į tai, kad blog’as yra chronologinis daiktas – įrašus ir derėtų tvarkyti pagal datą. Šiuo požiūriu sutinku su didžiąja dalimi blog’erių, kurie taip ir daro. Jeigu įrašus dėlioti į folderius pagal kategoriją – gausime per ilgus ir nepatogius adresus, bei prarasime blog’o prasmę laike. Mano įrašai gulės adresu /YYYY/MM/iraso-pavadinimas.html

WordPress turi dar kelis turinio objektų tipus – tai pages ir attachments. Dėl paprastų puslapių galvos daug sukti turbūt nereikia – /puslapis.html ir /puslapis/subpuslapis.html bus pakankama ir struktūriška. Dėl prisegtų failų (ir paveiksliukų) šiek tiek teko padvejoti. Prisegtų failų (paveiksliukų) adresas mano nuomone turi parodyti kuriam įrašui priklauso pats failas, tačiau žvelgiant tolyn – turi būti ir saugiai panaudojamas ateityje. Kadangi neketinu daug tuo naudotis – manau pasirinksiu paprastą įšeiti, kad virtualiai jie gulėtų /attachments/ direktorijoje, su subfolderiais pagal datą. ImageShack ir panašiomis tarnybomis neketinu naudotis – mano turinys, mano kontrolė, o srauto ir apkrovimo problemas galima išspręsti kitais būdais. Ir šiaip – artimu metu neplanuoju patirti Slashdot efekto ;)

Archyvų, sąvadų ir rodyklių nuorodos

WordPress suteikia gana daug įvairių turinio pjūvių. Ar jų visų tikrai reikia? Kiek iš jų galima atsisakyti ir palikti “dinamiškai paieškai”? Kiekvieno blog’o specifika matyt pateiktų savo atsakymus. Mano asmeniniam blog’ui toli gražu nereikalingas filtravimas pagal autorių – taigi ir pastovios nuorodos į jį nebus. Pastovias rodykles norėčiau turėti tik metams, mėnesiams, kategorijoms ir tagams.

Metų rodyklė kuo puikiausiai telpa /YYYY/, analogiškai ir mėnesinė. Kategorijos ir tag’ai turėtų atsirasti /categories/pavadinimas.html puslapyje, kuriame būtų rodomi keli paskutiniai įrašai, o toliau /categories/pavadinimas.YYYYMM.html leistų naršymą/puslapiavimą laike. Visos kitos pjūvių kombinacijos turėtų keliauti į paiešką ir nepakliūti paieškoms robotams.

Failų išplėtimai, feed’ai ir viskas

WordPress idėja naudoti /feed/ ir /feed/atom/ priedėlius prie bet kokio adreso mane tiesą pasakius vimdo. Negražu man taip. Juk feed’as – tai tas pats turinys, tik kita forma. Todėl visur kur aukščiau paminėjau .html reikėtų galimybės tiesiog pakeisti į .rss.xml – ir problema išspręsta. Analogiškai ir su trackback adresu (kuris beje turėtų vėlgi nerūpėti paieškos robotams) – tiesiog pakeičiam .html į .trackback prie įrašų (ir kitų komentuoj-abilių objektų).

Tiek to džiaugsmo, tiek tų problemų. Beje, jau susidėliojęs visą logiką sau, pastebėjau, kad labai panašų principą naudoja Blogger – o Google žino ką daro. Toliau: suformuluojam galutinę užduotį ir rašom WordPress pluginą, kad pasiekti šiuos tikslus.

Papildomam skaitymui

Nors didžiąją dalį to ką parašiau apie URL parėmiau savo patirtimi, yra keletas resursų, kurie praplečia akiratį ir kuriuos dera suvokti, net jeigu ir atrodo, kad viskas aišku.

• Talk like a Googler: parts of a url, Matt Cutts. Bet kuris web kūrėjas privalo tiksliai suvokti tai kas ten rašoma ir naudoti tuos terminus – net jeigu atrodo, kad viską žinai, atsišviežinti žinias derėtų.
• Uniform Resource Identifier, Wikipedia. Svarbiausia dalis – suvokti kuo skiriasi URI ir URL: URL yra URI, kuris papildomai parodo ir būdą kaip pasiekti identifikuotą resursą.
• URL normalization, Wikipedia. Truputis beletristikos apie adresų kanonizavimą.
• URL redirection, Wikipedia. Dar truputis beletristikos apie adresus.
• Extensible Resource Identifier, Wikipedia. Nauja URI karta. Tiuzyro, tskant.