Добавить возможности загрузки файлов, необходимые для пользовательской роли для не-сообщений

Наконец, мне удалось обновить старый сайт WP 3.3.1 до WP 4.1 с несколькими проблемами, но, похоже, произошло одно неожиданное изменение относительно загрузки файлов.

В версии плагина WP 3.3.1 я включил загрузку для настраиваемой роли с помощью «read» и «upload_files».

ПРИМЕЧАНИЕ. Это относится к содержимому, которое НЕ отправлено по почте. Это просто редактор, который я хочу захватить для некоторых пользовательских таблиц db . В вызове wp_editor явно указано значение ''. Я использую буферизацию, чтобы переместить редактор, который подробно описан на странице https://wordpress.stackexchange.com/a/66345

// capture the editor for later use... // HACK: https://wordpress.stackexchange.com/a/66345 ob_start(); wp_editor( '', 'xyz-note-editor', array( 'textarea_rows' => '10', ) ); $editor = ob_get_clean(); // ... $edit_form_template = str_replace('{{NotesEditor}}', $editor, $edit_form_template); 

После обновления WP 4.1 все работает для редакторов и администраторов .

Это не удается для авторов, авторов и моей собственной роли с ошибкой: «У вас нет разрешения на прикрепление файлов к этому сообщению».

(«Пост» представляется неродственным экземпляром персонализированного типа сообщения, которому присваивается загружаемый носитель, при успешной загрузке в качестве редактора или администратора).

Я не задумываюсь о том, чтобы перестроить вещи или отыскать какой-нибудь плагин (например, члены Justin Tadlock, рекомендованные в другом месте на StackExchange).

Почему редакторы могут обходить ограничения загрузки в этом случае?

Я попытался назначить разрешения для редактирования / публикации / чтения для редакторов (и ниже) для настраиваемой роли без каких-либо успехов – на основе http://codex.wordpress.org/Roles_and_Capabilities .

 add_role( XxYyConfig::USER_ROLE(), 'Custom Data Manager', array( 'read' => true, // ADDED: to address changes in how WordPress "Add Media" works - re: "You don't have permission to attach files to this post." error // NOTE: Custom Data Managers, Contributors and Authors CANNOT add media -- BUT Editors/Administrators can. Trying to add to {custom_post_type} post (for reasons unknown). Content for editor set to ''... 'edit_files' => true, 'edit_others_pages' => true, 'edit_others_posts' => true, 'edit_pages' => true, 'edit_posts' => true, 'edit_private_pages' => true, 'edit_private_posts' => true, 'edit_published_pages' => true, 'edit_published_posts' => true, 'publish_pages' => true, 'publish_posts' => true, 'read_private_pages' => true, 'read_private_posts' => true, // ADDED: END 'upload_files' => true, ) ); 

Я знаю, что я немного в левом поле, но это кажется непоследовательным (даже если что-то давно уже давно «фиксировано»).

map_meta_cap выглядит так, как он может применяться здесь, но никакой пользовательский тип сообщения заставляет меня думать, что это неправильное решение.

В идеале, я хотел бы знать, почему пользовательский тип сообщения помечается во время всего этого, но я придерживаюсь того, какие настройки разрешений / возможностей нужно настроить, чтобы разрешить загрузку через редактор WYSIWYG?

EDIT: поскольку моя роль настроена во время активации плагинов, я был уверен, что деактивирует и повторно активирует плагин, чтобы гарантировать, что там ничего необычного не происходит.

Нашел основную проблему! Хотя другой контекст, чем тот, который вы описали, коренная причина, вероятно, такая же. Я пытался разрешить пользователям настраивать личную страницу и загружать изображение для показа там. Я продолжал получать страшные «У вас нет разрешения на прикрепление файлов к этому сообщению».

Само сообщение приходит от wp_ajax_upload_attachment () в /wp-admin/includes/ajax-actions.php, хотя пользователь работает на первой странице, а не на панели управления, потому что плагин, который я использую (дополнительные пользовательские поля – – рекомендуется!) использует библиотечные программы wordpress (к счастью, он ограничивает доступ к библиотеке). Ошибка возникает, если current_user_can () не дает разрешения. (Вы можете доказать, что сообщение находится в этой подпрограмме, изменив инструкцию сообщения на что-то еще.)

В свою очередь, current_user_can () вызывает $ current_user-> has_cap () для получения текущих возможностей.

has_cap () предлагает хороший фильтр, который мы можем использовать, но он все равно терпел неудачу. Причина заключалась в том, что он сначала вызывает map_meta_cap (), который создает большой массив возможных возможностей для этого экземпляра. Если какая-либо из этих возможных возможностей остается пустой, то has_cap возвращает false.

Это означает, что любой настраиваемый фильтр, который определяется для разрешения, должен проходить через массив и устанавливать все значение true. Мне кажется, что лучшим постоянным решением было бы для WordPress игнорировать любую кепку, которая явно не разрешена или запрещена.

На данный момент, вот примерная функция фильтра, которая работает для меня:

// allow users to add images to their home page function allow_own_attachments( $user_caps, $req_caps, $args, $UserObj ) { if ( empty($args[2]) ) { return $user_caps; // nothing to check } $post = get_post( $args[2] ); // post_id was passed here if ( $post->post_author == $UserObj->ID ) { // this is my post foreach ( (array) $req_caps as $cap ) { if ( empty( $user_caps[ $cap ] ) ) $user_caps[ $cap ] = true; } } $user_caps['edit_post'] = true; // tested by wp_ajax_upload_attachment() return $user_caps; } add_filter( 'user_has_cap', 'allow_own_attachments', 10, 4 );