클라이언트가 방금 긴 슬러그 (90 자), 특수 문자 (하이픈 이외) 등으로 게시물을 만들었습니다.
관리자 백엔드에서 “미리보기”또는 “이 게시물보기”링크를 포함하여 해당 게시물에 대한 링크를 클릭 할 때마다 404가 생성되었습니다.
슬러그를 수동으로 손질하면 모든 것이 예상대로 작동했습니다. 이것이 “기능”입니까, “버그”입니까?
편집 : DB 제한에 대해 이야기하는 모든 사람들을위한 참고 사항.
DB 필드 제한에 도달하면 슬러그 자체가 잘립니다. 잠깐 생각 해봐 대부분의 WP 설치의 경우 wp_posts.post_name은 VARCHAR (200)입니다. 누군가가 200자를 초과하는 제목을 입력한다고 가정 해 봅시다. 무슨 일이야? 슬러그는 200 자로 잘리고 wp_posts.post_name에 저장됩니다. 누군가가 들어가서 브라우저 주소 표시 줄에 게시물의 전체 제목을 입력하여 공백으로 대시를 대체하는 것과는 다릅니다. URL은 WordPress에 의해 생성되고 있으며 wp_posts.post_name 테이블에서 URL을 가져와 앵커 태그의 href 속성에 넣습니다. 따라서 차이가 없을 것입니다. DB 전체는 붉은 청어입니다.
어쨌든 문제의 슬러그는 90 자이므로 DB 제한과 관련이 없습니다.
다시 쓰기와 관련하여 알려진 제한이 있습니까?
답변
wp_posts 테이블 구조로 인해 post_name 열 (슬러그 열)의 길이는 200 자입니다.
답변
자체적으로 제한이 없지만 슬러그 데이터베이스의 필드 속성이 최대 길이로 설정되었을 수 있습니다.
데이터베이스를 확인하십시오!
답변
아마 문제는 전혀 직접 WordPress / 데이터베이스와 관련이 없었습니다 …
그러나 URL 길이는 255자를 초과했습니다 (모든 웹 브라우저가 그렇게하는 것은 아닙니다).
여기에서 발생한 것은 255자를 초과하는 URL 일 수 있으며, 브라우저를 열 때 브라우저의 주소 표시 줄에 의해 잘려서 잘못된 영구 링크 검색이 발생하여 4o4가 발생했습니다.
따라서 최대 슬러그 길이는 다음과 같습니다.
255-(프로토콜 + FQDN + 퍼머 링크 구조)의 길이 …
- 브라우저의 하드 한계를 기반으로합니다.
그러나 200자를 초과 할 수 없습니다 …
- post_name의 필드 크기를 기준으로합니다.
이 특별한 경우에 다른 무언가가 4o4를 유발했을지라도.
제대로 url_encoded되지 않은 문자 일 수 있습니다 .4o4의 이유는 끝이 없습니다 … HDD의 불량 클러스터 또는 결함이있는 RAM 모듈로 간주됩니까? 🙂