Александр Маджугин

Тут 2 варианта:

1. Заказывают верстку, подразумевают создание шаблона/темы для CMS. По хитрости, по не знанию, по глупости - не важно. Важно не подписаться пилить это по цене только верстки.

Верстка - это когда макет превращается в набор html/css/js файлов.

Да, могут быть вариации. Может быть сразу под движок: Smarty, Twig, Jade, или все шаблоны в Handlebars, или сразу чтобы всё под Angular было. Но это всё частные случаи, требующие более высокой квалификации, или находящиеся уже где-то во front-end разработке.

2. Просят учесть особенности CMS.

Маленьких нюансов может быть много.

Вот Битрикс, например, и его Эрмитаж (тыкнул в блок - тут же его отредактировал если по простому). Где-то лишняя обертка элемента, чтобы в режиме редактирования не разваливалось. Везде - z-index меньше 1000, чтобы Эрмитаж не перекрывало.

Wordpress вообще генерирует огромное количество своих классов. Взять те же навигационные меню. Использовать их = наплевать на все эти ваши БЭМ и прочее.
И т.д.

Если я верстал и без проблем натягивал свои макеты на Wordpress - могу ли сказать что у меня есть опыт верстки под Wordpress?

Могу.
Так же как могу сказать что есть опыт верстки под Drupal (не знаю натягивали ли какие-то из моих работ на Drupal, но чё бы нет).

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

.nav
    .nav__list
        .nav__item

Когда ему движок выдаст меню в виде

.menu
    ul
        li

Но я не считаю это своей проблемой.
Когда понадобилось, оказалось нет ничего сложного 1 раз потратить время и написать свой вывод меню в Wordpress, чтобы можно было любую верстку натянуть. Почему так не может сделать тот кто натягивает? Почему в ТЗ об этом не предупредили?

Уменьшает ли "опыт верстки под CMS" время верстки?
Если не были оговорены нюансы (те же меню WP) - то нет.
Может увеличиться время натягивания верстки на движок, но это уже проблемы заказчика, который не озвучил требования заранее.

Таким образом, хотя в идеале на движок должно быть возможным натянуть любую верстку, действительно некоторые имеют CMS особенности.
Об этих особенностях следует договариваться заранее. Должно быть конкретное ТЗ на верстку.
В остальном как правило речь об "опыте верстки под %CMS%" - просто болтовня.

Кроме js вы пробовали только php, и этот горький опыт заставил вас остановить свой выбор на js? Не стоит на таком примере делать выводы обо всех других языках. В сфере профессионалов принято не подыскивать новые задачи под единственный известный язык, но, наоборот, подбирать (и изучать при необходимости) язык исходя из стоящих задач. Прежде чем останавливать свой выбор на каком-то конкретном языке или стеке технологий вам нужно сначала определиться с тем кругом задач, о области которых вам интересно работать, и потом подходить к выбору инструментов для решения этих задач. Все зависит от того что вас интересует: web-разработка, фронтэнд, бекэнд, десктопные приложения или мобильные, разработка игр, больше/меньше заниматься пользовательским интерфейсом, может быть, системное программирования?

1. Создайте новую страницу без подключения header & footer. Просто в начале файла укажите

require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");

после чего вставьте код вызова нужного компонента.
2. При вызове модального окна укажите этот файл в качестве источника. Например, bootstrap вызывает примерно так:

<a class="btn" data-toggle="modal" href="remote.php" data-target="#modal">Click me</a>

3. В принципе, Ынджой

Как поступить? контента он генерирует не слабо (судя по яндекс картинкам)

Закрыть веб-студию и заняться зарабатыванием денег. Теперь вы знаете как.

Отличный повод для PR. Слоганы такие "Мы не порно-сайт, но сайты делаем не менее интересными:)". Вообще от вас зависит что вам удобно или нравится. Проведите анкетирование у клиентов - предложите им пять-шесть других доменов и названий. С другой стороны - всё равно у кого там какой домен похожий на ваш - если ваш товар или услуга того стоит то ничто не помешает.

Наймите проверяльщика

Эх, надо было погуглить и выкупить домены в других зонах)) Хотя, название для студии тоже следовало выбрать более тщательно))) Скажите хоть название, заинтриговали же!
Делайте себе сексуальный слоган и обменяйтесь ссылками с тем сайтом, пусть траффик вам гонят. Ведь любители «клубнички» это такие же потенциальные заказчики)

Никак. У поля стоит атрибут required. Можно только его убрать и обработать js. А js покажет div с сообщением об ошибке, который вы настроите сами.

Для начала надо знать примерное место расположения файла. Но если не знаешь то ищи по всему сайту...
Ищи в файлах по уникальному отрезку исходного кода.

как узнать расположение файла php отвечающего за блок

Так сложно сказать как найти, каждый ищет по своему...
А что хочешь найти и где???

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

Если вас интересует как ускорить запись - можно сначала загонять все в буфер (redis например) и потом пачками заносить все в базу.

Если интересует как ускорить чтение - кеширование, индексы, агрегация штуками типа elasticsearch. Но опять же только если у вас есть проблемы с производительностью. Не занимайтесь преждевременной оптимизацией. Сначала напишите нагрузочные тесты и посмотрите насколько все плохо и надо ли что-то делать.

По мне так, "вся" информация, которая должна меня заинтерисовать в плане покупок, должна находится в шапке. В футере же обычно находится
- контактная информация
- копирайт
- как проехать к магазину
- вакансии
- о вас
- FAQ,
- методы оплаты итд
В футер обычно заглядывают в том случае, когда надо копать глубже, т.е. клиента интерисует не только найти товар и нажать кнопочку "заказать". Поэтому все что касается удобства в плане покупок для клиента должно быть видно СРАЗУ. Вот серьезно иногда так бесит, когда важную информацию куда-то шкерят :)

* {
    box-sizing: border-box;
}

Но лучше для этого иметь спиленный под себя ресет.

Зачем нужен header_block?
Зачем пустой wrapper?

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

echo $arRes["NAME"];

$arRes - это массив с разделами, если функция CIBlockSection::GetList отработала правильно.

А вообще возьмите себе вот такую функцию для дебага и вывода массива на экран, мне помагает всегда:

/**
     * @param array $what
     * @param bool $exit
     *
     * Вывод массива на экран.
     * Если $exit равен true - завершаем выполнение.
     */
function pre($what, $exit = false)
    {
	    if(count($what) == 0){
		    echo "array is empty";
		    return false;
	    }

        echo '<pre>';
        print_r($what);
        echo '</pre>';
        if($exit) exit;
    }

Если у вас аккуратные англоязычные ЧПУ/транслит - устраивать переход на кириллический вариант не считаю правильным.

Вообще, если у вас кириллический домен - смысл использования кириллицы в урл есть, а если домен с латинскими символами, то смешивать в URL кириллицу с латиницей я бы не стал.

Хотите выделение URL в выдаче - лучше сделайте правильный транслит в ЧПУ.

Прочтите исходник, открыт же весь код