Italiano
Español
РусскийExistă o limită maximă pentru lungimea slug-ului?
Un client a creat recent un articol cu un slug foarte lung (90 de caractere), fără caractere speciale (în afară de liniuțe) etc.
De fiecare dată când se accesa linkul către acel articol, inclusiv prin linkurile "Previzualizare" sau "Vezi articolul" din panoul de administrare, se genera o eroare 404.
După ce am scurtat manual slug-ul, totul a funcționat corespunzător. Este aceasta o "caracteristică" sau un "bug"?
EDIT: O notă pentru cei care menționează limitele bazei de date.
Dacă aș fi depășit limita câmpului din baza de date, atunci slug-ul în sine ar fi fost trunchiat. Gândiți-vă un moment. În cazul majorității instalărilor WP, wp_posts.post_name este VARCHAR(200). Deci, să presupunem că cineva introduce un titlu cu > 200 de caractere. Ce se întâmplă? Slug-ul este trunchiat la 200 de caractere și stocat în wp_posts.post_name. Nu e ca și cum cineva introduce manual titlul complet al articolului în bara de adrese a browserului, înlocuind spațiile cu liniuțe, nu? URL-ul este generat de WordPress, care îl ia din tabela wp_posts.post_name și îl pune în atributul href al tag-ului anchor. Deci nu poate exista o discrepanță acolo. Discuția despre baza de date este o heringă roșie.
În orice caz, slug-ul în cauză are doar 90 de caractere, deci nu are nicio legătură cu limitele bazei de date.
Există limitări cunoscute ale sistemului de rewrite?
@TomAuger & Eugene - puteți confirma problema, pentru că Tom spune că slug-ul avea 90 de caractere. Știu că limita este de 200, dar asta nu include URL-ul principal, nu-i așa?
brasofilo
@Eugene, exact. 200 de caractere. Slug-ul meu avea exact 90 de caractere, deci nu depășim limita din baza de date.
Tom Auger
@Cel care a dat vot negativ: Răspunsul este corect. Prin urmare, am dat din nou vot pozitiv.
kaiser
GUID-ul nu este URL-ul. Doar că arată ca unul, dar nu este folosit pentru a citi o cerere. Dacă muți WordPress de pe un domeniu pe altul, GUID-ul nu va fi schimbat. Vezi http://core.trac.wordpress.org/ticket/6492 și http://core.trac.wordpress.org/ticket/10857.
fuxia
Păi, pentru ce altceva decât scopuri de identificare ar trebui folosit un ID unic atunci? Adică, întrebarea practic este: Care este motivul pentru care este aruncată o eroare 404 în acest caz?
Martin Zeitler
Eroarea 404 și GUID-ul nu sunt legate, cred. WordPress pur și simplu nu folosește GUID-ul atunci când caută un articol care să corespundă unui URL.
fuxia
Cred că ai dreptate în privința asta... post_name și GUID pot fi excluse ca surse ale problemei - ce rămâne sunt permalink-urile și re-scrierile. Fără fișierele de log Apache sau altceva, asta este doar o presupunere ;)
Martin Zeitler
@syslogic Cred că re-scrierile sunt probabil cauza și merită investigat mai departe. URL-ul, inclusiv partea cu http://, era încă sub 128 de caractere, așa că nu cred că depășește limita dură a browserului privind lungimea URL-ului.
Tom Auger