Immortal_pony

Можно. Эти занимаются специально обученные люди, которых вы можете найти на сайтах фриланса.

Если хотите заняться этим сами, то ищите информацию по запросу "натяжка на joomla" например, или "сделать шаблон для joomla"

https://phpdelusions.net/pdo/common_mistakes

Запихните результат во временную таблицу и сделайте выборку из нее. Где уже не надо будет выполнять concat.

stackoverflow.com/questions/3311903/remove-duplica...

select u.id, u.login
    coalesce(income.sum, 0) - coalesce(payment.sum, 0) as balance
    from users u
        left join (
            select user_id, sum(money) as sum from moneyuser group by user_id
        ) income ON u.id = income.user_id
        left join (
            select user_id, sum(money) as sum from payments group by user_id
        ) payment ON u.id = payment.user_id

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

where payment.user_id is null and income.user_id is null

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

https://packages.debian.org/jessie/php5-ssh2
не он?

Ну а непосредственно по листингу - configure не может найти заголовки библиотеки, т.е. *-dev пакет библиотеки. Для jessie и wheezy - это libssh2-1-dev

У вас может быть и модель, и прдставление и контроллер хоть в одном файле, суть то не в этом.

MVC описывает не все приложение (есть Model2 которое убого но описывает все приложение, но я бы не рекомендовал вам сейчас на него ориентироваться). Оно описывает только "как сделать так, что бы приложение ничего не знало о UI".

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

Далее, у нас есть представление. Вопреки вашему мнению, представление это не html а http. Поскольку PHP должен сформировать именно HTTP ответ (так или иначе, при помощи echo и header или при помощи абстракций над http). Просто обычно сайтики в качестве тела ответа содержат html. Но намного проще воспринимать "представление" как HTTP ответ. "шаблонизаторы" в этом плане не относятся к представлению, это способ его генерации. Сделаем допущение что весь view в нашем MVC это обычный HTTP ответ. Просто кусок текстовой инфы выплюнутый в буфер вывода. Помимо HTTP есть еще варианты: CLI или консольные скрипты, у них сфой формат представления. А еще есть менеджеры очередей и кучи других вариантов.

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

Ранее мы уже сказали что "шаблонизаторы" это не часть представления а только способ его получения. Где мы должны использовать шаблонизатор тогда? Как сделать так, что бы наша "модель" или точнее наше приложение ничего не знало об этом "шаблонизаторе" (или сериалайзере, или json_encode, или еще чем-то там)? Положим между представлением и моделью что-то промежуточное - контроллер.

Опять же контроллер - это не обязательно один объект. Это может быть целая цепочка объектов, которая может передавать запросы друг дружке и что-то с ними делать. Например один "контроллер" глянет мол "ага, он в качестве тела запроса прислал json - десериализуем". А второй контроллер такой "ага, он должен быть авторизован - надо проверить". Ну и т.д. покуда мы не дойдем до последнего контроллера в цепочке, который уже будет дергать "один" метод модельки. Это слой адаптеров между http и нашим приложением. Вот ключевая мысль MVC на бэкэнде (или ели точнее Mediating controller MVC или MVA, паттерн который реализован в большинстве современных бэкэнд фреймворков).

Зачем нужно отделять UI от приложения? потому что что-то из этого явно меняться будет чаще и не одинаково. А еще можно распаралелить работу. А еще можно заменить реализацию одной из частей без вреда для другой. Словом мы получаем намного больше гибкости, но только если приложение ничего не знает о представлении.. В противном случае мы получаем антипаттерн под названием smart ui, для борьбы с которым 40 лет назад и придумывали MVC.

Уже было на тостере,

RewriteEngine On
RewriteCond %{REQUEST_URI} ! \.html$
RewriteCond %{REQUEST_URI} ! /$
RewriteRule ^(.*)$ $1.html

В htaccess. Обращение на /about будет открывать /about.html, к примеру

Это самый простой способ

Приведите хранение данных в нормальную форму. И будет вам простой и быстрый поиск на уровне субд.

По нажатию кнопки "Next" проводите валидацию только открытой секции

Отрисовка через OpenGL, а вот он и поломался.
Поставьте Debian/Ubuntu где будет все работать из коробки. Ну или если хотите дальше мучиться, то курите что у вас сломано, иксовый драйвер, поддержка в ядре, меса несвежая или слишком свежая.

- много актуального видео;
- много актуальных фото;
- отзывы (из соц. сетей или букингов разных);
- форма для бронирования (опять же с букинга, скорее всего);
- карта проезда с информацией как добраться с аэропорта, метро, вокзала и т.д.;
- правила чекина, чекаута, залога;
- что хорошего, нужного, интересного есть рядом;
- цены, акции;
- номер телефона, e-mail;
- информация для организаторов конференций, банкетов и прочих мероприятий.

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

За последнее время, посетил около сорока гостиниц, по этому представляю чего хочу от сайта отеля.

Странный вопрос...
Запоминать слишком много, детально, по крайней мере в части языков программирования, библиотек - не только не полезно, но откровенно вредно. Особенно, когда языков этих используемых становится несколько, а в голове сплошная каша...
Нужно понимание, а не запоминание.
А для всего остального, особенно в нынешнее время, есть а). справочные системы и б). архивы своих собственных предыдущих наработок, где нужно только знать откуда "списать".