Можем ли мы создать php “страницу” без “страницы” WordPress?

Где-то вне главной страницы нам нужно показать контейнерную страницу, которая делает что-то с пользовательскими типами записей. На самом деле не важно, что она делает, главное, что она должна существовать и быть доступной из меню главной страницы.

Мы уже делали это раньше и создали “страницу” WordPress, чтобы она функционировала как контейнерная страница, а затем в теме/бэкенде/PHP создали файл page-xxx.php, где вся работа контейнера происходит и это … вроде как … работает.

Но это значит, что в меню администратора WordPress появляется эта бесполезная “страница”, которую мы должны объяснить клиенту не редактировать, так как “это не настоящая страница, просто заполнител”. В основном, это нормально. Но это не идеально.

Я знаю, что мы можем скрыть страницу-заполнитель от клиента. Но есть ли более элегантное решение?

Можем ли мы создать страницу на PHP с кодом для выполнения конкретной задачи и иметь возможность обращаться к этому коду как к слагу/адресу без фактического существования страницы как страницы в администраторе?

Ну, внутри вашей директории просто оставьте обычный php файл, например my-page.php, а затем создайте красивый URL для него, используя .htaccess. Откройте файл .htaccess (если он присутствует в директории установки) или создайте новый

RewriteEngine On
RewriteRule ^my-page-slug my-page.php

Это должно сработать

обновление

если вы хотите получить доступ к записям WP и другим объектам, вам нужно включить “wp-load.php”, и вы сможете получить доступ к обычному объекту $wpdb или $WP_query. Вот небольшой пример кода

<?php
//path/to/your/wordpress/installation/my-page.php

include_once ("wp-load.php");

$posts = get_posts();
foreach($posts as $post){
    echo $post->post_name;
    echo "<hr/>";
}

Когда мне нужна пользовательская php страница, которая работает с WordPress, я обычно делаю следующее:

1. Я добавляю переменную запроса к переменным, разрешенным WordPress:

   add_filter( 'query_vars', 'myplugin_add_query_var' );
   
   function myplugin_add_query_var( $query_vars ){
      $query_vars[] = 'myplugin_page_name';
   }
   

2. Я добавляю функцию к действию parse_request, которая проверяет, установлена ли ранее объявленная переменная.

    add_action( 'parse_request', 'myplugin_front_controller' );
   
    function myplugin_front_controller( $query ){
       if( array_key_exists( 'myplugin_page_name', $query->query_vars ) ){
         myplugin_dosomething();
         die();
       }
    }
   

3. Я оборачиваю в функцию код, который мог бы написать на php странице

    function myplugin_dosomething(){
        echo 'Hello World';
    }
   

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

Как насчет создания пользовательского шаблона страницы для главной страницы и вставки своих пользовательских запросов и других элементов туда? Вы можете назначить эти шаблоны страниц для всех видов страниц. Используйте что-то вроде front-page.php, home.php или custom.php (Ссылка) Таким образом, у вас будет ваша обычная главная страница в бэкенде, но на фронтенде она будет отображаться с вашими дополнительными модулями. С таким подходом вы могли бы добавить пользовательские поля (например: с ACF) для этого конкретного шаблона страницы тоже.

Редактировать:
Создайте пользовательский шаблон страницы: custom-template.php

<?php
/**
 * Имя шаблона: Пользовательская главная страница
 */

get_header();

    if ( have_posts() ):

        while ( have_posts() ): the_post();

            get_template_part( 'template-parts/content', get_post_type() );

        endwhile;
    endif;

// Добавьте свой пользовательский модуль
get_template_part( 'template-parts/your-custom-stuff' );

get_footer(); 

.. а затем назначьте созданный шаблон (атрибуты страницы) на страницу, которую вы хотите

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

Вы можете создать пользовательский тип записи с помощью функции register_post_type() с false в качестве параметра show_ui, как это.

//код взят из codex
//имя пользовательского типа записи здесь book. Измените имя типа записи и другие параметры по своему усмотрению
//Установите `show_ui` и `show_in_menu` в false
add_action( 'init', 'codex_book_init' );
function codex_book_init() {
$labels = array(
    'name'               => _x( 'Книги', 'Общее имя типа записи', 'your-plugin-textdomain' ),
    'singular_name'      => _x( 'Книга', 'Единичное имя типа записи', 'your-plugin-textdomain' ),
    'menu_name'          => _x( 'Книги', 'админ-меню', 'your-plugin-textdomain' ),
    'name_admin_bar'     => _x( 'Книга', 'добавить новую в админ-меню', 'your-plugin-textdomain' ),
    'add_new'            => _x( 'Добавить новую', 'книга', 'your-plugin-textdomain' ),
    'add_new_item'       => __( 'Добавить новую книгу', 'your-plugin-textdomain' ),
    'new_item'           => __( 'Новая книга', 'your-plugin-textdomain' ),
    'edit_item'          => __( 'Редактировать книгу', 'your-plugin-textdomain' ),
    'view_item'          => __( 'Просмотреть книгу', 'your-plugin-textdomain' ),
    'all_items'          => __( 'Все книги', 'your-plugin-textdomain' ),
    'search_items'       => __( 'Искать книги', 'your-plugin-textdomain' ),
    'parent_item_colon'  => __( 'Родительские книги:', 'your-plugin-textdomain' ),
    'not_found'          => __( 'Книг не найдено.', 'your-plugin-textdomain' ),
    'not_found_in_trash' => __( 'Книг не найдено в Корзине.', 'your-plugin-textdomain' )
);

$args = array(
    'labels'             => $labels,
    'public'             => true,
    'publicly_queryable' => true,
    'show_ui'            => false,
    'show_in_menu'       => false,
    'query_var'          => true,
    'rewrite'            => array( 'slug' => 'book' ),
    'capability_type'    => 'post',
    'has_archive'        => true,
    'hierarchical'       => false,
    'menu_position'      => null,
    'supports'           => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' )
);

register_post_type( 'book', $args );
}

Таким образом, он не будет показан в меню администратора. Но вы все равно сможете использовать его с URL, например example.com/wp-admin/edit.php?post_type=book.

Вы можете создать отдельный шаблон single-book.php, чтобы отображать его так, как вам нравится. Вы также можете создать отдельный файл с id, как вы сделали со страницей.

Если у вас есть группа файлов, которые попадают в одну и ту же категорию, вы можете использовать register_taxonomy() для создания таксономии и использовать разные шаблоны для этих групп страниц.

Я верю, что это отвечает всем вашим требованиям:

• Он не отображается в меню администратора.
• Вы можете использовать все функции WordPress
• Создавать отдельный php код для каждой страницы (или группы страниц, если вам нужно, с пользовательской таксономией)