มีความยาวกระสุนสูงสุดหรือไม่

ลูกค้าเพิ่งสร้างโพสต์ที่มีกระสุนยาวมาก (90 ตัวอักษร) ไม่มีอักขระพิเศษ (นอกเหนือจากเครื่องหมายขีดกลาง) เป็นต้น

เมื่อใดก็ตามที่มีการคลิกลิงก์ไปยังโพสต์นั้นรวมถึงลิงก์ "ดูตัวอย่าง" หรือ "ดูโพสต์นี้" จากส่วนหลังของผู้ดูแลระบบจะมีการสร้าง 404 ขึ้น

เมื่อเราตัดทากด้วยตัวเองทุกอย่างทำงานตามที่คาดไว้ นี่เป็น "คุณสมบัติ" หรือ "ข้อบกพร่อง" หรือไม่?

แก้ไข: หมายเหตุสำหรับทุกคนที่พูดถึงขีด จำกัด ฐานข้อมูล

ถ้าฉันกดปุ่ม จำกัด เขตข้อมูลแล้วตัวบุ้งจะถูกตัดทอน ลองคิดดูสักครู่ ในกรณีของการติดตั้ง WP ส่วนใหญ่ wp_posts.post_name คือ VARCHAR (200) สมมุติว่ามีคนพิมพ์ชื่อเรื่องด้วย> 200 ตัวอักษร เกิดอะไรขึ้น? กระสุนถูกตัดให้เหลือ 200 ตัวอักษรและเก็บไว้ใน wp_posts.post_name มันไม่เหมือนมีใครบางคนกำลังเข้ามาและพิมพ์ชื่อเต็มของโพสต์ในแถบที่อยู่ของเบราว์เซอร์แทนที่ช่องว่างด้วยขีดกลางใช่มั้ย WordPress สร้างขึ้นโดย URL และได้รับ URL จากตาราง wp_posts.post_name แล้วใส่ลงในแอตทริบิวต์ href ของแท็กจุดยึด ดังนั้นจะไม่มีความเหลื่อมล้ำที่นั่น สิ่ง DB ทั้งหมดเป็นปลาเฮอริ่งแดง

ในกรณีใด ๆ กระสุนที่เป็นปัญหามีเพียง 90 ตัวอักษรดังนั้นจึงไม่มีอะไรเกี่ยวข้องกับขีด จำกัด ฐานข้อมูล

มีข้อ จำกัด ใด ๆ ที่รู้จักในการเขียนซ้ำหรือไม่?

slug

— ทอมสว่าน
แหล่งที่มา

คุณสามารถใช้เครื่องมือฟรีเช่น MySQL ปรับแต่งเพื่อตรวจสอบประเภทข้อมูล (และความยาวสูงสุดถ้ามี) ของสนาม WordPress ใดตามที่กำหนดไว้ในตารางที่สอดคล้องกัน WordPress / คอลัมน์

— Jordi Cabot

คำตอบ:

เนื่องจากโครงสร้างตาราง wp_posts ความยาวของคอลัมน์ post_name (คอลัมน์สำหรับทาก) เท่ากับ 200 อักขระ

— Eugene Manuilov
แหล่งที่มา

@TomAuger & Eugene - คุณสามารถยืนยันปัญหาได้เพราะ Tom บอกว่ากระสุนมี 90 ตัวอักษร ฉันทราบว่าขีด จำกัด คือ 200 แต่ไม่นับ URL บ้านใช่ไหม

— brasofilo

@Eugene แน่นอน 200 ตัวอักษร กระสุนของฉันคือ 90 ตัวอักษรดังนั้นเราจึงไม่ได้กดขีด จำกัด ฐานข้อมูล

— Tom Auger

ฉันเดาว่ามันไม่มีขีด จำกัด โดยตัวมันเอง แต่คุณสมบัติของฟิลด์ในฐานข้อมูลสำหรับตัวบุ้งอาจถูกตั้งค่าเป็นความยาวสูงสุด

ดังนั้นตรวจสอบฐานข้อมูล!

— Fredrik Weiland
แหล่งที่มา

หนึ่ง @The ที่ downvoted: คำตอบคือถูกต้อง ดังนั้นฉันจึงอัปเดตอีกครั้ง

— ไกเซอร์

อาจเป็นปัญหาที่ไม่ได้โดยตรงกับ WordPress / ฐานข้อมูลที่เกี่ยวข้องเลย ...

แต่ความยาวของ URL เกิน 255 ตัวอักษร (ไม่ใช่เว็บเบราว์เซอร์ทั้งหมดที่ทำเช่นนั้น)

สิ่งที่เกิดขึ้นที่นี่อาจเป็น URL ที่ยาวกว่า 255 ตัวอักษรซึ่งถูกตัดทอนโดยแถบที่อยู่ของเบราว์เซอร์เมื่อเปิดมัน ... ทำให้เกิดการดึงลิงก์ย้อนกลับที่ไม่ดี ... ซึ่งส่งผลให้ 4o4

ดังนั้นความยาวสูงสุดของทากอาจสันนิษฐานได้:

255 - ความยาวของ (โครงสร้างโปรโตคอล + FQDN + Permalink) ...

ตามขีด จำกัด ฮาร์ดของเบราว์เซอร์

แต่ต้องไม่เกิน 200 ตัวอักษร ...

ขึ้นอยู่กับขนาดฟิลด์ของ post_name

แม้ว่าบางสิ่งบางอย่างอาจทำให้ 4o4 ในกรณีนี้โดยเฉพาะ

มันอาจเป็นตัวละครที่ไม่ถูกต้อง url_encoded เช่นกันเหตุผลสำหรับ 4o4 นั้นค่อนข้างไม่มีที่สิ้นสุด ... เคยคิดว่าคลัสเตอร์ที่ไม่ดีบน HDD หรือโมดูล RAM ผิดปกติหรือไม่ :)

— Martin Zeitler
แหล่งที่มา

GUID ไม่ใช่ URL มันเกิดขึ้นกับดูเหมือน แต่ไม่ได้ใช้ในการอ่านคำขอ หากคุณย้าย WordPress จากโดเมนหนึ่งไปยังอีก GUID จะไม่ถูกเปลี่ยน ดูcore.trac.wordpress.org/ticket/6492และcore.trac.wordpress.org/ticket/10857

— fuxia

เอ่อแล้วจะมีการใช้ ID ที่ไม่ซ้ำกันเพื่อวัตถุประสงค์อื่นนอกเหนือไปจากการระบุตัวอย่างไร ฉันหมายถึงคำถามพื้นฐานคือ: อะไรคือสาเหตุที่ 4o4 ถูกโยนทิ้งในกรณีนี้?

— Martin Zeitler

ฉันคิดว่า 404 และ GUID นั้นไม่เกี่ยวข้องกัน WordPress ไม่ได้ใช้ GUID เมื่อค้นหาโพสต์ที่ตรงกับ URL

— fuxia

คิดว่าคุณพูดถูก ... post_name และ GUID สามารถยกเว้นได้ว่าเป็นสาเหตุของปัญหา - สิ่งที่เหลืออยู่คือ permalinks และการเขียนซ้ำ โดยไม่ต้อง Apache logfiles หรืออะไรนี้เป็นเพียงการคาดเดาไปรอบ ๆ ;)

— มาร์ตินเซ็ทเลอร์

@ syslogic ฉันคิดว่าการเขียนซ้ำอาจเป็นสาเหตุและมีการสอบสวนเพิ่มเติม URL รวมถึงส่วน http: // ยังอยู่ภายใต้ 128 ตัวอักษรดังนั้นฉันไม่คิดว่ามันจะมีขีด จำกัด ของเบราว์เซอร์ที่มีความยาว URL

— Tom Auger