Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Добрый вечер всему сообществу.
Я столкнулся с такой проблемой: если пытаться развернуть Laravel на среднестатистическом хостинге, не имеющем шелл-доступа, то можно очень долго и неэффективно тратить свое время, пытаясь понять, как его заставить нормально работать.
У меня следующая ситуация:
1) есть веб-директория на сервере: /web;
2) я туда выгружаю содержимое архива с laravel таким образом, что файл "paths.php" лежит в папке "web" -> "/web/paths.php",
все папки (application, bundles, public, storage и laravel) лежат рядом с ним;
3) я открываю http://site/public - вижу страничку приветсвия фреймворка, всё хорошо;
4) по ссылке http://site/public/index.php/docs открывается документация - ок;
5) как только я пытаюсь, последовав инструкции по установке (http://laravel.ru/docs/install, пункт про короткие адреса, а конкретно - с использованием mod_rewrite), убрать из адреса "public/index.php" (прописываю рерайты, убираю адрес индекса из конфигов) - мне выдаёт "No input file specified." на странице по адресу http://site/docs, где я надеялся опять увидеть документацию.
Подскажите, пожалуйста, что я делаю не так?
Update:
рерайт с официального сайта помог:
Options +FollowSymLinks
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [L]
Изменено Apache (12.06.2012 00:18:48)
Не в сети
Не в сети
Да, оказалось именно эта проблема, попросил хостеров обновить php до 5.3 - заработало
Не в сети
А можно для тех кто на бронепоезде разжевать. У меня аналогичная проблема, настройки в /public/.htaccess я прописал, но всё равно на хостинге отображает только в виде sitename/public/index.php/mysite, хотя локально нормально работал sitename/public/mysite
Не в сети
При выдаче хостингом ресурса для клиента последнему «дается» каталог (директория, папка) в публичном каталоге. Допустим, ~/vasjapupkin/public_html. Это и есть ваш рабочий (основной) каталог, в котором сервер ищет скрипты. Вам нужно перенаправить сервер из этого каталога в каталог ./public, где у вас находится index.php от Laravel (в данном случае). Для этого есть mod_rewrite. Т.е. у вас должен быть .htaccess в public_html, который перенаправляет запросы в ./public, и рабочий в ./public, который перенаправляет запросы в index.php. Все это описано в документации (особенно в английской) [laravel.com]. Если есть трудности с пониманием работы сервера (Apache в данном случае), нужно почитать документацию, слава обществу, с этим трудностей нет. К тому же, если вы не знаете, как работает сервер, как вы тогда собираетесь писать сайт? Вопрос, конечно, риторический…
Не в сети
- К тому же, если вы не знаете, как работает сервер, как вы тогда собираетесь писать сайт? Вопрос, конечно, риторический…
Он не столько риторический сколько спорный. Лет 8 назад, когда я только начинал заниматься вёбом, многие тоже кричали, что не зная работы Apache не возможно нормально писать сайты. Это в частности было главным аргументом против Денвера.
Тем не менее это не помешало мне писать сайты в течении лет 5, вообще не имея представление о том, что делает Денвер и что такое httpd.conf, а через 5 лет завезти свой сервер и успешно его администрировать.
Не в сети
Может быть, в этом и нет необходимости, когда сайт представляет собой набор html файлов. Но сейчас, как правило, сайты проявляют характер приложения, (наверное, поэтому и вошло в обиход именование web-приложение) и необходимо знать работу сервера с точки зрения web-приложения, т.е. работу с каталогами, куки, сессии, заголовки, технологии обработки запросов и т.д.
Например, совсем недавно был вопрос — почему после установки куки приложение его не видит, но в браузере установленный куки есть. Что и кого только не пинали — и фреймворк, и сервер, и даже провайдера… Все оказалось банально просто — просто «разработчик» не знал, как работает WEB, в частности сервер, CGI, AJAX. Вот такая история.
Или еще: смотрел недавно некий ресурс с «закрытой» базой — так там «разработчики» любезно предоставляют адрес с доступом к исходникам прямо в javascript скрипте…
Не в сети
- Может быть, в этом и нет необходимости, когда сайт представляет собой набор html файлов.
Не помню, когда бы я писал сайт, состоящий из одних HTML. Первые годы я, конечно, писал далеко не профессиональные вещи, но знание внутренностей вёб-сервера на них никак не повлияло бы — просто банальный опыт разработки под конкретно этот язык и среду.
Другое дело, что волей-неволей я узнавал про mod_rewrite, .htaccess и сопутствующие технологии — но это было плавно и ненавязчиво (грубо говоря, появилась задача — потребовалось решение). Если бы перед началом разработки я бы сперва изучил Apache, потом mod_rewrite, потом SSI (мало ли, пригодится), потом установку под Linux (конечно, у меня его тогда не было, но мало ли что в жизни случается), потом какой-нибудь XSLT (слово-то, слово какое! как мимо пройдёшь ), то не знаю, когда бы дело дошло до собственно программирования под PHP — профессионального или нет, не важно.
Да и изучи я все эти технологии в начале всё равно бы пришлось потом пересматривать руководства по применению в данной ситуации — точно также происходит во время долгой учёбы в универе — вроде учил что-то целые 5 лет, а потом приходишь на работу и понимаешь, что всё что у тебя осталось — максимум указатель в духе «если в проблеме фигурирует слово $#@ ищи решение там-то и там-то».
Так стоит ли тратить на это время? ИМХО, конечно.
- т.е. работу с каталогами, куки, сессии, заголовки, технологии обработки запросов и т.д.
Все эти вещи замечательно можно решить, не имея представления о браузере, стандарте HTTP и вёб-сервере. Помню, меня первое время тоже сбивало с толку, почему я не могу прочитать cookie сразу же после его установки — но набив пару шишек принял как данность, что до следующей загрузки страницы я его не вижу. И всё. Тогда просто интернет был медленнее, было проще своим умом что-то решить, чем терзать лишний раз сообщество на форуме
- так там «разработчики» любезно предоставляют адрес с доступом к исходникам прямо в javascript скрипте…
Это опять же проблема некомпетентности разработчика даже в его узком профиле, а не незнании вёб-технологий. Как ни крути — исходник страницы ближе к теме, чем работа вёб-сервера/HTTP, и если человек никогда не заглядывал в этот исходник, то знание последнего ему (уже/ещё) вряд ли поможет.
Не в сети
Не в сети
Страницы 1