Sådan fjernes Public fra laravel projekt url (Laravel Installaion)

Situationen

På tværs af hele domænet vil vi gerne have webadresserne skjul filtypenavne og fjern skråstreg, uafhængigt af selve domænenavnet (som i, fungerer på ethvert domæne).

Eksempel på vores katalogstruktur

Vi bruger ikke indeks * filer med undtagelse af startsiden.

  • /
    • /index.php
    • /account.php
    • /konto
      • /subscriptions.php
    • /login.php
    • /Log på
      • /reset-password.php

Målet

Nogle eksempler på, hvordan disse filer kan blive anmodet om, og hvordan de skal se ud i browseren:

  • / og index.php --> mydomain.com (bogstaveligt talt bare det bare domænenavn).

  • /account.php eller /account/ eller /account --> mydomain.com/account

  • /account/subscriptions.php eller /account/subscriptions/ eller /account/subscriptions --> mydomain.com/account/subscriptions

Som du kan se, er der flere måder at få adgang til hver webside, men uanset hvilken af ​​de 2 eller 3 måder du bruger for at komme derhen, viser den kun den ene foretrukne URL i browseren.

Spørgsmålet

Hvordan gøres dette med .htaccess ved hjælp af mod_rewrite?

Jeg har slået hovedet mod væggen og forsøgt at finde ud af dette, men generelt ser omskrivningsstrømmen ud til at være sådan noget:

  1. Ekstern 301-omdirigering ( mydomain.com/account/ --> mydomain.com/account )
  2. Internt tilføje .php ( mydomain.com/account --> mydomain.com/account.php )

Jeg har googlet dette hele dagen, læst tusinder af dokumentationslinjer og konfigurationstekster og har prøvet flere dusin gange ... Jeg tror, ​​at flere hjerner på dette ville hjælpe meget.

OPDATER

Vi fandt et svar på vores spørgsmål (se nedenfor).

  • Hvordan skelner du mellem account.php og en konto / mappe? Det er, hvad den bageste skråstreg er til.
  • Godt spørgsmål. De er de samme ting. Mappen "konto" omskrives til "account.php". (Du finder ofte denne struktur i Visual Studio-webprojekter.)
  • Hvad? Undskyld, det giver ikke mening for mig. Hvis der er en /account.php-fil og en /account/index.php-fil (normalt kun tilgængelig med / account /), hvordan skelner du mellem de to? På et filsystem er de det ikke det samme. Hvis du bootstrapper alt gennem en enkelt index.php-mappe, som PHP-rammer gør, er det måske fornuftigt. Er det hvad du mener?
  • Undskyld, jeg burde have været mere klar. Vi bruger ikke indeksfiler (undtagen hjemmesiden; men bekymre dig ikke om det for dette spørgsmål). Alle filnavne er beskrivende for deres indhold. Dette betyder for eksempel det /account/ vil omskrive til /account og faktisk levere /account.php, ikke /account/index.php.

Tak for din tid til at se på spørgsmålet, men vi syntes at have fundet ud af det:

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] 

Vi er nødt til at slukke for Multiviews og Indexes, så motoren ikke bliver forvirret og i stedet prøve at henvise til nogen index.* fil eller vis en katalogliste (også forvirrende kaldet et "indeks" med Apache ...), når en mappe ser ud til at blive anmodet.

Den første omdirigering synligt (R=301) fjerner det bageste skråstreg, og det andet omskriver det internt til den vedlagte fil (eller HTML osv.).

Denne .htaccess-fil understøtter også forespørgselsstrenge.

Opdatering Som bemærket i kommentarerne nedenfor meget tidligere har vi skiftet til nginx, og dette er alt vores conf-fil indeholder relateret til URL-omskrivning (fra min dev-boks):

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

Vi har også skiftet fra PHP til bare almindelig HTML, men at ændre udvidelserne ovenfor burde næppe gøre en forskel, overhovedet.

  • Efterhånden har vi skiftet til nginx, og hele denne opgave var SUPER-let ...
  • Mindre punkt, men du behøver ikke at undslippe skråstreg (/) i regex, da det ikke har nogen særlig betydning. \/ er det samme som '/'.
  • @ w3d Godt punkt. Det er en vane fra mit Javascript regex'ing.

Hvorfor vil du omdirigere / konto til /account.php? Faktisk eksisterer siden / kontoen kun med indholdsforhandling. Hvis du ikke vil have det, skal du bare deaktivere direktivet.

Om dine to regler synes jeg det er ligetil:

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

Det er dog uprøvet. Du kan også tilføje [R,L] til første linje, i dette tilfælde vil browseren foretage en yderligere omdirigering.

  • 1 I teorien er det den generelle idé (bortset fra at vi ikke vil vise .php i browseren), men det fungerer kun for account.php. Vi håber på en generel løsning, der fungerer overalt på siden. Brug refiddle til at teste vores regex, vi ved godt den regex er ligesom ^(.*)/$ angive webadresser med et skråstreg, men det ser ud til kun at have effekt i topkataloger, ikke underkataloger. (Anmodninger om underkataloger omskriver med fuld serversti i URL'en og viser den i browseren af ​​en eller anden grund.) Vi er også sikre på, at ^(.*)[^/]$ angiver en URL uden et skråstreg.

Hvis du ønsker en fleksibel og enkel måde at dirigere URL-anmodninger til dit websted eller din app, vil jeg anbefale en PHP-mikroramme. Ikke kun vil du have fuld kontrol over din URL-routing, men det vil også give andre fordele.

Jeg har brugt Slim Framework før kombineret med Symfony Templating Component med gode resultater. Hvis jeg skulle gøre det igen, ville jeg sandsynligvis bare bruge Silex Micro-framework, da det også er en del af Symfony Components.

  • Vi tænkte på noget som dette (tak for linkene), men vores udviklingsversion af webstedet er PHP-drevet, og det implementerede produktionssted er 100% statisk (ingen PHP). Denne .htaccess-fil vil være før det implementerede produktionssted.
  • Det ville være meget let hurtigt at oprette et statisk sted baseret på disse mikrorammer. Det projekt, jeg brugte dem til, var for det meste statisk indhold med kun et stænk af PHP, der blev brugt til at bootstrape webstedet ved hjælp af mikrorammen. Afhængig af størrelsen på webstedet kan det være hurtigere at konvertere det til at bruge en mikroramme end at slå dit hoved mod .htaccess hele dagen.

arbejdet for dig: Charles Robertson | Ønsker du at kontakte os?