Sanjeev
contexto
He estado trabajando en un nuevo blog de wordpress como un sitio web personal. En parte, tengo un formulario de contacto personalizado donde las personas ingresan sus datos para ponerse en contacto conmigo. Ha estado funcionando bien hasta la mañana, después de lo cual actualicé a 4.2.2v citando razones de seguridad.
problema
Después de la actualización, el formulario no puede guardar la información en la base de datos. los $wpdb->insert_id está devolviendo 0. La consulta es la misma, la página es la misma, todo es igual. El único cambio es que he actualizado a 4.2.2v desde 4.2.1v.
¿Hay algún problema con la actualización reciente o tengo que hacer más pasos después de la actualización? actualización del manual de prensa de word ?
depuración hecha…
Me he asegurado de que la versión DB esté actualizada. Muestra 31535. Al depurar usando el $wpdb->lastquery y $wpdb->print_error() yo obtengo
WordPress database error: []
SHOW FULL COLUMNS FROM `wp_tst_tbl_contacts`
?
No podía entender lo que está mal aquí. Si ejecuto la misma consulta de inserción, además de la anterior show full columns en la línea de comando usando las mismas credenciales de usuario de usuario wp, funciona perfectamente.
nota: si se necesita más información, por favor pregunte.
Sanjeev
Encontré la causa del problema. Es debido a una limitación de ancho de columna.
Tengo una columna VARCHAR (9) y estaba enviando datos que tienen una longitud de 16 caracteres. El nuevo cambio en el 4.2.2 obtiene la meta de la tabla y recorta los datos para que se ajusten correctamente al tamaño de la columna como se define en la base de datos. Y también compara los datos previos y posteriores al cultivo. Si no coinciden, está fallando.
El problema es que falla silenciosamente sin arrojar ningún error. Encontré esto al depurar el archivo wpincludes/wp-db.php.
Verifique el límite de su columna y la longitud de los datos de la columna que envía.
Una vez que aumenté el ancho de la columna (ya que los datos definitivamente tendrán más de 9 caracteres), el problema se resolvió.
-
¡Muchas gracias! Deberían haberlo puesto en el registro de cambios. Rompió algunas funciones de nuestro sitio web y no pudimos averiguar por qué porque no cambiamos nada. Te mereces más votos a favor 🙂 codex.wordpress.org/Version_4.2.2
– tim-nosotros
15 de mayo de 2015 a las 2:09
-
No hay razón por la que wordpress necesite verificar la longitud de las cadenas cuando MySQL es perfectamente capaz de truncar las inserciones por usted. Fallar en silencio es una falla horrible por culpa de Word Press. ¡Gracias por descubrir por qué!
– Darryl E. Clarke
06/08/2015 a las 19:00
-
Este error también ocurrirá si su post_type personalizado tiene más de 20 caracteres (tamaño predeterminado de la columna post_type).
– Michael DePetrillo
16 de marzo de 2016 a las 18:48
-
Confirmado, 4.6 también hace esto, a menudo los autores de complementos olvidan que la IP puede tener hasta 50 caracteres, por lo que si almacenan la entrada en la tabla donde la IP es, por ejemplo, VARCHAR 15 o incluso 20 y entra el usuario de IPv6, la inserción de wpdb falla 🙂
– jave.web
23 de agosto de 2016 a las 15:09
-
@DarrylE.Clarke Si ha diseñado bien su aplicación, no debería necesitar DB para truncar algo por usted… Creo que es WP diciendo ‘Oye amigo, ¡probablemente tengas un mal diseño!’ – en muchos casos – ese es el caso 🙂
– jave.web
23 de agosto de 2016 a las 15:12
Patricio Perkins
Estaba experimentando este mismo problema y resultó que algunos valores sin escape se insertaron en la base de datos desde una función de importación csv.
Apliqué lo correcto esc_url() y/o esc_attr() y/o esc_html() en su caso, para desinfectar la inserción previa de valores y luego la consulta se ejecutó correctamente.