Иван

Разверни демку от симфони и xdebug'ом пройдись несколько раз по пути запроса клиентского. Думаю, что сразу много интересного увидишь :) Там и события, и компиляция, и DI, и слабая связанность, и много всего другого. Самое главное, что реализовано толково, я бы даже сказал академически правильно. Ну насколько это возможно сделать на "академически странном" языке php.
А затем попробуй на этом же фреймворке реализовать какое-нибудь простое приложение, например, которое просто принимает от клиента запросы по АПИ и что-нибудь делает простое.

Не помню точно методов этой библиотеки, но логика вроде ж простая:
1. В коде определяем ориентацию по соотношению стороны по вертикали и горизонтали.
2. Если картинка в портретной ориентации(ширина по Х меньше, чем по У), то делаешь applyFilter(a), иначе применяешь фильтр б.
Чем так не подходит ?

В распараллеливании смысл, конечно, есть. Просто это должно делаться на всех уровнях. Апач не использовал уже несколько лет, поэтому тут ничего сказать не могу, но судя по описанным симптомам, затыком у тебя является БД.
Конкретно с firebird не работал, но наверняка её можно распараллелить через репликации.
Т.е. сейчас у тебя получается 3 php-скрипта делают запросы к бд. Бд обрабатывает запросы синхронно, поэтому никакого выйгрыша в скорости не получается. Можно либо в настройках бд поискать асинхронную обработку запросов, но врядли там такое есть, либо реплицировать бд по типу мастер-слейв и запрашивать с разных слев-серверов бд данные, тогда прирост в скорости будет.

Вы представляете себе, что Модель это что-то конкретное, но на деле это просто абстрактный слой и Вы сами решаете какие классы в него входят, а какие нет. На деле в модели содержится ВСЁ, что связано с данными и бизнес-логикой над ними. Далее идет уже реализация, которая может быть очень и очень разной. Например, есть шаблоны проектирования ORM DataMapper и ActiveRecord. Они чуть ли не противоположно разные в реализации, но они обе модели. При этом есть более низкоуровневые архитектуры, например Domain Driven Development и Data Driven Development. В обоих случаях уровень Модели может быть размазан на несколько слоёв приложения.
Я сейчас работаю в проекте с Domain Driven и там модель размазывается просто на кучу слоёв приложения. Как она будет размазана завист от того, какие слои для своего приложения Вы сами определили изначально.
И Ваше утверждение, что большинство фреймворщиков ничего не понимают в этом - полная глупость. Фреймворк Симфони - это просто эталон академичности проектирования в пхп. На его основе Ларавель - тоже достаточно грамотный фреймворк. Есть еще Yii, которые пошли другим путем, но тоже очень четко разделяют внутри модель MVC, хотя и дают много возможности наговнокодить и всё смешать в кучу.
Тут скорее Вы не понимаете, что модель - это не что-то конкретное, а лишь один из 3х компонентов, из парадигмы mvc, ответственный за хранение и изменение состояния данных. Реализаций может быть столько сколько существует программистов и даже больше.
Еще более неопределенное - это то, как взаимодействуют эти 3 компонента из MVC между собой. Они могут на основе событийной модели взаимодействовать, или явно вызывая друг друга, и еще огромным числом разных способов.
Касательно Вашего примера, то Вы описали слой хранения данных, переходящий в модель. Моделью, в Вашем случае, является 3ий уровень - строка таблицы(ну может и таблица тоже). 1ый уровень у Вас - это уровень, который должен синхронизировать модель с хранилищем данных. Причем таких "синхронизаторов" может быть несколько и хранилища могут быть очень разными. Например ORM и ODM. Они будут проэцировать и синхронизировать модели с хранилищями данных, но по сути к моделям они не относятся, хотя если нам нужно их всё же определить только в рамках MVC, то это конечно же будет моделью. Но в mvc есть много вещей, которые не относятся ни к одному из этих 3х компонентов, а являются связующими звеньями этих компонентов, например те же ORM, ODM, валидаторы(иногда их в модель зашивают, хотя они могут использоваться и во вне), роутинг, событийные компоненты, логер и прочее-прочее.

А в чем сложность через brew установить себе nginx и всё прочее, что необходимо ?

Тем плохо, что кол-во экземпляров этих классов будет равно кол-ву открытых соединений с БД. Плюсом экземпляры класса могут умереть неожиданно, а соединения будут висеть не закрытыми, что не очень хорошо.
Нужно стремиться к тому, чтобы было минимальное кол-во соединений с бд.
Denis Derepko дал правильное направление тебе.

Если ты занимаешься написание программ для компьютеров, то можешь себя называть программистом смело :)
А вот называть себя "супер программистом", это уже сложнее. Для каждого это что-то своё.
Рядовые рубисты считают себя супер программистами, но по мне дк большинство просто выскочки с натянутой самооценкой.
Вордпрессеры многие тоже себя считают супер программистами и что имеют опыт решения "сложных" задач. Главное не спрашивать каких, а то все мозги проедят какой-то мелкотнёй. Возможно это и правда, ведь в контексте вордпресса они многое знают, но в рамках программирования ...
Я могу так бесконечно перечислять, потому что сам прошел через многие различные этапы, когда считал себя "супер программистом". НО чем я больше узнаю в этой сфере, тем больше понимаю, что очень и очень далеко мне еще до каких-то званий. Во всём мире я вижу не так уж и много "супер программистов", даже среди тех, кто сделал какие-то популярные решения. Примеры приводить не буду :) Просто кто для Вас "супер программист" ? Торвальдс ? Ван Россум ? Брин ? Если кто-то их уровня, то думаю не в этой жизни нам называться с приставкой "супер". Ну а если какой-нибудь Вася из веб-студии "супер сайты", то возможно, Вы уже намного "супернее" и сейчас :)

Можешь попробовать приводить все входящие данные url к одному виду(canonical) и хранить этот вид в базе в отдельной колонке.
Допустим, сперва определяешь сколько уровней домена.
ecco.ru - 2 уровня (ecco и ru),
men.ecco.ru - 3 (men, ecco, ru),
www.men.ecco.ru - 4 (www, men, ecco, ru)
Сделать это можно как-то так:

$urls = "www.ecco-shoes.ru
www.ecco-shoes.ru
http://ecco-shoes.ru
https://www.ecco-shoes.ru/
www.ecco-shoes.ru/
ecco-shoes.ru
www.ecco-shoes.ru/?
www.ecco-shoes.ru/#
www.ecco-shoes.ru/index.php";

$urls = explode("\n", $urls);

foreach ($urls as $url) {
	$hostname = parse_url($url, PHP_URL_HOST);
	$domains = explode('.', $hostname);
	
	echo $url."<br/>";
	echo $hostname."<br/>";
	
	foreach ($domains as $domain) {
		echo $domain."<br/>";
	}
	
	echo "<br/><br/>";
}

Затем конструируешь из этих частей урла нужный вид, например игнорируя www, и сохраняешь это в базе в доп. колонке. Желательно все эти части привести к одному регистру, допустим к нижнему.

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

А не пробовали просто создать тег с подключением файла и вставить ?

Не понимаю, как можно попасть на сервер что-то введя в браузер. С другой стороны не понимаю, как можно попасть на сайт, но не попасть на какой-то сервер :) Но это лирика.

Во-первых: для обновления DNS требуется время, но если у Вас в hosts-файле прописан явно ip домена, то браузер на этом компьютере и не полезет в DNS.
Во-вторых: домен должен быть настроен и подключен к исходникам сайта на новом сервере, как написали уже здесь.

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

Я думаю, что всё таки чего-то Вы недоговариваете. Давайте больше информации.

Я установил highline и всё стало норм.
sudo gem install highline

Пишу самописный движок одного сайта.

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

• С какими цмс и фреймворками Вы уже работали и насколько глубоко их знаете ?
  
• С каким кол-вом проектов в целом уже сталкивались, какие сложности возникали ?
  
• На какой тип проектов рассчитана Ваша cms ?
  
• Какие готовые решения будете брать за основу ?
  

Думаю, конечно, что Вы почти ни с чем не работали еще и даже не очень представляете, как спроектировать более-менее гибкую и надежную систему, ну да ладно, это Ваше уже дело.

Какой htaccess ? А если "сайт взлетит" и придется nginx поставить ? :) Ладно, шучу, не взлетит ни сайт, ни cms, так что за это не беспокойтесь :)

По сути Вашего вопроса.
У Вас должен быть слой, который отвечает за сопоставление запроса к некоторому контроллеру/действию/методу/еще чему-то. Назовем данный слой Router.
А у Router'a может быть такая логика: если после домена идёт /(ru|en|pl), то установить в сессию или куку соответсвующее значение текущего языка.
В коде, где выводите какой-либо текст, то оборачиваете этот текст в метод перевода. Например, пусть это будет статический метод Translator::trans($message). Внутри статического метода берёте из сессии/куки текущий язык и смотрите есть ли данное сообщение для такого языка. Ну а дальше развивайте логику, как хотите.