Languages: English • Français • 日本語 한국어 • ລາວ • myanmar • Nederlands • Português do Brasil • ไทย • 中文(简体) • 中文(繁體) • (Add your language)
NB! Deze pagina is nog niet helemaal vertaald.
Permalinks zijn de permanente URL's naar zowel jouw individuele berichten als naar categorieën en andere overzichten van berichten. Een permalink is waar een andere weblogger naar verwijst om te linken naar jouw artikel (of deel van je website) of hoe je naar jouw verhaal linkt in een e-mailbericht. De URL naar elk bericht zou permanent moeten zijn en zou nooit moeten veranderen — vandaar "perma"-link.
Er zijn drie soorten permalinks:
De standaard ziet er zo uit
http://example.com/?p=N
waar N het Post ID nummer is. Het werkt op alle server-omgevingen maar het ziet er niet zo mooi uit als op sommige andere manieren.
Als mod_rewrite of lighttpd beschikbaar is kunnen er veel mooiere permalinks gegenereerd worden (zie Pretty Permalinks). Er zijn veel verschillende notaties maar de meest gebruikte en meest veelzijdige ziet er zo uit
http://example.com/2012/post-name/
of
http://example.com/2012/12/30/post-name
Mooie permalinks zijn beschikbaar voor:
PATHINFO permalinks zien er bijna hetzelfde uit als mod_rewrite permalinks, met één uitzondering: ze hebben /index.php er tussen gezet:
http://example.com/index.php/yyyy/mm/dd/bericht-naam/
Verder zijn ze hetzelfde als de "mooie" mod_rewrite permalinks en zijn ze even flexibel. Alles wat mod_rewrite permalinks kunnen, kunnen PATHINFO permalinks ook, maar dan met behulp van /index.php.
Er is een handige plugin die laat zien welke type permalink er wordt gebruikt en gedetailleerde informatie over de interne rewrite rules van WordPress.
In de Instellingen → Permalinks panel, kun je een van de "algemene" structuren kiezen of je eigen invoeren in het "Aangepaste structuur" veld met de structuur tags.
Let op: Zet nooit je site-adres in de permalinks velden. Je kunt uitsluitend een van de structuurtags gebruiken of een combinatie van tags.
Om PATHINFO permalinks te activeren, moet je permalinkstructuur beginnen met index.php/.
Let op:
Zet nooit je site-adres in de permalinks velden. Je kunt uitsluitend een van de structuurtags gebruiken of een combinatie van tags.
Deze tags kun kun je aanpassen om "Mooie" of "Bijna Mooie" permalinks te maken. Tips:
De Categoriebasis en Tagbasis zijn voorvoegsels die gebruikt worden in URL's voor categorie- en tag-archieven, die er zo uitzien:
example.net/wp/categoriebasis/categorienaam example.net/wp/tagbasis/tagnaam
De standaardwaarden voor deze twee zijn categorie en tag. Je kunt ze aanpassen, maar je kunt ze niet verwijderen uit de URL's.
Aangepaste permalinks werken probleemloos op de meeste systemen, maar onder bepaalde omstandigheden treden er fouten op.
Als je meerdere categorieën aan een bericht verbindt kan er maar één in de permalink staan. De categorieën zijn alfabetisch geordend. Elke groep subcategorieën is ook alfabetisch geordend (zie Manage Categories). Het bericht blijft normaal bereikbaar via alle categorieën.
Voorwaarden:
AllowOverride FileInfo
of AllowOverride All
) Als je een "mooie" permalink structuur maakt of bijwerkt zal WordPress rewrite rules genereren en proberen om deze in het juiste .htaccess-bestand in te voegen. Als dat niet lukt zal er een mededeling verschijnen als Je moet nu je .htaccess-bestand bijwerken en de regels zullen er onder staan zodat je ze kunt kopiëren en plakken in het bestand (zet dit aan het einde).
In WordPress 2.0+ versies, hoef je dit waarschijnlijk maar één keer te doen, omdat WordPress het rewriten intern doet. Als je ooit je WordPress installatie-map verplaatst ("Siteadres") moet je deze stap herhalen.
WordPress werkt prima samen met reeds aanwezig .htaccess-bestand en zal geen enkele bestaande RewriteRules of andere regels aanpassen of verwijderen. Als je andere mod_rewrite regels hebt, zet deze dan vóór die van WordPress.
De index.php en .htaccess bestanden van WordPress dienen samen in de map te staan die is ingevuld bij Siteadres (URL) op de Algemene Instellingenpagina. Omdat de naam van het bestand met een punt begint, kan het zijn dat het niet zichtbaar is in je FTP-programma tenzij je de voorkeuren van het FTP-programma zo instelt dat alle bestanden moeten worden getoond, inclusief verborgen bestanden. Sommige hostingbedrijven (zoals bijvoorbeeld Godaddy) verbergen het .htaccess-bestand of staan je niet toe om het te bewerken als je WordPress installeert via de installer in het control panel van je hoster.
Als je nog geen .htaccess-bestand hebt, maak er dan een. Als je shell- of ssh-toegang op de server hebt, is een simpel touch .htaccess
commando genoeg om het bestand aan te maken. Als je FTP gebruikt om bestanden over te zetten, maak dan een bestand aan op je computer, noem het 1.htaccess, upload het naar de WordPress installatiemap en hernoem het dan naar .htaccess.
Je kan het .htaccess-bestand aanpassen via FTP, shell, of (waarschijnlijk) via het control panel van je hosting.
Deze permalink rewrite code zou in je .htaccess-bestand moeten staan (vanaf WordPress 3.0):
# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress
Als je .htaccess-bestand fouten bevat waardoor je website down gaat ("Internal Server Error (500)"), moet je via FTP of het control panel dat loeder van een .htaccess-bestand verwijderen.
Als WordPress jouw .htaccess-bestand niet automatisch kan updaten zal er een mededeling verschijnen zoals Als je .htaccess-bestand beschrijfbaar zou dit automatisch gedaan kunnen worden. Dat is het nu niet... onderaan de Settings → Permalinks-panel.
Als je wil dat WordPress dit voor je doet, moet je WordPress schrijfrechten geven aan het .htaccess-bestand. Welke rechten dat precies zijn, hangt af van de instellingen van je server. Probeer eerst de schrijfrechten van de eigenaar, dan de groep en dan de wereld aan te passen en test het na elke verandering; zodra WordPress het bestand succesvol heeft bewerkt, verander de rechten dan niet meer.
Na het toepassen van de permalinks, moet je de rechten van het bestand veranderen naar iets sterkers zoals 660 of 664 om te voorkomen dat anderen op de server toegang hebben tot het bestand.
"Pretty" permalinks usually require mod_rewrite, and IIS (common on Windows servers) does not support mod_rewrite. (If you are using Apache 2.0.54, on Windows, mod_rewrite may work, provided it is enabled in apache\conf\httpd.conf.)
If you are using IIS 7 and have admin rights on your server, you can use Microsoft's URL Rewrite Module instead. Though not completely compatible with mod_rewrite, it does support WordPress's pretty permalinks. Once installed, open the web.config file in the WordPress folder and add the following rule to the system.webServer element
<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <rewrite> <rules> <rule name="WordPress Rule" stopProcessing="true"> <match url=".*" /> <conditions> <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" /> <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" /> </conditions> <action type="Rewrite" url="index.php?page_id={R:0}" /> </rule> </rules> </rewrite> </system.webServer> </configuration>
There's a full installation guide on the IIS site. The module is available for x64 and x86 systems.
If this isn't an option, you can try PATHINFO permalinks; put index.php/ at the start of your custom permalink structure:
/index.php/%year%/%monthnum%/%day%/%postname%/
This option may not always work, especially in cases of WordPress running on IIS 6. To make this option work on IIS, add these 2 lines to a php.ini file and store that file in your webroot :
cgi.fix_pathinfo = 1 cgi.force_redirect = 0
Another solution exists using IIS' custom 404 redirects. It requires that your web host allows you to add a custom 404 redirect, but it doesn't require you to install any 3rd party mod_rewrite software and it also doesn't require that your permalink structure begin with /index.php/. This site explains how to do it: Permalinks on IIS without ISAPI plugin.
If your installation of WordPress does not generate a .htaccess file or if it does not write the new rules onto your existing .htaccess file then there are a couple reasons that could be causing this. Work step by step and continue to the next step only if the previous step does not work.
$is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;and replace it with
// $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;
// $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;and type in
$is_apache = 1;
A note about Microsoft Frontpage: many servers (shared and dedicated) maintained and built by various hosting companies come with mod_frontpage compiled with the apache build, and in many cases with the Frontpage Server Extensions installed, on each virtual server. This is more common than not, many/most binary distributions used in the server build process at most hosting companies these days include both mod_fronpage and the server extensions. Even if you're not using Frontpage, because of the way that the extensions interact with apache (and the httpd.conf file) you'll likely get something like a 500 error or blank white page when trying to view your WP install (although the admin panel may operate correctly) simply because extensions/mod_frontpage exist on your server.
WordPress will operate correctly with the Frontpage Extensions installed, however permalinks will not function at all and ANY change to the permalinks section from the WordPress admin interface will cause corruption of the Frontpage server extensions due to the addition of the mod_rewrite rules to the .htaccess file. There is however now a fix for this situation.
Frontpage Extensions Fix: If you don't care about permalinks and just want to make the MS Frontpage server extensions work again, simply edit your .htaccess file and remove the WordPress section with the rewrite rules.
To Use Permalinks: If you don't care about Frontpage(but your hosting company has the extensions installed)
You will need to remove (or have your hosting company do so) the MS Frontpage server extensions, or simply edit the .htaccess file to removed all of the Frontpage Lines, leaving only the WordPress mod_rewrite code.
Finally, A solution.
There have been a number of threads on this issue in the support forums, and until now, no solution to the problem.
Normally, on a Unix server with the Microsoft FrontPage Server extensions installed WordPress works just fine and you are able to edit and publish pages (with Microsoft FrontPage) — until — you make a change to the permalinks (for example to the date based kind that I like /2005/04/etc). I often suggest that type of URI to folks asking about permalinks etc, as that is the method recommended by the w3c (see http://www.w3.org/Provider/Style/URI ).
Now, the problem is that FrontPage uses the .htaccess file (which the WordPress mod_rewrite rules must access) for its "publishing" and "web authoring" configuration. As soon as the WordPress mod_rewrite code is added to the file, two things happen — the permalinks don't work and the Frontpage Server extensions become corrupt.
I have tried countless ways to get around this, including trying to use rewrite rules that "ignore" the %{HTTP_USERAGENT)% used by FrontPage, to using a second AccessFilename .wpaccess to the httpd.conf file, and a host of other things, and nothing worked to allow use of FrontPage and management and use of permalinks in WordPress at the same time.
The solution is actually simple, and I figured it out by accident.
If you are using, or wish to use FrontPage (or if your hosting package is pre-configured that way) along with WordPress, you'll need to take the following simple steps on your server or have your hosting company do them for you.
Microsoft FrontPage creates the following directory
_vti_binNested within that it creates both
_vti_admand
_vti_aut
In addition to in your site (or WordPress) root folder in all of those directories you will find additional .htaccess files.
In all three of these directories AND in the root directory, at the top of ALL of the .htaccess files you simply need to add one line:
Options +FollowSymlinks
There may or may not already be a line in each like
Options None
Edit and save each .htaccess file and you're done. Now everything works perfectly, including FrontPage, AND the permalinks of your choosing.
When using extra long permalinks in email and posting in comments and chats, some long permalinks are "chopped off" or only the first section is actually recognized as a link and the end seen as text. Here is an example.
Can result in:
To click on the lower link, the user would get a 404 Page Not Found Error. If you have a tendency to use very long permalink post titles, take these steps to prevent this problem.
1. Check that you are indeed using Permalinks.
2. Edit your .htaccess file and add the following:
RewriteRule ^post/([0-9]+)?/?([0-9]+)?/?$ /index.php?p=$1&page=$2 [QSA]
3. Test it. Find a post's ID number and type the following (with your information) in your browser and you should be redirected to your post:
http://yourdomain.example.com/post/(the ID #)
It is also worth noting that most email software will not cut off URLs that have been delineated with angle-brackets (< and >), so when pasting URLs into emails, you should write them as so:
Additionally, some decent email clients offer a "preformat" option when composing plain-text emails. Using the "preformat" option when pasting links will force the email client not to insert linebreaks inside the links.
If your .htaccess file is being generated correctly, but Permalinks still do not function, the following might be a problem. If problems persist, post a note in the WordPress Forum's How To section.
<Directory /> Options FollowSymLinks AllowOverride All </Directory>
You may also have to enable the AllowOverride directive in your DocumentRoot:
<Directory /var/www/html> # ... other directives... AllowOverride All </Directory>
http://www.example.com/page/2/ http://www.example.name/category/categoryname/page/2/ http://www.example/year/month/day/page/2/ http://www.example/year/month/page/2/
If these steps do not work, search for your problem in the Codex, Troubleshooting, or in the Support Forum. As a last resort, file a bug report.
Note that even though one might never make more than one posting a day, and thus wishes to use e.g., %year%%monthnum%%day%, links so generated will however be interpreted as the archive of all posts for that day. One needs at least %year%%monthnum%%day%%hour% to target an individual post.
A way to check if the blog has a permalink structure is:
<?php if ( get_option('permalink_structure') ) { echo 'permalinks enabled'; } ?>
Terug naar de Startpagina