FanatPHP

Если речь о 20-и строках, то вопрос о скорости не имеет смысла. Можешь делать в базе, можешь в скрипте, а можешь попеременно - на скорости это никак не скажется.

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

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

Неправильно.
Правильно будет так:
1. пишем в адресной строке браузера mysqli_fetch_assoc
2. В открывшемся окне переходим по первой ссылке
3. Внимательно читаем.
4. Думаем.
5. Смотрим примеры.
6. Пишем правильный код.

Странное условие. Чтобы написать такое "без фреймворков", надо, по сути, написать одноразовый фреймворк, который всю эту красоту - "использование паттернов, namespace, PDO" и реализует. (Впрочем, ПДО здесь лишний - хороший код никогда не будет использовать прямое обращение к DB API, а завернет такие обращения в абстракцию).

Плюс, само понятие "хорошего кода на ПХП" в 2014 году включает в себя непременное условие "с использованием фреймворков".

Но если хочется так прям говнокодить по-старинке, но думать, что используешь правильные паттерны - www.phptherightway.com

Сначала учим матчасть.

Содержимое вывести НЕЛЬЗЯ.
Результат работы - можно.

Эх, твою бы энергию - да в мирных целях...

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

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

Очередной криворукий спамер.
Гадить уже научился, а гуглить - нет.

Для начала научись пользоваться поиском.
Этот вопрос здесь уже задавали не раз, не два и не десять.

Интересно, почему каждый беспомощный любитель халявы, который не в состоянии вбить примитивный запрос в гугль, обязательно ставит тег "open source"?

Могу предсказать, чем кончатся эти изыскания. Они все на один манер:

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

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

Жалоба на вопрос: ответ легко ищется поисковиком.

Тут действительно можно выкинуть кучу бесмысленного кода.

$sql = "SELECT ...";
return $this->database->query($sql)->fetch_assoc();

- это ВЕСЬ код, который нужен.

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

А проблема, скорее, не в совпадениях, а в отсутствии исходных данных и неумении корректно добавляь данные в запрос.

На все сразу записывать нет смысла.
Посетителя авторизуют после того, как он заходит на очередной домен (как это происходит, например, на тостере/хабре).

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

Но ли если это слишком сложно, то можно погуглить (сюрприз!) "кроссдоменная авторизция".

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

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

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

Здесь же ты должна понимать, что работая в ПэЛэ-Плюс, ты работаешь не с БД, и даже не с индустриальным стандартом PL/SQL, а с "проблемно-ориентированной" кустарной подделкой. 1С:Битрикс же среди разработчиков и вовсе давно уже является ругательством. Но главная проблема не в этом. А в том, что оба инструмента обречены на стагнацию и умирание. Садиться на проприетарные средства разработки в век открытого программного обеспечения - это хоронить себя заживо. Какой бы уникальной ни была разработка, оставаясь в руках единственной организации, она будет чудовищно отставать в развитии и вместе с собой тормозить разработчиков.

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

Так же, как и любой другой файл.

Правда, насчет необходимости ты ошибаешься.

переадресация на страницу 404.php

Вот поэтому.
Более феерической глупости придумать невозможно.

Вместо Not Found клиент получает ответ... Found(!) и его потом перенаправляют на страницу, где отдается Not Found.

404 надо обрабатывать СРАЗУ, безо всяких редиректов.

Погда и дурацких вопросов "куда делся реферер" возникать не будет.

в коде php заменял всё на "1251"

Это самая большая глупость, которую ты только мог сделать.
Особенно при "постепенном" переводе, когда в таблице могут быть данные как на русском, так и на английском.

1. убеждаешься, что все таблицы имеют чарсет utf8. Посмотреть можно через SHOW CREATE TABLE
2. в РНР, в настройках работы с БД оставляешь только utf8
3. после этого работа с БД будет нормальной и простых вопросов не будет (кроме тех данных, которые ты уже загубил). Остается победить вопросы в ромбиках, что совсем просто - из своих скриптов отправляешь заголовок Content-type с кодировкой utf-8

Подробнее: phpfaq.ru/charset

как вызвать php функцию, а не файл.

Никак, разумеется.

Для начала надо понять, что в файле index.php НЕТ ни textarea, ни функции вывода информации из этой textarea. А есть просто набор абстрактного текста.
Для этого надо вдумчиво прочитать букварь, phpfaq.ru/na_tanke

И после этого догадаться, что аякс для этих телодвижений не нужен.