Pods: Aktuelles Problem: Reservierte Namen dürfen nicht hinzugefügt werden

Erstellt am 13. Juli 2019  ·  20Kommentare  ·  Quelle: pods-framework/pods

Beschreibe den Fehler
Zum ersten Mal mit Pods. Stolperte in dies (mit Master reproduziert): classes/PodsAPI::save_pod bricht ab, bevor cache_flush_pods aufgerufen wird, wenn beim Speichern neu hinzugefügter Felder Fehler auftritt. Obwohl es den Anschein hat, dass die anderen Felder noch in der Datenbank gespeichert sind, sind sie für den Endbenutzer erst sichtbar, wenn der Cache geleert wurde.

Aktuelle Revisionszeilennummer 2356 :

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

$this->cache_flush_pods( $pod );

(PS Soweit ich das beurteilen kann, scheint es keine Fehlerbehandlung zu geben, wenn Felder nicht gespeichert werden.)

Reproduzieren
Schritte zum Reproduzieren des Verhaltens:

  1. Bearbeiten eines Pods
  2. Fügen Sie ein Feld mit dem Namen 'foobar' hinzu
  3. Fügen Sie ein Feld mit dem Namen 'name' (oder 'post_title' oder dem Namen eines vorhandenen Felds) hinzu.
  4. Pod speichern

Beachten Sie: Keines der neu hinzugefügten Felder wird nach dem Speichern angezeigt

Reproduced Bug Documentation

Alle 20 Kommentare

Issue-Label Bot wendet automatisch das Label Type: Bug mit einer Konfidenz von 0,98 auf dieses Problem an. Bitte markieren Sie diesen Kommentar mit :thumbsup: oder :thumbsdown: um unserem Bot Feedback zu geben!

Links: App-Startseite , Dashboard und Code für diesen Bot.

+1 Habe das gleiche Problem. Beim Festlegen von beibehaltenen Namen wird kein Fehler ausgegeben.

Siehe #4122 Dies sollte auf Feldnamen, Taxonomie, Post-Typen usw. angewendet werden. Jemand sollte KEINEN Feldnamen, Post-Typ oder Taxonomie eingeben können, die auf der RESERVED Names Field List stehen.

Ich habe einen Fehlerbericht Nr. 5440 eingereicht, in dem ich das gleiche Problem mit einem Feld mit der Bezeichnung "Status" hatte. "Status" ist jedoch nicht auf der Liste der reservierten Begriffe von Wordpress. Aus dem oben erwähnten Fall ist 'name' auf dieser Liste, 'foobar' jedoch nicht. Das gleiche gilt für die PHP-Liste der reservierten Wörter.

WordPress-Liste: (https://codex.wordpress.org/Reserved_Terms)
PHP-Liste https://www.php.net/manual/en/reserved.php

Vielleicht stört auch eine andere Liste reservierter Wörter?

@raoulunger Hast du die neueste PR zu reservierten Keywords ausprobiert?

BEARBEITEN: status ist kein für WordPress reserviertes Schlüsselwort, sondern für Pods, da es als eines der Pod-Objektfelder verwendet wird. (wird derzeit noch untersucht)

Hi, ich sehe, du hast die Frage ausgekratzt ;-). Danke für die Untersuchung!

Ja, nach der Untersuchung stellt sich heraus, dass status ein Alias ​​für post_status in Pods ist (zur Verwendung in Magic Tags usw.).
Vollständige Liste der Standardschlüssel und -aliase:

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 Ich denke, dieses Problem kann geschlossen werden, einverstanden?

Ok, das klärt die Dinge in Bezug auf den 'Status' - danke, dass du das herausgefunden hast und für die Liste!

Um das breitere Problem der Verwendung reservierter Wörter (dieses Thema und auch #4122) zu lösen, scheint es einige Optionen zu geben:

  • Code wird so geändert, dass Aliase für IDs tatsächlich verwendet werden können, oder (wenn das nicht machbar ist),
  • eine Warnung wird angezeigt, wenn ein 'verbotenes' Wort verwendet wird, und
  • Irgendwo in der Dokumentation wird auf dieses Phänomen und auf die obige Liste für No-Go-Wörter verwiesen.

Das alles vorzuschlagen fällt mir übrigens leicht, da ich hier nicht wirklich helfen kann - meine Programmierkenntnisse sind viel zu begrenzt, sorry!

Beifall!

ID ist einfach ein reserviertes Schlüsselwort, ich glaube nicht, dass wir das ändern können.
Über die Warnungen, die es derzeit gibt, werden diese jedoch über AJAX (serverseitig) und nicht direkt beim Tippen angezeigt. Ich denke, dies ist etwas, das wir in Zukunft hinzufügen werden, aber nicht als Wartungsversion.
Dokumentation ist immer eine gute Idee. @jimtrue Könnten Sie dafür eine Dokumentseite erstellen, die ich verwenden kann?

Kann nicht geschlossen werden, bis es dokumentiert ist. Irgendwelche anderen dieser 'Aliasnamen', die nicht zum Erstellen als Feld funktionieren würden? dh 'Titel' 'Eltern' usw.?

Das ist alles, was ich bisher finden konnte (abgesehen von den bereits erwähnten WP-Kern-Keywords)

Dies müsste noch gepatcht werden, da wir erklären müssen, WARUM wir das Hinzufügen dieser Felder nicht zulassen. Im Moment geben wir ihnen keine Informationen.

Das ist nicht ganz richtig, AJAX gibt eine Fehlermeldung zurück, aber nur beim Speichern.

Ich habe keinen sichtbaren Fehler erhalten, als ich das Problem duplizierte. Wenn für den Benutzer kein Fehler sichtbar ist, ist dies ein Problem.

Hast du mit der neuesten PR getestet? #5441
Beachten Sie, dass diese reservierten Schlüsselwörter für Feldnamen zulässig sind. Nur nicht für Pods (CPT/Steuer), siehe #5428.

Ich habe auch keine Fehlermeldung erhalten (deshalb die Verwirrung). Ich habe aber nicht mit der neuesten PR getestet, weil ich wirklich keine Ahnung habe, wie das geht (sorry nochmal - ich bin ein ziemlicher Neuling hier).

Am 19. August 2019 um 17:50 Uhr schrieb Jory Hogeveen [email protected] :

Hast du mit der neuesten PR getestet? #5443 https://github.com/pods-framework/pods/pull/5443
Beachten Sie, dass diese reservierten Schlüsselwörter für Feldnamen zulässig sind. Nur nicht für Pods (CPT/Steuer), siehe #5428 https://github.com/pods-framework/pods/pull/5428 .


Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie auf diese E - Mail direkt, sehen sie auf GitHub https://github.com/pods-framework/pods/issues/5420?email_source=notifications&email_token=AM2NSKDD43ZU2JY47LPKRV3QFK6LTA5CNFSM4ICZDB72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4TNDNQ#issuecomment-522637750 , oder schalten Sie den Faden https://github.com/ Benachrichtigungen/unsubscribe-auth/AM2NSKESXEIVUY3PLHRRMW3QFK6LTANCNFSM4ICZDB7Q .

@sc0ttkclark @jimtrue Kann das geschlossen werden?

Wenn wir das Cache-Flushing verschieben, bevor wir den pods_error senden, können wir den Hauptfokus dieses Tickets lösen.

Behoben in #5459

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen