Въпреки че си харесвах темата която намерих и човърках, накрая се уморих от външния и вид(и общия мрачен тон, който тя имаше). Аз съм изключително позитивен и усмихнат човек и ползването на толкова тъмна тема, не изразяваше много добре същността ми.

От може би половин година си бях наумил да сменя дизайна на блога си, но поради други по-важни неща(работа, личен живот и тн.) така и не ми се отдаде тази възможност. Да си призная, факта че визуалните изкуства не ми се отдават много много(мога да направя нов елемент да пасне вече съществуващия дизайн, но не мога да изградя нещо от нулата) също допринесе за забавянето.

Но изведнъж ми светна, че е време да си намеря нова тема. След бързо търсене в Google, се озовах на следната публикация във WPMU Dev – 85 Free Clean and Simple WordPress Themes. Честно казано темата Landscape от същия списък също ми допадна, но впоследствие реших да я пропусна поради тъмните и цветове(предполагам че това е нещо което щеше да е лесно да се оправи, но не ми се занимаваше). Въпреки че не всички теми от върпосния списък биха паснали за блога ми, някои от тях изглеждат доста добре и определено могат да паснат за различни видове сайтове.

В крайна сметка избрах темата Highwind от James Koster(не стигнах до края на списъка защото бях достатъчно впечатлен от тази конкретна тема). Тя е изчистена, приспособява се към всякакви устройства(което старта ми тема не поддържаше) и е центрирана около съдържанието. Темата може да се нагласи така че да е по ваш вкус, чрез използването на заглавни изображения(Header images) и вградения в WordPress Customizer(екран на който можете да променяте различни настройки на сайта и да ги преглеждате в реално време, без промените да засягат сайта за посетителите) дава лесен достъп до основния външен вид на сайта(основните цветове и позицията на страничната лента).

Темата е абсолютно безплата и със отворен код – можете да я намерите както на WordPress.org, така и на GitHub. Бърз преглед на кода ме остави с доброто впечатление, че темата е добре организирана и следва стандартите за код на WordPress. Също така темата е написана с мисълта за дъщерни теми, така че промяната на функционалността и чрез дъщерна тема е изключително лесно.

Заглавието е доста общо, но дава някаква идея за какво иде реч. Като цяло пермалинковете на WordPress са доста гъвкави, обаче си имат и своите ограничения. Съвсем на скоро докато работех по проекта на един клиент се натъкнах на едно от тях.

Проекта беше за създаване на база за Често Задавани Въпроси, използвайки WordPress. Клиента искаше следната структура за базата(това е опростена версия):

• Индекс на базата ( http://example.com/faq/ ) [Индекс на цялата база]
  • Основна категория ( http://example.com/faq/category/ ) [Индекс на Основната категория]
    • Публикация в основната категория ( http://example.com/faq/category/post-1-slug/ ) [Преглед на Публикация 1]
    • Под-категория ( http://example.com/faq/category/sub-category/ ) [Индекс на под-категорията]
      • Публикация в под-категорията ( http://example.com/faq/category/sub-category/post-2-slug/ ) [Преглед на Публикация 2]
  • Друга основна категория ( http://example.com/faq/another-category/ ) [Индекс на другата основна категория]

Всичко изглежда нормално(като структура на линковете) за нормалния потребител, обаче WordPress е на друго мнение по въпроса Вместо линк като http://example.com/faq/category/  ние ще можем да видим индекса на основната категория на линк от рода на http://example.com/faq-category/category/. Което както виждате не съвпада съвсем с първоначалната идея. За да оправим този проблем трябва да прибегнем до добавянето на няколко специално написани Permalink правила и функции.

Първата стъпка е да регистрираме новия пост тип(Custom Post Type). Това се случва със следната функция:

Този код ще регистрира новия пост тип, заедно с новата таксономия “FAQ Categories”, която ще използваме за да категоризираме въпросите.

След като регистрираме новия пост тип остава да добавим две функции които да направят така че Permalink-овете да работят както искаме ние

В горния код регистрираме две функции – register_faq_rewrite_rules() и fix_faq_subcategory_query().

Първата функция добавя следните няколко правила:

• faq/([^/]+)/?$ – това правило ще бъде приложено когато адреса на страницата която се зарежда прилича на “faq/any-character/” – тоест когато имаме начална част “faq/” последвана от всякаква комбинация от символи, без “/”( “([^/]+)” ), евентуално последвана от “/”( “/?” ). Също така тази част трябва да е последната част от адреса на страницата, за да има съвпадение(т.е. няма да има съвпадение, ако адреса е “faq/any-character/something”).

  Когато адреса съвпадне, на текущата страница ще бъде показан архив за категорията(според примера който дадох по-горе) “any-character”.

• faq/([^/]+)/([^/]+)/?$ – това правило е почти същото като предишното, с изключение на това че вече адреса който би съвпаднал би изглеждал като “faq/any-character/post-slug/”.

  Това ще зареди публикация с кратко име(slug) “post-slug” от категорията за ЧЗВ с кратко име “any-character”.

• faq/([^/]+)/([^/]+)/([^/]+)/?$ – това правило е почти същото като предишното, с изключение на това че вече адреса който би съвпаднал би изглеждал като “faq/any-character/sub-category/post-slug/”.

  Това ще зареди публикация с кратко име(slug) “post-slug” от категорията за ЧЗВ с кратко име “sub-category”.

Втората функция от друга страна оправя проблема със под-категориите. А самият проблем се състои в това, че когато се опитате да заредите страница с адрес faq/category/child-category/, WordPress ще се опита да зареди публикация с кратко име “child-category” вместо под-категорията с кратко име “child-category”. Самата функция е по всяка вероятност не най-красивото решение на проблема, най-малкото защото трябва да направим една допълнителна заявка към базата данни, но това е единствения начин по който успях да реша проблема Понеже функцията проверява дали има публикации с краткото име “child-category”, ако случайно има такава публикация, може да получите неочаквани резултати

Това е достатъчно за да подкарате секцията за ЧЗВ, обаче в момента ако искате да използвате пълноценно новите адреси на категориите и публикациите, ще трябва да си ги пишете сами. Това е защото WordPress не знае как трябва да генерира линковете така че да съвпадат с нашата идея. За това добавяме още няколко функции:

Горните функции “филтрират” резултата от две вградени в WordPress функции, които се грижат да създадат правилните линкове за всички страници, публикации и архиви на таксономии.

Остава един проблем, който може да не е никак малък за някои потребители – проблема с дубликиращото се съдържание. Има доста голяма вероятност Google или някоя друга търсачка която обхожда сайта ви да не остане очарована от факта, че намира идентично съдържание на два различни адреса(например faq-item/post-2-slug/ и faq/category/sub-category/post-2-slug/). Това може да се избегне с една функция която да препраща потребителите към правилния адрес, но оставям това на вас

Ако искате да видите цялата идея в действите, можете да отидете на Custom Permalinks Test.

Иии най-накрая се хванах и си взех още един хостинг + домейн
За съжаление moonwatch.com е вече зает, ама и този си ми харесва

Що се отнася до SuperHosting.bg – супер бързо се случиха нещата както винаги Лятната им промоция(1 = 2) е повече от иделна – сносен хостинг(за лично ползване) за 3 години + домейн за една година = 102.75 лв. – което си е повече от без пари(хостинга е 84, което делено на 3 прави 28 лв на година, или 2.33 лв на месец!)…

Ако си търсите хостинг – мога спокойно да ви ги препоръчам

Стига толкова реклама за хостинг компанията, сега малко детайли покрай местенето

Ако пробвате да отворите някой линк от стария сайт, ще се озовете на същата страница, само че на новия – това стана с буквално 18 реда код :)))

Оставих активната тема на стария сайт свалена до минимум(index.php – празен, style.css – само описанието на темата, functions.php – само функцията за пренасочване) с цел пренасочването да се случва възможно най-бързо.

Самото местене на файловете стана доста бързо, благодарение на любимия ми cPanel, който поддържа архивиране/разархивиране на архивни файлове. Тоест, вместо да свалям при мен и да качвам на новия сървър 1000+ файла, свалих 1 който после разархивирах тук

Export на базата данни, няколко SQL заявки след import-a на новия сървър и все едно нищо не се е случило

Така, ето и функциите за пренасочване и с това ще приключа за тази вечер

function curPageURL() {
$pageURL = 'http';
if ($_SERVER["HTTPS"] == "on") {$pageURL .= "s";}
$pageURL .= "://";
if ($_SERVER["SERVER_PORT"] != "80") {
$pageURL .= $_SERVER["SERVER_NAME"] . ":" . $_SERVER["SERVER_PORT"] . $_SERVER["REQUEST_URI"];
} else {
$pageURL .= $_SERVER["SERVER_NAME"] . $_SERVER["REQUEST_URI"];
}
return $pageURL;
}

function redirect_to_new_domain() {
$requested = curPageURL();
wp_redirect(str_replace('moonwatch.kbsk-titanite.com', 'themoonwatch.com', $requested), 301);
exit;
}
add_action('init', 'redirect_to_new_domain', 1);