Tag Archives: Wordpress

Как да използваме Autoptimize с HTTP/2

от Гонзо
лиценз CC BY-NC-SA

В по-новите версии на Autoptimize има възможност чрез филтър да съставите списък с разрешени за обединяване скриптове. Това позволява да обедините скриптовете, които са задължителни за всички страници в сайта и да оставите скриптовете, които се зареждат само на определени страници извън пакета. Това решава и един друг проблем с Autoptimize – когато различни скриптове се зареждат на различни страници, пакетите, които се генерират са различни. Това води до безконтролно увеличаване на кеша на Autoptimize и до забавяне на зареждането за потребителите, защото вместо да заредят кеширан файл, всеки път теглят различен.

И така, да започнем с обединяването на задължителните скриптове:

/**
 * Whitelist scripts to autoptimize
 *
 * @return: whitelist
 */
function gonzo_js_whitelist() {
  $whitelist = array(
    'jquery.js',
    'jquery-migrate.min.js',
    'wp-embed.min.js'
  );
  return join( ',', $whitelist );
}
add_filter( 'autoptimize_filter_js_whitelist', 'gonzo_js_whitelist' );

След като вече имаме пакет с най-важните скриптове, нужни за сайта, трябва да се погрижим за две неща:

  • Да зареждаме обединените скриптове преди останалите, защото пакетът съдържа jQuery, а някои от останалите скриптове най-вероятно разчитат на него.
  • Да зареждаме скриптовете асинхронно, за да не блокират изобразяването на страницата.

Генерираният от Autoptimize скрипт елемент може да поставим веднага след елемента title така:

/**
 * Where in the HTML optimized JS is injected.
 *
 * @param array $replacetag, containing the html-tag and the method (inject "before", "after" or "replace")
 * @return array with updated values
 */
function gonzo_override_js_replacetag( $replacetag ) {
    return array( '</title>', "after" );
}
add_filter( 'autoptimize_filter_js_replacetag', 'gonzo_override_js_replacetag', 10, 1 );

За да зареждаме всички скриптове асинхронно, и в същото време последователно, ще добавим атрибут defer към тях. Така скриптовете не само се зареждат асинхронно, но и не блокират изобразяването на страницата когато се изтеглят. Освен това атрибута defer кара скриптовете да се изпълнят по реда в документа.

/*
 * Defer all javascripts
 */
function gonzo_defer_js($tag, $handle) {
  if( ! is_admin() ){
    $tag = str_replace( ' src', ' defer="defer" src', $tag );
  }
  return $tag;
}
add_filter( 'script_loader_tag', 'gonzo_defer_js', 10, 2 );

/**
 * Change flag added to Javascript.
 *
 * @param $defer: default value, "" when forced in head, "defer " when not forced in head
 * @return: new value
 */
function gonzo_override_defer( $defer ) {
  return "defer ";
}
add_filter( 'autoptimize_filter_js_defer', 'gonzo_override_defer', 10, 1 );

И на края, за да гарантираме, че скриптовете ще се кешират правилно от браузърите и прокситата, ще премахнем GET променливата с версията, която WordPress добавя към адресите на всички ресурси:

/*
 * Remove query string from static assets
 */
function gonzo_remove_script_version( $src ){
  return remove_query_arg( 'ver', $src );
}
add_filter( 'script_loader_src', 'gonzo_remove_script_version' );

Естествено, подобен подход можем да приложим и към CSS файловете, които сайта зарежда. На края ще имаме бърз сайт за удоволствие на потребителите и печалба на клиента.

Експортиране на заглавия, съдържащи HTML, от WordPress

от Гонзо
лиценз CC BY-NC-SA

WordPress позволява да се въвежда HTML на много места, на които не бихте си помислили да го направите. Например заглавията на публикациите – например за да откроите някои думи, да маркирате правилно абревиатура или по друга причина. Например повечето статии в „Как се пише“ съдържат HTML, за да откроят думите, за които се отнася статията. Обаче ако ви се наложи да експортирате това съдържание, ще откриете, че заглавията са изчистени от всякакъв HTML и форматирането е загубено. Така стандартният експорт на WordPress става безполезен за пазене на архив на съдържанието или за прехвърлянето му на друга инсталация. Обаче има лесно решение.

Ако поровите в кода на функцията export_wp(), ще видите две интересни неща:

  1. Там е дефинирана функцията wxr_cdata(), която затваря подадения стринг в CDATA блок.
  2. Заглавията на публикацитиите се филтрита през филтъра the_title_rss.

Значи за да можем да експортираме заглавията заедно с HTML-а, трябва да махнем от този филтър функцията, която чисти HTML-а (strip_tags естествено, както и esc_html()) и да добавим wxr_cdata(). Всъщност това второ няма да стане, защото функцията е дефинирана само в контекста на export_wp(), така че ще трябва просто да я клонирате.

function htr_cdata_post_title ( $title ) {
	$title = '<![CDATA[' . $title . ']]>';
  return $title;
}
add_filter( 'the_title_rss', 'htr_cdata_post_title' );

remove_filter( 'the_title_rss', 'strip_tags' );
remove_filter( 'the_title_rss', 'esc_html' );

Това е всичко, при… опа, това беше от друго шоу.

Установяване на правилен локал на формите, създадени с Contact Form 7

от Гонзо
лиценз CC BY-NC-SA

Наскоро ми се наложи да правя сайт с WordPress на Иврит. За незапознатите с особеностите на близкоизточните езици ще напомня, че се пишат от дясно на ляво и нямат главни букви. Освен това чуждите думи, изписани на латиница (или друга писменост, която се пише от ляво на дясно), както и числа, изписани с арабски цифри, се пишат както си трябва – от ляво на дясно. WordPress поддържа достатъчно добре всякакви писмености и езици, правилната локализация също е важно условие за одобряване на темите в wordpress.org. Аз обаче се сблъсках с един проблем на разширението Contact Form 7, който не е очевиден, когато сайтът е на език, изписван от ляво на дясно. В случая с Иврит обаче, въпреки че всичко останало по сайт сменяше посоката на подравняване на текста и елементите, полетата във формата оставаха подравнени вляво. Бърз преглед на генерирания HTML показа наличието на атрибути lang и dir на елемента, който съдържа формата, за манипулиране на които атрибути няма настройка. Проблемът е, че в моя случай тези атрибути имаха стойности като за английски локал, което не само, че обръщаше подравняването на текста, но би имало неприятни последици и за потребителите на екранни четци – ако екранният четец превключи на друг език, това би било най-малкото доста объркващо.

След кратко търсене в сайта на разширението и в Гугъл намерих въпрос, зададен от потребител, използващ Contact Form 7 в многоезичен сайт на английски и арабски. Неговият проблем беше подобен на моя – формите на арабски си оставаха подравнени вляво. Отговорът за мен изглежда доста нелепо: локала на формата се установява на базата на локала на администрацията по време на създаване на формата и се наследява при клониране на формата. При условие, че често в многоезичните (а и не само) сайтове администраторите на сайта използват локал, различен от този на публичния сайт, и като имаме предвид, че новите версии на WordPress дават възможност в администрацията потребителите да избират локал, различен от основния локал на сайта, това поведение на Contact Form 7 има сериозни последствия върху достъпността на сайта. Проблемът може да се отрази не само на потребителите, използващи екранни четци, но и на всички останали – въпреки, че разширението блокира валидирането на формите в браузъра, това може да бъде отменено от други разширения, и тогава съобщенията на браузъра ще са на езика, установен от локала на формата, а не на езика на сайта.

Понеже не намерих конкретно решение на проблема, освен да си сменям езика в администрацията – това не беше решение в случая – се зарових в кода на разширението. И намерих точно каквото ми трябваше – кука за действие, чрез което могат да се манипулират свойствата на обекта, отговарящ за генерирането на формата, точно преди превръщането ѝ в HTML. Ето и кодът, който написах:

function gonzo_fix_cf7_locale( $cf7 ) {
  $cf7->set_locale( get_locale() );
}
add_action( 'wpcf7_contact_form', 'gonzo_fix_cf7_locale' );

Това, което правя е просто – пренаписвам локала на формата с основния локал на сайта. Решението е универсално и ще работи винаги, когато формата е на същия език като сайта.

Responsive header images with WordPress

от Гонзо
лиценз CC BY-NC-SA

Големите картинки, заемащи почти целия екран от доста време са на мода, но освен да впечатляват потребителя, те могат и доста да го изнервят докато чака да се заредят. Проблемът става съвсем явен когато потребителя разглежда сайта на екрана на телефона си, особено ако на мястото на което се намира няма 3G покритие. За решаването на този проблем на помощ идват отзивчивите картинки.

Годината е вече 2016та, най-популярните браузъри от доста време поддържат srcset, sizes и picture, така че няма причина да не ги използваме. А с новата версия 4.4 на WordPres това е още по-лесно. Не че с предишните беше трудно, просто трябваше да се инсталира разширението RIGC Responsive Images.

И така, постановката е проста, в горната част на сайта, под главата или като част от нея, искаме да поставим голяма картинка, която да заема цялата ширина на екрана. Освен това сайтът ще е с отзивчив дизайн, все пак е 2016 година вече. До тук нищо сложно, но като погледнем картинката с пропорции 16:9 на екрана на телефона в портретен режим и виждаме, че нещо е е така. Тогава сигурно бихме искали картинката също да е в портретен режим или поне да отива към квадрат, може би да увеличим основния елемент в нея. За да решат този проблем, хората от Responsive Images Comunity Group измислиха елемента picture.

Веднага ви давам пример:

<picture>
   <source media="(min-width: 45em)" srcset="large.jpg">
   <source media="(min-width: 32em)" srcset="med.jpg">
   <img src="small.jpg" alt="">
 </picture>

Браузърите, които поддържат picture, ще заредят първия елемент source, в чийто атрибут media е посочена медийна заявка, отговаряща на устройството на потребителя. Браузърите, които не поддържат picture просто ще покажат елемента img.

За да направим заглавната картинка в WordPress да използва елемента picture първо трябва да накараме WordPres да създава варианти на картинката с необходимите ни размери:

function image_sizes() {
   add_image_size( 'image-big', 1920, 1080, true );
   add_image_size( 'image-medium', 1024, 768, true );
   add_image_size( 'image-small', 480, 480, true );
 }
 add_action( 'after_setup_theme', 'image_sizes' );

След това идва интересната част. Тук предполагам, че темата вече поддържа custom-header. В предишните версии на WordPress заглавната картинка се показва обикновено с функцията header_image(). Но в най-добрия случай с тази функция ще получите img елемент с атрибути srcset и sizes, което не е това, което искаме. За да можем да използваме дефинираните от нас размери на картинки първо трябва да вземем ID на картинката и след това да използваме wp_get_attachment_image_src() за искания размер. Ако търсите начин да вземете ID на заглавната картинка в codex-а, няма да намерите (поне аз не успях), но един преглед на кода на WordPress веднага ще ви посочи get_custom_header() като решение на проблема. Накрая получаваме това:

<?php
 $header = get_custom_header();
 ?>
 <picture>
 <?php
 $src = wp_get_attachment_image_src()( $header->ID, 'image-big' )[0];
 ?>
 <source media="(min-width: 1024px)" src="<?php echo esc_attr($srcset); ?> />
 <?php
 $src = wp_get_attachment_image_src()( $header->ID, 'image-medium' )[0];
 ?>
 <source media="(min-width: 480px)" src="<?php echo esc_attr($srcset); ?> />
 <?php
 $src = wp_get_attachment_image_src()( $header->ID, 'image-small' )[0];
 ?>
 <img src="<?php echo esc_attr($src); ?>" />
 </picture>

Това е добре, но има един недостатък – една и съща картинка се сервира при доста голям диапазон от размери на екрана и съответно в доста случаи ще натовари клиента с излишен трафик и браузъра с по-тежко преоразмеряване на голяма картинка. Решението е на всеки source елемент вместо една картинка със src да подадем набор от размери чрез srcset. Тук на помощ идва функцията wp_get_attachment_image_srcset, която е нова в WordPress 4.4, в по-ранни версии може да се използва чрез разширението RICG Responsive Images. Тя връща srcset атрибут със всички дефинирани размери картинки със същата пропорция като подадения като втори параметър размер.

<?php
 $header = get_custom_header();
 ?>
 <picture>
 <?php
 $srcset_value = wp_get_attachment_image_srcset( $attachment_id, 'header-image-small' );
 $srcset = $srcset_value ? ' srcset="' . esc_attr( $srcset_value ) . '"' : '';
 ?>
 <source media="(min-width: 1024px)" <?php echo $srcset; ?> />
 <?php
 $srcset_value = wp_get_attachment_image_srcset( $attachment_id, 'wide-big' );
 $srcset = $srcset_value ? ' srcset="' . esc_attr( $srcset_value ) . '"' : '';
 ?>
 <source media="(min-width: 600px)" <?php echo $srcset; ?> />
 <?php
 $srcset_value = wp_get_attachment_image_srcset( $attachment_id, 'square-medium' );
 $srcset = $srcset_value ? ' srcset="' . esc_attr( $srcset_value ) . '"' : '';
 ?>
 <source <?php echo $srcset; ?> />
 <img src="<?php echo esc_attr(wp_get_attachment_image_src($attachment_id, 'header-image-base', false)[0]); ?>" />
 </picture>

И така получаваме картинка в главата, която наистина реагира на размера на екрана, с още малко усилия може да подавате различни картинки за различна ориентация при една и съща ширина на екрана. И при това без да изразходвате безплатните мегабайти от плана на потребителя.

Малко полезни разширения

Вече споменах RIGC Responsive Images, официалното разширение добавящо поддръжка за отзивчиви картинки в WordPress. От версия 4.4 вече е част от самия WordPress, но можете да го използвате, за да активирате лесно picturefill или заради добавянето на подобрена компресия на картинките.

Докато работите върху сайта и се опитвате да прецените какви точно пропорции на картинките ще подхождат на различните екрани и какви размери картинки да генерирате, неизбежно ще ви се наложи да променяте набора от размери, които искате WordPress да генерира. Тогава на помощ идват разни разширения, които регенерират различните размери картинки. След няколко проби аз се спрях на Image Regenerate & Select Crop.

Когато започнете да качвате картинки бързо ще забележите, че автоматичното оразмеряване не винаги работи добре и често ще имате нужда ръчно да отрежете картинка така, че да се вижда най-добре дадена част от нея. Тук на помощ идва Manual Image Crop – това разширение ви позволява ръчно да изберете как да се отреже всеки регистриран размер на картинката.

2520

от Ясен Праматаров
лиценз CC BY

WordPress 3.6 е свежо обновление, признавам. Интересни стъпки, може би най-вече с визуалните промени. Не мога още да свикна с новия изглед Twenty Thirteen, макар че на много други блогъри ще им потекат лигите. Най-интересно ми е продължаващото развитие с различните формати на публикациите. Далеч e от гъвкавостта в Drupal, но пък май нарочно ги правят така. Още не свиквам – твърде ненастройваеми ми стоят.

May the 4th

от Ясен Праматаров
лиценз CC BY

Няколко неща се случват – и добри, и не дотам. Недоброто е, че съм доста болен и то точно по Великден и прилежащите му почивни дни. Даже си изгърмях два дни платен отпуск, като си мислех, че съединявам почивните дни за малко по-голяма ваканция, а пък то една ваканция… цяла седмица съм с кашлица и на купешки илачи. Ама как да знам, че ще се разболея? Докторът ме пита дали ми трябва болничен, а аз му викам не, аз си имам отпуска – зачуди ми се за секунда, преди да се сети.

Та лошо е да се боледува, но явно стресът ми е дошъл в повече и тялото е казало “баста”. Бронхит, но като гледам как не мина след антибиотика, дано не е някаква пневмония. А яка доза пих – Аугментин 1гр. през 8 часа. В понеделник ще ида до поликлиниката – поне ни е наблизо, даже по-близо от в Надежда.

Между другото, сайтът ми вече не е на Drupal. От преди малко. Преди два дни някъде ми щукна да не се занимавам да копирам на ръка от Друпал в Уърдпрес, както бях почнал преди половин година (и спрял пак някъде тогава). Отворих си конзола в MySQL, за всеки случай и за по-визуално ориентиране се заиграх с пробни заявки през графичен клиент и накрая взех да копирам публикациите от едната база поокастрени и натъкмени в другата. Признавам си – не стана докрай и не стана съвсем добре, затова порових във вечното спасение – някое и друго търсене в мрежата. Не е срамно да си признаеш, а и както вика един приятел, “сисадмините без гугъл сме загубени”. Ползвах някои заявки на хора от нета и накрая съдържанието беше преместено. Само с етикетите и категориите не успях автоматично както трябва. Ще ги добавям на ръка в скоро време, тъкмо ще прегледам самите текстове. Снимките почти ги няма все още, на старото място са, но ще ги премествам и тях.

Отказвам се от всякакви допълнителни, нестандартни и рядко нужни екстри, каквито бях изсипал в Друпал и ще поддържам минимална инсталация на WordPress. Лесна поддръжка и всъщност колкото може по-малко поддръжка, това е целта. Спестеното време по-добре са го отделям за писане и снимане, отколкото за ровене в код и четене на иначе прекрасната документация на drupal.org. Та честит ми нов блог-дом!

Темата е под-вариант на TwentyTwelve, промених я доста, но нещо все още не ми харесва шрифтът, не ми пасва за четене много. Ще се дооправя в движение. Чудя се дали, за да ми е по-лесно, не преместя и фотоблога така – въпреки че Pixelpost е страхотен и удобен, само спам-контролът му куца (а и си е изоставен проект, колкото и да е кофти).

Най-хубавото е за десерт, разбира се. Който знае какво е “May the 4th”, може да се е досетил. Успяхме да намерим време този късен следобед и до тъмно, с една почивка за следобедна закуска по средата, да изгледаме с децата “Междузвездни войни: Нова надежда“. Или “Епизод 4″. Тоест първият… тъй де. Гледахме обновената версия, от 1997г., с добавените кадри, с надписи на български. Светко се оказа, че си ги е чел съвсем свободно и бързо през цялото време, а аз и Краси се редувахме да им четем – всъщност да четем на Оги. И двамата са много впечатлени, разказвахме им за идеите и им давахме прилики с приказките, с доброто и злото, различните видове характери и различните мотивации на хората…

Светли е много доволен и, познайте – казва, че е Дарт Вейдър. Той му бил харесал най-много, а и освен него готини били Джаба и R2. Джаба участва в римейк версията, затова. R2 – ясно, най-готиният дроид. Но Вейдър… И тогава се сетих, че и аз като малък повече харесвах Империята и Вейдър. Оня Император ми беше гаден, но виж Лорд Вейдър си е друга работа! Даже му рисувахме шлема по тетрадките… Бунтовниците и джедаите във старите серии са някаква шайка несериозници, като се замисли човек – за разлика от новите серии, където си е пълно с джедаи.

Майтапа настрана, тези филми са класика на жанра, нещо повече – обемат го почти целия.

May the 4th be with you!