Видаліть слиз із користувацьких URL-адрес типу публікації


48

Здається, що всі веб-ресурси засновані на темі видалення користувацького типу публікації, тобто

yourdomain.com/CPT-SLUG/post-name 

зараз дуже застарілі рішення, які часто посилаються на встановлення до WP версії 3.5. Спільним є:

'rewrite'   => array( 'slug' => false, 'with_front' => false ),  

у межах функції register_post_type. Це більше не працює і вводить в оману. Тож я прошу спільноту у ІІІ кварталі 2018 року на межі WordPress 5 ...

Які сучасні та ефективні способи видалити службового типу "Публік" з URL-адреси публікації користувальницького типу повідомлення з аргументу перезапису чи деінде?

ОНОВЛЕННЯ: Здається, існує кілька способів змусити це працювати з регулярними виразами. Зокрема, відповідь Яна Бека, якщо ви будете послідовно готові контролювати створення контенту, щоб не створювати конфліктні імена сторінок / публікацій .... Однак я переконаний, що це головна слабкість в ядрі WP, де з нами слід працювати. . Як опція / гачок при створенні CPT, так і вдосконаленого набору опцій для постійних посилань. Будь ласка, підтримайте заліковий квиток

Зноска: Будь ласка, підтримайте цей квиток на проїзд, переглядаючи / просуваючи його: https://core.trac.wordpress.org/ticket/34136#ticket


Я думаю, я чухаю голову, чому ти хотів би це зробити? Плутати.
Майкл Еклунд

3
@MichaelEcklund, оскільки будь-яка CPT, яка використовується для створення загальнодоступних веб-сторінок, має в URL-адресі вимушене ім’я. Насправді багато WP-розробників прагнуть безпечно видалити слимака.
Бен Рачикот

Відповіді:


60

Наступний код буде спрацьовувати, але ви просто повинні мати на увазі, що конфлікти можуть траплятися легко, якщо слуга для вашого користувальницького типу публікації збігається зі сторінкою або публікацією публікації ...

По-перше, ми видалимо слима з постійної посилання:

function na_remove_slug( $post_link, $post, $leavename ) {

    if ( 'events' != $post->post_type || 'publish' != $post->post_status ) {
        return $post_link;
    }

    $post_link = str_replace( '/' . $post->post_type . '/', '/', $post_link );

    return $post_link;
}
add_filter( 'post_type_link', 'na_remove_slug', 10, 3 );

Просто видалити слизу недостатньо. Зараз ви отримаєте сторінку 404, оскільки WordPress очікує, що повідомлення та сторінки будуть вести себе таким чином. Вам також потрібно буде додати наступне:

function na_parse_request( $query ) {

    if ( ! $query->is_main_query() || 2 != count( $query->query ) || ! isset( $query->query['page'] ) ) {
        return;
    }

    if ( ! empty( $query->query['name'] ) ) {
        $query->set( 'post_type', array( 'post', 'events', 'page' ) );
    }
}
add_action( 'pre_get_posts', 'na_parse_request' );

Просто змініть "події" на свій спеціальний тип публікації, і ви готові йти. Можливо, вам доведеться оновити постійні посилання.


Дякую. Як ви вважаєте, це краще, ніж створювати переписування вручну? Я бачив це рішення, і це може тримати конфлікти, про які ви згадуєте, у страху?
Бен Рачикот

1
Він не вдається з nginx, тому що умова 2 != count( $query->query ). За допомогою nginx ви можете мати $ query-> query як array('page' => '', 'name' => '...', 'q' => '...'). Отже, @NateAllen, в чому сенс цієї умови?
Фабіо Монтефусколо

3
Нам потрібно щось краще, ніж це. Підтримка видалення вбудованої слизи, щоб згодом ми не могли створювати конфліктуючі URL-адреси. Те, як регулярні публікації та сторінки створюють свої URL-адреси.
Бен Рачикот

3
Це тільки я або це порушує деякі умовні теги wordpress, такі як is_single () та is_singular ()?
rob-gordon

1
Це рішення, на жаль, спричинило поломку посилань, і мій блог перестав показувати публікації і був просто звичайною сторінкою. Дивіться краще рішення Метта Кіза нижче.
Radley Sustaire

20

Запишіть наступний код у реєстрацію таксономії.

'rewrite' => [
  'slug' => '/',
  'with_front' => false
]

Найголовніше, що вам потрібно зробити після зміни коду

Після того, як ви змінили свій спеціальний документ з системою таксономії, спробуйте перейти в Налаштування> Постійні посилання та збережіть свої налаштування , інакше ви отримаєте 404 сторінки не знайдені.

Ознайомтеся з найкращим рішенням: http://www.krazzycodes.com/how-to-remove-custom-post-type-taxonomy-base-from-url-in-wordpress/


Це насправді працює, я не знаю, як ніхто раніше цього не помічав. Звичайно, це може заважати іншим сторінкам, якщо вони мають таку ж постійну посилання, але якщо ні, то це чудове рішення.
Олександр Джорджевич

4
Спробував це. Це дає бажаний результат для моїх користувацьких посилань типу публікації. Однак він 'ловить' всі поштові журнали типу POST або PAGE і намагається вирішити їх як URL-адресу для мого користувальницького типу публікації, а потім 404. (так, я зберегла постійні посилання).
Метс Кіс

4
Це не працює. Дає 404, навіть коли ви оновлювали постійні посилання.
Крістін Купер

3
Знову навіть після повторного збереження налаштувань постійної посилання, публікації та сторінки більше не працюють (404)
amklose

1
Це рішення працює для видалення слизи з URL. Але сторінки архіву вже не працюють.
Аннапурна

13

Я намагався розібратися в цьому недавно, і коротка відповідь з того, що я знаю, - ні . Принаймні, не з аргументу переписати.

Довге пояснення стає очевидним, якщо ви подивитесь на фактичний код register_post_typeу рядку wp-include / post.php 1454 :

add_permastruct( $post_type, "{$args->rewrite['slug']}/%$post_type%", $permastruct_args );

Ви можете побачити його префікси $args->rewrite['slug']до %$post_type%тегу переписати. Можна подумати, "давайте просто встановимо слизьку на nullпотім", поки ви не подивитеся на кілька рядків вгору:

if ( empty( $args->rewrite['slug'] ) )
    $args->rewrite['slug'] = $post_type;

Ви можете бачити, що функція завжди очікує значення "pug", яке не є порожнім і в іншому випадку використовує тип публікації.


Дякую @JanBeck Чи є основна причина цього існування? Чому б не зламати цей основний файл з умовою пропускати певні типи публікацій з цього правила?
Бен Рачикот

9
Ви повинні нагородити відповідь Яна Бека. WordPress потребує слупку post_type для належного маршрутування запитів. Це правило запобігає називанню конфліктів між нативними WP-сторінками (які відображаються без слизи) та будь-якими визначеними на замовлення типами публікацій. Якщо ви зламаєте слизьку, то WordPress не дізнається різниці між сторінкою, що називається "пікнік", та подією (тип користувальницької пошти) під назвою "пікнік".
dswebsme

3
@dswebsme Погоджено, але є ситуації, коли ви абсолютно повинні змінити URL-адресу. Отже, окрім того, чому ви не можете вдома і не повинні, як це зробити так ефективно?
Бен Рачикот

7

У відповідь на мою попередню відповідь : ви, звичайно, можете встановити rewriteпараметр під falseчас реєстрації нового типу публікації та самостійно обробляти правила перезапису.

<?php
function wpsx203951_custom_init() {

    $post_type = 'event';
    $args = (object) array(
        'public'      => true,
        'label'       => 'Events',
        'rewrite'     => false, // always set this to false
        'has_archive' => true
    );
    register_post_type( $post_type, $args );

    // these are your actual rewrite arguments
    $args->rewrite = array(
        'slug' => 'calendar'
    );

    // everything what follows is from the register_post_type function
    if ( is_admin() || '' != get_option( 'permalink_structure' ) ) {

        if ( ! is_array( $args->rewrite ) )
            $args->rewrite = array();
        if ( empty( $args->rewrite['slug'] ) )
            $args->rewrite['slug'] = $post_type;
        if ( ! isset( $args->rewrite['with_front'] ) )
            $args->rewrite['with_front'] = true;
        if ( ! isset( $args->rewrite['pages'] ) )
            $args->rewrite['pages'] = true;
        if ( ! isset( $args->rewrite['feeds'] ) || ! $args->has_archive )
            $args->rewrite['feeds'] = (bool) $args->has_archive;
        if ( ! isset( $args->rewrite['ep_mask'] ) ) {
            if ( isset( $args->permalink_epmask ) )
                $args->rewrite['ep_mask'] = $args->permalink_epmask;
            else
                $args->rewrite['ep_mask'] = EP_PERMALINK;
        }

        if ( $args->hierarchical )
            add_rewrite_tag( "%$post_type%", '(.+?)', $args->query_var ? "{$args->query_var}=" : "post_type=$post_type&pagename=" );
        else
            add_rewrite_tag( "%$post_type%", '([^/]+)', $args->query_var ? "{$args->query_var}=" : "post_type=$post_type&name=" );

        if ( $args->has_archive ) {
            $archive_slug = $args->has_archive === true ? $args->rewrite['slug'] : $args->has_archive;
            if ( $args->rewrite['with_front'] )
                $archive_slug = substr( $wp_rewrite->front, 1 ) . $archive_slug;
            else
                $archive_slug = $wp_rewrite->root . $archive_slug;

            add_rewrite_rule( "{$archive_slug}/?$", "index.php?post_type=$post_type", 'top' );
            if ( $args->rewrite['feeds'] && $wp_rewrite->feeds ) {
                $feeds = '(' . trim( implode( '|', $wp_rewrite->feeds ) ) . ')';
                add_rewrite_rule( "{$archive_slug}/feed/$feeds/?$", "index.php?post_type=$post_type" . '&feed=$matches[1]', 'top' );
                add_rewrite_rule( "{$archive_slug}/$feeds/?$", "index.php?post_type=$post_type" . '&feed=$matches[1]', 'top' );
            }
            if ( $args->rewrite['pages'] )
                add_rewrite_rule( "{$archive_slug}/{$wp_rewrite->pagination_base}/([0-9]{1,})/?$", "index.php?post_type=$post_type" . '&paged=$matches[1]', 'top' );
        }

        $permastruct_args = $args->rewrite;
        $permastruct_args['feed'] = $permastruct_args['feeds'];
        add_permastruct( $post_type, "%$post_type%", $permastruct_args );
    }
}
add_action( 'init', 'wpsx203951_custom_init' );

Ви можете бачити, що add_permastructдзвінок зараз більше не включає слизу. Я перевірив два сценарії:

  1. Коли я створив сторінку зі службовим «календарем», ця сторінка буде перезаписана архівом типу публікацій, який також використовує «календар».

введіть тут опис зображення

  1. Коли я створив сторінку зі слизом "моя подія" та подією (СРТ) зі слизом "моя подія", відображається користувацький тип публікації.

введіть тут опис зображення

  1. Будь-які інші сторінки також не працюють. Якщо ви подивитесь на малюнок вище, стає зрозуміло, чому: спеціальне правило типу публікації завжди буде відповідати сторінці. Оскільки у WordPress немає можливості ідентифікувати, чи це сторінка або нестандартний тип публікації, який не існує, він повернеться 404. Ось чому вам потрібна слуга для ідентифікації сторінки або CPT. Можливим рішенням було б перехоплення помилки та пошук сторінки, яка може існувати аналогічно цій відповіді .

Отже, якщо мета - видалити слизьку для CPT, чи не змогли ми назвати CPT чимось унікальним, яке не зіткнеться, оскільки воно ніколи не буде помічено в URL-адресі? Або пост-ім'я можливий конфлікт, якщо його названо таким же, як сторінка?
Бен Рачикот

Я оновив свою відповідь, щоб показати, що це насправді порушує всі сторінки. Без слизи WP шукатиме CPT замість сторінки, і якщо вона не знайде її, поверне помилку. Тож насправді це не пов’язано з посадою.
Ян Бек

1
Я бачу. Повинні бути переписані правила, які додають "-1" до майбутніх конфліктуючих URL-адрес, як-от рідні WP-повідомлення проти сторінок. Я створив билетний квиток на core.trac.wordpress.org/ticket/34136#ticket дуже сподобався б вашим думкам.
Бен Рачикот

7

Переглядаючи відповіді тут, я думаю, що є місце для кращого рішення, яке поєднує в собі деякі речі, про які я дізнався вище, і додає автоматичне виявлення та запобігання повторюваних дублівок.

ПРИМІТКА. Переконайтеся, що ви змінюєте "custom_post_type" для власного імені CPT у моєму прикладі нижче. Існує багато подій, і "знайти / замінити" - це простий спосіб зловити їх усіх. Весь цей код може знаходитись у вашому function.php або у плагіні.

Крок 1: Вимкніть перезаписи у вашому користувальницькому типі публікації, встановивши параметри перезаписів на "помилкові" під час реєстрації публікації:

register_post_type( 'custom_post_type',
    array(
        'rewrite' => false
    )
);

Крок 2: Додайте власні переписування вручну до нижньої частини перезаписів WordPress для нашого custom_post_type

function custom_post_type_rewrites() {
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/?$', 'index.php?attachment=$matches[1]', 'bottom');
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/trackback/?$', 'index.php?attachment=$matches[1]&tb=1', 'bottom');
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$', 'index.php?attachment=$matches[1]&feed=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$', 'index.php?attachment=$matches[1]&feed=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/comment-page-([0-9]{1,})/?$', 'index.php?attachment=$matches[1]&cpage=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/embed/?$', 'index.php?attachment=$matches[1]&embed=true', 'bottom');
    add_rewrite_rule( '([^/]+)/embed/?$', 'index.php?custom_post_type=$matches[1]&embed=true', 'bottom');
    add_rewrite_rule( '([^/]+)/trackback/?$', 'index.php?custom_post_type=$matches[1]&tb=1', 'bottom');
    add_rewrite_rule( '([^/]+)/page/?([0-9]{1,})/?$', 'index.php?custom_post_type=$matches[1]&paged=$matches[2]', 'bottom');
    add_rewrite_rule( '([^/]+)/comment-page-([0-9]{1,})/?$', 'index.php?custom_post_type=$matches[1]&cpage=$matches[2]', 'bottom');
    add_rewrite_rule( '([^/]+)(?:/([0-9]+))?/?$', 'index.php?custom_post_type=$matches[1]', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/?$', 'index.php?attachment=$matches[1]', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/trackback/?$', 'index.php?attachment=$matches[1]&tb=1', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$', 'index.php?attachment=$matches[1]&feed=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/(feed|rdf|rss|rss2|atom)/?$', 'index.php?attachment=$matches[1]&feed=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/comment-page-([0-9]{1,})/?$', 'index.php?attachment=$matches[1]&cpage=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/embed/?$', 'index.php?attachment=$matches[1]&embed=true', 'bottom');
}
add_action( 'init', 'custom_post_type_rewrites' );

ПРИМІТКА. Залежно від ваших потреб, ви можете змінити вищезазначені переписування (відключити зворотні канали? Канали? Тощо). Вони представляють типи "перезаписів" за замовчуванням, які були б створені, якби ви не відключили переписування на кроці 1

Крок 3: Зробіть знову посилання на свій власний тип публікації "досить"

function custom_post_type_permalinks( $post_link, $post, $leavename ) {
    if ( isset( $post->post_type ) && 'custom_post_type' == $post->post_type ) {
        $post_link = home_url( $post->post_name );
    }

    return $post_link;
}
add_filter( 'post_type_link', 'custom_post_type_permalinks', 10, 3 );

ПРИМІТКА. Ви можете зупинитися тут, якщо ви не турбуєтесь про те, щоб ваші користувачі створили конфліктну (дублюючу) публікацію іншого типу публікації, що створить ситуацію, коли лише один з них може завантажуватися, коли запит на сторінку.

Крок 4: Запобігання повторення дублікатів публікацій

function prevent_slug_duplicates( $slug, $post_ID, $post_status, $post_type, $post_parent, $original_slug ) {
    $check_post_types = array(
        'post',
        'page',
        'custom_post_type'
    );

    if ( ! in_array( $post_type, $check_post_types ) ) {
        return $slug;
    }

    if ( 'custom_post_type' == $post_type ) {
        // Saving a custom_post_type post, check for duplicates in POST or PAGE post types
        $post_match = get_page_by_path( $slug, 'OBJECT', 'post' );
        $page_match = get_page_by_path( $slug, 'OBJECT', 'page' );

        if ( $post_match || $page_match ) {
            $slug .= '-duplicate';
        }
    } else {
        // Saving a POST or PAGE, check for duplicates in custom_post_type post type
        $custom_post_type_match = get_page_by_path( $slug, 'OBJECT', 'custom_post_type' );

        if ( $custom_post_type_match ) {
            $slug .= '-duplicate';
        }
    }

    return $slug;
}
add_filter( 'wp_unique_post_slug', 'prevent_slug_duplicates', 10, 6 );

ПРИМІТКА. Це додасть рядок "-duplicate" до кінця будь-яких дублікатів. Цей код не може запобігти повторенню дублівок, якщо вони вже існують до впровадження цього рішення. Не забудьте спочатку перевірити наявність дублікатів.

Мені б хотілося почути відгук у будь-кого іншого, хто ходить, щоб переконатися, чи добре це спрацювало і для них.


Тільки тестував це, і здається, він працює досі.
Крістін Купер

Сподівався на такий підхід, але дає мені 404 в моїх публікаціях CPT, навіть після відновлення Постійних посилань.
Гарконіс

Вибачте, це не спрацювало для вас Гарконіс. Я з цим часом спілкувався з кимось іншим, і вони також мали проблеми з цим на своєму сайті. Я, мабуть, пам’ятаю, що це мало значення, якщо посилання на ваші блоги постійні посилання мають на них префікс. На сайті, що я розробив це для публікацій блогу, використовується структура постійної посилання: / blog /% postname% /. Якщо у ваших публікаціях блогу немає префікса, і це прийнятно, ви це зробите, спробуйте його і дайте мені знати, як це відбувається!
Метт Кіс

2
Це працювало для мене. На відміну від інших рішень на сторінці, він не порушував звичайні сторінки або макет блогу і не викликав нескінченних переспрямувань. Він навіть показує правильну URL-адресу в області "Постійне посилання" під час редагування цих сторінок cpt. Тут досить вдале рішення, лише застереження полягає в тому, що сторінка архіву не працює. ЗАБУДУЙТЕ, щоб поміняти "custom_post_type" та оновити постійні посилання після цього .
Radley Sustaire

@MattKeys, налаштування Постійної посилання за замовчуванням мають спеціальну структуру /%category%/%postname%/. Коли ви додаєте свій код, CPT виглядає добре (хоч і не вистачає косої риски) ... і програма перевірки конфліктів теж працює. Але фактичні результати на 404
Гарконіс

1

Вам не потрібно стільки жорсткого коду. Просто використовуйте легкий плагін:

У ньому є налаштовані параметри.


Тепер я знаю, чому ви звернули увагу на це, це не дозволяє нормальному вирішенню посилань на сторінку. Я не бачив цього, тому що я отримував кешовані копії існуючих сторінок, незважаючи на оновлення.
Вальф

@Walf Чи можете ви детально розповісти про цю проблему?
Т.Тодуа

Перейшовши за посиланнями на сторінки (які не були типовим типом публікації) з головного меню, було 404 помилки, як ніби сторінки не існувало; Це воно.
Вальф

@Walf, ви можете надати мені будь-який приклад URL-адреси вашого випадку? (ви можете прикрити доменне ім'я, якщо хочете, мені просто потрібен приклад) дякую, я
оновлю

1

Тут були ті самі проблеми, і, здається, немає руху на сайті wordpress. У моїй конкретній ситуації, коли для одиничних блогових постів потрібна така структура / blog /% postname% /

https://kellenmace.com/remove-custom-post-type-slug-from-permalinks/

закінчилася купою 404-х

Але разом з цим чудовим підходом, який не використовує бекенд-структури постійної посилання для блогу, він, нарешті, працює як шарм. https://www.bobz.co/add-blog-prefix-permalink-structure-blog-posts/

Дякую купу.


0

і ми можемо внести деякі зміни до вищезгаданої функції:

function na_parse_request( $query ) {

if ( ! $query->is_main_query() || 2 != count( $query->query ) || ! isset( $query->query['page'] ) ) {
    return;
}

if ( ! empty( $query->query['name'] ) ) {
    $query->set( 'post_type', array( 'post', 'events', 'page' ) );
}
}

до:

function na_parse_request( $query ) {

if ( ! $query->is_main_query() || 2 != count( $query->query ) || ! isset( $query->query['page'] ) ) {
    return;
}

if ( ! empty( $query->query['name'] ) ) {

    global $wpdb;
    $pt = $wpdb->get_var(
        "SELECT post_type FROM `{$wpdb->posts}` " .
        "WHERE post_name = '{$query->query['name']}'"
    );
    $query->set( 'post_type', $pt );
}
}

щоб встановити правильне значення post_type.



0

Для тих, хто читав це, що мав проблеми з дочірніми повідомленнями, як я, я знайшов найкращий спосіб - додати свої власні правила переписування.

Основне питання, яке у мене виникло, полягало в тому, що WordPress розглядає переспрямування зі сторінок, які мають 2 рівні (дочірні дописи) глибокі трохи інакше, ніж це стосується 3 рівня глибокого (дочірнє дочірнє повідомлення).

Це означає, що коли у мене є / post-type / post-name / post-child / я можу використовувати / post-name / post-child, і він перенаправить мене на той, який має пост-тип спереду, але якщо у мене є пост-тип / post-name / post-child / post-правнук, тоді я не можу використовувати post-name / post-child / post-grandnuck.

Переглядаючи правила перезапису, схоже, що це відповідає речам, відмінним від назви сторінки на першому та другому рівнях (я думаю, що другий рівень відповідає вкладеним файлам), а потім робить щось, щоб перенаправити вас на потрібну посаду. На глибині трьох рівнів це не працює.

Перше, що вам потрібно зробити, - це також видалити посилання типу публікації від дітей. Ця логіка повинна відбутися тут, якщо ви подивитесь на відповідь Нейт Аллена:

$post_link = str_replace( '/' . $post->post_type . '/', '/', $post_link );

Сам я використав суміш різних умов, щоб перевірити, чи є у допису дітей та чого іншого, щоб дістатись до потрібної постійної посилання. Ця частина не надто складна, і ви знайдете приклади людей, які роблять це деінде.

Наступним кроком є ​​те, де все змінюється від даної відповіді. Замість того, щоб додавати речі до основного запиту (який працював для користувацьких публікацій та їхніх дітей, але не для подальших дітей), я додав перезапис, який перейшов до нижньої частини правил WordPress, щоб, якщо ім’я сторінки не перевірялося, і це було натисніть 404, він зробив би останню перевірку, щоб побачити, чи одна сторінка у користувацькому типі публікації має таку саму назву, інакше вона викине 404.

Ось правило перезапису, яке я використовував, припускаючи, що "подія" - це назва вашої CPT

function rewrite_rules_for_removing_post_type_slug()
{
    add_rewrite_rule(
        '(.?.+?)?(:/([0-9]+))?/?$',
        'index.php?event=$matches[1]/$matches[2]&post_type=event',
        'bottom'
    );
}

add_action('init', 'rewrite_rules_for_removing_post_type_slug', 1, 1);

Сподіваюсь, це допомагає комусь іншому, я не міг знайти нічого іншого, що стосувалося б дочірніх дописів та видалення сливи з них.


Здається, що в регексе є помилка друку. Між '(:' a '?' Потрібен, щоб використовувати його як підхоплюючий субпатерн => '(?:'. Третій? Здається неправильним, оскільки він дозволяє порожній перший підпакет. Імовірно, він повинен бути розміщений між (і:. без цього помилки вираз буде таким же , як той , який можна знайти на пості типу «сторінку» в збірках.
йота
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.