¿Es obligatorio usar el prefijo $ wpdb-> en tablas personalizadas


16

Lo siento si esta pregunta es trivial. Estoy empezando a desarrollar complementos en WordPress.

En todos los tutoriales encontré esto: al crear las tablas personalizadas, $wpdb->prefixse usa.

Ejemplo:

$table_name = $wpdb->prefix . "liveshoutbox";

Mi pregunta:

¿Es obligatorio usar $wpdb->prefix? ¿Qué sucede si no uso el prefijo para mis tablas personalizadas?

Respuestas:


22

Es obligatorio, aunque no se aplica.

Considere el escenario cuando dos sitios de Wordpress se han configurado en la misma base de datos. Uno con prefijo wp_y otro con wp2_. Si instala su complemento en ambos sitios con el prefijo, sus tablas creadas serán wp_liveshoutboxpara el primer sitio y wp2_liveshoutboxpara el segundo sitio. Pero si omite el prefijo, ambos sitios usarán la misma tabla nombrada liveshoutboxy todo se romperá.


12
En otras palabras , es obligatorio . :)
Rarst

4

Considera lo siguiente:

Su complemento se utiliza en una red de WordPress, que utiliza diferentes prefijos de tabla para cada sitio. Su complemento podría estar ejecutándose simultáneamente en 836 sitios diferentes, todos en la misma base de datos. wp_385677_liveshoutboxes un nombre de tabla perfectamente razonable.

Su complemento es instalado por un usuario que tiene algún concepto de seguridad y ha cambiado el prefijo de la tabla para bloquear los bots que intentan inyectarse select * from wp_usersen el sistema. Incluso si encuentran una nueva vulnerabilidad, no funcionará.

Tomar atajos como nombres de tablas de codificación fija es una buena manera de poner en funcionamiento un producto, pero no es una buena forma de lanzarlo. en muy poco tiempo, el complemento tendrá un montón de comentarios de "no funciona", en el peor de los casos, romperá el sitio de otra persona.

Si tengo una consulta compleja y no quiero lidiar con el dolor de escribir 'select foo from ' . $wpdb->prefix . '_mytable left join ' . $wpdb->prefix . '_mytablemeta on ' . $wpdb->prefix . '.ID = ' . $wpdb->prefix . '.meta_id ...., puede usar reemplazos. Por ejemplo:

$query = 'select foo from %table% left join %meta% on %table%.ID = %meta%.meta_id ... ';

$change = array (
    '%table%' => $wpdb->prefix . '_mytable',
    '%meta%'  => $wpdb->prefix . '_mytablemeta'
    );


$sql = str_replace( array_keys( $change ), array_values( $change ), $query );

$results = $wpdb->get_results( $sql );

Wordpress está cambiando constantemente. Lo que "funciona" hoy puede no funcionar mañana. Por eso hay funciones API. Los desarrolladores de Wordpress se asegurarán de que el comportamiento de la API pública sea coherente (o depreciarán la función). Si comienzas a usar llamadas a métodos internos porque es "más rápido de esa manera", generalmente volverá a morderte. Hay muy pocos atajos verdaderos en el software: simplemente mueven el trabajo requerido de ahora en adelante y, al igual que su tarjeta de crédito "más tarde", generalmente cuesta más.


Como esto menciona multisitio, un elemento adicional a tener en cuenta que no vi en la respuesta es que el uso $wpdb->prefix . "users"dará como resultado una tabla no válida en una instalación multisitio. Esto se debe a que colocará el prefijo db en la tabla. Sin embargo, multisitio usa solo una tabla de usuario, ya que todos los usuarios son usuarios de la red. Entonces, si la consulta involucra las tablas wp_users o wp_usermeta, debe usar $wpdb->userso $wpdb->usermetarespectivamente.
butlerblog
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.