Квадратный корень из 256 или провал voice search

Он удобен при наборах через гарнитурку, например когда за рулём.

PHPLego: Плагины к сайту своими руками

Это не взаимоисключающие условия (имена по умолчанию и переопределение).

PHPLego: Плагины к сайту своими руками

Под «хранятся в репозитории» я и понимал системы контроля версий.

PHPLego: Плагины к сайту своими руками

Смысл только в том, что для начала неплохо, как минимум, избавиться от копипастинга.
А развивать и улучшать дальше можно практически бесконечно.
Тесты при таком хранении и использовании, конечно обязательны.
Лучше даже не «запускаете тесты», а «запускаются тесты и шлют вам на e-mail сведения об ошибках».

PHPLego: Плагины к сайту своими руками

Думаю, — высосали далеко не всё, а только надкусили.

Код из наследника Lego:

    return $this->fetch("lego_fotos.tpl");

Очень нехороший хардкод шаблона для контроллера.

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

    private $_template = 'lego_fotos.tpl';

2. Принять стандарты именования и вообще
больше не определять имя шаблона.
Пусть родитель (Lego) сам автоматом ориентируясь
по имени наследника, либо по пути, где он живёт
сам определяет шаблон.

PS. foto photo

PHPLego: Плагины к сайту своими руками

Статья хорошая и правильная.
Но возникает один вопрос, — если модули в проекты (цитирую автора) копипастятся,
то совершенно неудобной становится их поддержка.
Есть модуль, нашли в нём ошибку, либо решили доработать, — каким образом
вносить изменения во все проекты, куда он включен?

Я предлагаю такое решение:

1. Модули хранятся в репозитории.
   
2. На сервере для работы хранятся в одном месте, скажем
   /webhome/lib/modules
   
3. Этот путь прописан в include_path.
   

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