Lis
2
2011

Ustawienia bezpośrednich odnośników w WordPress

Jedną z pierwszy rzeczy, jakie warto zrobić w świeżo postawionym serwisie opartym na systemie WordPress jest właściwe ustawienie tzw. ładnych linków lub według nomenklatury WordPressa bezpośrednich odnośników.

Aby to zrobić należy wejść w menu administracyjnym w zakładkę:

Menu -> Ustawienia -> Bezpośrednie odnośniki

Tam zobaczymy listę dostępnych opcji:

  • Domyślny http://www.mojastrona.pl/?p=123
  • Dzień i nazwa http://www.mojastrona.pl/index.php/2011/07/10/sample-post/
  • Miesiąc i nazwa http://www.mojastrona.pl/index.php/2011/07/sample-post/
  • Liczbowy http://www.mojastrona.pl/index.php/archives/123
  • Własny format /index.php/%year%/%monthnum%/%postname%/

Jako domyślna opcja zaznaczone jest zawsze Domyślny.

My możemy wybrać sobie dowolny z pre-definiowanych lub ustawić własny standard odnośników. Wszystkie możliwe do zastosowania opcje (tagi) najlepiej opisane są w CODEXie w artykule Using Permalinks, chociaż w większości przypadków wystarczą te proponowane.

Warto pamiętać, że ze względów wydajnościowych nie zaleca się dla większych strony ustawiania jedynie /%postname%/ – polecam ustawić własny format: /%year%/%monthnum%/%postname%/ (problem wydajnościowy powinien zostać poprawiony w najbliższym dużym wydaniu WordPressa, czyli w wersji WordPress 3.3).

W wielu przypadkach wystarczy wybrać interesującą nas opcję i nacisnąć Zapisz zmiany. W wyniku tej operacji powinien utworzyć się w katalogu głównym naszej strony plik .htaccess zawierający odpowiednie wpisy.

Co zrobić jeśli .htaccess nie utworzy się automatycznie, a na naszej stronie po wprowadzeniu powyższych zmian wszystkie linki stają się martwe?

Możemy wtedy stworzyć plik .htaccess wraz z odpowiednią zawartością sami!

W tym celu otwieramy notatnik lub inny edytor tekstu i wpisujemy odpowiedni kod, a następnie kopiujemy plik do katalogu głównego serwera.

Jeśli instalujemy WordPressa w katalogu głównym (root) naszego serwera/domeny, to wpisujemy kod:

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Jeśli instalujemy WordPressa w innym katalogu (w naszym przypadku jest to katalog „kalafior”), to wpisujemy kod:

# BEGIN WordPress

RewriteEngine On
RewriteBase /kalafior/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /kalafior/index.php [L]

# END WordPress

Jeśli zastosujemy się do powyższej wskazówki, to nasze linki nie będą musiały zawierać w sobie brzydkiego sluga /index.php/.

Powiązane wpisy

O autorze: Jakub Milczarek

Miłośnik wszystkiego co związane ze sprawami użyteczności, a także specjalista z dziedziny fizykochemii kryminalistycznej. Stronami internetowymi zajmuje się od 1997 roku, a z samym WordPressem zaprzyjaźnił się już w 2007 roku. Miał zaszczyt być szefem organizacji pierwszego polskiego WordCampu w 2010 roku, a w latach 2010-2012 prowadził z sukcesami firmę WP-Expert. Obecnie pracuje jako UX Specialist w OnTheGoSystems. W wolnych chwilach zdobywa Koronę Europy, poszukuje skrzynek OpenCaching i bloguje jako Lodzermensch.

9 komentarzy + Dodaj komentarz

  • Troszkę słabo wyczerpany temat. To ma być serwis, który będzie dobry zarówno dla nowych jak i bardziej doświadczonych użytkowników WP stąd byłoby fajnie gdybyśmy przeczytali tu także o własnych regułach przepisywania URL’i :)

    • Ale to już jest zupełnie inny temat i inna para kaloszy :D

      • Pewnie, że tak. Ale temat url’i był już wałkowany na wielu blogach.

    • @Krystian – Świetny pomysł na kolejny wpis! Czy możemy liczyć, że napiszesz na ten temat?
      Myślę, że Konrad ucieszy się z kolejnego redaktora, a ja będę się cieszył z interesującego materiału uzupełniającego mój wpis…

  • Problem pojawia się gdy nie mamy apache`a tylko np nginx na serwerze, a właściwie zmieniać poza standardową czwórką moim zdaniem warto głównie gdy przenosimy się z jakiejś farmy blogowej, tak jak sam to ostatnio robiłem i zależało mi by zachować dotychczasowy format adresów. Tak by link sprzed np 2 lat, działał po przenosinach na WP

    • Nie ma żadnego kłopotu z przenoszeniem się na nginx’a (którego serdecznie polecam). Jakiś czas temu opublikowałem działający zestaw dla MU [zawiera tez poprawki interpretacji adresów administracyjnych] (dla single wystarczą ostatnie 3 linijki): http://iworks.pl/2011/09/21/konfiguracja-wordpressa-mu-na-nginxa/

  • W trakcie dyskusji prowadzonej na jednym z blogów lub w naszej WordPressowej grupie na FB (zabijcie, ale nie pamiętam;) doszliśmy do wniosku, że format /%postname% może być ciężarem nie tyle dla dużych blogów, co dla blogów z dużą ilością stron (nie mylić z postami:).

    • A oprócz tego, że to złe są jeszcze jakieś wnioski? Jakieś rozwiązanie by url jednak zawierał tytuł strony?

      Po za tym dziwna sprawa, analizowaliście zapytania sql?

      • wszystko się zgadza, ale… niedługo nie będzie to problemem :)

        po kolei: autor csstricks w czerwcu 2011 zauwazyl, ze samo %postname% w urlu faktrycznie obciaza mozna wordpressa -> http://digwp.com/2011/06/dont-use-postname/

        spowodowalo to nieco zamieszania wokol wordpressa (bo problem faktycznie wystepuje przy duzej ilosci wpisow, wplywa na to sposob przetwarzania regexpów na urlach przez wp).

        w sierpniu andrew nacin zajala sie sprawa i dodal obsluge %postname% natywnie (mozna ją bedzie sobie wybrac z listy) http://core.trac.wordpress.org/changeset/18541/

        bug ma juz status needs testing http://core.trac.wordpress.org/ticket/16687

        …i rozwiazanie pojawi sie w wordpressie 3.3

        tak to bedzie wygladalo , przedostatnia pozycja na liscie to wbudowane natywnie %postname%

Uwaga, leci reklama:

Firefox jest znów szybki!

Gdzie nas czytać?

Autorzy »
Komentujący »
#wpzlecenia »