Спасибо тов. curlybrace за то, что открыл глаза на существующие правила и нормативы в постинге на Хабре. Будем вникать, а пока что вторая часть статьи о WordPress и темах.

Query Posts

Хотелось ли вам самим определять какие сообщения и когда должны показываться на странице? Нет ничего проще, ведь существует чудо функция query_posts, определяющая какие записи попадут в выдачу. Функция работает как некий фильтр, отбирающий посты по указанным критериям. Сейчас всё станет более ясно на примерах, а затем я просто перечислю большинство существующих параметров, после чего всё ограничится вашим воображением.

В последнее время приходится периодически править чужие темы, что натолкнуло на мысль — составить список тех вещей, которые необходимо выполнить, чтобы новая тема работала так же как и старая — на все 100%. К тому же, надеюсь (в который уже раз даю себе обещание) сменить тему в своём блоге на нечто более живописное.

Так же этот список может пригодиться тем из пользователей WordPress, которые любят менять тему в соответствии с сезоном или праздниками (а ведь Новый Год на носу), сам я этим не страдаю, но знаю, что существуют и такие индивиды.

1. Удостоверьтесь, что весь перевод (если вы его делали) сохранен в кодировке блога, а то печально наблюдать крякозябры в перемешку с нормальным текстом.

2. Перенесите свои спец. виджеты из старой темы (код из файла function.php) в новую, проверив чтобы названия виджетов не дублировались.

3. Заново разместить все свои виджеты в сайдбаре(-ах), указав необходимые настройки.
3 и 4 пункты — если вы используете тему с динамическим сайдбаром, если же нет, то правим прямо sidebar.php

4. Переносим функции, которые размещали для правильной работы плагинов. Например, тот же Wp-PageNavi, WP-RelatesPosts, ну и в том же духе.

5. Вставляем в хэдер или футер коды своих «счётчиков/анализаторов» (liveinternet/google-analystic), чтобы потом не удивляться резкому падению посещаемости до 0.
Для пользователей аналистика советую плагин Google Analyticator, который кроме автоматического внедрения нужного кода в хэдер, ещё и позволяет исключать определенных пользователей. Ведь вам же не нужно считать свои собственные клики?

6. Проверяем правильно ли прописан фид, если вы перешли на FeedBurner, т.к. ссылка по умолчанию будет на www.сайт.ру/feed.
Мой вам совет, чтобы не морочить себя пунктом 6, воспользуйтесь плагином Feedburner Feed Replacement, который автоматически редиректит все обращения к вашему фиду на фидбёрнер.

7. Монетизирующим блог напомню перенести коды от своих контекстных (и не только) программ в новую тему, хотя и тут можно обойтись использованием правильных плагинов. Возможно напишу потом об этом отдельно. И не забудьте повесить баннеры и проплаченные ссылки, а то на вас обидятся рекламодатели.

8. Протестируйте свою тему — пройдитесь по всем разделам, поищите через поиск, проверьте, чтобы текст был грамотно написан, коментарии оставлялись, а плагины не выдавали ошибок, а фид вёл туда куда нужно. Причём советую перед тестом разлогиниться, так как большинство фич (та же капча) видны только гостям.

9. Проверьте как ваш сайт отображается в разных браузерах. И если у вас на компьютере стоит, например, только IE (вздрогнул при мысли об этом), то воспользуйтесь сервисом http://www.browsershots.org/.

10. Оповестите читателей об этом знаменательном событии. Ведь многие читают вас исключительно по rss и не смогут оценить изменений. Так же попросите посетителей оставлять свои замечания и сообщать вам о найденных ошибках в комментариях к новости или в письмах. Обратная связь — полезная возможность, которой не стоит пренебрегать.
Ну вот и всё. Надеюсь, что следуя данному списку вы сэкономите себе и время, и нервы, а ваши посетители будут обрадованы красотой и функциональностью блога.

Оригинал статьи «10 вещей, которые стоит сделать при смене темы в WordPress»

Пост посвящается всем дизайнерам и верстальщикам тем под WordPress.
Порой я впадаю в уныние от того, что дизайнер из меня никакой, а вёрстка не приносит радости, а только нервный тик. Особенно когда подгонишь всё качественно в FireFox, а потом посмотришь на сайт в IE. Сидишь и тихо всхлипываешь.
К чему я это пишу? А к тому, что умей я быстро и качественно делать темы для ВордПресса, то вполне возможно имел бы ого-го сколько бэклинков, ведь никто не мешает вставить ссылку на себя в футере.

Вдогонку к предыдущему посту о темах, взгляд с другой стороны, а если быть точным, то пост для тех самых пользователей, которые все эти темы качают.

(по версии WhenPenguinsAttack.Com)

После длительного поиска хорошего шаблонного движка на PHP, Justin Silverton составил следующий список с краткими описаниями.

Разрабатывая сайты мне всегда хотелось облегчить себе жизнь, так я познакомился с jQuery. Все было бы хорошо если бы проекты не погружались в зыбучую смесь UI и js кода. Следующим этапом стало то что мы выделили UI Шаблоны в отдельные файлы, код стал более чистым, но, черт побери, все равно приходилось писать кучу UI кода, например вставка и настройка дополнительных компонентов в шаблон, event bind, надписи и т.д. И только после всего этого на выходе получался нужный нам компонент. Возникало, конечно, много проблем, особенно когда дизайнер менял шаблон, но все это решаемо.

для нетерпеливых: quicky-tpl.net
что такое Квики (высокой производительный шаблонизатор с расширением синтаксиса и функционала Smarty) я писал здесь habrahabr.ru/blogs/php/45337, а подкатом история о том, как у квики оказался новый дом =)

Основные изменения по сравнению с 0.4.x: (http://code.google.com/p/quicky/)
[~] {math} теперь компилируется в нативный PHP-код.
[~] Отображаются номера строк при ошибках компиляции, ошибки компиляции выдаются сразу все, а не по одной, показывается тег, в котором ошибка.
[+] Добавлена функция {debug} отображающая debug-консоль (о том почему у Quicky наиболее совершенный дебагер читайте под катом).

Я думаю многие со мной согласны, что Doctrine — один из самых мощных и удобных ORM для PHP, но с недавнего времени возможностей оного мне перестало хватать. Начнем с того что невозможно использовать ассоциации с условиями фильтрации, «волшебный» поиск с учетом перевода через I18n и много другого.

Всячески экпериментируя с возможностями Doctrine, я написал кучу нужных и ненужных расширений, которые и решил вывести «в мир». Тем самым и начинаю цикл статей, посвященных практическому написанию всяких упрощающих жизнь свистелок. В процессе я также постараюсь раскрыть методологию разработки, так что возможно наличие взаимоисключающих параграфов в течение статьи, но в итоге они разрешатся.

Начну с самого легкого — с расширения для мультиязычности Doctrine_Template_I18n. Оговорюсь сразу, текста будет много, как и много сумбурной технической информации

Одним из проектов, над которым работала моя команда, был новый движок представления для ASP.NET.

ASP.NET MVC всегда поддерживал концепцию “движка представлений”, собственно он представляет из себя заменяемые модули, которые реализуют выбор различного синтаксиса шаблона. Сегодня, стандартный движок представлений для ASP.NET MVC использует аналогичные файлы, что и ASP.NET Web Forms — .aspx/.ascx/.master. Существуют и другие популярные ASP.NET MVC движки представлений — Spark и NHaml.

Новый движок представлений, над которым мы работаем, оптимизирован под генерацию HTML-кода, фокусируясь на коде шаблона. Кодовое имя для данного движка – “Razor”, первая бета-версия будет доступна уже скоро.

 — Здравствуй *с широко развевающейся по лицу улыбкой* дружок.
 — Ваа! *с ярким блеском в широко распахнутых глазах* Тётя Ася приехала!
 — Да, и у меня есть для тебя новая сказка *присела и взяла малыша за руки* хочешь послушать?
 — Конечно! *слегка смутился и отвёл взгляд* Мне тут дядя такие страшные истории рассказывал…
 — Ну, надеюсь моя история тебя не испугает *потрепала его по волосам* Она должна научить тебя мыслить шаблонно.
 — Эээ? *лицо перекосилось от недопонимания* Это как?
 — М… сейчас узнаешь *подмигнула и взяла на ручки* Вот когда тебе нужно вставить переменные в строку — ты как поступишь?
 — Ну… *взял карандаш и чирканул на лежащей рядом бумажке* примерно так:

var query= 'xxx'
var resultCount= 512
var message= 'По запросу <kbd>' + query + '</kbd> найдено страниц: ' + resultCount

 — Ты ничего не забыл? *победоносно подняла голову*
 — Да вроде нет… *уткнулся носом в код, ещё раз внимательно его проверяя*
 — Что, если пользователь введёт… *выдержала многозначительную паузу и добавила*

Доброго времени суток!

Не так давно я начал свое знакомство с фреймворками впринципе и сразу столкнулся с таким вопросом — как же организовать простую смену шаблонов, чтобы в любой момент можно было добавить, скажем, в папку templates еще одну папку с шаблоном и безболезненно изменять шаблоны в будущем. Но в Kohana 3 (к сожалению, ничего не могу сказать о других фреймворках, так как работал с ними лишь поверхностно) во-первых все View-файлы лежат в папке views (все-таки templates проще и понятнее простому пользователю), а во-вторых, нет механизма выбора нужного View-файла из папки Views (кроме как подключение его напрямую). Что ж — сейчас я хочу рассказать, как это реализовать. Используемая версия фреймворка — 3.0.7, последняя на данный момент.
Давайте начнем.

Одним из компонентов нашего проекта Shopium.ua является административный интерфейс, который строится как полностью выполняющийся на клиенте rich internet application.

Для отрисовки данных приходящих с сервера в HTML нам часто нужен Javascript-шаблонизатор.

Различных шаблонизаторов для Javascript существует предостаточно. Даже в библиотеке ExtJS которую мы используем для своего проекта их целых два, однако их синтаксис и возможности каждого далеки от идеала.

К хорошему быстро привыкаешь, и мы быстро привыкли к синтаксису шаблонов Jinja2 который мы используем для генерации HTML на стороне сервера. И захотели такой же, но с перламутровыми пуговицамино для Javascript.

И сформировали к нему такие требования:

Мы начали с ( javascript шаблонизатора), что использовать один и тот же шаблон на стороне клиента и на стороне сервера, это удобно. Готовых рализаций такого подхода кот наплакал. Кровь приливает к голове, мы решаемся написать своё решение.

Обрисуем исходные данные и задачу

Пусть у нас есть шаблоны, от нашего шаблонизатора. На сервере они обрабатываются perl'ом. В конечном итоге мы хотим некоторые из имеющихся шаблонов, или их частей, не вынесенных в отедельный файл, использовать на стороне клиента. Необходимо с минимальными затратами(в потерере функциональности) воспроизвести процедуры генерации html. В результате обработки шаблонов, мы хотим получить наборы предварительно указанных шаблонов и блоков, оформленных в виде библиотеки javascript. Сказано – сделано.

Как мы все знаем Microsoft подобрела и выпустила некоторые свои вещи под свободной лицензией MIT. В числе них оказались и их новые плагины для jQuery. Плагины оказались мощными настолько, что «независимое» сообщество решило включить, так давно просимый функционал шаблонов, в основную библиотеку (тут). Нонсенс! Фурор! Или… Или есть какие-то иные причины? Не будем это выяснять, а лучше посмотрим на сравнительные тесты данной библиотеки, и подумаем, нужно ли это нам на самом деле.

Как человек, занимающийся терминальными службами Microsoft, Citrix и другими, часто сталкиваюсь у заказчиков с ситуацией, когда на сервер ставится 8, 16 и более гигабайт памяти для работы с 32 разрядной операционной системой. Теоретические знания и практические наблюдения позволяют настаивать на том, что для 32-разрядной операционной системы больше 4 гигабайт памяти ставить расточительно и неверно. Не только из-за того что операционная система не использует всю память (без PAE), а из-за того, что 32-bit приложение не умеют, в большинстве своем, с таким объемом памяти работать.

Сервис Initializr позволяет всего в несколько кликов получить рыбу для типового проекта. Если более конкретно, то он может

• наполнить страницу базовым контентом;
• подключить jQuery в разных формах;
• подключить библиотеки типа Modernizr;
• сконфигурировать настройки сервера, создав например .htaccess.

Ребята активно развиваются и уже сделали русскую версию.

Доброго времени суток, Хабралюди!

Гуру C++, а также люди смыслящие в шаблонном метапрограммировании могут смело пропускать этот топик, ничего нового для себя они здесь не найдут. Однако, если после прочтения заголовка, у вас в голове еще не возникло решение данной задачи (и даже если оно возникло, но не при помощи шаблонов), то милости просим под кат.

В статье описан способ группировки типов в языке C++, реализованный через шаблонный класс IGroup. Приём группировки типов даёт возможность указать несколько типов для объекта. Например, можно указать два интерфейса объекта.

Вообще этот приём мог быть языковой конструкцией, но таковой конструкции ни в одном ЯП не встречал (в комментариях мне уже разъяснили что почём и про Generics и про Boost и даже про STL, спасибо за обсуждение). Потому было интересно попытаться реализовать его на C++.

Одно время приходилось постоянно работать с сетевыми данными и в особенности с заголовками сетевого и транспортного уровней модели OSI. Постоянно напрягал тот факт, что многие поля были в Big-Endian, а код выполнялся на архитектуре Little-Endian. Ну невозможно было постоянно вызывать ntohl(), htonl(), ntohs(), htons()...


Автор фото: Ciroduran, источник фото: flickr.