Создание плагина с легкими мультимедийными тегами с пользовательской таксономией

Мы используем Media-теги ( http://wordpress.org/plugins/media-tags/ ) на некоторое время, особенно для функций управления мультимедийными данными панели управления, а не для любых функций дисплея переднего конца. Он практически не поддерживается нигде, и поскольку WP 3.5 – это просто огромное количество накладных расходов для чего-то, что должно быть достигнуто с помощью немного большей, чем обычная таксономия.

При попытке создать рабочий минимальный плагин Media Tags я использовал этот вопрос ( как использовать таксономии вложений с новой медиабиблиотекой? ) В качестве основного руководства, но он страдает, по крайней мере, двумя проблемами, которые возникают у меня решения проблем.

1) Когда вы просматриваете теги на панели управления, я всегда получаю подсчет 0, даже если есть четкие элементы, помеченные указанным тегом (и нажатие на 0 даже приведет вас к ним). Я попробовал обновить значение update_count_callback до '_update_generic_term_count' по другому вопросу, к которому я привязался, но он не дает мне ничего, кроме 0.

EDIT: мои подсчеты были отключены из-за не этого кода, а ранее существовавших записей в базе данных из предыдущего кода.

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

Вот код, который я сейчас пытаюсь, но столкнувшись с двумя проблемами выше:

// Register Custom Taxonomy function cets_media_tags_init() { $labels = array( 'name' => _x( 'Media Tags', 'Taxonomy General Name', 'text_domain' ), 'singular_name' => _x( 'Media Tag', 'Taxonomy Singular Name', 'text_domain' ), 'menu_name' => __( 'Media Tags', 'text_domain' ), 'all_items' => __( 'All Media Tags', 'text_domain' ), 'parent_item' => __( 'Parent Media Tag', 'text_domain' ), 'parent_item_colon' => __( 'Parent Media Tag:', 'text_domain' ), 'new_item_name' => __( 'New Media Tag', 'text_domain' ), 'add_new_item' => __( 'Add New Media Tag', 'text_domain' ), 'edit_item' => __( 'Edit Media Tag', 'text_domain' ), 'update_item' => __( 'Update Media Tag', 'text_domain' ), 'separate_items_with_commas' => __( 'Separate Media Tags with commas', 'text_domain' ), 'search_items' => __( 'Search Media Tags', 'text_domain' ), 'add_or_remove_items' => __( 'Add or remove Media Tags', 'text_domain' ), 'choose_from_most_used' => __( 'Choose from the most used Media Tags', 'text_domain' ), ); $args = array( 'labels' => $labels, 'hierarchical' => false, 'public' => true, 'show_ui' => true, 'show_admin_column' => true, 'show_in_nav_menus' => false, 'show_tagcloud' => false, 'update_count_callback' => '_update_generic_term_count', 'query_var' => false, 'rewrite' => false, ); register_taxonomy( 'media-tags', 'attachment', $args ); } // Hook into the 'init' action add_action( 'init', 'cets_media_tags_init', 0 ); 

Solutions Collecting From Web of "Создание плагина с легкими мультимедийными тегами с пользовательской таксономией"

К сожалению, я не нашел недостатки в вашем коде, насколько это возможно. Скопируйте и вставьте мой для сравнения (вставьте его в плагин, который вы можете легко отключить). Это работает как шарм, при правильном обновлении всех показателей:

 class ZGAttachmentTags { const SLUG = 'attachment-tags'; function __construct() { add_action( 'init', array( $this, 'register_custom_taxonomy' ) ); } function register_custom_taxonomy() { register_taxonomy( self::SLUG, array( 'attachment' ), array( 'label' => __( 'Media Tags' ), 'labels' => array( 'name'=> __( 'Media Tags' ), 'singular_name'=> __( 'Media Tags' ) ), 'hierarchical' => false, 'update_count_callback' => '_update_generic_term_count' ) ); } } $zg_attachment_tags_plugin = new ZGAttachmentTags(); 

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

Что касается ссылки «Просмотр» – по умолчанию запросы архива системы таксономии включают только сообщения, статус которых является общедоступным (обычно «публиковать» и «закрывать» – если ваш пользователь вошел в систему). Вложения не публикуются – они получили статус «наследовать». Затем решение должно изменить либо запрос, либо запрос, чтобы включить сообщения со статусом «inherit».

Самый простой способ сделать это – использовать фильтр parse_query , который запускается после того, как все вазы запросов были проанализированы в основном объекте query и непосредственно перед get_posts() метода get_posts() который в конечном итоге генерирует запрос SQL. Вы делаете это так:

 add_filter( 'parse_query', 'parse_query__attachment_status' ); function parse_query__attachment_status( $query_obj ){ // Make sure we don't contaminate any other queries... if ( $query_obj->query['attachment-tags'] ){ $statuses = get_post_stati( array( 'public' => true ) ) ; $statuses['inherit'] = 'inherit'; // push 'inherit' status onto the list $query_obj->set( 'post_status', array_keys( $statuses ) ); } return $query_obj; } 

Обратите внимание, что для простоты я включил этот пример, как если бы это был отдельный фрагмент кода в вашем functions.php например. Но вы могли (и должны) катить его в свой класс и, следовательно, использовать константу класса для таксономии slug ( self::SLUG ). Также не забудьте изменить свой add_filter() чтобы использовать форму массива.

Единственная проблема с этим подходом (на мой взгляд, это не проблема) заключается в том, что WordPress автоматически выполняет некоторые функции, когда обнаруживает, что вы запрашиваете вложение. Он добавит JOIN в wp_posts для запроса родительского сообщения и добавит предложение в WHERE , которое проверяет post_status родителя, а также статус ребенка.

Это означает, что вы можете получить некоторое дублирование, если на самом деле некоторые элементы мультимедиа были включены в сообщения. Один из способов избежать этого – жестко закодировать статус как «наследовать» (а не использовать подход get_post_stati() который я использовал, прежде всего потому, что я восхищаюсь использованием латинского множественного числа в имени функции.).

Другая вещь, которую вы могли бы сделать, если вы parse_query сердцем, избегает фильтра parse_query в пользу фильтра posts_clauses и переписывает posts_clauses WHERE и JOIN . Это потребовало бы немного творческого поиска и замены, и для меня это казалось слишком сложным для этого ответа, хотя это, несомненно, самый правильный путь и самый надежный в будущем.