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

Берите код, который для записей, только там где 'post_type' = > 'post' меняйте на 'post_type' => 'page'.

1. У WP_Query нет и никогда не было аргумента 'hide_empty'. Этот аргумент у таксономий встречается, в WP_Term_Query. Соответственно, его значения true или false никакого эффекта не дадут, он игнорируется. Уберите его.
2. 'meta_key' => 'sort' инструктирует WP_Query в первую очередь выбрать записи, у которых данное мета-поле есть.
Сортировка происходит (условно) после выборки, сортируются те результаты, которые соответствуют условиям выборки, в данном случае это записи у которых мета-поле sort существует.
3. Попробуйте вот так:

$args = [
	'meta_query' => [
		'relation' => 'AND',
		'meta_exists_clause' => [
			'key'     => 'sort',
			'compare' => 'EXISTS',
		],
		'meta_value_clause' => [
			'key'  => 'sort',
			'type' => 'numeric',
		],
	],
	'orderby' => [
		'meta_exists_clause' => 'ASC',
		'meta_value_clause'  => 'DESC',
	],
];

Плагин не плагин, а регистрируется post_status в конечном итоге с помощью функции register_post_status. Как и многие другие функции WP, она принимает ряд аргументов, в том числе такие:

public
(bool) (optional) Whether posts of this status should be shown in the front end of the site.
Default: false

internal
(bool) (optional) Whether the status is for internal use only.
Default: false

private
(bool) (optional) Whether the posts of this status should be accessible by their urls.
Default: false

Эти аргументы определяют, будет ли доступен данный статус на фронтенде и будут ли генерироваться ЧПУ. Скорее всего плагин конфигурирует их как приватные, поэтому они недоступны. Есть 3 варианта (возможных):

1. В самом плагине есть возможность перенастроить эти свойства под себя.
2. Плагин предоставляет фильтр, с помощью которого можно изменить эти аргументы.
3. Менять эти аргументы напрямую в определении статусов, через глобальный доступ (фильтрами тут WordPress, увы, не радует):

function make_archived_status_public()
{
	global $wp_post_statuses;

	// Меняем public на true
	$wp_post_statuses['archived']->public = true;

	// Повторяем для других аргументов, если нужно
	// ...
}
add_action( 'init', 'make_archived_status_public' );

Внимательно читаем документацию:

post_status (string / array) - use post status. Retrieves posts by Post Status. Default value is 'publish', but if the user is logged in, 'private' is added. Public custom statuses are also included by default. And if the query is run in an admin context (administration area or AJAX call), protected statuses are added too. By default protected statuses are 'future', 'draft' and 'pending'.

То есть, значения по умолчанию вам не подходят и необходимо явно указать необходимые статусы. Минимум:

$args = [
    'post_status' => [ 'publish', 'private' ],
];

Или совсем явно:

$args = [
    'post_status' => 'any',
];

ЗЫ: И не делайте 'posts_per_page' => -1,, это плохая практика. Укажите пусть большое (с запасом), но конкретное число. Например 100, 500, 1000.

Технически можно и так, и сяк. Но, как всегда, есть нюансы, на которых и сыпется большинство советчиков (в том числе в этом треде).

Если у вас только сайт на домене, максимум почта на других портах, и даже CDN не используется - можете спокойно использовать основной домен без www. Если у вас сайт многоязычный, и языки размещены на поддоменах - тогда тоже без www. Если же у вас есть и другие ресурсы в домене, например:

www.example.com - публичный сайт
developers.example.com - публичный сайт инструментов для разработчиков
api.example.com - какой-нибудь публичный АПИ
cdn.example.com - поддомен content delivery network (можно много - cdn1, cdn2 итд)
docs.example.com - публичная документация
help.example.com - публичная справка
support.example.com - публичная служба поддержки
dev.example.com - закрытая, непубличная копия сайта, стейджинг
hr.example.com - закрытая, непубличная часть, внутренние ресурсы компании для сотрудников
mail.example.com - технический субдомен для почты
webmail.example.com - веб-морда для почты (может быть как публичной, так и открытой для отдельных IP, доступ по VPN и тд)
vpn.example.com - чисто технический поддомен для проксирования трафика через VPN компании
ns1.example.com - поддомен для своего сервера имен (ns1/ns2/ns3 или primary/secondary и тд)

... и так далее. Таких поддоменов может быть очень много, и у каждого своя, совершенно изолированная кухня. Так вот, если использовать для публичного сайта домен без www, то все его куки будут распространяться на все поддомены. А это плохо. На современном сайте этих кук штук 10 минимум, большая часть из них совершенно не нужна, или даже откровенно лишняя на всех других поддоменах. В это же время, если вы используете www и хотите поделиться куками с него с другим поддоменом - это вполне возможно сделать, осознанно.

Кроме этого - с www намного удобнее работать на уровне DNS, если это CNAME. Записи типа А лучше ставить долгий TTL, а вот CNAME может иметь короткий и его можно перебрасывать в любой момент. Пошла DDoS-атака - в считанные минуты пустили трафик через гейт сервиса защиты от DDoS или выделенный файрвол (у который другие IP-адреса). Или балансировку нагрузки делать. При этом основной домен (origin) и его IP не меняется, почта не слетает, внутренние сервисы не слетают, АПИшки не падают и тд.

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

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

+1 к ответу yarovikov
Вот пример вывода html одной строки таблицы:

<tr id="post-25868" class="iedit author-other level-0 post-25868 type-post status-publish format-standard has-post-thumbnail hentry category-podrostkovye-strizhki category-strizhki">
...
</tr>

Категории добавляются в виде классов category-{term_name}. Соответственно, их можно спокойно стилизовать через CSS. Если же нужно цвета в админке настраивать - используйте метаданные терминов и храните в termmeta значение цвета для каждой категории. Потом на хуке admin_head берите оттуда все цвета и генерируйте стили.

Вы неправильно понимаете суть плагинов в WordPress. Воспринимаете это как что-то плохое, или сложное, или тяжелое, или как-то еще. Все на самом деле просто:

1. WordPress в процессе выполнения подключает кучу файлов - и своих, из ядра, и пользовательских.

2. Любой пользовательский код, где бы он ни находился - в mu-плагине, в обычном плагине, в шаблонах темы, в functions.php или в файле, который подгружается с помощью autoload вообще из другой папки при использовании Composer - абсолютно любой пользовательский файл подключается и выполняется идентично и одинаково. Для PHP и для WordPress это просто код, который надо выполнить.

3. Разница между тем, куда помещать свой пользовательский код только в удобстве и очередности подключения и исполнения этого кода, а также обновления и прочие плюшки. Исходя из этого:

- mu-плагин обычно 1 php-файл, его нельзя отключить в админке, выполняется из пользовательского кода условно первым. Не использует систему обновлений плагинов, поэтому изменения надо заливать вручную. Выполняется до pluggable функций WP, то есть может их переопределять. Используется для разных задач, когда конкретный пользовательский код нужно выполнить ДО обычных плагинов, когда он критичен для работы проекта и его нельзя отключать и тд. При смене темы сайта функциональность из mu-плагина остается.

- обычный плагин - может быть как простым (1 файл), так и любой сложности. Выполняется после mu-плагинов, перед pluggable. Используется для всего остального. Можно выключить из админки, обновить (с WP.org, сайта разработчика и даже со своего репозитория), при смене темы сайта остается.

- functions.php активной темы. Загружается после обеих типов плагинов, сразу перед срабатыванием хука init. При смене темы, разумеется, любая функциональность которая определена в этой файле будет утеряна. Обновляется вместе с темой. Еще стоит помнить про то, что их может быть 2 - родительской темы и дочерней.

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

Для WordPress в целом абсолютно все равно, где будет ваш код. И да, ваша функция / класс будет идентично работать (и по производительности в том числе), не важно где она будет - в functions.php или в плагине. Это будет все та же функция или класс, только в случае с плагином в голове документа будет блок с комментарием, который и определяет, что это плагин. Все. Больше никакой разницы.