Игорь Воротнёв

Так строчкой выше же: get_queried_object()->name;

У вас при регистрации custom post type стоит 'capability_type' => 'page',. Это генерит capabilities вида "edit_pages", "publish_pages" и тд. А при создании роли вы указали "edit_posts", "publish_posts". Capabilities разные.

И вообще, если уж регистрировать custom post type с мыслью о дальнейшем контроле доступа, то генерите свои произвольные capabilities, в данном примере это будет "'capability_type' => 'estate',", далее назначайте эти capabilities нужным ролям. Почитайте еще про map_meta_cap.

Именно ролями с корректно выставленными capabilities можно контролировать что юзер может делать в админке, а что нет. С помощью remove_menu_page( 'plugins.php' ); вы только убираете ссылку из меню, сама страница остается и она доступна. Зайдя по ее прямому адресу пользователь все равно сможет админить плагины. Огромная дырка тут у вас :) В документации же черным по белому написано:

Please be aware that this would not prevent a user from accessing these screens directly. Removing a menu does not replace the need to filter a user's permissions as appropriate.

Правильный способ закрыть юзеру доступ к определенным фичам - убрать у него соответствующую capability, в случае с плагинами это будет:

- activate_plugins
- delete_plugins
- edit_plugins
- install_plugins
- update_plugins

Полный список ролей и их capabilities есть в документации.

В общем, вам обратно за парту надо. Разобраться в тонкостях roles и capabilities, map_meta_cap и тд. Иначе вы соберете франкенштейна.

Проще простого. Просто фильтруем соответствующие wp_options, говорим движку что обновлений нет. От версии WP вообще никак не зависит.

add_action( 'after_setup_theme', function() {
	add_filter( 'pre_option_update_core', '__return_null' );
	add_filter( 'pre_site_transient_update_core', '__return_null' );
} );

Шаблон: single-{post-type}.php
Conditional tag: is_singular( 'post-type' );

У the_permalink() нету таких функций.

Каких "таких функций"? Эта функция получает объект WP_Post $post и собирает правильную ссылку.

Добавьте в массив $args параметр 'parent' со значением 0 (то есть, комментарии верхнего уровня):

$args = array(
    'number' => 6,
    'orderby' => 'comment_date',
    'order' => 'DESC',
    'status' => 'approve',
    'type' => 'comment',
    'parent' => 0,
);

Родного фильтра в WordPress для таких задач не существует. Можно решить через output buffering. Для этого создайте mu-plugin (он гарантированно будет выполняться до темы), в котором включите буферизацию и зарегистрируйте свой фильтр. Например, файл wp-content/mu-plugins/html_filter.php:

<?php
// Включаем буферизацию.
ob_start();

// Регистриуем свой фильтр на хуке shutdown, он выполняется в конце цикла работы WP, страница на этот момент сгенерирована.
add_action( 'shutdown', function() {
    $html = '';

    // Уровней буферизации может быть больше одного нашего, мы должны взять все:
    while( ob_get_level() ) {
        $html .= ob_get_clean();
    }

    // А теперь пропускаем финальный вывод через свой кастомный фильтр:
    echo apply_filters( 'filter_html', $html );
}, 0);

А теперь можем хукаться в наш фильтр:

add_filter( 'filter_html', function( $output ) {
    return str_replace( 'foo', 'bar', $output );
});

Писал с головы, без тестирования. Могут быть нюансы, но в целом смысл должен быть понятен.

WordPress использует заголовки style.css в строго определенном формате для того, чтобы определить саму тему. Воспринимайте их как конфиг, файл конфигурации и оставьте их в покое. Чем они вам мешают? Несколькими байтами кода?

Ох там и винегрет)) при чем у каждого register_post_type свои приколы, например:
- 'query_var' => 'post_type', - это во втором куске
- $rewrite - в первом нет, во втором есть
- 'exclude_from_search' => true, - вангую, что объекты недвижимости таки должны искаться
- 'capability_type' => 'page', - вангую, что тут редактора с разными ролями могут быть, импорт и тд, а значит capability свои надо генерить а не наследовать от page

- 'taxonomies'  => array( 'estate_type', 'estate_operation', 'estate_district', 'estate_building_type', 'estate_class'),

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

Ну и много такого. Воспользуйтесь GenerateWP -> Post Type Generator и создайте ваши custom post types по одной и той же схеме, как положено. Таксономии можете пересоздать там же. Глядишь, и баги уйдут.

ЗЫ: А вообще если у вас в проекте их много (таксономий и типов записей), то пора переходить на новый уровень - использовать библиотеки.

Авторизованный юзер - это кука у юзера на клиенте и сессия на сервере у вас. При всех запросах браузер автоматически передает куку на сервер, по ней идентифицируется сессия пользователя. Если сессия есть и она валидная, юзер считается авторизованным. Ну и все его данные доступны - ID, роль, permissions и тд. Поскольку при аякс-запросе выполняется не только 1 эта функция-коллбек, а сначала загружается и выполняется ядро WordPress, то функция is_user_logged_in() на момент ее вызова в коллбеке уже работает в нормальном окружении WP, имеет доступ к сессии, данным юзера и тд. Вот и вся магия.

Если вам надо производить такие вычисления, то у вас архитектурно неправильно реализовано. Такие данные нужно хранить не в postmeta, а в отдельной таблице. Структура, грубо (назовем таблицу post_ratings):

id  |  post_id  |  user_id  |  rating
-------------------------------------
1   |  189      |  34       |  4

Именно по этой таблице делаете начальную выборку с просчетом среднего рейтинга и сортировкой, на выходе получаете список post_id. Их потом передаете в WP_Query через параметр post__in.

Как вариант, можно "кешировать" средний, уже просчитанный, рейтинг в таблице postmeta, в виде одного int. Пересчитывать его либо каждый раз при добавлении новой записи в кастомную таблицу (запросом или отправкой в очередь), либо кроном раз в какое-то время.