Absm50336

Не оттуда пляшете.

Давайте я вам как девочка девочке всё объясню. На примере джинсов.
Есть такая штука мода. Сейчас в обтяжку, раньше клеш или широченные. Но при этом всегда остаются люди предпочитающие классику или консерваторы, которые предпочитают даже слегка устаревшую классику.

Так вот, с сайтами аналогичная история.
10 лет назад считалось, что шрифт 14px это гигантомания и использовали 10 или 12. Между строчками крошечные отступы. Особо нерадивые даже между абзацами пытались не делать пустых строк.

Есть мода и восприятие пользователем современных сайтов. То, как хочется видеть именно сейчас. Изменяются даже пропорции и зависимости.
96 это точно такое же красивое число как 100. Это 16*6. А 16 это стандартный размер шрифта основных браузеров.

Кроме этого есть аспекты адаптивности.
И правильно не ширина кнопки равна 100 или 96px, а ширина кнопки это ширина текста плюс отступы. И хорошо бы, чтобы эти отступы были пропорциональны размеру шрифта, а не кратны 5px. Вы поставите отступ четко 20px, а пользователь поставит в настройках браузера шрифт 150%. И получится куцая кнопка с некрасивыми маленькими отступами.
При этом не все элементы должны быть кратны размеру шрифта, какие-то имеют другие зависимости.

Другой вариант, пропорции относительно размеров экрана или блока. Например, кнопка должна занимать всю ширину блока или половину. Если текст не помещается, то переносится.

Поэтому, хороший дизайнер либо сопровождает работу верстальщика, либо пишет сопроводительное письмо с указанием зависимостей, либо и то и другое.

И да, дизайнер может четко сказать, что справа отступ 19px, а слева 17, потому что визуально (например, из-за особенностей шрифта) получается ровно. Если это проблема для верстальщика, то не надо работать с таким верстальщиком.
Верно и в обратную сторону, если дизайнер нагородил какую-то невменяемую конструкцию из-за которой прибавляется лишняя 1000 строчек кода, то имеет смысл обсудить целесообразность ее использования с самим дизайнером и заказчиком.

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

Насколько реально получить из сайта на Вордпресс личную информацию админов?

Зависит от того, кто будет искать. Если хулиганы, то лишь через перебор доступов или дырку в плагине, а вот если органы, то здесь другой риторический вопрос...

Доменное имя у сайта есть? Договор на аренду этого домена кто-то оформлял? И зачем нам IP, если можно получить данные владельца домена, а он уже сам всё расскажет.

Как вариант, для постов можно использовать get_posts():

<?php

$args = array(
    'post_type' => 'post', // posts
    'posts_per_page' => -1, // counts per page
    'order' => 'ASC', // по умолчанию get_posts() возвращает посты в порядке от новых к старым, изменим на обратное
);

$posts = get_posts($args);

if (!empty($posts)) :

    foreach ($posts as $post) : setup_postdata($post); ?>
        <div>
            <h3><?php the_title(); ?></h3>
            <h4>Краткое описание:</h4>
            <p><?php the_excerpt(); ?></p>
            <a href="<?php the_permalink(); ?>">Ссылка на запись</a>
            <p>Тип записи: <?php echo get_post_type($post); ?></p> <!-- check post type -->
        </div>
    <?php endforeach;

    wp_reset_postdata();
endif; ?>

P.S. вставлять в button превью и заголовок не самая лучшая идея...

Студентам в начале курса говорила, кто хорошо в детстве играл в лайнс, тетрис и подобное, тот будет хорошо верстать.
Верстка это обычная геометрия средней школы записанная с помощью тегов и раскрашеная/подвинутая стилями. Всё.
Всякие JS и т.д. это просто следующий этап.

План действий может быть таким:
1. Берете/получаете макет
2. Внимательно рассматриваете его, мысленно разбивая на блоки. Думаете что куда может/должно растягиваться или уменьшаться при изменениях экрана и увеличении/уменьшении контента.
3. Если п.2. сразу не осилился, идете гулять или спать.
4. Возвращаетесь к п.2.
5. Верстаете понятные большие блоки, затем их заполняете. Разбивайте задачи более простые.

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

А совсем без проблем не выйдет, потому что экранов много, браузеров много, хотелок у заказчиков еще больше. Хорошо, когда эти хотелки интересные :)

Как можно установить чат с поддержкой на сайт?

- Установив плагин (множество бесплатных), онлайн-чаты для WP.
- Руками, вставив соответствующий код в тему или плагин WP:
-- Бесплатные: Quickley, Chatra, Бесплатный онлайн-чат для сайта на JS?
-- Условно бесплатные: Bitrix24 chat, AmoCRM chat, Umnico Live Chat итп.
-- Платные: JivoChat, Carrot quest, LiveChat итп.

Если проблема в плохих SQL запросах - то переписывать их
Если проблема в медленности диска \ отсутсвии кеша(тот же redis) - значит разбираться с этим

Запустил профилировщик, увидел, что все упирается в бд, на ум сразу пришло вынести эту часть в микросервис,

Начал правильно, но вывод сделал левый, по уму надо начать с тюнинга postgresql, оптимизировать SQL запросов (может у тебя там индексов не хватает или еще хуже, проблема N + 1), кешировании данных.

все упирается в бд, на ум сразу пришло вынести эту часть в микросервис

Какой ещё микросервис? Микросервис, который делает что?

В-нулевых, нужно конкретизировать что значит "упирается в БД". Тормозят какие-то конкретные запросы? СУБД не хватает ресурсов? Слишком медленный диск? Или, может, под "упирается в БД" вы понимаете всю бизнес-логику приложения, которую вы называете "берет из бд нужные данные" (и тогда становится понятно про микросервис)?
Во-первых, нужно вынести СУБД на отдельную машину, желательно на голое железо (если речь про реальный хайлоад, а не про кривой код и конфиги).
В-третьих, под это железо нужно СУБД корректно сконфигурировать.
В-четвёртых, нужно добавить кэширование.
В-пятых, нужно проверить алгоритмы и пофиксить узкие места (на последнем месте, потому что это самое трудоёмкое).

Я понимаю, что python и django не самые быстрые инструменты (мягко скажем)

Я вас уверяю, что проблема в вашей компетенции (мягко скажем), а не в инструментах. Есть достаточно проектов, написанных на Джанго, которые вывозят большие нагрузки.
Вы, в принципе, правильно сделали, что попытались поначалу закидать проблему железом - оно обычно дешевле, чем время разработчиков. Но параллельно надо и оптимизацией заниматься, и это требует системности, которой в вопросе не очень-то видно. Ну и компетенций разных - если тормозят алгоритмы - это одно, если конкретные SQL-запросы - это другое, если СУБД задыхается в принципе - это третье.

1. Оптимизация SQL запросов.
2. Кеширование часто используемых данных.
3. Кеширование ответов на GET запросы.

К сожалению с начальным знанием программирования - никак.
Вы не можете привлекать сторонних разработчиков, но уже привлекаете их через Тостер.

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

Как говорят - оптимизация до оптимизации не нужна.

У меня был опыт запуска интернет-магазина во времена, когда их было десяток на всю страну. Первый интернет-магазин мы писали почти полгода, внедрив в него тысячи фич, которые оказались невостребованными. Через год проект себя отбил, и мы заказали не редизайн а весь магазин с нуля. Разработка шла 2 месяца, обошлась в 4 раза дешевле. Функционал стал гораздо удобнее. И мы поняли, что в первый раз надо было тоже пойти по более простому пути, тогда мы мы запустились на 4 месяца раньше и отбились бы за полгода.