Ca imagine generală căutările în WordPress nu sunt grozave, iar afișarea chiar rea:
Caută toți termenii în titlurile postărilor.
Caută orice termen din șirul de căutare în titlurile postărilor.
Potriviri complete ale șirului de căutare în conținutul postării.
Orice termen în conținutul postărilor
Rezultatul este afișat în ordinea descrescătoare a datei publicării postărilor.
Cum subiectul tutorialului nu este optimizarea căutărilor în WordPress voi mai insista doar un pic, cu un exemplu: dacă termnii căutați sunt într-un articol mai vechi, deși este poate mai relevant, el se va găsi spre coada căutărilor, conform cu vechimea lui. Asta pentru că WordPress nu are un sistem complex, nu filtreză după „cele mai citite”, „cele mai apreciate” sau „cele mai relevante, asta ca să dau doar câteva exemple. Așa că pentru o căutare mai eficientă fie folosiți Google, fie pluginuri.
Cum poți limita sau extinde căutarea în WordPress?
Revenind, căutarea WordPress se face în articole și pagini. Dacă dorim să adăugăm și alte taxonomii putem proceda în felul următor:
function wp_search_filter( $query ) {
if ( $query->is_search ) {
$query->set( 'post_type', array('post','page') );
}
return $query;
}
add_filter('pre_get_posts','wp_search_filter');
Avem o matrice cu elementele în care să se facă căutarea:
WordPress oferă mai multe metod condiționale e ce vă permit să identificați locul în care sunteți. Prima pagină, articol, pagină sau arhivă. Cele două is_home() și is_front_page() par la fel și în unele situații chiar sunt identice. Totuși sunt și diferențe, importante.
Când utilizezi id_home() și când is_front_page()?
Așadar: is_front_page () returnează true dacă utilizatorul se află pe pagina sau pagina de articole, care este setată pe prima pagină din Setări -> Afișare.
Setarea primei pagini
Deci, dacă setați pagina „Prima pagină” sau oricare alta ca primă pagină, atunci condiționalul is_front_page() va fi cel potrivit. El va returna true, dacă sunteți pe pagina respectivă sau pe pagina selectată la „Pagină articole”.
Celălalt condițional e util să vă identifice pagina setată la „Pagină articole”. Pe acestă pagină is_home() va returna true în timp ce is_front_page() va returna false.
Pe de altă parte, dacă setările din afișare a paginii dvs. de pornire sunt lăsate în mod implicit (fișierul index .php sau home.php), atunci pagina de pornire va returna true atât pentru is_front_page(), cât și pentru is_home().
Înțelegeți acum diferența dintre cele două?
Un exemplu de utilizare is_home(): ați setat pagina de postări la o pagină numită Știri. Când un utilizator ajunge acolo doriți ca în antet să afișați un meniu suplimentar. Puteți utiliza is_home() pentru a face acest lucru.
Am găsit că în unele situații cele două metode condiționale nu oferă acuarețea așteptată. (unii dezvoltatori spun că problema apare mai ales în siteurile multisites). Soluția de mai jos nu-mi aparține. Ea folosește matricea de sistem $_SERVER astfel:
if ($ _ SERVER ['REQUEST_URI'] == '/') {
// trebuie să fii pe pagina principală
}
Atenție, metoda nu nu va funcționa pentru instanțele WP instalate în subdirectoarele rădăcinii web. Testați înainte de a pune în producție.
Dacă sunteți developer și lucrați după un design primit, atunci e posibil să întâlniți situația în care într-un blockquote să aveți inserat de designer un div.
Add <div></div> to default blockquotes in WordPress
Sunt două locuri unde puteți insera divul, fie deasupra paragrafului, fie dedesubt:
<blockquote class="wp-block-quote">
<div class="top_quote"></div>
<p>Etiam malesuada finibus dolor, non vulputate dui auctor a. Sed iaculis felis in rhoncus pharetra. Cras sit amet commodo purus, quis faucibus augue.</p>
</blockquote>
sau:
<blockquote class="wp-block-quote">
<p>Etiam malesuada finibus dolor, non vulputate dui auctor a. Sed iaculis felis in rhoncus pharetra. Cras sit amet commodo purus, quis faucibus augue.</p>
<div class="top_quote"></div>
</blockquote>
Pentru a rezolva problema aveți nevoie de jQuery. Această bibliotecă este de multe inserată de temă (verificați), dacă nu trebuie să o inserați manual:
Se poate întâmpla ca pe site / blog să apară uneori warninguri sau noticeuri generate fie de vreun plugin nou, fie de temă sau chiar de WordPress. Aceste atenționări apar de obicei la schimbările de versiune PHP, când dezvoltatorii de pluginuri rămân în urmă, sau, din contră, o iau înainte și versiunea de PHP de pe server este prea veche.
Noțile sunt enervante pentru că arată urât, ba chiar și mai rău, pot fi indexate de google.
Cum le eliminăm?
Cea mai la îndemână soluție este să se verifice directiva din fișierul wp-config.php:
define( 'WP_DEBUG', false );
Este important ca acest parametru să fie setat FALSE. Varianta de TRUE este rezervată depanării codului php de către dezvoltatori.
Dacă chiar și cu WP_DEBUG pus pe FALSE tot apar warningurile și / sau notice, atunci înseamnă că e o setare de server. Pentru a le inhiba apariția mesajelor, înlocuiți directiva de mai sus cu:
WordPress 5.8 întărește tendința, observabilă încă de la versiunea 5.6, de a se trece editarea pe blocuri. De data asta se face un pas în plus, prin modificarea zonei de editare a pieselor / widgeturilor. În locul clasicelor coloane vom avea, începând cu acestă versiune, un editor cu blocuri. Pentru cei care nu au trecut încă la editorul cu blocuri, sau nu vor să treacă din diverse motive, comunitatea WordPress oferă un plugin ce păstrează forma clasică a editării widgeturilor.
Exemplu:
1. sistemul clasic de piese
2. noul editor de piese
Administrează piesele cu blocuri
După luni de muncă grea, forța blocurilor a ajuns în Editorul de piese cu blocuri și în Personalizator. Acum poți adăuga blocuri în zonele pentru piese din site, dar și folosind previzualizarea live din Personalizator. Deschidem noi posibilități de a crea conținut: de la aranjamente simple care nu necesită cod, până la biblioteca de blocuri de bază și terțe, care este în continuă creștere. Găsești mai multe detalii în nota pentru dezvoltatori privind piesele.
Principalele modificări aduse de WordPress 5.8
Înlăturăm suportul pentru Internet Explorer 11
Începând cu această versiune, înlăturăm suportul pentru Internet Explorer 11. Este posibil să ai probleme la administrarea site-ul tău, dar acestea nu vor fi rezolvate în viitor. Dacă în prezent utilizezi IE11, îți recomandăm insistent să folosești un navigator modern.
Adăugăm suport pentru WebP
WebP este un format modern pentru imagini pe web care oferă o comprimare îmbunătățită, cu sau fără pierderi. Imaginile WebP sunt cu aproximativ 30% mai mici decât alternativa lor, JPEG sau PNG, deci site-urile care le folosesc sunt mai rapide și utilizează o lățime de bandă mai mică.
Adăugăm suport suplimentar pentru blocuri
WordPress 5.8 extinde suportul pentru blocuri, anterior implementat în WordPress 5.6 și 5.7, introducând câteva marcaje noi de tip supports pentru blocuri și opțiuni noi pentru a-ți personaliza blocurile înregistrate. Sunt disponibile mai multe informații în nota pentru dezvoltatori privind suportul pentru blocuri.
Comentarii recente