Игорь Воротнёв

InfiniteWP.

Для тех, кто спрашивает, лучший вариант - модуль. Чтобы потом не было вопросов "ой у меня это не работает!"

С точки зрения производительности - nginx + php-fpm под линуксом

Создаю минимальную разметку с базовыми элементами и пишу для них CSS.
Потом добавляю в разметку остальные элементы и пишу CSS.
И так далее.

Очевидно Disqus больше распространен в мире. Если ваша ЦА Россия - то ВК думаю однозначно.
Для ЦА в виде программерской аудитории, однозначно DIsqus

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

Как объяснить? По-простому.

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

Задача первого этапа - получить работающий образец. Хорошо, когда он полностью работоспособен, и даже находится в эксплуатации. Однако, для того, чтобы получить возможность *эффективного развития - нужна работа над качеством, в том числе и внутри.

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

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

Для начала надо понимать как устроен WordPress Самые азы *
Затем зная Иерархию шаблонов и умело пользуясь Условными тегами вы в сможете оформить вывод так, как вам надо
________________________________________
* Русский вариант слегка устарел, однако пользовать его можно, в английском варианте статьи информация более актуальная.

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

конечно, можно.
только это не алгоритм, а какая-то фигня.

На фирме решали подобную задачу. Все вполне реализуемо.
Не пишите всякий бред про плагины!
В данном случае без плагина не обойтись. Потому что тему нужно менять "на лету" поэтому в админке вы сможете настроить только основную тему, все сайдбары и настройки мобильной нужно реализовывать через плагин (это моно считать единственным костылем).
На всю работу с версткой мобильной версии у нас ушло около 40-ка часов

Посвещаю вас в тайны: беру 450 рублей / час, заказчик присылает ТЗ (или дает образец сайта), я считаю сколько времени мне потребуется на верстку каждой страницы и общую подготовку, суммирую часы и получаю итог.

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

Вы покажите макет и назовите CMS, включая перечень модулей, тогда вам и ответят. Иначе, пальцем в небо.

ну конечно WordPress

А чем не устраивает просто снять чекбокс «разрешить комментарии» в свойствах записи?
Форма комментов исчезнет, а уже опубликованные комменты останутся нетронутыми.

Через teamviewer дать заказчику возможность "подергать" страницы живьем на своем компьютере. Передачу файлов запретить.

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

1) Столбцу необходимо указывать тот тип данных, который для него подходит, и не обязательно минимально возможный. Чтобы понять имеет ли смысл экономить место, нужно проанализировать ваши запросы - по каким именно столбцам происходит поиск - вот их оптимизировать в первую очередь. Если запросы не выполняют поиск по вашему текстовому полю, то особо нет разницы какой оно длины - строка будет найдена например по id primary кей. а прочитать 2 кб или 3 кб - разницы нет. То есть ВСЕ поля минимизировать для ускорения нет смысла, разве что для уменьшения памяти.

2) sql не адресует биты, он все равно будет выделять минимально байт для хранения флага. enum не означает 2 байта, enum может означать список флагов, это вполне может быть и 1 байт со значениям 0 и 1. или 0,1,2. Зависит от базы.

3) text - удобно, если вы не знаете точный размер. varchar хранится прямо в строке, text и blob хранит там ссылку, а сами данные хранятся отдельно. С точки зрения оптимизации памяти - текст выгоднее. С точки зрения скорости доступа к данным - varchar быстрее. Плюс по text нельзя индексировать.

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

5) varchar(2000) для всех значений. На случай если вы вдруг измените строку в таблице, и чтобы это место в памяти не "раздвигать", перемещая ВСЕ данные.