Pods: Problema real: los nombres reservados no deben permitir que se agreguen

Creado en 13 jul. 2019 · 20Comentarios · Fuente: pods-framework/pods

Describe el error
Primera vez que utilizo Pods. Me encontré con esto (reproducido usando master): classes/PodsAPI::save_pod rescata antes de llamar a cache_flush_pods cuando encuentra algún error al guardar los campos recién agregados. Si bien parece que los otros campos aún se guardan en la base de datos, no son visibles para el usuario final hasta que se vacía la caché.

Número de línea de revisión actual 2356 :

if ( ! empty( $errors ) ) {
    return pods_error( $errors, $this );
}

$this->cache_flush_pods( $pod );

(PD: Por lo que puedo decir, no parece haber ningún manejo de errores en el lugar por no guardar los campos).

Reproducir
Pasos para reproducir el comportamiento:

Editar un pod
Agrega un campo con el nombre 'foobar'
Agregue un campo con el nombre 'nombre' (o 'post_title', o el nombre de un campo existente)
Guardar pod

Observe: ninguno de los campos recién agregados se muestra después de guardar

Reproduced Bug Documentation

Fuente

brucevdkooij

Todos 20 comentarios

Issue-Label Bot aplica automáticamente la etiqueta Type: Bug a este problema, con una confianza de 0.98. Por favor, marque este comentario con: thumbsup: o: thumbsdown: para darnos su opinión sobre el bot.

Enlaces: página de inicio de la aplicación , panel de control y código para este bot.

issue-label-bot[bot] en 13 jul. 2019

👍1

+1 Tener el mismo problema. Establecer nombres preservados no da un error.

jarrin en 15 jul. 2019

🎉1

Ver # 4122 Esto debe aplicarse a nombres de campo, taxonomía, tipos de publicaciones, etc. Alguien no debería poder escribir NINGÚN nombre de campo, tipo de publicación o taxonomía que esté en la Lista de campos de nombres RESERVADOS.

jimtrue en 15 jul. 2019

Presenté un informe de error # 5440 donde tuve el mismo problema con un campo etiquetado como 'estado'. Sin embargo, el 'estado' no está en la lista de Términos reservados de Wordpress. En el caso mencionado anteriormente, 'nombre' está en esa lista, pero 'foobar' no. Lo mismo es cierto para la lista PHP de palabras reservadas.

Lista de Wordpress: (https://codex.wordpress.org/Reserved_Terms)
Lista de PHP https://www.php.net/manual/en/reserved.php

¿Quizás alguna otra lista de palabras reservadas también está interfiriendo?

raoulunger en 17 ago. 2019

@raoulunger ~~¿Ha probado las últimas relaciones públicas relacionadas con las palabras clave reservadas?~~

EDITAR: status no es una palabra clave reservada de WordPress, pero es para Pods, ya que se usa como uno de los campos de objeto de Pod. (todavía investigando en este momento)

JoryHogeveen en 19 ago. 2019

Hola, veo que tachaste la pregunta ;-). ¡Gracias por investigar!

raoulunger en 19 ago. 2019

Sí, después de la investigación, resulta que status es un alias de post_status dentro de Pods (para usar en etiquetas mágicas, etc.).
Lista completa de claves y alias predeterminados:

ID                     ==> id
post_title             ==> title & name
post_content           ==> content
post_excerpt           ==> excerpt
post_author            ==> author
post_date              ==> created & date
post_date_gmt
post_status            ==> status
comment_status
ping_status
post_password
post_name              ==> slug &  permalink
to_ping
pinged
post_modified          ==> modified
post_modified_gmt
post_content_filtered
post_parent            ==> parent
guid
menu_order
post_type              ==> type
post_mime_type
comment_count
comments

@ sc0ttkclark @jimtrue Creo que este problema se puede cerrar, ¿de acuerdo?

JoryHogeveen en 19 ago. 2019

Ok, eso aclara las cosas en lo que respecta al 'estado': ¡gracias por averiguar esto y por la lista!

Para resolver el problema más amplio del uso de palabras reservadas (este tema, y también el # 4122), parece que habría algunas opciones:

el código se cambia para que los alias para las identificaciones puedan usarse, o (si eso no es factible),
se muestra una advertencia cuando se usa una palabra 'prohibida', y
Se hace alguna referencia en alguna parte de la documentación a este fenómeno y a la lista anterior para las palabras prohibidas.

Por cierto, es fácil para mí sugerir todo esto, por supuesto, ya que realmente no puedo ayudar aquí: mis habilidades de codificación son demasiado limitadas, ¡lo siento!

¡Salud!

raoulunger en 19 ago. 2019

ID es simplemente una palabra clave reservada, no creo que podamos cambiar eso.
Acerca de las advertencias, se muestran actualmente, pero esto se hace a través de AJAX (lado del servidor) y no directamente al escribir. Sin embargo, creo que esto es algo que agregaremos en el futuro, pero no como una versión de mantenimiento.
La documentación siempre es una buena idea. @jimtrue ¿Podrías crear una página de documento para esto que pueda usar?

JoryHogeveen en 19 ago. 2019

No se puede cerrar hasta que esté documentado. ¿Algún otro de esos 'alias' que no funcionaría para crear como campo? es decir, "título", "padre", etc.

jimtrue en 19 ago. 2019

Esto es todo lo que pude encontrar hasta ahora (aparte de las palabras clave centrales de WP ya mencionadas)

JoryHogeveen en 19 ago. 2019

Esto aún debería ser parcheado porque tenemos que explicar POR QUÉ no permitimos que se agreguen esos campos. Ahora mismo, no les damos información.

jimtrue en 19 ago. 2019

Eso no es del todo cierto, AJAX devuelve un mensaje de error, pero solo al guardar.

JoryHogeveen en 19 ago. 2019

No recibí ningún error visible cuando dupliqué el problema. Si no hay ningún error visible para el usuario, eso es un problema.

jimtrue en 19 ago. 2019

¿Probaste con las últimas relaciones públicas? N.º 5441
Tenga en cuenta que estas palabras clave reservadas están permitidas para nombres de campo. Solo que no para Pods (CPT / Tax), consulte el n. ° 5428.

JoryHogeveen en 19 ago. 2019

Tampoco recibí un mensaje de error (por lo tanto, la confusión). Sin embargo, no he probado con las últimas relaciones públicas, porque realmente no tengo ni idea de cómo hacerlo (lo siento de nuevo, soy bastante nuevo por aquí).

El 19 de agosto de 2019, a las 17:50, Jory Hogeveen [email protected] escribió:

¿Probaste con las últimas relaciones públicas? # 5443 https://github.com/pods-framework/pods/pull/5443
Tenga en cuenta que estas palabras clave reservadas están permitidas para los nombres de los campos. Solo que no para Pods (CPT / Tax), consulte # 5428 https://github.com/pods-framework/pods/pull/5428 .
-
Recibes esto porque te mencionaron.
Responder a este correo electrónico directamente, visualizarla en GitHub https://github.com/pods-framework/pods/issues/5420?email_source=notifications&email_token=AM2NSKDD43ZU2JY47LPKRV3QFK6LTA5CNFSM4ICZDB72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4TNDNQ#issuecomment-522637750 , o silenciar el hilo https://github.com/ notificaciones / unsubscribe-auth / AM2NSKESXEIVUY3PLHRRMW3QFK6LTANCNFSM4ICZDB7Q .

raoulunger en 19 ago. 2019

@ sc0ttkclark @jimtrue ¿Se puede cerrar esto?

JoryHogeveen en 4 sept. 2019

Si movemos el vaciado de la caché antes de enviar pods_error, podemos resolver el foco principal de este ticket.

sc0ttkclark en 5 sept. 2019

Corregido en # 5459

JoryHogeveen en 5 sept. 2019

Lo siento, reacción tardía, ¡pero gracias!

El 5 de septiembre de 2019, a las 14:27, Scott Kingsley Clark [email protected] escribió:
Cerrado # 5420 https://github.com/pods-framework/pods/issues/5420 a través de # 5459 https://github.com/pods-framework/pods/pull/5459 .
-
Recibes esto porque te mencionaron.
Responder a este correo electrónico directamente, visualizarla en GitHub https://github.com/pods-framework/pods/issues/5420?email_source=notifications&email_token=AM2NSKBMJPPMDU5DSLKEPWTQID3JNA5CNFSM4ICZDB72YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOTOL3AQY#event-2610409539 , o silenciar el hilo https://github.com/ notificaciones / unsubscribe-auth / AM2NSKDMLL2WOT3F7ITJ47TQID3JNANCNFSM4ICZDB7Q .