Игорь Воротнёв

Если подходить к делу правильно, то процесс следующий:
1. Брейнсторминг на бумаге, продумывание интерфейса и структуры и отображение в 3х вариантах (desktop, tablet, mobile)
2. Разработка модульных сеток (они же wireframes) - Photoshop, Illustrator, Fireworks или сцеп. приложения для сеток и утверждение их клиентом. В 3х вариантах (desktop, tablet, mobile)
3. Верстка голого прототипа по этим 3м вариантам (responsive уже давно стандарт де-факто, а не "бонус").
4. Дизайнер рисует дизайн, четко по утвержденным сеткам.
5. Правки по дизайну, утверждение клиентом.
6. Верстка дизайна, тестирование и отладка, утверждение.

При таком подходе процессы параллельны. Когда есть утвержденная сетка, мы можем работать сразу в 3х направлениях - дизайнер спокойно себе рисует дизайн, в это время верстальщик (он же coder, он же front-end developer) создает голый скелет (прототип) и верстает в него голый контент, а программер (back-end developer) уже может выводить свою часть (динамический контент) в html. Когде же утвержден дизайн, верстальщик этот низкоуровневый скелет начинает "украшать" - добавляются конечные стили (отступы, типографика, цвета и прочее).

Следует еще упомянуть обязательный "шаг 0". Для корректной работы начиная с шага 1 необходимо получить от клиента реальный контент. В процессе шага 1 этот контент вместе с клиентом доводится до ума, финализируется и утверждается. В современной разработке работать с Lorem Ipsum - дурной тон и путь в никуда.

UPDATE:
Еще один бонус - когда сверстан низкоуровневый прототип по сеткам, можно прикручивать его к CMS, и уже с этого момента клиент может наполнять сайт (ну или наш контент-редактор). Часто это бывает очень важно (если контента много).

Из этого всего выплывает:
1. Дизайнер - это дизайнер. Его стихия - графический редактор. Понимание принципов верстки и веб-технологий вообще - обязательно. Умение самому заколбасить что-нибудь на jQuery не обязательно.
2. Верстальщик / кодер / front-end developer - это человек, работающий с клиентской стороной (HTML+CSS+Javascript), переносит картинку от дизайнера в код и прикручивает то, что ему дает программер.
3. Программист / back-end developer / просто web developer - человек, работающий с серверной частью (например, PHP), CMS и т.д.
Это "минимальная конфигурация" Для более сложных проектов работа делится на более узкие направления и появляются профильные люди.

Да без проблем. Что .psd, что .ai - какая разница? Проблема с конкретным верстальщиком может возникнуть только если он не знает Illustrator или фанатеет по Corel.

Пока нет рекоммендаций, портфолио и "связей" - фрилансерские сайты, FFF (friends, fools, family). Особо бойкие и амбициозные могут заняться прямыми продажами, ходите в места скопления ваших потенциальных "клиентов", знакомьтесь, оставляйте визитки и презентации. Создайте что-то полезное (инструмент, сервис) для какой-то локальной ниши и предложите это решение - если оно реально полезно, то у вас начнут покупать, а дальше пойдет кастомизация, поддержка, отдельные решения, рекоммендации и так далее.

Но точно не холодные звонки - это порожняк. Реклама тоже в основном неэффективна, выбросите деньги на ветер, ускорите наступление банкротства.

И да, ни в коем случае, ни при каких обстоятельствах не начинайте на начальном этапе вкладывать деньги в офис, мебель, технику и прочее. Trello+Git+почта (или другой, более сложный workflow - на усмотрение), сидите себе по домам, в кафешке с ноутами, на крайняк в коворкинге и работайте, работайте, работайте.

Если уж останавливаться на одной CMS/CMF, то точно не Joomla. Из бесплатных - WordPress, Drupal. Из коммерческих - Expression Engine. Порог качественного входа примерно одинаков. Прелесть этих готовых решений (будем говорить об этой популярной тройке - Joomla, WordPress, Drupal) и всех их экосистем одновременно является слабым местом и головной болью. Из-за низкого порога входа (а у Joomla он самый низкий) модули, плагины, темы и т.д. создают люди, которым по-хорошему надо руки ломать и к компьютеру не подпускать. Отсюда куча мусора, дыр по части безопасности, откровенно вредоносного кода, неэффективных и тормознутых решений. Ибо создание качественных решений требует знаний и опыта. В этом плане и WordPress, и Drupal стоят на несколько ступенек выше. В случае WordPress, например, причины следующие: все плагины в Codex проходят проверку, за самим WP стоит компания Automattic и wordpress.com (крупнейшая ферма в мире, на мощностях которой крутятся крупнейшие в мире новостные сайты). WP - это платформа, под которую разрабатывают эксклюзивные решения профессионалы очень высокого уровня. У WP самое большое open source комьюнити, посему решения допиливаются до ума. И так далее...

Я специально выше выделил жирным "порог качественного входа". Следует разделять использование платформы как CMS для более-менее стандартного сайта, в конфигурации "из коробки" + парочка плагинов и использование в качестве CMF для создания кастомных решений. С первым справится хомячок (и в этом случае с Joomla будет больше потенциальных проблем, чем с WP), для второго нужно изучать ядро платформы, да и PHP вообще. Когда копаешь глубоко, начинаешь понимать, чем действительно отличается CMS от CMF.

Ну а если в планах строить вообще свои кастомные решения и сервисы и становиться настоящим профессионалом - тогда однозначно изучение на наиболее низком уровне - сначала программирование как таковое, алгоритмы, ООП, РБД/ОРБД, сетевые протоколы и т.д. Потом уже PHP. И только тогда - фреймворки. Хотя, думаю, пройдя этот путь PHP станет не интересен, как минимум Python уже. Путь долгий и тернистый, но на Олимп иначе не попасть. Если не сломаешься по пути - через 5-6 лет будешь в топе.

Использование данного решения - вопрос привычки. Мозг начинает по-другому считать, к этом надо привыкнуть. Назад к "классической" модели возвращаться не захочется) Использовать ли? Мой выбор - да. Упрощает жизнь, ибо логичнее и понятнее. Поддержка во всех современных браузерах есть. Для старых (включая IE) есть полифил, или же старым вообще выдавать упрощенную версию.

mailto: всегда. Форма обратной связи имеет смысл, если это большой сайт, есть например разные отделы и типы запросов и т.д., но ее наличие не исключает обычной ссылки на почту.

1. Зачем через `has_shortcode();`, можно ведь по-другому...
2. Немного модифицированное предложение @ZetRider:

if ( get_post_gallery() ) :
		$gallery = get_post_gallery( get_the_ID(), false );
// array of ids;
		$ids = explode(',', $gallery['ids']);
// array of urls;
		$images = $gallery['src'];
		$i = 0;
		foreach( $images as $image ) {
			$title = get_the_title($ids[$i]);
// тут свой формат вывода
			echo '<img src="'.$image.'"><span>'.$title.'</span><br>';
			$i++;
		}
	endif;

Но, функция `get_the_title();` дает нам только 1, и не самое лучшее поле. Имея массив IDшек (а это айдишки attachment'ов) можно воспользоваться одной из функций именно аттачментов - там вернется больше данных. Например, можно заюзать `wp_get_attachment_image()`, `wp get attachment metadata()`.

Для этих целей существует Theme Customization API

На выходе - удобная для юзера работа с настройками, собственно в настройках темы, прямо с визуальным предпросмотром + легкое внедрение для разрабочика, благодаря удобному API. Уроков в сети - пруд пруди.

В ФШ я ничего подобного не видел, скорее всего это отдельная прога, которая всегда сверху над всеми активными приложениями.
Под Windows:
ruler.codeplex.com
www.picpick.org/en
www.arulerforwindows.com
Под Mac OS или другую платформу спросите у Гугла, ключевое слово "ruler"