Такая ситуация. Написал скрипт - на локалхосте все протестил - работает. Залил на хостинг - не работает - выдает 500-ю ошибку. Стал копаться в логах - нарыл: "PHP Fatal error: Call to a member function getIp() on a non-object in /home/clients/.../index.php on line 83" Вот куски кода: ПОПРАВИЛ КОД: Все заработало!!! ВОПРОС: почему в изначальном варианте у меня на локалхосте все работало, а у хостера нет! Судя по словам тех.поддержки хостера - версии php у нас одинаковые! PS. Скажу что причину я уже нашел, но побиться над ее выяснением пришлось долго... Просто интересно - местные спецы найдут загвоздку?
Ладно... пора бы уже выложить ответ Дело в том, что на момент выполнения 83-й строки переменная $ip уже не является объектом, о чем нам и сообщается в логах. Значит где-то она переопределяется. НО ведь у меня на локалхосте все работает и переопределения не происходит. Почему же у хостера оно происходит? А потому, что у меня на локалхосте директива register_globals отключена, а у хостера она включена!!! Да - да, оказывается есть еще такие хостеры! В общем что получается: в 82-й строке стартует сессия, из которой нам нужны данные $_SESSION['ip'] вот и получается, что session_start() переопределяет переменную $ip а такое возможно только при включенном register_globals В исправленном коде понятно почему все заработало.
Прикольно) Хотя если кто не застал времена PHP3(да и PHP4 я, к примеру, тоже не застал), имхо ему простительно этого не знать.
В каком смысле? У большинства хостеров register_globals как раз включено, не знаю почему. Меня это страшно бесит. Сам постоянно натыкаюсь на эту проблему.
В чем проблема в .htaccess дописать его запрет? А заодно и всяких там экранирований gpc. У меня для всех проектов он одинаковый впринципе, его всегда таскаю и поэтому не забывается ничего.
Директива в .htaccess работает только в том случае, если PHP установлен как Апач-модуль (на юникс серверах это 99% случаев). Кроме того, требуются права AllowOverride All либо AllowOverride Options. Так что это не универсальное решение.
Очень смешно. Отвечай по-существу. Не надо увеличивать счётчик бестолковыми постами. Я как-то пытался использовать след.функцию: но она почему-то не срабатывала (true в первом учловии херачило).
Всего лишь ответ в виде нелепого поста на нелепый пост. Чтобы показать нелепость Что мешает сменить хостинг на платный и избавить код от подобных проверок? А что вы будете делать с таким подходом, если на сервере не будет GD? Или запрещены сокеты? Или нет возможности запустить system("mencoder ?
Поверь мне, я уже лет пять как ушёл от безплатных хостингов. Ситуация пару лет назад была такая - из трёх хостеров (по-моему это были peterhost, majordomo и slavhost), на одном .htaccess не сработал (сервер вылетал с 500-ощибкой). Везде сайты были промышленные, заказные, что прикажешь делать? Конечно, я прошёлся по своему коду, как это сделал Mikola, подправил его и всё заработало. Но осадочек-то остался.
beotiger, а если мне есть что сказать - я говорю. И люблю высмеивать фанатиков. И люблю, чтобы каждый занимался своим делом. Программист программировал, а админ - админил. А то потом будет "а мой прошлый программист мне еще дизайны рисовал и сортир мыл, вы так не делаете?"
The Last Winged, очень похвально. Но опять же слова в воздух. Из-за чего наш спор разгорелся? Вы правильно заметили, что для установки PHP-флага register_globals можно использовать соответствующую директиву в .htaccess. Я в ответ заметил, что это не универсальное решение, так как всегда есть шанс, пуст небольшой, что эта директива не будет работать на нужном нам хостинге. Вы в ответ стали ёрничать, говорить что-то об отключении серверов из розетки и т.п. ... ??? Ещё по существу вопроса замечу, что директива в .htaccess не срабатывает при вызове скрипта напрямую (из шелла) типа А это часто бывает нужно при выполнении cron-задач. Буду очень признателен вам или кому-нибудь за универсальное решение, только ответы типа отключения серверов из розетки, пожаров в дата-хостингах или землетрясении в Москве не принимаются.
Согласен. И это элементарно решается тикетом админам или самостоятельной перенастройкой(в зависимости от ситуации). За пару минут и без проблем. опция -d Я дал универсальный вариант для консоли и для сапи в этом сообщении
Да, согласен. Спасибо. Кроме того при вызове cron-задач, IMHO, всякие $_POST,$_GET,$_SESSION,$_COOKIE,$_FILES и т.п. и.т.д. variables редко используются.
Хочу добавить вдогонку, что можно использовать след.команду: для запуска скрипта из консоли для того, чтобы он прошёл через обработку Апачем (Апач устанавливает многие системные переменные, которые недоступны при прямом вызове скрипта через консоль, в частности, очень полезную переменную $_SERVER['DOCUMENT_ROOT'], отталкиваясь от которой можно задавать абсолютные пути для файлов прктически на любом сервере). Для этого, естесно, lynx должен быть установлен в системе хостера (я знаю по крайней мере одного, где lynx'а нет).
wget, fetch, etc + куча внешних сервисов-дергателей по времени, но это сродни лечению зубов через задницу. Для части своих скриптов я использую демонизацию и они в фоне 100% времени аптайма работают, поэтому крон мне не нужен.
Да, если используешь VPS либо дедик. На обычном хостинге тебе аптайма 100% не дадут. Приходится извращаться. Через крон, а не черз ж..., как вы могли подумать.
PoliceMan, учите матчасть. Приведу аналог: вам закручивает и отрывает руку станком и вы через минуту только жмете ногой на кнопку-"плинтус". Не поздновато ли?
PoliceMan, если вы программист, то должны уметь рассуждать логически. Даже не читая теории. Ваш PHP-скрипт стартанул. PHP-препроцессор, согласно установки register_globals==true уже экстрактнул (exctract) все соотв. массивы ($_GET,$_COOKIE и т.п.). И тут он встречает такую директиву: Ты ему что прикажешь сделать? unset всех этих переменных??? Глупо, согласись, и не логично. Честно говоря, не вижу тута никакого аналога.