it-swarm.com.de

Beiträge deaktivieren, nur vorhandene Seiten bearbeiten, keine neuen erstellen (create_posts)

Ich versuche, eine Benutzerrolle so einzuschränken, dass nur vorhandene Seiten bearbeitet werden können, aber keine neuen erstellt werden können oder mit Beiträgen etwas Ähnliches gemacht wird.

Ich habe folgendes gelesen:

Gibt es eine vorhandene Fähigkeit, die Bearbeitung von nur vorhandenen Seiten zu ermöglichen? Wenn nicht, ein guter Weg, dies umzusetzen? und das dort erwähnte Ticket: https://core.trac.wordpress.org/ticket/16714

Deshalb habe ich eine neue Benutzerrolle mit den folgenden 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 dadurch nicht nur die Erstellung neuer Seiten deaktiviert wird, sondern auch alles andere wie das Auflisten von Seiten verboten wird.

Sobald ich nur edit_posts hinzufüge, funktioniert alles wie erwartet im Seitenbereich, aber natürlich können Beiträge jetzt bearbeitet werden.

Ist dies etwas, zu dem WP in dieser bestimmten Kombination einfach nicht in der Lage ist, oder mache ich es einfach falsch? Irgendwelche Hinweise, wo es stecken bleibt?


EDIT: Okay, ich glaube, ich spüre das Problem auf. Ich glaube, der Grund dafür ist, dass Posts und Seiten dieselbe Verwaltungsdatei edit.php haben. Einige weitere Details:

Die globale Variable $pagenow wird auf edit.php gesetzt, unabhängig davon, 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] ) ){

Wie die deaktivierte Nachbearbeitung edit.phpin $_wp_menu_nopriv[$pagenow] setzt, ist dies auch für Seiten nicht mehr möglich.

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

4
kraftner

Okay, los geht's. Es ist ein Fehler in WordPress selbst .

Ich habe das Problem bereits in Kürze in meiner Frage erläutert, schauen Sie es sich also an oder sehen Sie sich das oben verlinkte Ticket an, um weitere Einzelheiten zu erfahren.

Bis das Problem richtig gelöst ist, schlage ich diesen schmutzigen, schmutzigen Hack vor. Es basiert auf der Idee, dass alles wieder funktioniert, sobald ein anderes Untermenü hinzugefügt wird, auf das zugegriffen werden kann. Deshalb fügen wir vorübergehend ein Dummy-Untermenüelement hinzu, um die Prüfung zu täuschen, und entfernen es dann sofort.

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 schon erwähnt, dass dies ein schmutziger, schmutziger Hack ist, mit dem Sie vorsichtig umgehen sollten?

9
kraftner