Posts deaktivieren, nur bestehende Seiten bearbeiten, keine neuen erstellen (create_posts)

Ich versuche, eine Benutzerrolle zu beschränken, um nur existierende Seiten zu bearbeiten, aber keine neuen zu erstellen oder irgendetwas anderes mit Posts zu machen.

Ich habe das gelesen:

Gibt es eine Möglichkeit, nur bestehende Seiten bearbeiten zu können? Wenn nicht, eine gute Möglichkeit, dies zu implementieren? und das dort erwähnte Ticket: https://core.trac.wordpress.org/ticket/16714

Also habe ich eine neue Benutzerrolle mit diesen Berechtigungen erstellt:

  • edit_pages
  • edit_others_pages
  • edit_published_pages
  • read

Dann habe ich Folgendes hinzugefügt:

 function disable_page_creation(){ if( check_user_role('rolename'){ // This checks if the current user belongs to this role get_post_type_object('page')->cap->create_posts = 'do_not_allow'; } } 

Das Problem ist, dass dies nicht nur das Erstellen neuer Seiten verhindert, sondern auch alles andere wie Listenseiten verbietet.

Sobald ich nur edit_posts hinzufüge, edit_posts alles wie erwartet im edit_posts , aber natürlich sind Beiträge jetzt editierbar.

Ist das etwas, was WP in dieser besonderen Kombination nicht kann oder mache ich es einfach falsch? Irgendwelche Hinweise, wo es stecken bleibt?


EDIT: Okay, ich denke, ich bin auf der Suche nach dem Problem. Ich glaube, der Grund dafür ist, dass Posts und Seiten die gleiche Admin-Datei edit.php . Einige weitere Details:

Die globale Variable $pagenow wird auf edit.php gesetzt, edit.php , ob wir einen Beitrag oder eine Seite bearbeiten.

In user_can_access_admin_page () wird diese Prüfung durchgeführt

  if ( isset( $_wp_menu_nopriv[$pagenow] ) ){ 

Da die deaktivierte Nachbearbeitung die edit.php in $_wp_menu_nopriv[$pagenow] , wird auch nach Seiten $_wp_menu_nopriv[$pagenow] .

Ich würde sagen, das ist ein WP-Bug. Kann jemand bestätigen oder hat eine Lösung?

Solutions Collecting From Web of "Posts deaktivieren, nur bestehende Seiten bearbeiten, keine neuen erstellen (create_posts)"

Okay, hier sind wir. Es ist ein Fehler in WordPress selbst .

Ich habe das Problem bereits kurz in meiner Frage erläutert, also schauen Sie es sich an oder schauen Sie sich das oben verlinkte Ticket für weitere Details an.

Bis das Problem richtig getriggers ist, schlage ich diesen schmutzigen, schmutzigen Hack vor. Es basiert auf der Idee, dass, sobald ein anderes Untermenü, das zugänglich ist, hinzugefügt wird, alles wieder gut funktioniert. Also fügen wir vorübergehend einen Dummy-Unterpunkt hinzu, nur um die Prüfung zu überlisten und dann sofort zu entfernen.

 function workaround_issue_22895(){ add_submenu_page( 'edit.php?post_type=page', 'Workaround_Issue_22895', 'Workaround_Issue_22895', 'edit_pages', 'workaround_issue_22895' ); add_filter('add_menu_classes', 'workaround_issue_22895_unset'); } add_action( 'admin_menu' , 'workaround_issue_22895' ); function workaround_issue_22895_unset ($menu){ remove_submenu_page( 'edit.php?post_type=page', 'workaround_issue_22895'); return $menu; } 

Übrigens, habe ich erwähnt, dass dies ein schmutziger, schmutziger Hack ist, den Sie mit Vorsicht behandeln sollten?