FanatPHP

Вью - это логика отображения. Условный переход - это, несомненно, логическая конструкция. То есть, утверждение сводится к "допустимо ли использовать логику для логики?" ответ - TRUE.

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

А вот сократить количество логики, как ваыше написали - можно. К примеру, подготовить все нужные данные заранее - либо в контроллере, либо в хелпере, а в шаблоне заниматься только выводом этих данных. Втом числе данных для пагинации. То есть, условных переходов не станет меньше, но они перейдут в тот слой, где более уместны.

Я просто оставлю это здесь:
Ничего не работает! Что делать???

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

Апдейт.
Из комментариев к другому вопросу становится ясно, что автору надо сначала понять, что cookie - это HTTP заголовок, и чем отличаются HTTP заголовки от переменных в программе.

Процедурный однозначно.
Если такой вопрос в принципе возникает - это значит, что ООП автор не понимает от слова "совсем". И в итоге, при попытке написать собственные классы, получит адский треш. Поэтому только процедурный. Там тоже будет треш, но не адовый.

Более сложный вариант - посмотреть на календарь, узнать, что сейчас уже вторая декада XXI века, и перестать уже наконец использовать РНР так, как его использовали в прошлом тысячелетии, ковыряя каждую мелкую задачу самостоятельно на чистом РНР. После этого взять учебник по современному фреймворку, такому как Ларавель или Йии, прочитать его, и начать делать сайт с помощью готовых классов, которые уже написали для тебя, и которые берут на себя 80% черновой работы, и при этом делают её на 100500% лучше, чем твой собственный самопальный код (потому что учитывает миллион нюансов и правил, о которых ты вообще даже не подозреваешь). В итоге, по факту, сайт получится с использованием ООП, но не в том смысле, который имел в виду автор (писать все самому с нуля).

Здесь нет никакого запроса mysql, даже близко.
А есть какой-то самопальный винегрет, который собирает запрос из кусочков неизвестным читателю способом.

В любом случае, первое, что надо усвоить про составление запросов: ни одна переменная не должна попадать в запрос напрямую!

То есть, первый вариант делает весь этот самопальный винегрет (который, тем не менее, делает работу с БД безопасной) - бесполезным.

Поэтому, стоит использовать второй вариант, который, хоть и не оптимальный, но зато безопасный. А чтобы переменная не "затиралась" (а что ей еще остаётся делать, если её постоянно перезаписывают?), надо сделать её массивом:

$listings = [];
foreach ($array as $key => $value)
{
  $listings[] = $iaAuto->get(
        array('model_id' => $value), 
        $pagination['start'], 
        $pagination['limit'], 
        $_SESSION[iaAuto::SESSION_SORTING_KEY]
    );
}

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

1. Это увеличит нагрузку на БД.
2. Само по себе решение продиктовано только дикостью и чудовищным невежеством. Через годика два, если наберешься опыта, то сам с ужасом будешь смотреть на этот свой вопрос.

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

Если взять ларавель, то в модели постов надо будет добавить метод

public function recentComments()
{
    return $this->hasMany('Comment')
        ->orderBy('created_at', 'desc')
        ->limit(3);
}

и ВСЯ лента будет строиться одним оператором, что-то вроде

return Post::orderby('created_at', 'desc')
    ->with([
            'photos',
            'recentComments',
        ]);
    ->limit(5);

1. Записать файлы в массив.
2. Отсортировать его.
3. выводить через цикл for с начальным и конечным значением, задаваемым переменными.

Для п.1 и для контроля расширений можно использовать glob()

<?php
$out   = array();
$files = glob("$directory/*.{jpg,png,gif}", GLOB_BRACE);
sort($files);
for ($i=$start; $i <= $end; $i++)
{
    $out[] = array(
        'title' = htmlspecialchars(basename($files[$i]));
        'file'  = $files[$i];
    );
}

В шаблон передаем массив $out и там его выводим.
Как получать стартовое и конечное значение и как выводить ссылки на страницы можно посмотреть здесь: phpfaq.ru/paginator#new

Если отвечать на тело вопроса, а не на один только заголовок, то из текста вопроса видно, что сначала надо научиться различать, где у тебя HTML5, а где mysql. то есть, самые основы клиент-серверной архитектуры сайта. Как раз хороший текст, который объясняет разницу между серверной и клиентской частью: phpfaq.ru/na_tanke

mysql - это база данных, она находится на сервере, HTML5 - на клиенте. Напрямую из HTML5 работать с базой данных нельзя.

Для изучения рекомендую выбрать что-то одно - либо серверные технологиее, либо клиентские.

Дла начала надо понять, что никакой живой пользователь никогда не будет читать 20 000 записей на одной странице.

после этого можно продолжать оптимизацию

Открою маленький секрет.
Начав учить Ларавель, ты обнаружшь, что огромный кусок этоого фреймворка составляют... компоненты Симфони!

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

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

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

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

Это означает, что ошибка была в запросе.
По умолчанию mysqli не сигнализирует об ошибках в mysqli_query(). Чтобы заставить её делать это, надо перед коннектом написать волшебное слово:

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

Это самый простой, но менее удобный способ, поскольку в сообщении об ошибке нам желательно сразу увидеть и запрос с ошибкой. Поэтому лушче проверять результат запроса, и порождать ошибку РНР с ошибкой mysql и запросом.

Ошибка в запросе может быть вызвана чем угодно. В частности - мусором, переданным в запрос. Именно поэтому данные для запроса должны форматироваться только перед непосредственным выполнением запроса, а не где-то ещё!

Поэтому вместо того, чтобы продолжать писать на mysqli ТОТ ЖЕ САМЫЙ УРОДЛИВЫЙ ГОВНОКОДО, что и на mysql, надо использовать более интеллектуальный подход, который будет обеспечивать как форматирование, так и обработку ошибок:

function get_products($db, $ids, $start_pos, $perpage){
    if($ids){
        $query = "SELECT * FROM sdvd_products WHERE parent IN($a) LIMIT ?i, ?i";
    } else {
        $query = "SELECT * FROM sdvd_products LIMIT ?i, ?i";
    }
    return $db->getAll($query, $ids, $start_pos, $perpage);
}

Я бы хранил всю переписку во-первых, в одной ячейке, а во-вторых, тупо дублировал бы её. Это, конечно, расход места, но зато просто.

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

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

sphinxsearch.com

Как всегда - дурацкий вопрос, да еще и по-дурацки сформулированный, порождает кучу дурацких ответов.

ЕСЛИ не читать тело вопроса, а отвечать на вопрос из заголовка (а это ключевой момент для Q&A сайта, поскольку тупые поисковики приводят именно по заголовкам. И администрация должна следить за релевантностью оных и вычищать вопросы, которые автор не в состоянии сформулировать), то ответ однозначный - за выборку ЗАПИСЕЙ только для того, чтобы ПОСЧИТАТЬ их, дают пожизненный эцих с гвоздями. Считать должна база!

ЕСЛИ отвечать на вопрос вне контекста вставки, а только глядя на запросы, то ответ - ОДИНАКОВО. В обоих случаях никакого подсчета нет а есть только выборка по ключу.

ЕСЛИ вникать в контекст задачи чуть глубже, то появляются варианты ускорить МНОЖЕСТВЕННУЮ проверку, такие как prepared statements (тот редкий случай, когда их фича с множественным исполнением может выстрелить).

ЕСЛИ вникать в задачу окончательно, то правильным будет ответ @zeromodule. Причем вставку надо либо делать множественную, по тысяче записей, либо заворачивать в транзакцию - поскольку ОБНОВЛЕНИЕ ИНДЕКСА при таком количестве вставок начнет тормозить работу куда сильнее, чем нищасные селекты, столь пугающие аффтара. И опять же использовпать prepared statements.

Открываю стрррррашный секрет:

$stmt = $this->db->prepareQuery( 'insert ignore into `xref_tags` ( `tag_id`, `post_id` ) values( ?, ? )' );
$stmt->execute(array( $tagId, $postId ));

Нет, нельзя.