Volodimir Babeshko

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

И по поводу того, что должно быстрее грузиться в начале и что потом: сама форма весит крайне мало, основная нагрузка при загрузке - это сам текст комментариев, поэтому прятать форму смысла не имеет, а имеет смысл ограничить количество выводимых при загрузке комментариев с кнопкой «Показать ещё», пагинацией или бесконечной прокруткой. Саму форму вместе со скриптом обработки можно вообще вызывать только по клику на кнопку (ссылку) «ответить» под комментариями и в самом конце (начале) блока с комментариями. Говорю это по опыту, если не позаботиться об ограничении комментариев при загрузке, то можно через пару-тройку лет получить проблему - у нас несколько страниц выросло до мегабайта в сжатом ганзипом объема, ну и как понимаете это были популярные странички - по сео особо из-за этого не просели (субъективно), но время загрузки превышало медиану раза в два.

Даже если не впадать в крайности, как предлагал hint000, то существовала раньше возможность привязать несколько сайтов к одному владельцу через код аналитикса или метрики (айди был одинаков), как сейчас обстоит дело без понятия, но вполне возможно есть способ узнать и по хешу из тега, если знать особенности его формирования (если не рандом), но по поводу этого ничего не знаю. А вот по айди счетчика даже сервисы поиска связанных сайтов были.

Попробуйте проверить вообще nginx установлен или нет (вполне возможно Вы работаете под апачем), если установлен, то в /etc/nginx/sites-available/ создайте любой файл, доступный пользователю nginx'а (прописан в /etc/nginx/nginx.conf в самом верху) и запишите в этот файл всю конфигурацию и поставьте симлинк на этот файл в /etc/nginx/sites-enabled/

Вам уже все правильно подсказали, я расскажу зачем эта папка нужна и почему такие проблемы если ее удалить. Сам gulp выполняет только одно действие - он запускает программы, которые Вы ему пишите в gulpfile.js (точнее какие именно и для каких файлов и в каком порядке), а эти все программы устанавливаются в папку node_modules и список этих программ с версиями записывается в packages.json (включая другую информацию по проекту, типа названия и описания). Так вот получается так - если в проекте используется gulp, то для него мы пишем вначале packages.json и там записываем (вручную или через параметр установки --save или --save-dev) какие программы нужны и простой командой npm install все устанавливаем (вот ту самую папку node_modules и создаем), затем пишем в gulpfile.js что должно выполняться в проекте и профит. Это почему нельзя работать без папки node_modules.

Теперь ответ на вопрос, как же не тягать папку node_modules, а точнее одни и те же программы в каждый проект. Я лично делаю так (у меня проектов мало - мы продуктовая компания и продуктов всего до десятка, но вот версий очень много, поэтому часто мешает все это дело), в корне папки создал packages.json и gulpfile.js. В этой же папке я создаю для каждого проекта подпапку и ложу туда проект. Все действия для gulp описываю в gulpfile.js,, который лежит не в отдельной папке, как у Вас, а корне основной папке (в корне той папки где лежит сама папка с проектом) и указываю пути в эту папку. Это конечно не очень удобная практика, т.к. в одном файле gulpfile.js находятся все команды для всех проектов, но у меня специфика позволяет удобно этим всем управлять, т.к. новых проектов очень мало, а поменять путь к новой версии и прочему - это минутное дело. Хотя я стараюсь в последнее время делать как Вы, т.е. один проект - один конфиг gulp и своя папка node_modules, чтобы избежать путаницы.
Теперь про сдачу на проверку - Вы сдаете только готовый продукт, верстку или что-то похожее и тянуть все не имеет смысла. Обычно делают так - в папке с проектом лежат в отдельной папке исходники и в отдельной папке уже готовые обработанные файлы, которые собираются из исходников - вот как раз эту готовую папку без исходников Вы можете давать на проверку и потом если все хорошо и все утвердили, то потом просто прикладываете к ней папку с исходниками, gulpfile.js и packages.json и ничего другого не нужно. Заказчик просто запустит в папке с packages.json команду npm install и ему все остальное установится (ну кроме глобального галпа) и ничего тяжелого в виде node_modules никому передавать не нужно.
И совет, уже многие советовали пользоваться Git и публиковать свои проекты в отдельных репозиториях на github.com или bitbucket.com. Это очень удобно, т.к. можно просто передать ссылку на репозиторий заказчику и он оттуда сразу же скачает. Если заказчик против публичных ссылок, то можете это делать для себя в приватных репозиториях, например: у bitbucketа бесплатные приватные репозитории. Но для Вашей работы это очень упрощает очень многие процессы, типа хранения старых проектов и их изменения + передача другим разработчикам.

По сути Вам нужен только домен с S добавлять. Если Вы все равно или сделали или планируете их склеить и поэтому и www и обычный домен без S будут без трафика и в отчетах там будет почти пусто, а на основном зеркале будет вся статистика. У нас тоже добавлено три домена (https://www... не добавляли) и толку от того что там домены эти есть толку нету - по ним трафика нет, т.к. это неосновные зеркала.

Мы делаем аналогично, но у нас на проектах очень маленькие базы. А Вам бы я посоветовал настроить репликацию мастер-слейв и делать бекап со слейва, в инете много туториалов на эту тему. Это должно решить вопрос с доступностью сайта + всегда можно дамп сжимать ганзипом и проверять после этого архив, а лучше делать распаковку и импорт в тестовую базу и следить за возникновением ошибок во время этого.