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

Верстаем мы всегда с макета.
Я не говорю о таком кейсе как собрать админку из компонентов бутстрапа по прототипу - это как раз самое правильное его использование.

Так вот от макета мы очень сильно зависим.
Если дизайнер потрудился хотя бы использовать сетку, то сетка и система breakpoints из Botstrap (4 версия, на scss) нам очень поможет. Если дизайнер идиот - не поможет ничего.

В моем шаблоне проекта сетка и брекпоинты есть по умолчанию. Так же как некоторые helper-классы.

Что касается остальных компонентов (типографика, таблицы, формы, кнопки и т.д.) - всегда нужно задавать вопрос, что проще/лучше: стилизовать свою кнопку или переопределить имеющиеся.

Насколько классы предлагаемые бутстрапом впишутся в общий стиль проекта?

Насколько мы облегчим поддержку проекта, перекостылив под дизайн половину того что взяли от бутстрапа, а 2/3 проекта написав своими стилями?

Я видел как по дефолту суют
bootstrap.min.css
bootstrap-theme.min.css
bootstrap.min.js
потом в отдельном файле переопределяя и дописывая все что нужно. Целый мать его bootstrap.min.js из которого использовалось только меню-бутерброд!

Видел целую коллекцию костылей, перемотанную изолентой чтобы было как в дизайне.

И что, насколько я новичёк и максималист с моей библиотекой миксинов (документированных, в т.ч. из бутстрапа), scss файлами, разнесенными по блокам и BEM-подходом к наименованию классов?
С опрятным css на выходе и инструкцией-рекомендацией как и зачем всё же использовать препроцессоры.

Таким образом, присоединяюсь к ответам Сергей и Serj-One . Каждой задаче - свой инструмент.
А поддерживать легко не столько код где использовался фреймворк (особенно в контексте css), а код, где использовалась голова.

P.S. Вот ещё достойное мнение например:https://gist.github.com/iAdramelk/d328b73c72cab92ef95f

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

Новички поступают как раз наоборот, т.е. лепят тот же бутстрап всюду, независимо от того, нужен ли он там на самом деле.
Дело в том, что css фреймворки - скорей инструмент прототипирования, нежели основа проекта.
Их применение оправдано в проекте без дизайна, какой-то технической вёрстке, админке, и т.д. Но в большинстве проектов с уникальным дизайном они попросту неуместны.
Верстай с нуля, и не парься. Это будет только плюсом, наберёшься опыта.

Найти шаблон слайдера и обернуть

<a href="/ссылка_раз"><img src="pick4er_bog.jpg"/></a>
<a href="/ссылка_раз"><img src="pick4er_bog.jpg"/></a>

Тут 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?

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