Как да премахнете Public от URL на проекта на Laravel (Laravel Installaion)

Положението

В целия домейн бихме искали URL адресите скриване на разширенията на файлове и премахване на наклонени черти, независимо от самото име на домейна (както в, работи за всеки домейн).

Пример за нашата структура на директории

Ние не използваме index. * Файлове с изключение на началната страница.

  • /
    • /index.php
    • /account.php
    • /сметка
      • /subscriptions.php
    • /login.php
    • /Влизам
      • /reset-password.php

Целта

Някои примери за това как тези файлове могат да бъдат поискани и как те трябва да изглеждат в браузъра:

  • / и index.php --> mydomain.com (буквално само голото име на домейн).

  • /account.php или /account/ или /account --> mydomain.com/account

  • /account/subscriptions.php или /account/subscriptions/ или /account/subscriptions --> mydomain.com/account/subscriptions

Както можете да видите, има няколко начина за достъп до всяка уеб страница, но без значение кой от 2 или 3 начина да използвате, той показва само един предпочитан URL в браузъра.

Въпроса

Как се прави това с .htaccess с помощта на mod_rewrite?

Ударих главата си в стената, опитвайки се да разбера това, но като цяло потокът за пренаписване изглежда като нещо подобно:

  1. Външно 301 пренасочване ( mydomain.com/account/ --> mydomain.com/account )
  2. Вътрешно добавете .php ( mydomain.com/account --> mydomain.com/account.php )

Цял ден го гуглих, прочетох хиляди редове документация и текстове за конфигуриране и се опитах няколко десетки пъти ... Мисля, че повече мозъци върху това биха помогнали много.

АКТУАЛИЗИРАНЕ

Намерихме отговор на нашия въпрос (вижте по-долу).

  • Как бихте направили разлика между account.php и акаунт / папка? За това е зачертаващата наклонена черта.
  • Добър въпрос. Те са едно и също нещо. Папката "акаунт" се пренаписва в "account.php". (Често ще намерите тази структура в уеб проекти на Visual Studio.)
  • А? Съжалявам, това няма смисъл за мен. Ако има файл /account.php и /account/index.php файл (обикновено достъпен само с / account /), как правите разлика между двете? Във файлова система те са не едно и също нещо. Ако зареждате всичко чрез една папка index.php, както правят PHP рамките, тогава може би това има смисъл. Това ли искаш да кажеш?
  • Извинете, трябваше да бъда по-ясен. Няма да използваме индексни файлове (с изключение на началната страница; но не се притеснявайте за това за този въпрос). Всички имена на файлове са описателни за тяхното съдържание. Това означава например това /account/ ще пренапише в /account и всъщност доставя /account.php, не /account/index.php.

Благодарим ви за отделеното време, за да разгледате въпроса, но изглежда го разбрахме:

Options -Multiviews -Indexes +FollowSymLinks RewriteEngine On RewriteBase / DirectorySlash Off # remove trailing slash RewriteRule ^(.*)\/(\?.*)?$ $1$2 [R=301,L] # rewrite /dir/file?query to /dir/file.php?query RewriteRule ^([\w\/-]+)(\?.*)?$ $1.php$2 [L,T=application/x-httpd-php] 

Трябва да изключим Multiviews и Indexes, за да не се обърка двигателят и вместо това да се опитаме да посочим някой index.* файл или покажете списък с директории (наричан също объркващо „индекс“ с Apache ...), когато изглежда, че е поискана директория.

Първото пренасочване видимо (R=301) премахва наклонената наклонена черта, а втората вътрешно я пренаписва в PHP (или HTML и т.н.) файл под ръка.

Този .htaccess файл също поддържа низове за заявки.

Актуализиране Както беше отбелязано в коментарите по-долу, много по-рано сме преминали към nginx и това е всичко, което съдържа нашият conf файл, свързан с пренаписването на URL адреси (от моята кутия за разработчици):

location = / { index index.html; } try_files $uri $uri.html =404; 

Също така сме преминали от PHP към обикновен HTML, но промяната на разширенията по-горе едва ли би имало значение, ако изобщо има.

  • Погледнато назад, преминахме към nginx и цялата тази задача беше супер-лесна ...
  • Малка точка, но не е нужно да избягвате наклонената черта (/) в регулярния израз, тъй като той няма специално значение. \/ е същото като '/'.
  • @ w3d Добра точка. Това е навик от моето регексиране на Javascript.

Защо искате да пренасочите / акаунт към /account.php? Всъщност страницата / акаунтът съществува само с договаряне на съдържание. Ако не го искате, просто деактивирайте директивата.

Относно вашите две правила, мисля, че е просто:

RewriteRule ^/account/$ /account RewriteRule ^/account$ /account.php [R,L] 

Не е тествано обаче. Можете също да добавите [R,L] на първия ред, в този случай браузърът ще направи още едно пренасочване.

  • 1 На теория това е общата идея (с изключение на това, че не искаме да показваме .php в браузъра), но това ще работи само за account.php. Надяваме се на общо решение, което да работи в целия сайт. Използвайки refiddle за тестване на нашите регулярни изрази, ние зная това регулярно изражение е подобно ^(.*)/$ посочете URL адреси с наклонена черта, но изглежда, че това има ефект само в директориите от най-високо ниво, а не в поддиректориите. (Искания към поддиректориите да презапишат с пълен път на сървъра в URL адреса и да го покажат в браузъра по някаква причина.) Също така сме сигурни, че ^(.*)[^/]$ указва URL адрес без наклонена черта.

Ако искате гъвкав и лесен начин за маршрутизиране на заявки за URL адреси за вашия уебсайт или приложение, бих препоръчал PHP микрорамка. Не само ще имате пълен контрол над маршрутизирането на URL адресите си, но ще осигурите и други предимства.

Използвал съм Slim Framework и преди, съчетан с Symfony Templating Component със страхотни резултати. Ако трябваше да го направя отново, вероятно щях просто да използвам Silex Micro-framework, тъй като той също е част от Symfony Components.

  • Помислихме за нещо подобно (благодарим за връзките), но нашата версия за разработка на сайта е с PHP, а внедрената производствена площадка е 100% статична (без PHP). Този .htaccess файл ще бъде пред разположената производствена площадка.
  • Би било много лесно бързо да създадете статичен сайт, базиран на тези микрорамки. Проектът, за който ги използвах, беше предимно статично съдържание, само с пръскане на PHP, използвано за стартиране на сайта с помощта на микрорамката. В зависимост от размера на сайта, преобразуването му за използване на микрорамка може да е по-бързо, отколкото да блъскате главата си в .htaccess през целия ден.

е работил за вас: Charles Robertson | Искате ли да се свържете с нас?