Buenas Prácticas para detectar errores de programación

1. Active la depuración del código para detectar errores

WP_DEBUG se puede activar con sólo añadir la siguiente línea a su archivo wp-config.php

define(‘WP_DEBUG’,true);

Si su página ya se encuentra al aire y no quiere dejar ala vista de todo el mundo los errores, añada estas líneas y deje los errores sólo para verlos usted. Indique el IP de su equipo y voila!

# 200.200.200.200 is an example IP and should be replaced by your own
# if you don’t know your IP you can visit www.whatismyip.com
if ($_SERVER['REMOTE_ADDR'] == ’200.200.200.200′) define(‘WP_DEBUG’,true);
2. Tenga una rutina de desactivación limpia
¿Habías echó un vistazo a la tabla de wp_options después de mucho tiempo para activar y desactivar los plugins? Si por lo que probablemente había visto a la basura que dejan por ahí.

Si usted va a escribir una opción con add_option o UPDATE_OPTION favor, por favor, por favor, asegúrese de eliminar sus opciones en la desactivación de plugins. Estoy bastante seguro de que nadie quiere tus sobras opciones como recuerdo.

Para lograr tal cosa, debe registrar un gancho de la desactivación por el register_deactivation_hook como seguir

register_deactivation_hook( __FILE__, ‘plugin_deactivate’ );
And obviously you will have to code an appropriate deactivation function, like plugin_deactivate in the example.

NOTE: Your deactivation function must be at the script’s main PHP file.
NOTE: Your deactivation function may have any name.
NOTE: The __FILE__ part specified at the deactivation hook is referencing your own script file.

Yo personalmente puse todas mis opciones que va a la base de datos de wp_options en una matriz asociativa mundial por lo que si puedo añadir más opciones a mi función de limpieza seguirán siendo compatibles.

global $aOptions;
$aOptions = array(
‘myplugin-default-lang’ => ‘en_US’
);
I also put my deactivation and cleanup functions apart so I can call the cleanup from within the deactivation function. This is made so if I want to add more deactivation functionalities else than cleanup I can do this without polluting my cleanup function with non-cleanup procedures.

The plugin_deactivate function will look like the following:

function plugin_deactivate() {
// Cleanup
plugin_cleanup();
} // end :: function :: plugin_deactivate
And the cleanup function as it follows:

function plugin_cleanup() {

global $aOptions;

// Delete our options
foreach ($aOptions as $sOptionKey => $sOptionValue):
delete_option($sOptionKey);
endforeach;

} // end :: function :: plugin_cleanup
This should be enough to keep your options table tidy.

 

 

3. Protjer los archivos para que no puedan ser accesados directamente

if (!function_exists (‘add_action’)):
header(‘Status: 403 Forbidden’);
header(‘HTTP/1.1 403 Forbidden’);
exit();
endif;
4. Use internationalization even if you aren’t going to translate yet
Even if you are not planning release you plugin with many languages I strongly recommend that you build yours i18n-ready by wrapping your texts on gettextw functions so other users can help (or even you in the future) to translate your plugin.

THE BASICS

Internationalization basics in PHP is very simple. There are mainly two functions: __() and _e(). The difference is that __() returns the internationalized string _e() echoes it.

When text is within a variable or returned by a function you should use the __() function and if you want to echo it, _e() instead.

ECHOING INTERNATIONALIZED TEXT IN A TEMPLATE FILE

<h2><?php _e(‘My text goes here’,'My text domain goes here’); ?></h2>
RETURNING INTERNATIONALIZED TEXT IN A FUNCTION

function somefunction() {
return __(‘My text goes here’,'My text domain goes here’);</h2>
} // end :: function :: somefunction
Internationalization is a wide subject and is covered greatly in the WordPress “Writing a Plugin” page.

Internationalizing your plugin is also a good marketing strategy since if someone releases a language file for your plugin, is also making it available in a wider market-share slice.

 

5. Employ current coding best practices
Separar el código
La aplicación de esta técnica en el desarrollo de plugins de WordPress es como tener el plugin de archivo php principal, justo lo que las llamadas y el registro de los ganchos y que sus funciones adecuadamente establecido en virtud de un lib / función o algo así. Lo mismo pasa con las imágenes o, JS / (JavaScript) y css /.

Documentar el código
Ok, esto es como decirle a los adultos que no toque el horno caliente o de poner el dedo en un enchufe de pared, pero mucha gente todavía le falta en la documentación de código. Sugiero que para mantener sus funciones, clases y archivos documentados en la sintaxis phpDocumentor.

http://www.heavyworks.net/blog/posts/5-best-practices-on-developing-wordpress-plugins

 

Deje un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

*

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>