Pods: Problema real: Nomes reservados não devem permitir a adição

Issue-Label Bot está aplicando automaticamente o rótulo Type: Bug a este problema, com uma confiança de 0,98. Por favor, marque este comentário com: thumbsup: ou: thumbsdown: para dar feedback ao nosso bot!

Links: página inicial do aplicativo , painel e código para este bot.

1 Tendo o mesmo problema. Definir nomes preservados não dá erro.

Ver # 4122 Isto deve ser aplicado a nomes de campo, taxonomia, pós-tipos, etc. Alguém não deve ser capaz de digitar NENHUM nome de campo, pós-tipo ou taxonomia que esteja na Lista de Campos de Nomes RESERVADOS.

Apresentei um relatório de bug # 5440 em que tive o mesmo problema com um campo denominado 'status'. No entanto, 'status' não está na lista de termos reservados do Wordpress. No caso mencionado acima, 'nome' está na lista, mas 'foobar' não. O mesmo é verdade para a lista de palavras reservadas do PHP.

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

Talvez alguma outra lista de palavras reservadas esteja interferindo também?

@raoulunger Você tentou as últimas relações públicas sobre palavras-chave reservadas?

EDIT: status não é uma palavra-chave reservada do WordPress, mas é para Pods, pois é usada como um dos campos do objeto Pod. (ainda investigando no momento)

Olá, vejo que você riscou a questão ;-). Obrigado por investigar!

Sim, após investigação, descobriu-se que status é um apelido para post_status em Pods (para uso em Magic Tags etc.).
Lista completa de chaves e aliases padrão:

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 Acho que esse problema pode ser

Ok, isso esclarece as coisas no que diz respeito ao 'status' - obrigado por descobrir isso e pela lista!

Para resolver o problema mais amplo de usar palavras reservadas (este tópico e também # 4122), parece que haveria algumas opções:

• o código é alterado para que os aliases para id's possam de fato ser usados, ou (se isso não for possível),
• um aviso é mostrado quando uma palavra 'proibida' é usada, e
• alguma referência é feita em algum lugar da documentação a esse fenômeno e à lista acima para palavras proibidas.

A propósito, é fácil para mim sugerir tudo isso, já que não posso ajudar aqui - minhas habilidades de codificação são muito limitadas, desculpe!

Saúde!

ID é simplesmente uma palavra-chave reservada, não acho que podemos mudar isso.
Sobre os avisos, atualmente são mostrados, mas isso é feito através de AJAX (lado do servidor) e não diretamente ao digitar. Acho que isso é algo que adicionaremos no futuro, mas não como uma versão de manutenção.
A documentação é sempre uma boa ideia. @jimtrue Você poderia criar uma página de doc para isso que eu possa usar?

Não pode ser fechado até que seja documentado. Qualquer outro desses 'aliases' que não funcionaria para a criação como um campo? ou seja, 'título' 'pai' etc?

Isso é tudo que pude encontrar até agora (além das palavras-chave principais do WP já mencionadas)

Isso ainda precisaria ser corrigido porque temos que explicar POR QUE não estamos permitindo que esses campos sejam adicionados. No momento, não damos informações a eles.

Isso não é totalmente verdade, AJAX retorna uma mensagem de erro, mas apenas ao salvar.

Não recebi nenhum erro visível quando dupliquei o problema. Se não houver nenhum erro visível para o usuário, isso é um problema.

Você testou com o PR mais recente? # 5441
Lembre-se de que essas palavras-chave reservadas são permitidas para nomes de campo. Apenas não para Pods (CPT / Imposto), consulte # 5428.

Eu também não recebi uma mensagem de erro (daí a confusão). Eu não testei com o PR mais recente, porque eu realmente não tenho ideia de como fazer isso (desculpe novamente - eu sou um novato aqui).

Em 19 de agosto de 2019, às 17:50, Jory Hogeveen [email protected] escreveu:

Você testou com o PR mais recente? # 5443 https://github.com/pods-framework/pods/pull/5443
Lembre-se de que essas palavras-chave reservadas são permitidas para nomes de campos. Só não para pods (CPT / imposto), consulte # 5428 https://github.com/pods-framework/pods/pull/5428 .

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, vê-lo no GitHub https://github.com/pods-framework/pods/issues/5420?email_source=notifications&email_token=AM2NSKDD43ZU2JY47LPKRV3QFK6LTA5CNFSM4ICZDB72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4TNDNQ#issuecomment-522637750 , ou silenciar o fio https://github.com/ notificações / unsubscribe-auth / AM2NSKESXEIVUY3PLHRRMW3QFK6LTANCNFSM4ICZDB7Q .

@ sc0ttkclark @jimtrue Isso pode ser fechado?

Se movermos a liberação do cache antes de enviar pods_error, podemos resolver o foco principal deste tíquete.

Fixo em # 5459

Desculpe, reação tardia, mas obrigado!

Em 5 de setembro de 2019, às 14:27, Scott Kingsley Clark [email protected] escreveu:

Fechado # 5420 https://github.com/pods-framework/pods/issues/5420 via # 5459 https://github.com/pods-framework/pods/pull/5459 .

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, vê-lo no GitHub https://github.com/pods-framework/pods/issues/5420?email_source=notifications&email_token=AM2NSKBMJPPMDU5DSLKEPWTQID3JNA5CNFSM4ICZDB72YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOTOL3AQY#event-2610409539 , ou silenciar o fio https://github.com/ notificações / unsubscribe-auth / AM2NSKDMLL2WOT3F7ITJ47TQID3JNANCNFSM4ICZDB7Q .