Apakah ada panjang siput maksimum?


14

Klien baru saja membuat posting dengan slug yang sangat panjang (90 karakter), tidak ada karakter khusus (selain tanda hubung) dll.

Setiap kali tautan ke pos itu diklik, termasuk tautan "Pratinjau" atau "Lihat posting ini" dari bagian belakang Admin, 404 dibuat.

Setelah kami memangkas siput secara manual, semuanya berjalan seperti yang diharapkan. Apakah ini "fitur" atau "bug"?

EDIT: Catatan untuk semua yang berbicara tentang batas DB.

Jika saya mencapai batas bidang DB, maka siput itu sendiri akan terpotong. Pikirkan sebentar. Dalam kasus kebanyakan instalasi WP, wp_posts.post_name adalah VARCHAR (200). Jadi, katakanlah seseorang mengetik judul dengan> 200 karakter. Apa yang terjadi? Siput akan dipotong menjadi 200 karakter dan disimpan di wp_posts.post_name. Ini tidak seperti seseorang masuk dan mengetik judul lengkap dari pos di bilah alamat browser, mengganti spasi dengan tanda hubung kan? URL sedang dibuat oleh WordPress, dan itu mendapatkan URL dari tabel wp_posts.post_name dan hanya menempatkannya di atribut href dari tag anchor. Jadi tidak akan ada disparitas di sana. Seluruh hal DB adalah herring merah.

Dalam kasus apa pun, siput yang dimaksud hanya 90 karakter, sehingga tidak ada hubungannya dengan batas DB.

Adakah batasan yang diketahui tentang penulisan ulang?


1
Anda dapat menggunakan alat gratis seperti MySQL workbench untuk memeriksa datatype (dan panjang maksimum jika ada) dari setiap bidang wordpress sebagaimana didefinisikan dalam tabel / kolom wordpress yang sesuai
Jordi Cabot

Jawaban:


11

Karena struktur tabel wp_posts panjang kolom post_name (kolom untuk siput) sama dengan 200 karakter.


1
@ TomAuger & Eugene - dapatkah Anda mengkonfirmasi masalah ini, karena Tom mengatakan siput itu memiliki 90 karakter. Saya sadar bahwa batasnya adalah 200, tetapi ini tidak menghitung URL beranda, bukan?
brasofilo

@Eugene, tepatnya. 200 karakter. Siput saya persis 90 karakter, jadi kami tidak mencapai batas DB.
Tom Auger

3

Saya kira itu tidak memiliki batasnya sendiri tetapi properti bidang dalam database untuk siput mungkin diatur ke panjang maksimal.

Jadi periksa Database!


@ Orang yang downvoted: Jawabannya benar . Karena itu saya melakukan reupvote.
kaiser

0

Mungkin masalahnya bahkan tidak secara langsung terkait dengan WordPress / database ...

Tetapi panjang URL melebihi 255 karakter (dan tidak semua browser web melakukan hal itu).

Apa yang terjadi di sini mungkin URL yang lebih panjang dari 255 karakter, yang terpotong oleh bilah alamat peramban saat membukanya ... menyebabkan pengambilan permalink yang buruk ... yang menghasilkan 4o4.

Jadi diasumsikan panjang siput maksimum mungkin:

255 - panjang (Protokol + FQDN + struktur permalink) ...

  • berdasarkan batas keras browser.

Tapi tidak lebih dari 200 karakter ...

  • berdasarkan ukuran bidang post_name.

Bahkan jika ada hal lain yang menyebabkan 4o4 dalam kasus khusus ini.

Bisa jadi karakter yang tidak url_encoded juga dengan baik, alasan 4o4 cukup tak terbatas ... pernah dianggap cluster yang buruk pada HDD atau modul RAM yang rusak? :)


GUID bukan URL. Itu hanya terlihat seperti satu, tetapi tidak digunakan untuk membaca permintaan. Jika Anda memindahkan WordPress dari satu domain ke domain lainnya, GUID tidak akan berubah. Lihat core.trac.wordpress.org/ticket/6492 dan core.trac.wordpress.org/ticket/10857 .
fuxia

Eh, untuk apa lagi selain tujuan identifikasi harus menggunakan ID unik itu? Maksud saya, pada dasarnya pertanyaannya adalah: Apa alasan 4o4 dilemparkan dalam kasus ini?
Martin Zeitler

404 dan GUID tidak terkait, saya pikir. WordPress tidak menggunakan GUID saat mencari posting yang cocok dengan URL.
fuxia

Pikirkan Anda benar tentang itu ... post_name dan GUID dapat dikecualikan sebagai sumber masalah - yang tersisa adalah permalink dan penulisan ulang. Tanpa file log Apache atau apa pun ini hanya menebak-nebak;)
Martin Zeitler

@loglogic Saya pikir penulisan ulang mungkin penyebabnya dan perlu penyelidikan lebih lanjut. URL, termasuk bagian http: // masih di bawah 128 karakter, jadi saya tidak berpikir itu memukul batas browser yang keras pada panjang URL.
Tom Auger
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.