Hvordan fjerne Public fra laravel-prosjekt-url (Laravel Installaion)

Situasjonen

Gjennom hele domenet ønsker vi at nettadressene skal skjul filutvidelser og Fjern etterfølgende skråstrek, uavhengig av selve domenenavnet (som i, fungerer på hvilket som helst domene).

Eksempel på katalogstrukturen vår

Vi bruker ikke indeks. * -Filer bortsett fra hjemmesiden.

  • /
    • /index.php
    • /account.php
    • /regnskap
      • /subscriptions.php
    • /login.php
    • /Logg Inn
      • /reset-password.php

Målet

Noen eksempler på hvordan disse filene kan bli bedt om, og hvordan de skal se ut i nettleseren:

  • / og index.php --> mydomain.com (bokstavelig talt bare det bare domenenavnet).

  • /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 det flere måter å få tilgang til hver webside, men uansett hvilken av de to eller tre måtene du bruker for å komme dit, viser den bare den foretrukne URL-en i nettleseren.

Spørsmålet

Hvordan gjøres dette med .htaccess ved hjelp av mod_rewrite?

Jeg har slått hodet mot veggen og prøvd å finne ut av dette, men generelt ser omskrivingsflyten ut til å være noe slikt:

  1. Ekstern 301-viderekobling ( mydomain.com/account/ --> mydomain.com/account )
  2. Internt legge til .php ( mydomain.com/account --> mydomain.com/account.php )

Jeg har googlet dette hele dagen, lest tusenvis av linjer med dokumentasjon og konfigurasjonstekster, og har prøvd flere titalls ganger ... Jeg tror flere hjerner på dette vil hjelpe mye.

OPPDATER

Vi fant et svar på spørsmålet vårt (se nedenfor).

  • Hvordan vil du skille mellom account.php og en konto / mappe? Det er det etterfølgende skråstrek er for.
  • Godt spørsmål. De er det samme. "Konto" -mappen skrives om til "account.php". (Denne strukturen finner du ofte i Visual Studio-nettprosjekter.)
  • Hu h? Beklager, det gir ikke mening for meg. Hvis det er en /account.php-fil og en /account/index.php-fil (vanligvis bare tilgjengelig med / account /), hvordan skiller du mellom de to? På et filsystem er de det ikke det samme. Hvis du bootstrapper alt gjennom en enkelt index.php-mappe, som PHP-rammer gjør, så er det kanskje fornuftig. Er det det du mener?
  • Beklager, jeg burde vært mer tydelig. Vi bruker ikke indeksfiler (unntatt hjemmesiden, men ikke bekymre deg for det for dette spørsmålet). Alle filnavnene er beskrivende for innholdet. Dette betyr for eksempel det /account/ vil skrive om til /account og faktisk levere /account.php, ikke /account/index.php.

Takk for tiden din for å se på spørsmålet, men vi så ut til å ha funnet det ut:

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 må slå av multiviews og indekser slik at motoren ikke blir forvirret og i stedet prøve å referere til noen index.* fil eller vis en katalogoppføring (også forvirrende kalt en "indeks" med Apache ...) når en katalog ser ut til å bli bedt om.

Den første viderekoblingen synlig (R=301) fjerner skråstrek, og den andre skriver den internt om til PHP-filen (eller HTML, etc.).

Denne .htaccess-filen støtter også spørringsstrenger.

Oppdater Som nevnt i kommentarene nedenfor mye tidligere, har vi byttet til nginx, og dette er alt conf-filen vår inneholder relatert til URL-omskriving (fra dev-boksen min):

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

Vi har også byttet fra PHP til rett og slett HTML, men å endre utvidelsene ovenfor burde neppe gjøre noen forskjell, i det hele tatt.

  • I ettertid har vi byttet til nginx, og hele denne oppgaven var SUPER-enkel ...
  • Mindre poeng, men du trenger ikke å unnslippe skråstrek fremover (/) i regex, da det ikke har noen spesiell betydning. \/ er det samme som '/'.
  • @ w3d Bra poeng. Det er en vane fra Javascript-regex'ingen min.

Hvorfor vil du viderekoble / konto til /account.php? Faktisk eksisterer siden / kontoen bare med innholdsforhandlinger. Hvis du ikke vil ha det, er det bare å deaktivere direktivet.

Om de to reglene dine, tror jeg det er greit:

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

Det er imidlertid uprøvd. Du kan også legge til [R,L] til første linje, i dette tilfellet vil nettleseren foreta en omdirigering til.

  • 1 I teorien er det den generelle ideen (bortsett fra at vi ikke vil vise .php i nettleseren), men det fungerer bare for account.php. Vi håper på en generell løsning som fungerer på hele nettstedet. Vi bruker refiddle for å teste regexene våre, vi vet den regexen er som ^(.*)/$ angi URL-er med en etterfølgende skråstrek, men det ser bare ut til å ha effekt i kataloger på øverste nivå, ikke underkataloger. (Forespørsler om underkataloger skriver om med full serversti i URL-en og viser den i nettleseren av en eller annen grunn.) Vi er også sikre på at ^(.*)[^/]$ angir en URL uten etterfølgende skråstrek.

Hvis du vil ha en fleksibel og enkel måte å dirigere URL-forespørsler for nettstedet ditt eller appen din, vil jeg anbefale et PHP-mikrorammeverk. Ikke bare vil du ha full kontroll over URL-rutingen, men det vil også gi andre fordeler.

Jeg har brukt Slim Framework før, kombinert med Symfony Templating Component med gode resultater. Hvis jeg skulle gjøre det igjen, ville jeg sannsynligvis bare bruke Silex Micro-framework, siden det også er en del av Symfony Components.

  • Vi tenkte på noe slikt (takk for koblingene), men utviklingsversjonen vår av nettstedet er PHP-drevet og det distribuerte produksjonsstedet er 100% statisk (ingen PHP). Denne .htaccess-filen vil være før det distribuerte produksjonsstedet.
  • Det ville være veldig enkelt å raskt lage et statisk nettsted basert på disse mikrorammene. Prosjektet jeg brukte dem til var for det meste statisk innhold, med bare et skvett PHP som ble brukt til å starte siden med micro-framework. Avhengig av størrelsen på nettstedet, kan det være raskere å konvertere det til et mikrorammer enn å slå hodet mot .htaccess hele dagen.

fungert for deg: Charles Robertson | Ønsker du å kontakte oss?