Am facut astfel o mini-traducere pe care o folosesc si pe siteurile mele pentru vizitatori, practic am tradus doar lunile anului si zilele saptamanii (de restul elementelor din tema de WordPress se ocupa fiecare), interfata mai bine ramane in engleza.

Download

Arhiva contine fisierul ro-date.mo

Cum se foloseste?

1. Se adauga fisierul in wp-content/languages (se creaza folderul daca nu exista)
2. Se modifica in wp-config.php linia cu WPLANG in define('WPLANG', 'ro-date');
3. Atat :)

O optiune vehiculata de unii si altii ar fi modificarea locale.php. Da, e si aia o optiune, dar sa rescrii fisierul la fiecare update de Wordpress nu e tocmai o solutie…

Daca tu iti scurtezi linkurile prin sp2.ro spre exemplu – apropo, pluginul Twitter SP2 o sa primeasca zilele astea un update major – de ce ai vrea sa ai inca un link asociat postului care sa fie folosit automat de crawlere drept link scurt?!?

Versiunea 1.6.1 a Wordpress.com Stats practic te obliga sa folosesti si serviciul Wordpress de scurtare a URL-urilor – wp.me.

Cum se scoate?

Se adauga in fisierul functions.php din tema activa o bucatica de cod:

    remove_action('wp_head', 'shortlink_wp_head');
    remove_action('wp', 'shortlink_header');

Solutia se numeste CSS separat, CSS care sa nu fie rescris la primul update de WordPress. Dar imaginea? Si imaginea o schimbam, doar e adaugata prin CSS.

Exista practic doua variante de a face modificarile:

• fie sub forma de plugin
• fie adaugand instructiuni in functions.php din tema activa

Diferenta intre cele doua variante e ca daca transformam mica functie in plugin va trebui sa accesam altfel fisierele imagine folosite (si nu le vom putea adauga in tema – ca nu pot fi accesate dinamic).

O sa prezint varianta cu function.php

Toate modificarile de CSS trebuie rulate in pagina de login. Un hook bun unde se poate adauga functia ce urmeaza sa fie folosita e login_head

ATENTIE: pagina de login nu ruleaza actionul admin_head ca restul interfetei de administrare

Avem instructiunea

add_action( 'login_head', 'dece_custom_login' );

Ce spune codul de mai sus? Pentru login_head ruleaza functia dece_custom_login. Perfect.

Sa scriem si functia

Fisierul pe care-l vrem in locul logo-ului de WordPress pentru pagina de login trebuie urcat undeva online. Eu l-am plasat tot in folderul temei active, in /images. Pe mai departe il putem accesa cu

<?php bloginfo( 'template_directory' ); ?>/images/logo-login.gif

Mai avem ceva de modificat? Nu neaparat.

Eu spre exemplu pe blog am ales sa modific si culoarea butonului de logare din albastru in rosu. CSS-ul defineste si o imagine cu un gradient dragut de albastru, eu mi-am facut una pe rosu pe care am adaugat-o tot in folderul cu imagini ale temei active, imagina accesabila cu

<?php bloginfo( 'template_directory' ); ?>/images/button-grad.png

Deci functia care se ocupa de modificarile de CSS pe care le-am dorit la deceblog arata cam asa:

function dece_custom_login() { ?> 
	<style type="text/css">
		h1 a { background:url(<?php bloginfo( 'template_directory' ); ?>/images/logo-login.gif) no-repeat 70px 10px; height:75px;}
		#login form .submit input { background: #b83939 url(<?php bloginfo( 'template_directory' ); ?>/images/button-grad.png) repeat-x scroll left top; !important border-color:#b83939; !important }
        .submit .button-primary, #login form .submit input {border-color:#b83939 !important}
		#login form .submit input:hover {border-color:#b83939 !important}
 
	 </style>
<?php  
}

Ce zice CSS-ul de mai sus?

Pune imaginea pe care o vreau eu la 70px distanta de marginea stanga si 10px de cea de sus (ca sa arate centrat), dupa care schimba dimensiunea elementului la 75px (default 67px).

Fa butonul de logare rosu #b83939 si adauga-i imaginea mea ca background.

Codul final este

function dece_custom_login() { ?> 
	<style type="text/css">
		h1 a { background:url(<?php bloginfo( 'template_directory' ); ?>/images/logo-login.gif) no-repeat 70px 10px; height:75px;}
		#login form .submit input { background: #b83939 url(<?php bloginfo( 'template_directory' ); ?>/images/button-grad.png) repeat-x scroll left top; !important border-color:#b83939; !important }
        .submit .button-primary, #login form .submit input {border-color:#b83939 !important}
		#login form .submit input:hover {border-color:#b83939 !important}
 
	 </style>
<?php  
}  
 
add_action( 'login_head', 'dece_custom_login' );

Save functions.php :)

Modificarile vor persista si dupa un update/upgrade de Wordpress in caz ca nu schimbi tema.

Problema e ca paginarea comentariilor o data activata creaza continut duplicat, chiar daca nu exista destule comentarii incat sa fie generate 2 pagini. Linkurile comentariilor sunt de forma /titlu-post/comment-page-X/#comment-Y. Unde X e numarul paginii de comentarii (standard: 1), iar Y id-ul comentariului.

Continutul de pe pagina 1 de comentarii este identic cu cel de pe pagina postului. In Webmaster Tools, Google semnaleaza problema la titlu si la descriere, dar continutul e in aceasi oala. Rezolvarea e totusi simpla.

Am vorbit mai demult despre cum se evita continutul duplicat in Wordpress. Solutia e o simpla extensie a codului pentru generarea metatagului Robots.

Daca pana la Wordpress 2.7 aveam nevoie in principiu doar de urmatoarele linii pentru a evita continutul duplicat

Codul vechi

<?php if (is_archive() || is_paged()) { ?> 
    <meta name='Robots' content='noindex, follow' /> 
<?php } else { ?> 
    <meta name='Robots' content='index, follow' />
<?php } ?>

Incepand cu WordPress 2.7 trebuie sa mai verificam si paginarea comentariilor cu o functie provizorie (pana cand apare o functie conditionala si pentru paginarea comentariilor) – despre get_query_var('cpage'). Deci codul de pus in <head> devine:

Codul nou

<?php if (is_archive() || is_paged() || get_query_var('cpage')) { ?> 
    <meta name='Robots' content='noindex, follow' /> 
<?php } else { ?> 
    <meta name='Robots' content='index, follow' />
<?php } ?>

Explicatie

Daca suntem pe pagina de arhive, ori daca suntem pe pagina Y a comentariilor, robotii nu vor indexa continutul, dar vor urma linkurile intalnite.

Versiunea WordPress 2.1, nume de cod Ella, aparuta pe 22 ianuarie 2007, introducea optiunea de a avea feed-ul blogului “taiat” te tagul more, daca era folosit, continutul din feed fiind la fel ca in pagina de blog – asta pe langa optiunea de feed partial (primele 55 de cuvinte din post, text neformatat, fara paragrafe, headinguri, liste sau linkuri), aparuta in wordpress 1.5.

Exista o solutie pentru cei care nu doresc sa aiba nici feed complet, dar nici unul ciuntit, ci limitat de tagul “more” cum era in versiunile pre-2.5:

Better Feed Plugin

Un plugin care permite limitarea feedului la tagul more, adaugarea numarului de comentarii la post in feed, numarul de cuvinte ramase in post, adaugarea unui link de “add to del.icio.us” si alte optiuni care fac optiunea FeedFlare din Feedburner cam inutila [ :) ].

Ca sa nu fie destul, pluginul permite adugarea oricarei informatii in footerul feedului: de la note de copyright pana la reclame (!)

Download

PS: nu stiu daca pluginul functioneaza si pentru versiuni mai vechi de 2.5 de wordpress

Pentru un blog care are mai multi editori si/sau autori poate fi o optiune interesanta, dar pentru blogurile cu un singur autor este un feature care doar umple baza de date in mod stupid la fiecare save pe care il primeste postul.

Practic la fiecare editare si salvare in baza de date mai apare o versiune a postului. Ceea ce e rau! Baza de date devine imensa si merge mai greu. Eu de exemplu editez si de 10 ori un post. Mai uit o virgula, mai apas un save din obisnuinta, mai fac cate un typo…

Pentru a opri post revision

O editare mica in fisierul wp-config.php

define('WP_POST_REVISIONS', false);

Pentru a sterge posturile in plus, versiunile suplimentare adica, e nevoie de acces la phpMyAdmin. Un backup inainte de pas ar fi util :)

Deci un query mic in baza de date si posturile in plus sunt sterse:

DELETE FROM wp_posts WHERE post_type = 'revision';

Vivat Wordpress 2.6

Dupa cateva luni bune doar cu taguri mi-am dat seama ca unele taguri sunt mult prea stufoase ca sa ramana taguri / etichete si ca de fapt arata mai degraba a categorii. Diferenta practic nu e foarte mare, dar e vorba de semantica si sens. Era prea general un tag de genul “Internet”.

Pentru Wordpress 2.3 – 2.7

Exista o modalitate destul de simpla de a reveni la categorii (partial sau total). Este nevoie de acces la phpMyAdmin.

In tabela wp_term_taxonomy se modifica proprietatea taxonomy din post_tag in category cam ca in imaginea de mai jos:

E simplu, dar se recomanda un backup inainte de orice modificare a bazei de date.

Pentru Wordpress 2.7+

De la versiunea Wordpress 2.7 exista posibilitatea de a converti tagurile in categori din cadrul interfetei de administrare, adresa de unde se pot face modificarile este /wp-admin/admin.php?import=wp-cat2tag&step=3

Se pot converti toate tagurile in categorii si vice-versa sau se pot selecta o serie de taguri care sa fie convertite. De asemenea Wordpress-ul identifica dublurile (tagurile care au acelasi nume ca si o categorie) cu un asterisc.

E stiut faptul ca Google penalizeaza destul de rau continutul duplicat. Cum? Prin neindexare. Indexeaza o singura locatie a textului, nu toate. In acelasi timp, structura Wordpress este de asa maniera incat exista nu una, ci multe modalitati de a ajunge vazut de motoarele de cautare cu continut duplicat.

Continutul duplicat in Wordpress

Exista in primul rand paginile de post, apoi categoriile, tagurile si arhivele; exista paginare pentru prima pagina, pentru categorii, pentru taguri si pentru arhive, desi continutul este dat doar de posturi.

Practic acelasi text ajunge sa fie vazut de motoarele de cautare o data pe prima pagina a blogului, o data pe pagina de post, apoi intr-un tag sau mai multe, intr-o categorie si intr-un final in arhiva pentru luna publicarii (plus arhiva de autor – in cazul in care e un blog colectiv), deci continut duplicat.

Odata cu cresterea numarului de posturi textul trece pe o pagina 2 a blogului, a categoriei, a tagurilor si a arhivei lunare. In functie de frecventa de indexare exista riscul ca acelasi text sa fie vazut la peste 10 url-uri diferite si indexat doar intr-o singura parte.

Indexarea postului

De preferat este ca indexarea sa se faca pe pagina postului, pagina articolului, nu o indexare variabila, ba pe pagina 5 a tagului, ba pe pagina 10 a blogului sau 13 a arhivei. E continut duplicat si este indexat doar pe pagina care are cel mai bun linking intern. O sa revin intr-un episod viitor cu cateva reguli pentru o cat mai buna indexare a postului.

Noindex pentru arhive

Cu un pic de php, folosind functii wordpress, se evita relativ usor situatia de mai sus, cu ajutorul unui meta-tag – robots.

Setam ca textul sa fie indexat doar pe pagina de post, pe prima pagina si pe paginile statice, iar in cazul arhivelor (temporale, de taguri, de categorii, de autor, etc) sa fie urmarite doar linkurile, fara ca textul sa fie indexat.

<?php if (is_archive()) { ?>
   <meta name='Robots' content='noindex, follow' />
<?php } else { ?>
   <meta name='Robots' content='index, follow' />
<?php } ?>

Codul fiind scris oriunde in <head>, deci in fisierul header.php.

Functia is_archive() raspunde TRUE pentru afisarea posturilor din arhivele de orice fel: categorii, taguri, de autor, temporale, deci ramane de evitat

Continutul duplicat pentru paginarea blogului

ex: www.decetutorial.net/page/2

Adaugam is_paged() ca si conditie in codul de mai sus si avem:

<?php if (is_archive() || is_paged()) { ?>
   <meta name='Robots' content='noindex, follow' />
<?php } else { ?>
   <meta name='Robots' content='index, follow' />
<?php } ?>

All in one SEO Pack

Pentru cei care folosesc pluginul All in one SEO Pack (prost si inutil din punctul meu de vedere) solutia de evitare a continutului duplicat e si mai simpla. Are intre optiuni “noindex for …”. E de la sine inteles ce face.

Indexare arhive si posturi

Exista totusi o solutie in Wordpress de indexare a posturilor dar si a arhivelor (ori de care am vorbi – categorii, taguri, etc), fara a avea continut duplicat, dar care necesita ceva mai multa munca la un blog cu multe texte deja scrise. Dar despre ea voi vorbi pe larg intr-un alt episod din serialul SEO Wordpress. ;)

Parca nu ti-ai dori sa citesti texte de jos in sus, din pagina 4 in pagina 3 si asa mai departe, sa nu stii exact care e primul post si care ultimul.

Solutia e simpla, un query string special pentru categoria pe care o doresti ordonata in ordine cronologica.

In mod normal loop-ul pentru afisarea posturilor arata ceva in genul asta:

<?php while (have_posts()) : the_post(); ?>
<div class="post">
bla-bla-uri pentru post
</div><!-- end post -->
<?php endwhile; ?>

Alterarea codului se face inaintea loopului/codului de mai sus printr-o line simpla:

<?php if (is_category('serialul-meu')) {
   query_posts($query_string . 'orderby=date&order=asc'); 
} ?>

Unde serialul-meu reprezinta slug-ul (sau url-ul) categoriei dorite pentru ordonare.

De asemenea, in loc de is_category si category= poate fi scris si is_tag, respectiv tag=, daca ordonarea se face pentru un anumit tag.

PS: daca exista intre fisierele temei de Wordpress care se doreste modificata un archive.php modificarea se face acolo, daca nu – in index.php

O serie de bloggeri mi-au spus ca simt uneori ca nu le ajunge casuta de text (textarea de compunere) din Wordpress si le vine greu sa compuna acolo, prefera sa-si scrie textele intr-un editor, unul mai mare, mai lat, mai lung, mai spatios, care sa nu inghesuie textul, in care sa nu fie nevoie multe scrolluri, si abia apoi sa le treaca in Wordpress. Vorbesc despre cei care nu folosesc optiunea Use the visual editor when writing si scriu in code mode.

E curios, unii se sperie de foaia goala/ecranul gol si se simt inhibati, nu pot sa scrie. Pe altii ii inhiba tocmai spatiul redus de compunere, ca cel din Wordpressul standard. Exista si o categorie de bloggeri, zic eu mai speciala, care nu sunt inhibati in fata foii sau a ecranului, indiferent de dimensiunea spatiului de scriere, ci sunt doar deranjati de dimensiuni. Pe mine unul m-a incantat totdeauna interfata Wordpressului, imi pare relaxanta si atragatoare, exact asa cum e.

Astazi mi-am adus aminte ca la un moment dat (cand aveam timp de texte mai analitice, mai personale ori pur si simplu mai lungi) am vrut si eu casuta de compunere mai mare si am marit-o. Cine ghiceste cum se face asta? Chiar amuzant de simplu:

In Options > Writing exista optiunea “Size of the post box:” exprimata in numar de linii.

Standardul e de 10 linii (cam putintel spatiu, daca ma gandesc acum), dar dimensiunea casutei de editare poate fi schimbata dupa bunul plac cu valori cuprinse intre 3 si 100.

Eu mi-am adaptat-o pentru lungimea medie a posturilor de pe blog, recomand o setare asemanatoare. De exemplu: pe deceblog am 20 de linii, pe blogul de tutoriale 30 etc.