C'è una lunghezza massima della lumaca?

Un cliente ha appena creato un post con una lumaca davvero lunga (90 caratteri), senza caratteri speciali (tranne i trattini) ecc.

Ogni volta che si faceva clic sul collegamento a quel post, inclusi i collegamenti "Anteprima" o "Visualizza questo post" dal back-end dell'amministratore, veniva generato un 404.

Una volta che abbiamo tagliato manualmente la lumaca, tutto ha funzionato come previsto. È una "caratteristica" o un "bug"?

EDIT: una nota per tutti coloro che parlano di limiti DB.

Se colpissi il limite del campo DB, allora lo slug stesso verrebbe troncato. Pensaci per un secondo. Nel caso della maggior parte delle installazioni di WP, wp_posts.post_name è VARCHAR (200). Quindi, supponiamo che qualcuno digiti un titolo con> 200 caratteri. Che succede? Lo slug viene troncato a 200 caratteri e archiviato in wp_posts.post_name. Non è come se qualcuno entrasse e digitasse il titolo completo del post nella barra degli indirizzi del browser, sostituendo gli spazi con trattini, giusto? L'URL viene generato da WordPress e sta ottenendo l'URL dalla tabella wp_posts.post_name e inserendolo nell'attributo href del tag anchor. Quindi non ci sarà una disparità lì. L'intero DB è un'aringa rossa.

In ogni caso, la lumaca in questione ha solo 90 caratteri, quindi non ha nulla a che fare con i limiti di DB.

Ci sono limiti noti riguardo alla riscrittura?

slug

— Tom Auger
fonte

Puoi utilizzare uno strumento gratuito come MySQL workbench per controllare il tipo di dati (e la lunghezza massima se presente) di qualsiasi campo wordpress come definito nella corrispondente tabella / colonna wordpress

— Jordi Cabot,

Risposte:

A causa della struttura della tabella wp_posts, la lunghezza della colonna post_name (la colonna per gli slug) è pari a 200 caratteri.

— Eugene Manuilov
fonte

@ TomAuger & Eugene - puoi confermare il problema, perché Tom dice che la lumaca aveva 90 caratteri. Sono consapevole che il limite è 200, ma questo non conta l'URL di casa, vero?

— brasofilo,

@Eugene, esattamente. 200 caratteri. Il mio slug era esattamente 90 caratteri, quindi non stiamo raggiungendo il limite DB.

— Tom Auger

Immagino che non abbia un limite da solo, ma la proprietà del campo nel database per gli slug potrebbe essere impostata su una lunghezza massima.

Quindi controlla il database!

— Fredrik Weiland
fonte

@ Colui che ha effettuato il downvoting: la risposta è corretta . Pertanto ho rieseguito il voto.

— Kaiser

Probabilmente il problema non era nemmeno direttamente correlato a WordPress / database ...

Ma la lunghezza dell'URL ha superato 255 caratteri (e non tutti i browser web fanno così).

Quello che è successo qui potrebbe essere stato un URL più lungo di 255 caratteri, che è stato troncato dalla barra degli indirizzi del browser all'apertura ... causando il recupero di un permalink errato ... che ha portato a un 4o4.

Quindi si presume che la lunghezza massima della lumaca potrebbe essere:

255 - la lunghezza di (Protocollo + FQDN + struttura permalink) ...

basato sul limite rigido di un browser.

Ma non può essere più lungo di 200 caratteri ...

in base alla dimensione del campo post_name.

Anche se qualcos'altro avrebbe potuto causare il 4o4 in questo caso particolare.

Potrebbe essere stato un personaggio che non era stato correttamente url_encoded, i motivi dei 4o4 sono piuttosto infiniti ... hai mai considerato un brutto cluster su HDD o un modulo RAM difettoso? :)

— Martin Zeitler
fonte

Il GUID non è l'URL. Sembra solo uno, ma non è usato per leggere una richiesta. Se si sposta WordPress da un dominio a un altro, il GUID non verrà modificato. Vedi core.trac.wordpress.org/ticket/6492 e core.trac.wordpress.org/ticket/10857 .

— fuxia

Ehm, per quale altro scopo di identificazione dovrebbe essere usato un ID univoco? Voglio dire, la domanda è sostanzialmente: qual è la ragione per cui un 4o4 viene lanciato in questo caso?

— Martin Zeitler,

Il 404 e il GUID non sono correlati, credo. WordPress non utilizza semplicemente il GUID quando cerca un post che corrisponde a un URL.

— fuxia

Pensa di avere ragione su ... post_name e GUID possono essere esclusi come fonte del problema - ciò che rimane sono permalink e riscritture. Senza file di log di Apache o altro, questo è solo un indovinello;)

— Martin Zeitler,

@syslogic Penso che la riscrittura sia probabilmente la causa e porta ulteriori indagini. L'URL, inclusa la parte http: //, era ancora al di sotto di 128 caratteri, quindi non credo che stia raggiungendo un limite del browser per la lunghezza dell'URL.

— Tom Auger