FanatPHP

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

Интересно, почему каждый беспомощный любитель халявы, который не в состоянии вбить примитивный запрос в гугль, обязательно ставит тег "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

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

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

Стыдно просить посторонних.

Никак.

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

https://www.google.ru/search?q=markdown+php

$result = $sth->fetchAll(PDO::FETCH_ASSOC);
$out = '';
foreach($companies as $company) { 
    $out .= "<div>$company[name]</div>\n";
}
return $out;

Но лучше бы ты открыл для себя шаблоны.

Если речь идет о метке времени Юникс, то задача сводится к двум арифметическим действиям.

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

Вопрос заключается в том, можно ли писать в РНР строки без кавычек.
Ответ: нельзя.

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

Вопрос дурацкий.
Если есть ошибка, то какой смысл спрашивать, почему на хостинге не работает? Ошибка - это и есть ответ, почему.

Другое дело, что ошибка выглядит странно. Такое ощущение, что она вообще не от этого сайта.

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

При чем здесь файл, ссылку на который он мне прислал? Этот файл же находится на совершенно другом сервере! Где брать нужный wsdl?

Параграфы взаимоисключающие здесь вижу я.
В первом ты даешь ссылку на файл WSDL, а во втором спрашиваешь, где его взять.

Правильно ли все указал оператор, или нужно что-то еще настроить с его стороны?

С его стороны надо указать полный путь к твоему WSDL.

Это в случае, если тебе действительно надо поднимать сервер, в чем я не уверен.