Чи є максимальна довжина кулі?

Клієнт щойно створив публікацію із дійсно довгим куліком (90 символів), без спеціальних символів (крім дефісів) тощо.

Щоразу, коли натискали посилання на цю публікацію, включаючи посилання "Попередній перегляд" або "Переглянути цю публікацію" із зворотного кінця адміністратора, створюється 404.

Після того, як ми вручну обрізали слизьку, все працювало так, як і очікувалося. Це "особливість" чи "помилка"?

EDIT: Примітка для всіх, хто говорить про обмеження БД.

Якби я потрапляв до межі поля БД, то сам слизок би був усічений. Подумайте про це на секунду. У випадку більшості установок WP, wp_posts.post_name - VARCHAR (200). Отже, скажімо, що хтось набирає назву з> 200 символів. Що сталося? Слуг стає усіченим до 200 символів і зберігається у wp_posts.post_name. Це не так, як хтось заходить і набирає повну назву публікації в адресному рядку веб-переглядача, замінюючи пробіли тиреми, чи не так? URL генерується WordPress, і він отримує URL-адресу з таблиці wp_posts.post_name і просто вводить її в атрибут href тега якоря. Тож там не буде розбіжності. Вся справа в БД - це червона оселедець.

У будь-якому випадку, про слизу йде лише 90 знаків, тому це не має нічого спільного з обмеженнями БД.

Чи існують відомі обмеження навколо переписування?

slug

— Том Ожер
джерело

Ви можете скористатися безкоштовним інструментом, таким як робочий стіл MySQL, для перевірки типу даних (та максимальної довжини, якщо така є) будь-якого поля wordpress, як визначено у відповідній таблиці / колонці wordpress

— Jordi Cabot,

Відповіді:

Завдяки структурі таблиці wp_posts довжина стовпця post_name (стовпець для слизів) дорівнює 200 символів.

— Євген Мануїлов
джерело

@TomAuger & Eugene - чи можете ви підтвердити проблему, тому що Том каже, що у слизина було 90 символів. Я знаю, що обмеження становить 200, але це не враховує домашню URL-адресу, чи не так?

— brasofilo

@Eugene, точно. 200 символів. У мого слима було рівно 90 знаків, тому ми не досягаємо межі БД.

— Том Оже

Я думаю, він не має обмеження самостійно, але властивість поля в базі даних для слизів може бути встановлена на максимальну довжину.

Тож перевірте Базу даних!

— Фредрік Вайланд
джерело

@Той, хто виступав проти цього: Відповідь правильна . Тому я відкликав свою пропозицію.

— кайзер

Можливо, проблема навіть не була пов’язана безпосередньо з WordPress / базою даних ...

Але довжина URL-адреси перевищила 255 символів (і не всі веб-браузери роблять так).

Те, що тут сталося, може бути URL-адресою довше 255 символів, яка врізається адресною панеллю браузера під час відкриття ... спричиняючи пошук поганого постійного посилання ..., що призвело до 4o4.

Таким припустимим, максимальна довжина слизи може бути:

255 - довжина (протокол + FQDN + структура постійної посилання) ...

на основі жорсткої межі браузера.

Але він не може бути довше 200 символів ...

на основі розміру поля post_name.

Навіть якщо щось інше, можливо, спричинило 4o4 в даному конкретному випадку.

Це міг бути персонаж, який також не був належним чином url_encoded, причини для 4o4 є досить нескінченними ... коли-небудь вважали поганим кластером на жорсткому диску або несправним модулем оперативної пам'яті? :)

— Мартін Цайтлер
джерело

GUID - це не URL. Це просто буває так, щоб виглядати як один, але не використовується для читання запиту. Якщо ви перемістите WordPress з одного домену в інший, GUID не буде змінено. Див. Core.trac.wordpress.org/ticket/6492 та core.trac.wordpress.org/ticket/10857 .

— фуксія

Ем, для чого, крім ідентифікаційних цілей, слід використовувати унікальний ідентифікатор? Я маю на увазі питання в основному таке: у чому причина 4o4 в цьому випадку?

— Мартін Цайтлер

Я думаю, що 404 та GUID не пов'язані між собою. WordPress просто не використовує GUID, коли він шукає публікацію, яка відповідає URL-адресі.

— фуксія

Подумайте, що ви в цьому правильні ... post_name та GUID можуть бути виключені як джерело проблеми - те, що залишилося - це постійна посилання та повторна запис. Без логістів Apache або чогось іншого, це просто здогадки;)

— Martin Zeitler

@syslogic Я думаю, що переписування, мабуть, є причиною і потребує подальшого дослідження. URL-адреса, включаючи частину http: //, все ще містила 128 символів, тому я не думаю, що вона досягає жорсткого обмеження браузера щодо довжини URL-адреси.

— Том Оже