oData es un protocolo creado por Microsoft para obtener y actualizar datos en aplicaciones. Para ello hace uso de HTTP, AtomPub y JSON para garantizar el acceso a la información desde cualquier aplicación, servicio o almacenamiento. El cual dispone de un SDK, includo PHP.
Vía / php|architect
Está claro que por ahora OAuth es el futuro para el uso de APIs, y como no, Google requiere OAuth para conectarnos a su API, lo cual puede parecer bastante difícil, pero cuando le coges el truco, es bastante sencillo:
$oauth = new OAuth($consumer_key, $consumer_secret);
$oauth->setToken($access_token, $access_token_secret);
$result = $oauth->fetch('https://www.google.com/analytics/feeds/datasources/ga/accounts');El resto es fácil, tan sólo hay que mirar la documentación y obtener los datos de las distintas peticiones.
Últimamente estoy trabajando bastante con Gutenberg, tiene sus cosas buenas y malas. Sea como sea, es el futuro de WordPress, así que toca aprender.
Lo más interesante de todo es poder usar lo que sabía de webpack, React, HMR, … Y para practicar he hecho un plugin que permite añadir snippets de código en los posts usando los bloques de Gutenberg
Para ello uso la librería highlight.js que permite destacar código de forma sencilla. Aquí un ejemplo
// Import CSS.
import './scss/style.scss';
import './scss/editor.scss';
import icon from './icon';
import edit from './edit';
import save from './save';
import attributes from './attributes';
import { __ } from '@wordpress/i18n'; // Import __() from wp.i18n
export const name = 'sentidoweb/snippet';
export const settings = {
// Block name. Block names must be string that contains a namespace prefix. Example: my-plugin/my-custom-block.
title: __( 'Snippets editor', 'sw-snippet' ), // Block title.
icon: icon,
category: 'common', // Block category — Group blocks together based on common traits E.g. common, formatting, layout widgets, embed.
keywords: [
__( 'code', 'sw-snippet' ),
__( 'format', 'sw-snippet' ),
__( 'snippet', 'sw-snippet' ),
],
attributes,
edit,
save,
};La jerarquía de las plantillas de wordpress permite definir diferentes plantillas para mostrar según el tipo de contenido. Por ejemplo, la template para mostrar el contenido de un post es single.php, pero si es un custom post type podemos crearnos la template single-miposttype.php y que use esa plantilla específica para mostrar los contenidos del custom post type. Si se trata de una página mostrará page.php, y así con todos los tipos de contenido.
Lo que nos encontramos en ocasiones es que queremos ejecutar un javascript específico asociado a esa plantilla, lo cual podemos hacerlo a la hora de añadir los scripts preguntando por el tipo de contenido. Pero si lo queremos hacer de una forma más automática, podemos añadir en el filtro template_include la acción de añadir el script.
add_filter('template_include', 'js_load_script_template');
function js_load_script_template($template) {
// Obtenemos el fichero de la template que se usa
$js = pathinfo($template);
$js = $js['filename'];
// Me gusta obtener la versión del theme para evitar caches
$my_theme = wp_get_theme();
$version = $my_theme->get( 'Version' );
// Si el fichero js existe, p.e. single-miposttype.js lo añadimos
if (file_exists(get_template_directory().'/js/'.$js.'.js')) {
wp_enqueue_script( $js, get_bloginfo('template_directory').'/js/'.$js.'.js', array(), $version );
}
// Tambien ejecuto el script relacionado con la plantilla generica, p.e. single.js
$js_part = preg_replace('#^([^\-]+)\-.*$#', '$1', $js);
if ($js != $js_part && file_exists(get_template_directory().'/js/'.$js_part.'.js')) {
wp_enqueue_script( $js_part, get_bloginfo('template_directory').'/js/'.$js_part.'.js', array(), $version );
}
return $template;
}
Kohana es un framework de PHP que deriva de CodeIgniter, el cual ya he comentado aquà que me gusta bastante. Basado inicialmente en CI, posee las mismas caracterÃsticas que este: seguro, liviano, fácil de aprender, MVC, compatible con UTF-8 y fácilmente extensible.
¿Qué diferencias existen entre CI y Kohana?
HTML Purifier es un filtro en PHP que elimina código XSS de HTML y hace que sea estándar. Acaba de sacar la versión 3.0 y entre las novedades nos encontramos con:
Para obtener datos de un HTML, en vez de hacerlo con expresiones regulares, hacerlo mediante DOMDocument:
$oldSetting = libxml_use_internal_errors( true );
libxml_clear_errors();
$html = new DOMDocument();
$html->loadHtmlFile( $url );
$xpath = new DOMXPath( $html );
$links = $xpath->query( '//a' );
foreach ( $links as $link ) {
echo $link->getAttribute( 'href' ), "\n";
}
libxml_clear_errors();
libxml_use_internal_errors( $oldSetting ); Se utiliza libxml_use_internal_errors para evitar HTML mal formados
Me pregunto si para obtener tan solo un dato del HTML (title por ejemplo) es mejor el DOM o las expresiones regulares.