Есть ли максимальная длина пули?

Клиент только что создал сообщение с очень длинным слагом (90 символов), без специальных символов (кроме дефисов) и т. Д.

При каждом нажатии на ссылку на этот пост, в том числе ссылки «Просмотр» или «Просмотр этого поста» от администратора, генерировалось 404.

Как только мы урезали слизняк вручную, все заработало как положено. Это «особенность» или «ошибка»?

РЕДАКТИРОВАТЬ: Примечание для всех тех, кто говорит об ограничениях БД.

Если бы я достиг предела поля БД, то сам слаг был бы обрезан. Подумай об этом на секунду. В случае большинства установок WP, wp_posts.post_name - это VARCHAR (200). Итак, допустим, что кто-то печатает заголовок с> 200 символами. Что происходит? Слаг будет усечен до 200 символов и сохранен в wp_posts.post_name. Это не значит, что кто-то входит и печатает полный заголовок поста в адресной строке браузера, заменяя пробелы черточками, верно? URL генерируется WordPress, он получает URL из таблицы wp_posts.post_name и просто помещает его в атрибут href тега привязки. Так что там не будет различий. Вся вещь БД - красная сельдь.

В любом случае рассматриваемый слаг составляет всего 90 символов, поэтому он не имеет никакого отношения к ограничениям БД.

Есть ли какие-либо известные ограничения по переписыванию?

slug

— Том Оже
источник

Вы можете использовать бесплатный инструмент, такой как MySQL Workbench, чтобы проверить тип данных (и максимальную длину, если есть) любого поля WordPress, как определено в соответствующей таблице / столбце

— WordPress

Ответы:

Благодаря структуре таблицы wp_posts длина столбца post_name (столбца для слагов) равна 200 символам.

— Евгений Мануйлов
источник

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

— brasofilo

@ Евгений, точно. 200 символов. Мой слаг был ровно 90 символов, поэтому мы не достигли лимита БД.

— Том Оже

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

Так что проверяйте базу данных!

— Фредрик Вейланд
источник

@ Тот, кто отрицал: ответ правильный . Поэтому я повторно проголосовал.

— Кайзер

Возможно, проблема даже не была связана напрямую с WordPress / базой данных ...

Но длина URL превышала 255 символов (и не все веб-браузеры так делают).

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

Поэтому предполагается, что максимальная длина пули может быть:

255 - длина (протокол + полное доменное имя + структура постоянной ссылки) ...

на основе жесткого ограничения браузера.

Но это не может быть длиннее 200 символов ...

основанный на размере поля post_name.

Даже если что-то еще могло послужить причиной 4o4 в этом конкретном случае.

Это мог быть персонаж, который также не был должным образом закодирован url_encoded, причины для 4o4 довольно бесконечны ... когда-либо считалось плохим кластером на жестком диске или неисправным модулем памяти? :)

— Мартин Цайтлер
источник

GUID не является URL. Это просто выглядит как один, но не используется для чтения запроса. Если вы переместите WordPress из одного домена в другой, GUID не изменится. См. Core.trac.wordpress.org/ticket/6492 и core.trac.wordpress.org/ticket/10857 .

— fuxia

Хм, для чего еще, кроме целей идентификации, следует использовать уникальный идентификатор? Я имею в виду, вопрос в основном таков: почему в этом случае выбрасывается 4o4?

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

Я думаю, что 404 и GUID не связаны между собой. WordPress просто не использует GUID при поиске записи, которая соответствует URL.

— Fuxia

Думаю, вы правы в этом ... post_name и GUID могут быть исключены как источник проблемы - то, что осталось, это постоянные ссылки и перезаписи Без лог-файлов Apache или чего-то еще это просто гадать;)

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

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

— Том Оже