Pods: Actual Issue: Reserved Names should not allow to be added

Issue-Label Bot is automatically applying the label Type: Bug to this issue, with a confidence of 0.98. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

+1 Having the same issue. Setting preserved names doesn't give an error.

See #4122 This should be applied to field names, taxonomy, post-types, etc. Someone should not be able to type ANY field name, post-type or taxonomy that is on the RESERVED Names Field List.

I filed a bug report #5440 where I had the same issue with a field labeled 'status'. However, 'status' is not on Wordpress' Reserved Terms list. From the above mentioned case, 'name' is on that list, but 'foobar' is not. The same is true for the PHP list of reserved words.

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

Perhaps some other list of reserved words is interfering too?

@raoulunger Have you tried the latest PR concerning reserved keywords? #5441

EDIT: status is not a WordPress reserved keyword but it is for Pods since it's used as one of the Pod object fields. (still investigating at the moment)

Hi, I see you scratched the question out ;-). Thanks for investigating!

Yep, after investigation it turns out status is an alias for post_status within Pods (for use in Magic Tags etc.).
Full list of default keys and aliases:

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 I think this issue can be closed, agreed?

Ok, that clarifies matters as far as 'status' is concerned — thanks for figuring this out, and for the list!

To solve the broader issue of using reserved words (this topic, and also #4122) it seems there would be a few options:

• code is changed so that aliases for id's can in fact be used, or (if that's not doable),
• a warning is shown when a 'forbidden' word is used, and
• some reference is made somewhere in the documentation to this phenomenon and to the above list for no-go words.

By the way, it's easy for me to suggest all this of course, as I can't really help here - my coding skills are far too limited, sorry!

Cheers!

ID is simply a reserved keyword, I don't think we can change that.
About the warnings, there are currently shown but this is done through AJAX (server side) and not directly upon typing. I think this is something we will add in the future though but not as a maintenance release.
Documentation is always a good idea. @jimtrue Could you create a doc page for this that I can use?

Can't be closed until it's documented. Any other of those 'aliases' that would not work for creating as a field? ie 'title' 'parent' etc?

This is all I could find so far (apart from the already mentioned WP core keywords)

This would still need to be patched because we have to explain WHY we're not allowing those fields to be added. Right now, we give them no information.

That is not entirely true, AJAX returns an error message, but only upon saving.

I didn't receive any visible error when I duplicated the issue. If there's no error visible to the user, that's a problem.

Did you test with the latest PR? #5441
Keep in mind that these reserved keywords are allowed for field names. Just not for Pods (CPT/Tax), see #5428.

I also did not receive an error message (therefor the confusion). I have not tested with the latest PR though, because I really have no clue how to do that (sorry again - i'm quite a newby here).

On 19 Aug 2019, at 17:50, Jory Hogeveen notifications@github.com wrote:

Did you test with the latest PR? #5443 https://github.com/pods-framework/pods/pull/5443
Keep in mind that these reserved keywords are allowed for fields names. Just not for Pods (CPT/Tax), see #5428 https://github.com/pods-framework/pods/pull/5428.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/pods-framework/pods/issues/5420?email_source=notifications&email_token=AM2NSKDD43ZU2JY47LPKRV3QFK6LTA5CNFSM4ICZDB72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4TNDNQ#issuecomment-522637750, or mute the thread https://github.com/notifications/unsubscribe-auth/AM2NSKESXEIVUY3PLHRRMW3QFK6LTANCNFSM4ICZDB7Q.

@sc0ttkclark @jimtrue Can this be closed?

If we move the cache flushing before sending the pods_error, we can solve this ticket's main focus.

Fixed in #5459

Sorry, late reaction, but thanks!

On 5 Sep 2019, at 14:27, Scott Kingsley Clark notifications@github.com wrote:

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

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/pods-framework/pods/issues/5420?email_source=notifications&email_token=AM2NSKBMJPPMDU5DSLKEPWTQID3JNA5CNFSM4ICZDB72YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOTOL3AQY#event-2610409539, or mute the thread https://github.com/notifications/unsubscribe-auth/AM2NSKDMLL2WOT3F7ITJ47TQID3JNANCNFSM4ICZDB7Q.