creative commons eestindamisest reedel 05.11.2010

Reedel toimub IT Kolledzis üritus, mis tutvustab Creative Commons litsentside eestindamise protsessi ja tulemust – aga kuna Teller seda (õigustatult) hästivarjatuks nimetab siis ma võtan vaevaks päevakava PDFist välja kopeerida ja taasavaldada – koos teatava imestusega selle “Päeva esimesest osast videoülekannet ei toimu” üle, sest me saame vist maha maailma esimese CC lokaliseerimist tutvustava üritusega mille sisu puhul ei ole lokaliseerijad nõus kasutama CC litsentsi. Või saan ma millestki valesti aru ja tegemist on lihstalt kaamerameeste plaanitud tööseisakuga prantsuse pensionirevolutsiooni toetuseks/vastu? Anyway…

Ametlik leht on Creative Commons litsentside eestindamise esitlus ja kuigi üritus on tasuta on vajalik eel-registreerumine.

10:00-11:45

  • Tervitussõnad, ülevaade päevast / Ene Koitla
  • Milleks meile Creative Commons – litsentside eestindamise protsess ja sisu? / Hele Karja
  • Mis toimus enne Creative Commonsit? / Heiki Pisuke

12:15-13:45

  • Mis juhtub pärast Creative Commonsit? / Toomas Seppel
  • Creative Commons praktikas (videoloeng) / Peeter P. Mõtsküla

14:00-15:00

  • Creative Commonsi väited ja näited / Kaido Kikkas
Postitatud rubriiki autõs | Sildistatud , , | Kommenteerimine suletud

arendusleping ja GPL

Sattusin ülevaatama ühe veebiarenduse lepingut/tingimusi ja jäi silma lause, mille kohaselt klient saab tarkvara osas tähtajatu kasutusõiguse ühe veebi tarbeks – mis on nähtavasti suht tavaline tüüplepingu punk. AGA juhtumisi on ette teada, et platvormiks saab WordPress mille litsentsiks on GPL ning see mida tegema hakatakse ehk kujunduspõhi on tarkvaralises mõttes väga tihedalt seotud WordPressiga jagades aadressruumi ja andmeid, laenates koodijuppe või täiendades olemasolevaid klasse.

Ülimalt lihtustatuna ütleb GPL järgmist (juristid & vaba tarkvara gurud on teretulnud seda tõlgendust täpsustama/laiendama):

  • igaühel on õigus GPL litsentsiga tarkvara kasutada
  • igaühel on õigus seda tarkvara levitada (aga seda tuleb teha koos lähtekoodi ning litsentsiga)
  • igaühel on õigus seda tarkvara muuta/täiendada/jne (aga kui plaanid muudetud tarkvara levitada, peab litsentsiks jääma GPL ja mõistagi tuleb levitada ka lähtekoodi, säilitada viited algsetele autoritele ja lisada enda oma; levitamine ei ole oma firma sees kasutamine, aga nt allhankijale/koostööpartnerile edastamine juba on)
  • tarkvaraga ei kaasne mingit garantiid (aga soovijatel on lubatud pakkuda tasulist garantiiteenust)
  • tarkvara eest ei tohi küsida raha, v.a tasu levitamise eest (nt CD+kopeerimine)

PARANDUS – tõepoolest, Wolli (aka Peeter P. Mõtsküla) leidis punkti, mille ma olin kirja pannud lähtudes (levinud väär)uskumusest ja mitte teadmisest. I shall stand corrected. Tänud! Aga see jupp väärib täies mahus kommentaarist esile tõstmist (toimetatud mõni täheviga):

Tarkvara litsentsi eest ei tohi levitaja raha küsida, kuna GPL puhul saab iga järjekordne tarkvara koopia valdaja litsentsi algselt autorilt. Samas ei ole levitamise eest võetava tasu suurus mitte kuidagi piiratud. GPL ei kohusta ühtegi tarkvara koopia valdajat (sh algset autorit) seda levitama, kuid juhul kui koopia valdaja otsustab selle kolmandale isikule üle anda, peab ta koopiaga kaasa andma ka litsentsi (mille andjaks on algne autor) ja lähteteksti (või tagama kunstlike piiranguteta juurdepääsu lähtetekstile).

Ehk siis kirjutades kliendi tarbeks WordPressi plugina või luues/muutes kujunduspõhja peab selle tarkvaralise osa (aga mitte kujunduselementide) litsentsiks olema GPL. Seda ei pea hakkama aktiivselt levitama, aga kindlasti ei saa piirata kliendi õigust seda veel kusagil kasutada, sõbrale edasi anda… või kui teie teed peaksid lahku minema siis uuele arendajale edastada. Millega seoses tuleks mõelda ka koodi asjakohasele märgendamisele, kusagilt koodijuppi kopeerides peaks viitama allikale… ja ärimudelis ei saa arvestada kliendi enda külge sidumisega autoriõiguse meetodil.

Mõtlemist kui palju, nii juristide kui arendusprotsesside poole pealt – või on kellelgi pakkuda head lepingu-punkti ja selget juhist kõige selle koodi-kommenteerimise jaoks? Ma vaatan, et ka minu õpetustes kasutatavad jupikesed on kohati kopeeritud, mõnikord WordPressi seest, mõnikord Thematic’ust, mõnikord kellegi veebist ning ma pole näinud vaeva allikale viitamisega…

Edasilugemiseks aga 2 linki, esimene neist mullune Matt Mullenwegi seisukohavõtt ja teine kokkuvõte suvisest Matti ja Chris Pearsoni ‘tulisest twitterivaidlusest’:

TÄIENDUSEKS – uurides Gravity Forms’i mis on GPL all tasuline plugin leidsin huvitava intervjuusarja WPblogger’ilt – GPL Week kus vastavad StudioPress’i Brian GardnerWooThemes’i Magnus Jepsonpress75 ja ThemeGarden’i Jason Schuller ja Gravity Forms’i Carl Hancock. Soovitan soojalt…

Postitatud rubriiki wordpress | Sildistatud , , , | Kommenteerimine suletud

kolimine, ümbersuunamine ja htaccess

Eelmisest postitusest nähtub minu suur vastumeelsus linkrot’i suhtes – veebiplatvormi vahetuse, olulise ümberseadistamise jms puhul tuleks näha veidi vaeva ja teha nii, et otsimootorist või talletatud lingiga saabuv kasutaja (samuti otsimootor ise :-) saaks 301 Moved Permanently abil ümber suunatud sinna kuhu ta minna tahtis ehk siis uuele ja toimivale lingile.

Osa neist ümbersuunamistest on lihtsalt tuletatavad – kataloogimuudatused, id=123, Google Webmaster Tools’ist sisenevad lingid jne – aga kindlasti jääb midagi ka 2silma vahele ning siis ei aita muu kui vaadata milliste URLide peale 404-errorit serveeritakse ning korduma kippuvad vead ära lappida. WordPressile on mitmeid pluginaid mis seda protsessi hõlbustavad, mulle meeldib Redirection mille abil saab ka tavakasutaja kohe ümbersuunamise korraldada. Ja kuigi Redirection toetab ka .htaccess’i kasutamist (kiirem kui WordPressi sisemised vahendid) on mul tavaks keerukamaid suunamisi otse .htaccessis korraldada.

.htaccess on mitmete veebiserverite puhul kasutatav konfiguratsioonifail mis lubab teha lokaalseid muudatusi serveri seadistustes, mõjudes .htaccess’i sisaldavale kataloogile ja selle alamkataloogidele; punkt failinime alguses tähendab peidetud faili, harilikult saab FTP-programmi seadistada neid näitama, OSX jaoks leiab õpetused ja automaatori

Kui WordPressil on seadistatud permalingid näeb .htaccessi sisu välja selline (viimase reaga kehtestatakse Mediatemple majutuses PHP5 kasutamine – ehk siis on tegu failiga mille kallal mässavad erinevad tegelased):

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
AddHandler php5-script .php

Lisades WP Super Cache või W3 Total Cache on tulemus oluliselt pikem ning vähemalt viimane tekitab täiendavaid .htaccess’e ka mõningatesse alamkataloogidesse. Kuna käsitsi lisatud suunamised võiksid käia üle kõigist programmilistest tuleks need panna faili algusesse, näiteks selliselt:

# BEGIN tehnokratt.net
<IfModule mod_rewrite.c>
Options +FollowSymLinks
RewriteEngine On
# siia kohta käivad kõik alljärgnevad näited
</IfModule>
# END tehnokratt.net

Alustaks millestki lihtsamast, suunaks mõned URLid lihstalt ümber kasutades rewrite’i (need lihtsamad saaks ka lihtsalt redirectida… aga kasutame parem algusest peale rewrite’i mis lubab teha põhjalikumat teisendust kus vaja). Esimene rida suunab esilehele päringu mis hakkas mind 404-logis segama (ilmselt soovis keski/miski leida Windowsi serverit), teine rida suunab vana veebi RSSi aadressi kenasti Feedburnerisse ümbes:

RewriteRule ^netlogon$ / [R=301,NC,L]
RewriteRule ^xml/rss.xml$ http://feeds.feedburner.com/tehnokratt/pets [R=301,NC,L]

Siinkohal ^ tähistab URLi pathi algust ja $ lõppu, NC ehk no case samastab suured ja väiksed tähed ning L ütleb, et selleks korraks on küll asendatud. Mäletamist mööda on .htaccess nende parameetrite osas suht noriv, nt ilutühikute lisamine [R=301,NC,L] vahele võib kõik nässu keerata.

Kui tahad põhjalikumat õpetust, siis minu püsi-bookmarkide hulgas on Stupid htaccess Tricks,  .htaccess tips and tricks ja more .htaccess tips and tricks. Kogu redirectimise teema lahtikirjutus neile kes lugeda viitsivad on The anatomy of a server sided redirect: 301, 302 and 307 illuminated SEO wise. Eriline au ja kuulsus saavad mõistagi saatma neid, kes endale ka regexi selgeks teevad, nt regular-expressions.info abil :-)

Edasi … vanast veebist üle toomisega jäid artiklite-uudiste numbrid samaks, aga muutus oluliselt see kuidas nende poole numbriliselt pöördutakse:

RewriteRule ^stories/storyreader\$([0-9]+) /index.php?page_id=$1 [R=301,NC,L]
RewriteRule ^discuss/msgreader\$([0-9]+) /index.php?p=$1 [R=301,NC,L]

Ehk siis pärast storyreader$ olevad numbrid (aga mitte seda, mis võib tulla pärast numbreid) antakse edasi page_id’na. Sama lahendus tiba klassikalisemaks juhuks ehk kui lehenumber on antud parameetrina võiks välja näha järgnev (arvestades võimalust, et id ei pruugi olla esimene parameeter… ohjah, seda saab vist ka ilusamalt teha aga hetkel on kell liiga öö et katsetada, lisaks tuleks välistada olukord kus see takistab mõnede id= kasutavate admin-pluginate toimimist):

RewriteCond %{QUERY_STRING} ^id=([0-9]+) [OR]
RewriteCond %{QUERY_STRING} &id=([0-9]+)
RewriteRule ^(.*) /?page_id=%1 [R=301,NC,L]

Olgu lisatud, et kui vanast mitte-WordPressi veebist üle tulevad inimloetavad URLid ei vasta WordPressi hierarhiale st enne oli /meeseep ja nüüd /tooted/seebid/meeseep siis selline ümbersuunamine toimub täiesti automaagiliselt – seda suunamist võib muideks ka teadlikult kasutada, nt avaldades reklaamis lühema URLi. Suunatakse muideks ka poolikud URLid, nt /mees -> /tooted/seebid/meeseep (mis võib kohati kukalt kratsima võtta, nt kui oled mõne lehe kustutanud ja külastajad täiesti suvalisele lehele sattuma hakkavad).

WordPress jälgib automaatselt ka postituste URLide ehk slugide muutumist ning suunab vanad uutele ümber. AGA ainult postituste puhul, lehe-slugi muutumise äratabamiseks on vaja Redirection’it.

Ja üks jupike veel, juhuks kui peaks olema vajadus iseleiutatud taksonoomia-slugid tagasi ametlikeks muuta:

RewriteRule ^teemad/(.*)$ /category/$1 [R=301,NC,L]
RewriteRule ^tagsonoomia/(.*)$ /tag/$1 [R=301,NC,L]

Ja veel mõned levinud näited, juhuks kui on vaja hüpata üle mõnest sisustamata alamlehest, muutub lehe permalink (nt toote nimi) või on vaja harmoniseerida üleslaetud dokumentide nimesid viies need mh kenasti otsimootoritele optimeeritud kujule:

RewriteRule ^alamleht[/]?$ /alamlehe/alamleht/ [R=301,NC,L]
RewriteRule ^tooted/meeseep/? /tooted/mesimummuseep/ [R=301,NC,L]
RewriteRule ^upload/files/mingi.pdf^ /misc/ilusa-nimega.pdf [R=301,NC,L]

Tänaseks kõik. Vigade parandus teretulnud, samuti kui kellelgi peaks olema kogemust mod_geoip kasutamisel – mis oleks, kui teeks rewrite’i mis suunab kõik ilma refererita esilehele saabunud Eesti IPga külastajad kenasti /et lehele? Või on miski muu hea nipp eristamaks äsja saabunud külastajaid neist, kes teadlikult ingliskeelse esilehe valivad? (ja sama ülesanne ka puhuks, kui avaleht on vaikimisi eestikeelne ja tahaks muumaalased saata ingliskeelsele)

Postitatud rubriiki wordpress | Sildistatud , , , , | Kommenteerimine suletud

veebimigratsioon wordpressi peale

Veebi üleviimine olemasoleva sisuhalduse pealt WordPressi peale ei pea olema meeletu käsitöö – pigem võiks kogu sisu ühe hooga üle tuua. Ja kuivõrd just sai kolitud senine Manila-põhine www.tehnokratt.net (v.a foorumiose) üle siia WordPressi-põhise tehnokratt.net’i peale on värskelt meeles kõik see mis seotud veebimigratsiooniga.

Executive brief – kõik alljärgnev on kole raju tehnospiik, aga kui Sa oled mõelnud tõsta oma senise veebi WordPressi peale siis ma heameelega aitan ja rakendan kõike kolekeerulist :-) Kui minu abi ei sobi, siis lisa vähemalt protsessikirjeldus hankele/töökäsule – et vot nii tuleb teha või veel paremini…

Minu meetod on selline:

  • genereerin algse veebi andmebaasist WXR ehk WordPress eXtended RSSi (sama formaati tekitab WordPress ise ekspordi käigus); kolhoosi puhul häkkisin ümber ühe varasema MovableType jaoks tekstifaili eksportinud skripti, aga kui sisu SQL-baasis siis kasutan SQL2RSS skripti koos mõningaste täienduste (utf8 tugi, WP-spetsiifiline kuupäevaformaat ja veel nipet-näpet) ja WXR-spetsiifiliste formaadifailidega – ja mis WXRi ei mahu nt erinevates keeltes lehtede seosed läheb kaasa metadata-väljadena
  • saadud tekstifail on hea võimalus teha esimest normaliseerimist – peamiselt saidisiseste linkide osas, mille puhul ?id=123 enam ei toimi – aga kuna artiklite numeratsioon tuleb kenasti üle siis võib need lihtsalt ?page_id=123’ks ümber asendada (n+1 lisaparameetri eemaldamine eeldab regexi-võimelise searchiga tekstieditori, minul TextWrangler saab täitsa hakkama :-)
  • WXR WordPressi sisse – ja kui kõik plaanipäraselt kulges peaks asi juba täitsa veebi moodi välja nägema… kuigi reaalses elus on kindlasti vaja veel midagi putitada ja sageli on seda mõistlik teha mõnes eelmises etapis (miska pole mõtet esimesel katsel normaliseerimist liiga tõsiselt võtta, äkki tuleb naasta andmebaasitõmmise juurde)
  • vahel juhtub, et algses süsteemis on eraldi numeratsioonid uudiste ja artiklite jaoks – kui nii, siis panen WXRi metadatana kaasa algse numeratsiooni, saan WordPressi baasist teada vanade ja uute numbrite vastavuse ning tekitan sellest Exceli kaasabil kaks tekstifaili – SQL käsud mille saab lasta peale postituste sisule eesmärgiga panna toimima varasemad saidisisesed uudistelingid ehk ?uudis=123 -> ?p=123 ja ning .htaccess jaoks rewrite’d mis tegelevad väliste vana-uudise linkidega
  • kui on tegu mitme keelega, siis kasutan WordPressis WPML.org pluginat ja eeldusel, et olen taibanud keelte-seose metadatana kaasa panna on umbes 1 lause SQLi mis postitused kenasti kokku seob
  • piltide ja failide puhul on lihtsalt ümberliigutamine lihtne, vajadusel tulnuks WXRis muuta kataloogirada ning tekitada rida .htaccessi mis välislingid ümber suunab – aga juhul kui nende nimetamises peaks esinema olulist saasta (täpitähed-tühikud mis URLis kenad ei ole, sama fail mitu korda jne) siis tuleb jällegi appi Excel, milles teen ümbernimetamise ja genereerin lisaks SQL ja .htaccess ridadele ka batchfaili ümbernimetamiseks – ning saadud ilusate nimedega failid lähevad WordPressi meediana üles
  • kui algsetes postitustes on sees kõvasti tarbetut HTML-märgendust (Word jms), siis tegelen sellega kas WXRis (regex oskus abiks) või kasutan Tidy Up pluginat (üldiselt toimib, aga kohati annab alla – ei ole olnud aega debugeerida)
  • lisaks panen uuele veebile peale Redirection’i mille 404-logi näitab ära sisenevad URLid mis mingil põhjusel ikkagi ei toimi – ning kohendan .htaccess või lisan sealsamas kiire suunamise, et lgp külastaja tulevikus 404 asemel midagi sisukamat näeks. ühtlasi toimib see kvaliteedikontrollina.

Üldjoontes selline mõnus andmete masseerimise ülesanne, natuke automaagiline ja natuke tüütu. Eriti tüütu on esimest korda kõike avastada ja käima jooksta. Sest olgu öeldud, et WXR parser on tiba pirtsakas ja vahel kulub aega saamaks aru, et teise postituse mitte-importimine on otseses seoses ühe täiesti normaalse väljaga RSS-kanali päises… või et threaded comments’i toimimise lõpetab see, kui esimese kommentaari parent’iks on sattunud postitus mida kommenteeritakse.

Postitatud rubriiki wordpress | Sildistatud , , , , , | Kommenteerimine suletud

wordpress ja teemaraamistikud

Lähedalseisjad teavad, et ma olen kevadest saadik agaralt (ogaralt?) tegelenud WordPressi õppimise … ja väikest viisi ka õpetamisega – nimelt hakkas mulle mingil hetkel sügavalt vastu tava alustada kujunduspõhja loomist nullist või iidsest standard-teemast nimega Kubrick. Samas kui saadavalt on hulk oluliselt vingemaid teemasid ja teemaraamistikke. Õigupoolest olingi ma alguses tasuliste profiteemade fänn (nt studiopress.com, greetings Brian! ), aga ühel hetkel võtsin ette suurema ringkäigu ja avastasin raamistikud ning eriti Thematic‘u (greetings, Ian & Chris!) sest …  Genesis‘t siis veel polnud.

Ja tasapisi hakkab kätte jõudma aeg seda kõike edasi õpetama hakata – mis vajaks aga kerget promo ja niisiis on mul valmimas ports ekraaniviisoreid mis aitavad algusega järje peale saada.

PARAKU … paistab, et ma suutsin pärast esimese video salvestamist jätkata normaalse mikrofoni asemel sisemikiga mistõttu need videod tuleb ümber teha AGA äkki on lgp lugejatel/vaatajatel ka mingeid sisulisi soovitusi mida peaksin teisiti tegema, nt õpetan ma CSSis midagi sellist mida mitte mingil juhul ei tohiks teha?

EHK kui viitsid vaata ja kommenteeri siinsamas – kui tahad sõbrale jagada saada Youtube playlisti link, sest üksikud videod lähevad väljavahetamisele. Ja vaadata on mugavam minu channel’i pealt :-)

Kui pildist jääb silma, et mul on enda tarbeks kasutusel mõned tekstifailid stiili- ja funktsioonipõhjadega, siis need ja video käigus tehtud childtheme’i leiab:

Postitatud rubriiki sahteldamata asjad | Kommenteerimine suletud