Hay muchos consejos para agilizar tus scripts de PHP, pero en este caso se concentran en el uso de funciones y sus funciones alias. Por lógica la llamada a una función será más rápida que la llamada a una función alias, salvo en un caso que la verdad me sorprende.
Los porcentajes que se muestran son reales, pero quizás no sean perceptibles, ya que el uso de estas funciones puede ser mÃnimo en un desarrollo, pero bueno, si algo de tiempo obtenemos, mejor que mejor.
Las funciones son las siguientes:
sizeof y count: count es un 12% más rápida.
is_int y is_integer: is_int es un 9% más rápida.
chop y rtrim: rtrim es un 7% más rápida.
doubleval y floatval: floatval es un 4% más rápida.
fwrite y fputs: fputs es un 23% más rápida, esta es la comparativa que me sorprende, porque fputs es alias de fwrite. Que alguien me lo explique, ¿una diferencia del 23%? o no son alias o el ejemplo está mal medido.
implode y join: implode es un 5% más rápida.
ini_alter y ini_set: ini_set es un 19% más rápida.
PHP viene por defecto configurado para desarrollo, pero en producción hay opciones que no son recomendables sobre todo por temas de seguridad. Cambiad en el php.ini las siguientes opciones para mejorar la seguridad en tu entorno de producción:
Desactiva el acceso a ficheros remotos: las funciones fopen, file_get_contents, y include permiten el acceso a ficheros remotos (http://host/..), lo cual puede dar problema en temas de seguridad. Si necesitas acceder a ficheros remotos puedes usar fsockopen o funciones de CURL.
allow_url_fopen = Off
Register globals: aunque ahora viene por defecto desactivado, en versiones anteriores de PHP, los parámetros de entrada se registraban como variables globales.
Modo seguro: PHP dispone de un modo seguro, en el que Apache solo puede acceder a ficheros de los que sea dueño, aunque nos puede dar problemas sobre todo cuando se trabaja en grupo, la tranquilidad que nos aporta pesa más que este inconveniente. Para ello usaremos una propiedad para que solo ejecute scripts que le pertenecen y otra permite acceso a los ficheros que pertenecen al grupo de Apache aun cual sea el dueño.
safe_mode = Off
safe_mode_gid = On
Acceso permitido a ficheros binarios: el modo seguro tampoco permite ejecutar ficheros binarios, pero se le puede indicar en que ruta si se pueden ejecutar.
safe_mode_exec_dir = /www/ejecutables
Acceso a variables de entorno: tampoco está permitido acceder a variables de entorno en el modo seguro, pero se puede inluir una lista (separada por comas) de prefijos que se permiten para estas variables.
max_execution_time = 30 ; Tiempo máximo de ejecución
max_input_time = 60 ; Tiempo máximo que trata la entrada
memory_limit = 16M ; Memoria máxima para la ejecución de un script
upload_max_filesize = 2M ; Tamaño máximo de un fichero para subir
post_max_size = 8M ; Tamaño máximo de un POST
Control de acceso a ficheros mediante Apache: aunque en este caso se debe configurar Apache, tampoco biene mal el contarlo. Se trata de evitar que Apache acceda a ficheros importantes, por ejemplo ficheros .inc, .sql.
<FilesMatch "\.(inc|.*sql)$">
Order allow,deny
Deny from all
</FilesMatch>
Buddypress es un plugin de WordPress que permite convertirlo en una red social. El plugin está bastante bien, pero una cosa que no me gusta es cómo muestra la pantalla de opciones de tu perfil, dividiendola en distintas secciones: profile, general, … Por lo que tener una única pantalla de opciones es un dolor de cabeza, sobre todo porque cuando se guardan los datos de un grupo de opciones, hace un redirect por lo que no podemos continuar guardando datos.
Para poder solucionar esto hay que mirar qué grupos de opciones se ejecutan inicialmente, y ver que antes del redirect hay un action que deberemos tomar en cuenta:
add_action( 'bp_core_general_settings_after_save', 'iqn_more_settings_save');
function iqn_more_settings_save() {
global $bp;
// Guardar datos del profile
$bp->current_action = 'profile';
$_REQUEST['_wpnonce'] = $_REQUEST['_wpnonce_xprofile'];
bp_xprofile_action_settings();
}
En mi caso, inicialmente, se guardaba antes el general settings, por lo que en el action bp_core_general_settings_after_save lo que hago es llamar a la siguiente función que guarda los siguientes datos.
También es necesario que _wpnonce se modifique para que el formulario no falle por temas de seguridad, por lo que hay que añadir en nuestro formulario lo siguiente:
WordPress 3.4 ha añadido la opción de theme customizer, la cual permite modificar las opciones del theme y darle el aspecto que deseas de forma muy visual y sencilla. En estos momentos, por lo que he podido ver, solo permite modificar el background y poco más. Pero viendo y pegándome con el código he podido ver cómo añadir mis propias opciones.
El ejemplo que voy a poner permite elegir entre tres tipos de fuente de Google Webfonts y modificar las css para usar ese tipo de letra.
Aviso que el código quizás no sea el mejor, pero realizar ingeniería inversa no siempre es fácil y tampoco he visto otro sitio donde lo hagan.
Lo primero que se tiene que hacer es crear las opciones en el panel de customizer. Para ello hay que crear una sección (section “Fuente”) y asignarle unas opciones (settings) y añadirle unos controles (control) a las opciones. Existen controles por defecto, el de elegir el color está muy bien, pero en mi caso me he creado uno personalizado que muestra un control radio modificado para que el label del radio muestre la tipo de letra en cuestión.
add_action('customize_register', 'mi_theme_customizer', 1);
function mi_theme_customizer() {
global $customize;
if($customize) {
// La seccion
$customize->add_section('mi_font', array(
'title'=>'Fuente'
) );
// La opcion
$customize->add_setting( 'mi_font_family', array(
'control' => 'color', // esto ni idea de para que sirve, realmente no es un control tipo color y funciona
'type' => 'option'
) );
$customize->add_control( 'mi_font_family', array(
'settings' => 'mi_font_family',
'section' => 'mi_font',
'type' => 'font_radio',
'choices' => array('Trocchi', 'Great Vibes', 'Bad Script') // las fuentes de google
) );
}
}
Una vez creado los controles, añado el código que dibuja (render) mi control personalizado, primero añado los css para que dibuje las fuentes de Google y luego dibujo el control en sí. He usado Javascript en vez de PHP porque parece ser que el código no está del todo completo, y no hay un filtro para crear tu propio control, por lo que tengo que añadirlo mediante jQuery a un elemento para que el Javascript del customizer tenga en cuenta cuando selecciono una opción y refresque el preview del theme.
// Añado los css de google webfonts mediante javascript para tener luego el nombre de las fuentes y usarlo para crear los radio buttons
add_action('customize_controls_print_scripts', 'mi_customize_scripts');
function mi_customize_scripts() {
$fonts = array('Trocchi', 'Great Vibes', 'Bad Script');
?>
type == 'font_radio') {
if ( empty( $control->choices ) )
return;
$name = '_customize-font-radio-' . $control->id;
?>
label ); ?>
Y ya por último solo falta usar la opción guardada para mostrarla en el theme
add_action('wp_head', 'mi_custom_styles');
function mi_custom_styles() {
$option = get_option('mi_font_family');
// El customizer modifica este filtro para refrescar el preview
$option = apply_filters('option_mi_font_family', $option);
if ($option) {
echo "";
echo '';
}
}
Y esto es todo, no sé si hay una forma mejor de hacerlo, estoy abierto a sugerencias.
Cada vez que tengo que usar un theme y me encuentro con el Visual Composer me dan los siete males. De todas formas, entiendo que si vas a crear contenido con diferentes módulos en cada página, los editores visuales pueden ser una buena solución.
El problema es que el Visual Composer cuesta unos 30$, y sinceramente, si puede ser gratis, mejor que mejor. Aquí paso un listado de los que he encontrado y que más me han gustando: