Test Plugin 3 – Testing plugin

Descripción

Para una mejor compatibilidad del archivo «README.md», los campos bajo el título del plugin, «Contributors», «Tags», etc., deben estar en un formato similar al de este ejemplo de archivo «readme». Esto significa que no debe haber caracteres después de «:» aparte del valor, sin formato, solo un valor y una nueva línea.

Esta es la descripción larga. Sin límite y puedes usar Markdown (así como en las siguientes secciones).

Para compatibilidad con versiones anteriores, si falta esta sección, se usará la longitud completa de la descripción corta y
el análisis de Markdown.

Algunas notas sobre las secciones anteriores:

• «Contributors» es una lista separada por comas de nombres de usuario de wp.org o wp-plugins.org
• «Tags» es una lista separada de etiquetas que se aplican al plugin
• «Requires at least» es la versión más baja en la que funcionará el plugin
• «Tested up to» es la versión más alta que has usado correctamente para probar el plugin. Ten en cuenta que puede funcionar
  en versiones más altas… esta es solo la versión más alta que has verificado.

• La etiqueta «Stable» debe indicar la «etiqueta» de Subversion de la última versión estable, o «trunk», si usas /trunk/ para la
  versión estable.

  Ten en cuanta que el archivo readme.txt de la etiqueta estable es el que se considera que define al plugin, así que,
  si el archivo /trunk/readme.txt dice que la etiqueta estable es 4.3, entonces es /tags/4.3/readme.txt el que se usará
  para mostrar la información sobre el plugin. En esta situación, lo único que se considera del archivo readme.txt de «trunk»
  es el indicador de la etiqueta estable. Por tanto, si desarrollas en «trunk», puedes actualizar el archivo readme.txt de «trunk» para reflejar los cambios en
  tu versión en desarrollo, sin tener esa información mostrada incorrectamente sobre la versión estable actual
  que carece de esos cambios, siempre y cuando el archivo readme.txt de «trunk» apunte a la etiqueta estable correcta.

  Si no se proporciona una etiqueta estable, se asume que «trunk» es estable, pero debes especificar «trunk» si es ahí donde
  pones la versión estable, para eliminar cualquier duda.

Probando algunos fallos de Markdown:
Ejemplos:
define( ‘TC_PRE’, ‘Theme Review:[[br]]
– Los temas deben ser revisados usando «define(\’WP_DEBUG\’, true);» en el archivo «wp-config.php»[[br]]]
– Los temas deben ser revisados usando los datos de prueba de las listas de comprobación de temas (TC)
—–
‘ );

define( 'TC_POST', 'Feel free to make use of the contact details below if you have any questions,
comments, or feedback:[[br]]
[[br]]
* Leave a comment on this ticket[[br]]
* Send an email to the Theme Review email list[[br]]
* Use the #wordpress-themes IRC channel on Freenode.' );

three backtics:
add_action( 'init', function() {
// do stuff
} );

or indents
add_action( ‘init’, function() {
// do stuff
} );

Sección arbitraria

You may provide arbitrary sections, in the same format as the ones above. This may be of use for extremely complicated
plugins where more information needs to be conveyed that doesn’t fit into the categories of «description» or
«installation.» Arbitrary sections will be shown below the built-in sections outlined above.

Un breve ejemplo de Markdown

Ordered list:

1. Alguna característica
2. Otra característica
3. Algo más sobre el plugin

Unordered list:

• algo
• algo más
• tercera cosa

Here’s a link to WordPress and one to Markdown’s Syntax Documentation.
Titles are optional, naturally.

Markdown uses email style notation for blockquotes and I’ve been told:

Asterisks for emphasis. Double it up for strong.

<?php code(); // goes in backticks ?>