[Feature] Te lange posts

[Verwijderd]

De inhoud is te lang na conversie: 98,620 bytes na conversie, 33,085 bytes meer dan mogelijk.
(interne identificatie: topic::new_message::maxcolumnsize_exceeded)

Krijg ik bijvoorbeeld als foutmelding.

Voor wie zich afvraagt waarom ik zoveel wil posten (en hoe ik dat vol krijg): WhatPulse Online keyboard en muis tracker - Deel 2 hier post ik dagelijkse stats in waarin dit voorkomt.

Heeft het nou bijvoorbeeld zin om codetags af te korten naar [ / ] om meer in een post te kunnen stoppen? Als ik de foutmelding goed begrijp worden de bytjes pas getelt na conversie maar ik vraag het voor de zekerheid nog maar even.

Tot slot een kleine feature request: is het mogelijk om het aantal bytes neer te zetten bij preview post/topic? Het is best wel irritant als je een post 'previewed' en dan bij submitten een foutmelding krijgt van een te lange post.

[crisp]

Nee, code-tags afkorten heeft geen zin; het gaat om de lengte van de post met geparsede RML (naar HTML dus).
De lengte achterhalen bij een preview is op zich wel mogelijk met een custom functie; daar kan ik voor de nieuwe layout eventueel nog wel naar kijken.

[Spider.007]

Is er een reden dat er een limiet is ingesteld voor de hoeveelheid gegenereerde HTML code per post? En waar is de huidige grens op gebaseerd?

[moto-moi]

huidige grens lijkt me 65535 bytes, en je mag zelf raden waarom dat zo is (tipje: sql datatypen)

[Spider.007]

[Spider.007@spider008 ~]$ expr 98620 - 33085 
65535

Ah.. dat zou wel eens de oorzaak kunnen zijn ja... Dat had ik mij nog niet een gerealiseerd.

[darkrain]

En het is niet mogelijk/gewenst om die grens een klein beetje te verhogen?

[Spider.007]

darkrain schreef op 14 september 2004 @ 21:12:
En het is niet mogelijk/gewenst om die grens een klein beetje te verhogen?

Zoals moto-moi al aangeeft is dit zonder ingrijpende technische wijziging van de kant van React niet mogelijk. Verder lijkt met niet dat dit probleem nou echt zo vaak voor zal komen dat deze grens verhoogd zou moeten worden (en dan ws meteen minimaal twee keer zo hoog)

[moto-moi]

* moto-moi wijst naar spider.
De eerstvolgende 'grens' is dan iets vna 16MB, en aangezien geen enkele posting dat 1-2-3 zal halen, is het nogal onzinnig om de hele database daarvoor te veranderen
En als je erachter komt dat je 2 replies nodig hebt in een topic kun je altijd een reply eronder ook even pakken om de rest van je startposting in te zetten

[crisp]

Er kan overigens ook een hoop zooi uit de RML gehaald worden; dingen als border=0 in img-tags enzo kan er allemaal uit; dat kan ook met CSS geregeld worden. In de nieuwe layout heb ik bijvoorbeeld al een

Cascading Stylesheet:

a img {
  border: none;
}

staan

[chem]

moto-moi schreef op 14 september 2004 @ 22:10:
* moto-moi wijst naar spider.
De eerstvolgende 'grens' is dan iets vna 16MB, en aangezien geen enkele posting dat 1-2-3 zal halen, is het nogal onzinnig om de hele database daarvoor te veranderen
En als je erachter komt dat je 2 replies nodig hebt in een topic kun je altijd een reply eronder ook even pakken om de rest van je startposting in te zetten

idd, de volgende stap is 16 mb (zie http://dev.mysql.com/doc/mysql/en/String_type_overview.html) - we gebruiken nu Text Columns.

En het grootste probleem is dat je ook niet zoveel data door PHP kan stampen; die 16mb moet dan eerst in PHP - en PHP mag niet eens meer dan 16 gebruiken. En dat dan per bericht, maal 999 per pagina... tel uit je winst; err memory swapping

Hopelijk dat de volgende release idd de nieuwe RML config etc bevat, dan kan er wat meer "in".

[crisp]

alle target="_blank" en class="link" en zut zijn lokaal al uit de RML gesloopt inmiddels
verder lijkt me dit een duidelijk verhaal, groter maken kan niet.