Что лучше: заказать у разработчиков сайт с нуля или использовать вордпресс?

Сначала он говорит

а потом

Затем, он узнает свое второе имя...

...и ретируется.

3 года в актерском, а потом забросить, но какая игра! Мы будем скучать.

Сайт визитка на

это уже не сайт визитка. Но ладно, раз вы изначально задачу не понимаете, то есть предположение, что и дальше ничего не поймете.

borisd, я вас просил привести пример мелочи, но вы ничего конкретного не сказали. Наверное потому, что любая мелочь реализуема, если это действительно мелочь. Если это не мелочь, тогда ставится под вопрос внедрение данного функционала, если он не основополагающий в конкретной бизнес-модели. Если без него никак, или его внедрение покроет затраты на внедрение, тогда выбирается: прикостылить к WP (можно в принципе все что угодно, и даже вынести в микросервис, на другую машину, на другой язык и другой стек технологий), или же писать на фреймворке. Но нужно учесть, что если писать на фреймворке, тогда нужно описать тонны того бойлерплейта (образно говоря), который в WP уже описан, и блоги, и посты, и поиск, и админку, роутинги и модели, адаптеры под кеш, работа с изображениями, архитектуру БД, и все то, с чего начинается проект. Все упирается в рентабельность. И да, что вы видите на сайте ресторана, чтобы выйти в топ по запросу "мухосранск аренда банкетного зала"? Что там должно быть? Игру браузерную? Пульс повара на главную через веб-сокеты?

Например, нужно реализовать дерево объектов разного типа (с разным набором полей, методов, с разной логикой работы и отображения), причем для каждого типа надо определить правила: какие типы допустимы в качестве родительских и какие в качестве потомков. Это банальный каталог, но нормальный, без глупых ограничений.

---------- Добавлено 07.06.2017 в 18:21 ----------

Зачастую это проще, чем делать на базе коробочной ЦМС. И кода там будет не тонны, а сотни строк всего, ну несколько тысяч.

Не проще? Нет ничего проще, чем ничего не делать. Там это все встроено. Даже по клавишам стучать не надо.

Вы считаете строки проекта? Или только то, что сами написали? И там и там число их будет примерно одинаковое +/-.

Это можно сделать в любой CMS, в которой можно создавать таблицы и писать код на PHP.

Конечно, всё что угодно можно сделать. Разве об этом спор?

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

Всегда можно связаться с автором модуля, и за денежку доработать. Но это произойдет уже после запуска проекта, когда доработка будет обусловлена не гипотезой, а необходимостью.

В крайнем случае - можно заказать компонент под свой проект. Компонент дешевле, и его на доработку передать другому разработчику всегда проще, поскольку его архитектура будет всегда обусловлена хорошо документированной архитектурой CMS. Внутри компонента может быть говнокод. Но даже в этом случае переписать его полностью - дешевле, чем в случае говнокода переписать сайт.

А обновлять модуль тогда как? Никак! Нехорошо хакать сторонний модуль под себя. Разве что если только автор модуля пожелает включить данный функционал в свой продукт.

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

Все бывает. И конечно, не очень правильно тут разгонять коня сферического в отсутствии деталей. Но могу только одно сказать, как заказчик, прошедший все модели - и самопис, и три CMS с модулями разной степени кривости. При наличии относительно типовой задачи, я предпочту:

• Никогда не использовать самопис - только коробочная CMS (не хочу платить за стандартный функционал)
• Никогда не соглашаться на правку ядра, только модули/плагины (важно сохранить уверенность, что секюрити-патч не сломает логику сайта)
• Никогда не соглашаться на большой, комплексный модуль/плагин - только декомпозиция до атомарных задач (легкая замена программиста)
• Всегда держать на хостинге три версии проекта: dev (для игр программиста), test (для игр девочек контент-менеджеров), prod (для людей)
• Всегда делать синхронизации между dev/test/prod только через git - это гарантирует, что софт будет написан так, чтобы работал на любом домене - облегчает переезд и развертывание у нового программиста.

.

В итоге, для меня выгоды такого варианта перебивают с лихвой возможные ограничения и тормоза CMS. ТСО на перспективу важнее. Вопрос замены программиста - жизненно критичен. Возможность искать для нового модуля/плагина стороннего разработчика - важна для нестандартных модулей (доставки, налоги, то есть когда нужен программист с финзнаниями).

И естественно, от меня на вход программисту:

• детальное ТЗ
• интерактивный прототип Axure RP
• предложения по составу (декомпозиции) модулей

Все, этот подход мне сейчас гарантирует не хороший, но вполне приемлемый вариант.

Ответ хоть и прост, но не всегда однозначен. Чем типичнее задача тем с большей вероятностью ее нужно делать используя готовые решения (CMS). Но, во первых могут быть нюансы. Во-первых производительность, например тот же Wordpress может долго думать (4-7 секунд загрузка), если количество постов перевалит за несколько сотент тысяч.

Во-вторых надо учитывать как ваш сайт будет расширятся. Сначала можно воспользоватся тем же Wordpress или Drupal, а потом, если необходимо, написать свою систему. Задача переноса существующих данных в новую структуру может быть нелегкой, но всеравно она значительно проще чем поддержка своего велосипеда там где можно было обойтись готовыми решениями.

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

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

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

В любом случае это на 70% зависит от професинальности и отвественности разработчика. Я сталкивался раз с ужасным быдлокодом написаным под Drupal и это был тот случай, когда нельзя было назвать прежнего разработчика идиотом, но желания написать код красиво, так чтобы было понятно еще кому-то кроме него небыло никакого. Это был тот случай (обменник между платежными системамия) когда лучше было бы написать с использованиям какого-то фреймворка и отдельно запустить какой-то лендинг с блогом на Wordpress. Но увы, у разработчки, наверно небыло представления как делать гибкую архитектуру, расширяемую архитетуру и он использовал махину Drupal, под которую только и умел делать. Неумения писать код перекрыло все преимучества использования Drupal

Только в том случае если разработчик этого стороннего модуля предусмотрел этот самый механизм наследования. Хотя бы проверку существования функций. А многие ли это делают? Особенно самописатели. Ну да, где-то 0,001% ;)

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

Я не знаю сколько, но именно у ВП есть множество разных средств. Механизм дочерних тем - это вообще бомба.

Всё, более менее современное сейчас активно юзает наследование

Например так:

class galery extends base_action {  

/* 

  url: /galery/page/(int) $page

  url: /galery/image/(int) $id

*/

  private $template = 'gal.tpl', $db=null;



  private function read($table, $where, $fields, $limit='LIMIT 0, 10'){

    return DB::q('SELECT', $table, $fields, $where, $limit )->by_Array();

  }

  

  public function page(){

    $page= isset(Request::URL_Section[2]) ? (int) Request::URL_Section[2] : 0;

    $start = $page * 10;

    echo $this->out($this->read('galery', ['is_visible'=>1], ['id','thumb','alt'], "LIMIT {$start}, 10"));

  }



  public function image(){

     echo $this->out($this->read('galery', ['is_visible'=>1, 'id'=>(int) Request::URL_Section[2]], ['path','thumb','title','alt'], 'LIMIT 1'));

  }



  private function out ($data){

    $twig = ....;

    $template = $twig->loadTemplate($this->template);

    return $template->render($data);

  }

}



class supergalery extends galery {

/* 

  url: /supergalery/page/(int) $page

  url: /supergalery/prosmotr_kartinki/(int) $id

*/

  

  function prosmotr_kartinki(){

    $this->template='super_galery_simpe.tpl';

    echo $this->out(

      array_merge(

          $this->read('supergalery', ['is_visible'=>1, 'id'=>(int) Request::URL_Section[2]], ['path','thumb','title','alt','reviews'], 'LIMIT 1'),

          $this->read('supergalery_comments', ['is_visible'=>1, 'id'=>(int) Request::URL_Section[2]], ['user_id','comment','user_name'], 'LIMIT 30')

      )

    );

    DB::q('UPDATE', 'supergalery', ['reviews'=>'`reviews` + 1'], ['id'=>(int) Request::URL_Section[2]]], null );

  }



}

набросал за 5 мин для иллюстрации как делают. Особенно самописатели😂 Если модули в этом стиле прибавить к автолоадеру, классу Request (для обработки и SANITIZE REQUEST_URI, пост, гет и прочих кук), роутеру и добавить класс-надстройку, например над PDO, для манипуляций с БД, то вот он, простейший, но вполне функциональный и быстрый фреймворк:p

Ворд пресс же, имхо, заложник своей популярности, т.к. все можно сделать гораздо проще, быстрей и эффективней, а не выходит, ибо вот. Да и в текущей системе не все гладко.