Esta página está en proceso de traducción. Es posible que haya errores o partes aún no traducidas. Puede ayudar corrigiendo los errores que encuentre.
This page is being translated. You may find some errors or some paragraphs not translated yet. You can help correcting the errors found
Permalinks son las URLs permanentes a una entrada individual del weblog, así como a las categorías y otras listas de la publicación del Weblog. Un permalink es lo que otro weblogger suele enviar a su artículo (o sección), o como usted podría enviar un enlace a su artículo en un mensaje electrónico. Especialmente cuando se utilizan para enlazar a entradas individuales, una vez publicado un artículo, la URL a este artículo debería ser permanente, y no cambiarse nunca. De ahí el "perma" del nombre.
Hay tres tipos básicos de permalinks en WordPress:
Por defecto se parece a esto http://ejemplo.com/?p=N donde N es un número. Este es el permalink por defecto para las nuevas instalaciones de WordPress porque WordPress trabaja con todos los entornos de servidores. Sin embargo muchas personas no lo desean porque no es tan agradable como las otras opciones.
Estos son el santo grial de los permalinks. Hay muchos formatos diferentes, pero el más común, y el más versátil se parece a http://ejemplo.com/año/mes/día/nombre-de-la-entrada/ Algunas personas eliminan también uno o todos los elementos de fecha (el día, el mes, el año) para tener un formato de permalink más corto. Permalinks mod_rewrite requieren módulo Apache mod_rewrite, esto quiere decir que la gente que usa otros servidores no puede usarlos. Vea Pretty Permalinks para más información.
Los permalinks PATHINFO se parecen mucho a los permalinks mod_rewrite pero con una excepción: tienen insertado delante /index.php. Quedan así: http://ejemplo.com/index.php/año/mes/día/nombre-de-la-entrada/ Dicho de otra manera, son las "urls amigables" permalinks mod_rewrite, y flexibles de modo similar. Todo lo que los permalinks mod_rewrite pueden hacer, pueden hacerlo también los permalinks PATHINFO, pero con la ayuda de /index.php.
Usted puede usar estas etiquetas para personalizar sus permalinks, ya sean estos "Pretty" o "Almost Pretty":
Estos tipos de permalinks trabajan sobre la mayor parte de sistemas sin ningún problema, pero en algunas condiciones todavía ocurren problemas.
/%year%/%monthnum%/%day%/%postname%/
El archivo .htaccess debería estar en el directorio que indica la "dirección de su Blog (URI)" establecida en su página de Opciones General. Ya que el nombre del archivo comienza con un ".", el archivo no puede ser visible por un cliente de FTP a no ser que usted cambie las preferencias de la aplicación de FTP para mostrar todos los archivos, incluyendo los archivos ocultos.
Si usted no tiene un archivo .htaccess, puede crear uno. Si tiene shell, o acceso ssh al servidor, un simple touch .htaccess creará el archivo. Si usted usa FTP, cree un archivo sobre su ordenador local, llámelo 1.htaccess, súbalo a la raíz de su instalación de WordPress, y después lo renombra a .htaccess. Ahora lea la sección siguiente para ver cómo puede corregir el archivo.
Su servidor debe tener mod_rewrite para permalinks libres de signos raros. En adición, puede crear un archivo .htaccess y ponerlo en el directorio principal de WordPress, o dar permisos de escritura a su directorio para que WordPress lo haga por usted. Por ejemplo, si su blog WordPress está instalado en dominio.com/wordpress/, meta el archivo .htaccess en dominio.com/wordpress/.htaccess. Sin embargo, si su instalación WordPress está en un subdirectorio, pero sus visitantes acceden a su sitio por el nivel superior de su dominio, coloque el archivo .htaccess en dominio.com/.htaccess.
Cuando crea una estructura de permalinks, WordPress generará automáticamente las reglas de reescritura e intentará insertarlas en el propio archivo .htaccess. Si no puede, imprimirá las reglas para que usted pueda copiarlas y pegarlas en su archivo .htaccess
Unas pocas precauciones acerca de la creación y edición de su archivo .htaccess:
.htaccess
para que WordPress escriba en él automáticamente las reglas. Después de aplicar permalinks, debería cambiar los permisos a algo más fuerte, como 660, para prevenir que otros tengan acceso potencialmente al servidor..htaccess
, puede pasar que las páginas en su sitio no estén disponibles (a pesar de eso todavía existirán y sus datos no estarán dañados). Si esto pasara, borre el archivo .htaccess y cree uno nuevo.Para cruftless permalinks, usted debe usar mod_rewrite, y IIS (común sobre servidores de Windows) no soporta mod_rewrite. Si usa Apache 2.0.54, sobre Windows, mod_rewrite puede trabajar. Si pone un nombre de archivo al principio, WordPress intentará usar esto para pasar los argumentos y evitará la necesidad de mod_rewrite.
/index.php/%year%/%monthnum%/%day%/%postname%/
Si usa esta opción, puede ignorar las reglas de reescritura (es decir puede ignorar .htaccess).
cgi.fix_pathinfo = 1 cgi.force_redirect = 0
Esta referencia es vía Cem http://blog.taragana.com/index.php/archive/wordpress-tip-on-permalink-options/
Existe otra solución usando 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/...
Aquí está el enlace a los archivos de instalación e instrucciones:
http://www.keyboardface.com/IIS-Permalinks/
si tiene privilegios de administrador en su servidor, puede interesarle esta solución:
URL Rewriting for WordPress under IIS
Si su instalación de WordPress no genera el archivo .htaccess o no escribe las nuevas reglas en el archivo .htaccess ya existente, hay un par de razones que podrían causar esto. Haga esto paso a paso y continue con el siguiente paso sólo si el paso anterior no funciona.
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 the extesions/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 MS 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 MS Frontpage uses the .htaccess file (which the wordpress mod_rewrite rules must go into) for it's "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 MS Frontpage Server extensions become corrupted.
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 so that a person would be able to both use MS Frontpage to manage the website and use the permalinks for wordpress at the same time.
The solution is acctually quite simple, and I kind of figured it out by accident.
If you are using or wish to use MS Frontpage (or that's just how your hosting company has things configured) along with wordpress you'll need to take the following simple steps on your server (or have your hosting company do it for you).
MS Frontpage creates the following directory _vti_bin
Nested within that it creates both _vti_adm and _vti_aut
In addition to in your website (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 everyhting works perfectly, including MS Frontpage, AND the permalinks of your choosing.
On a personal note, I prefer to use Frontpage to manage/maintain sites, I've been using it since around '96, and by now, since I do most work on UNIX servers anyway I have it configured to use external editors for just about everything, including Zend Studio for php files, Bradbury TopStyle for stylesheets, Adobe ImageReady/Photoshop for images, etc. I'm more or less just using Frontpage as a convenient way to manage the site and access everything, etc. Then when I hit the "save" button in any of the other applications, they have Frontpage save my changes directly to the server, with no need to be FTP'ing files around, etc. It does help to get lots accomplished very quickly, and I was pretty bummed for the past year or so with the permalink frustration, since I was either needing to not use permalinks or not use Frontpage, or keep re-installing the FP extensions. At one point I found a way to make a .htaccess for my "running" site, but then change it to a FP .htaccess when I was doing any work (permalinks of course didn't work), either way it was a real pain.
This should work with most versions of FP and most of the unix versions of the extensions in use today.
--Chradil 17:24, 17 May 2006 (GMT)
Usando permalinks extra largos en el correo electrónico y publicando en comentarios y chats, algunos permalinks extra largos son "cortados" o sólo se reconoce el principio como un enlace y el final como texto. Aquí hay un ejemplo.
Puede resultar en:
Si se pulsa sobre el enlace inferior, el usuario conseguiría una Página de Error 404 No Encontrado. Si tiene tendencia a usar títulos muy largos en sus entradas (posts), siga estos pasos para prevenir este problema.
1. Compruebe que de verdad está usando Permalinks.
2. Corrija su archivo .htaccess, añada lo siguiente y salve el archivo:
RewriteRule ^post/([0-9]+)?/?([0-9]+)?/?$ /index.php?p=$1&page=$2 [QSA]
3. Compruébelo. Encuentre el número ID de una entrada (post), escriba lo siguiente (con su información) en su navegador y usted debería ser redirigido a su entrada (post):
http://yourdomain.example.com/post/(the ID #)
También merece la pena notar que la mayor parte de software de correo electrónico no cortará las URLS delineadas con anaqueles de ángulo (<y>), así que pegando URLs en correo electrónico, debería escribirlas así:
Además, algunos clientes de correo electrónico decentes ofrecen una opción "preformatear" componiendo correos electrónico en texto simple. La utilización de la opción "preformatear" pegando enlaces forzará al cliente de correo electrónico a no insertar cortes de línea (linebreaks) dentro de los enlaces.
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>
Si estos pasos no funcionan, busque acerca de su problema en el Codex, Solución de Problemas, en el Foro de Soporte (en inglés) o Foro de Soporte (en español). Como último recurso, file a bug report.
There's an easy way to having your posts end in a .html extension, using the structure tags above. Following the example used on properly terminating permalinks, you could have a page like http://yoursite.com/2006/01/01/happy-newyear.html with this rule:
/%year%/%monthnum%/%day%/%postname%.html
Observar que esto no genera los archivos reales de .html. Es solamente una ilusión. No hay ventaja en esto... que alguna gente piensa equivocadamente que ofrece ventajas en la indexacion y busqueda de las entradas.