sindrom

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

Фреймворки обычно имеют более обобщенное целевое предназначение, по этой причине на них обычно легче сделать сайт-визитку, который эл. магазин, немного соц. сеть и частично CRM.

Пример где стоит использовать CMS: нужен эл. магазин, маленький бюджет и сроки тоже. Берем PrestaShop, устанавливаем, прикручиваем тему, настраиваем. Следующий!

Пример где стоит использовать фреймворк: вам нужен сайт на подобии того, на котором вы читаете мой ответ. Да, его можно за уши притянуть к понятию "блог", но переписывать и допиливать нужно многовато. Пойдем от обратного (вы таки выбрали WP)
* Потом поймете, что нужно было еще абстрактный уровень над WP написать, потому как после обновления ваши правки затерлись.
* Потом вдруг случается несчастье: ваш сайт стал популярным и железо не тянет, вы задумаетесь об масштабировании, но окажется, что система довольно таки целостная и что бы ее разделить придется не хило так по вкалывать.
* Через какое-то время ваш проект будет на 50% состоять переписанного кода и костылей, обходящих логику WP.
* Вдруг, на хабре вы читаете статью про уязвимость в вашей версии WP, начинаете ее прикручивать, при этом часть вашего сайта тупо отваливается из-за тех же артефактов и костылей. Вы, ясное дело, фиксите траблюки.
* В один прекрасный весенний денек, когда птички поют, радость, счастье, улыбки и бла-бла-бла вам звонит руководство и говорит, что "ничего не работает ( с )", отчаянье-печаль-грусть-уныние-безысходность-тлен. Зайдя на главную вы увидите замечательный баннер:
Вас взломал @ сраный_script_kid. Один глаз начнет немного дергаться, "это нормально ( с )". Восстановившись из бэкапа 4-х недельной давности, вы начинаете судорожно писать 1ккк проверок всего и вся. Система мутирует в еще более страшную и громоздкую хрень.
* Через какое-то время вас просят добавить фичу "на вчера", а что бы это сделать придется переписать добрую часть вашего монстра, вы (ну судя по количеству факапов) уже с прокачанным скилом "тебе фича не нужна эта" убеждаете руководство в этом, подобные разговоры возникают все чаще и в один прекрасный момент вы, или вас - увольняют.
* На смену вам компания набирает других человек, которые выльют пару ведер крови из глаз, убедят руководство, что код не саппортабельный и перепишут вашего монстра с 1,5кк строк до 0,3кк на нормальном фреймворке.

sindrom, а о каком объёме страниц идёт речь?
Если это агрегатор, и объём от 50-100к страниц, то моему опыту да, при таком объёме ~80% страниц заходит за месяц. Какие показатели сайта, на который вы ориентируетесь при покупке? Сопоставима ли его стоимость с ускорением индексации? Я предполагаю, что индексация ускорится недели на 2 при возрастном домене. Но тут больше вопрос не индексации, а, что более важно, ранжирования.

Если вопрос только в индексации, то всё проще, я бы рекомендовал делать на новом. Создать html карту сайта, а так же sitemap.xml. На хабовых (основных категориях, самых посещаемых роботами) страницах сделать ротацию ссылок, чтобы в зависимости от частоты заходов робота, каждых раз ему подсовывались новые ссылки на страницы сайта. Ну и так же загонять робота на хабовые страницы со списком ссылок на новые страницы, которых ещё нет в индексе, инструментом "переобход страниц" в Вебмастере.

Можно научиться программировать и написать приложение самому. Идеальный вариант. Дарю Вам эту идею ))

Из комментариев видно, что вам непонятен практический смысл терминов "напряжение" и "ток". В этом случае разобраться помогает сравнение с потоком воды. Напряжение - это аналог давления, или разницы уровней выше-ниже плотины. А ток - аналог расхода воды (не зря созвучен слову "поток"). Если кран закрыт (выключатель выключен, цепь разомкнута) то какое бы ни было напряжение/давление, (по)тока не будет.
Теперь с вашим примером. Есть адаптер 12 в, 0,5 а. Включаем его - на выходе 12 вольт, и никакого тока, хотя на нём написано 0,5 а - ещё не создан путь для потока. Подключаем кулер - пошёл такой ток, который затребовал кулер, т.е. 0,18 а, и не больше (поток течёт по размеру дырочки, которую ему открыли). Остальные 0,32 ампера пока не востребованы. Подключаем ещё один такой же кулер - ток возрос до 0,36 а (два потока по 0,18). Поскольку адаптер может обеспечить 0,5, всё нормально. Но если подключим ещё один такой же кулер, суммарный ток возрастет до 0,54 а, что больше допустимого для адаптера - он будет перегружен, от него требуют невозможного. Если через плотину перельётся поток больше, чем может прийти по реке, то поскольку вода ушла, верхний уровень над плотиной понизится. Аналогично при перегрузке по току выходное напряжение адаптера понизится и уже будет менее 12 вольт. Если защиты от перегрузки в схеме адаптера не предусмотрено, он просто перегреется и может сгореть. Если защита предусмотрена, то при перегрузке она сработает, адаптер отключится, выходной ток исчезнет.

если врубаем напрямую, то нужно ли еще какой элемент в цепи, чтобы обезопасить сию конструкцию?

Если встроенной защиты от перегрузки нет, то обычно последовательно в цепь включают такой элемент, как плавкий предохранитель. Сгорая сам, он защищает от повреждения остальную схему, гораздо более дорогую. В вашем случае полезно последовательно с выходной цепью адаптера включить предохранитель на 0,5 а. Но реальный ток сгорания у дешёвых плавких предохранителей не точен и может быть в пределах -30%... +80%. Так что не удивляйтесь, если увидите, что такой предохранитель сгорит при подключении всего двух кулеров или не сгорит вообще, когда уже весь адаптер будет в дыму.

Перво наперво настойчиво рекомендую сообщить об этом заказчику, саму верстку выполнить в полном объеме согласно принятому описанию заказа, а далее предложить варианты заказчику. Либо вы заканчиваете полностью просто верстку статичных html для последующей интеграцией специалиста по bitrix в саму систему, либо вы сами берете на себя эти доработки но с условиями расширения времени заказа (и может быть оплаты).
Вашей вины в том что заказчик полностью не описал задачу нет, но и самого заказчика конечно же полностью в этом винить нельзя и будет по честному для заказчика как можно быстрее ему сообщить о проблеме и наиболее легкие пути выхода для всех сторон.
Если там человек адекватный, он оценит честность и думает пойдет вас на встречу если вы аргументировано обоснуете иные сроки или иные условия выполнения заказа.
Ну и в крайнем случае можно закрыть заказ по согласовыванию сторон, если же он подаст жалобу, то у вас тоже есть право жаловаться на условия ТЗ, в которых не было раскрыта истинная сложность задания.
И еще раз повторю, я настоятельно рекомендую быть прежде всего честным с заказчиком, а не стараться сделать то что у вас очень может быть не получится и таким образом неожиданно для заказчика сорвать сроки/качество продукта. Поэтому лучше как можно раньше предупредить, чтобы человек тоже скорректировал свои планы и оценил вашу честность.

Я свои приложения (для различного учета) под андроид пишу на 1С.

Было время когда работал в коворкинг-центрах, но потом с коллегами сняли небольшое офисное помещение. Так сейчас выгоднее поступать.

Если вы заскучавший ПХПист, может лучше в сторону питончика посмотреть? Это все конечно очень субъективная вкусовщина, но по моему люди которым далек Руби, а ПХП родной часто воспринимают Python как "красивый PHP".

херак-херак - и в продакшн

Иди грузчиком работать. Кодинг это не твоё.

Вы хотите к работе правительства РФ багтреккер подключить?