EvgenyMorozov

Поставить роутер с авторизацией у входа, а второй роутер (который раздает wifi - я так понял?) перевести в режим "точка доступа".

Бери тут https://underscores.me/

Хотите проблем - ну делайте "модно-стильно-молодежно". Не хотите проблем - делайте кабелем. wifi был придуман для носимых устройств и оправдан там, где прокладка сети уже невозможна - в старых офисах, на арендуемых площадях, в исторических зданиях.
При проектировании сети всегда стоит закладывать на каждое место на одну розетку больше, чем было посчитано :) Узловые свитчи вязать оптикой. Серверную располагать так, чтобы "чужие здесь не ходят".

Вот смотри - у тебя хостинг. Он с вероятностью 10 раз в год может отвалиться (банально - перезагрузка).
Теперь у тебя еще есть стороннее облако. Оно с вероятностью в 10-ть раз в год может отвалиться (банально - перезагрузка).
Потом ты решил jquery с cdn грузить - эта либа с вероятностью в 10-ть раз в год может отвалиться.
Потом ты поставил метрику и пиксель - они с вероятностью в 10-ть раз в год (каждая) может отвалиться.
У тебя гугл рекапча - она в 2019-м блочилась роскомнадзором - в итоге сайт не совсем так работал.
У тебя комментарии ВК - но политиканы других стран (украина например) его заблочили. И ты можешь и не узнать оперативно об этом.
Ты поставил сторонний плагин (uLogin например) - он сливает твоих посетителей и зарабатывает на них загружая вредонос с третьей стороны к тебе на сайт. Как пример - он данные форм сливал.

Итог - разнося всё на разные решения ты лишь увеличиваешь шансы что конечный пользователь испытает проблемы с твоим сайтом. Ты не знаешь как политика разных стран все эти отдельные сущности будут блочить или когда у облака или cdn произойдет отказ. А это есть. Это бывает. В итоге ты лишь увеличиваешь варианты и шансы отказов. Тебе это надо?

Ну и ответ: всё храни у себя. Хороший хостинг все держит.

А как именно вы собираетесь кешировать в memcached, как его использовать? Как стандартный object cache? Fragment cache? Full page cache?

Из всех вариантов кеширования самым быстрым будет Nginx fastcgi_cache, поскольку он будет отдавать статические HTML-страницы прямиком с диска, а то и из памяти – даже не обращаясь к PHP-процессу, не поднимая WordPress и тем более не трогая базу. Но это полная статика, а значит не подойдет если у вас необходимость показывать динамические данные на странице (авторизованные пользователи с личными кабинетами, корзины покупателей и тд).

WP Super Cache по сути делает то же самое, но на уровне плагина - он генерирует статические HTML-страницы, и веб сервер конфигурируется чтобы отдавать их. Это тоже быстро, минусы плюс-минус те же, но как бонус есть возможность определенной настройки в админке и гибкости. Но это в экспертном режиме. Кроме него он может работать в cмешанных режимах где PHP все-таки задействован, не нужно менять конфиги сервера и при этом можно даже кешировать условно динамические страницы. Это огромное преимущество перед nginx fastcgi_cache, если сайту такая функциональность нужна.

Нужно ли иметь одновременно и nginx fastcgi_cache и wp super cache? Нет. Выберите одно из двух. Если сайт может полностью жить в статике - nginx fastcgi_cache настроили и забыли. Если логика статики и динамики чуток посложнее - WP Super Cache.

Независимо от первых 2х вариантов, можно использовать кеширующий бекенд (memcached, redis) для кеширования фрагментов, объектного кеша и любых других данных. Полезно для кеширования .mo файлов переводов, отрендеренных ресурсоемких фрагментов (меню, блоки/виджеты с калькуляциями и тд), стандартного объектного кеша WP и тд. Это второй, внутренний уровень кеширования и важен как раз для динамических запросов, которые не используют full page cache от Nginx / WP Super Cache.

Этот файл пережиток MS-DOS, там в нем хранились первоначальные настройки ОС. Современной винде он не нужен уже давно. Когда еще была DOS подсисетма в винде был аналог config.sys. Сейчас уже и DOS программы на винде не запустить, а значит и необходимости в файле нет.

Давайте для начала определим вашу роль и ваши цели.

Если ваша роль - разработчик, то must-have плагинами будут те, которые облегчат вашу работу - Advanced Custom Fields (желательно Pro), Query Monitor, Laps и тд, или же малой кровью решать типовые задачи - Classic Editor, Disable Comments, Safe SVG, Enable Media Replace и подобные. Под "малой кровью" имеется в виду что они имеют минимальный overhead, не делают ничего лишнего и вы сами лучше все равно не напишете. Все остальное пишем сами, форкаем у других разработчиков, тюним под свои задачи и тд - со временем накапливаем собственный инструментарий.

Если ваша роль - имплементатор (собираете сайтики на WP, но в PHP не умеете), то набор плагинов будет другим. Тут уж коллеги-имплементаторы подскажут какие плагины важны, какие нужны.

Если ваша роль - владелец сайта, который все сам хочет делать - это ближе к имплементаторам.

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

Теперь по целям. Чего вы хотите? Чтобы можно было быстро собрать сайт для тестирования бизнес идеи с минимальными расходами? Это одна кухня. Чтобы был легкий и быстрый контент-сайт, который выдерживает серьезный трафик? Это другая кухня. Интернет-магазин? Вообще другое. А в какой нише этот интернет-магазин? Физические товары или цифровые? А рынок местный или международный? Это все будет вас приводить к разному набору плагинов. Думаю, смысл уже понятен.

Ту платежную систему, которая вам нравится и условий которой вас устроят.
Размер магазина не имеет значения... ну и смотрите, чтобы плагины этой платежной системы корректно работали бы с актуальными версиями вукомерца и ВП

- В robots.txt запрещаем индексацию
- Добавляем в шапку noindex
- Отключаем карту сайта
- Закрываем доступ для неавторизованных посетителей, чтобы только админы и редактора могли ходить по сайту, для всех остальных одна страница-заглушка "coming soon"
- Когда сайт готов к публикации - открываем карту сайта, разрешаем индексирование, подключаемся к Google / Yandex Webmaster Tools, сабмиттим сайт в очередь на индексацию.

Открыл вопрос и из монитора хлынул поток воды, так что сразу к вопросам:

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

Да Микроты ставьте, если прокачаться хотите. В качестве свитчей - HP, например. Можно и D-Link, не слушайте диванных кукаретиков.

Как делать - 4 коммутатора на все устройства (в шкафу), или же по одному на этажах и центральный в серверную?

Всё в шкаф, чтоб потом не бегать по этажам и не искать причину поломки.

Как нарезать vlan? По этажам? По кабинетах?

По кабинетам геморройно, я бы вообще ничего не делал, сеть-то маленькая.

Так и не знаю делать ли интернет розетки или нет)

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

А, да, и AD бы всё-таки настроить и DNS с DHCP на Windows Server зарулить.

time будет каждый раз выдавать новое значение, поэтому лучше использовать filemtime. Это функция, которая возвращает время последнего редактирования файла.
В таком случае у вас информация всегда актуальная будет, и каждый раз скрипты и стили заново грузить не потребуется.