Post is getting cliped before the end

[norm_crawford]

My first post is real long and I can't get the text posted all the way to the end.
Is there some kind of a limit on how long a post can be?
The site is: uncorrectable government databases.com (without the spaces)
Thanks in advance
Norm

[garvinhicking]

Hi!

Serendipity's database table has a cap of around 65kb. If you use MySQL, you could use a tool like phpMyAdmin to change the columns "body" and "extended" in the database table "serendipity_entries" vom "text" to "Longtext".

HTH,
Garvin

[Don Chambers]

You might want to consider using the event plugin "Split long entries" (serendipity_event_entrysplit), the description of which is:

Enables you to split longer entries into several subpages and provides you with an auto-generated table of contents

I do not know if this plugin increases the 65kb limit Garvin mentioned - I have never used it.

[garvinhicking]

Hi Don!

Actually, sadly this plugin wouldn't help, because the DB storage limit is 65kb.

I now changed s9y 1.6 for new installations to use LONGTEXT by default...

Best regards,
Garvin

[Don Chambers]

Hi Don!

Actually, sadly this plugin wouldn't help, because the DB storage limit is 65kb.

I now changed s9y 1.6 for new installations to use LONGTEXT by default...

Best regards,
Garvin

Can an existing database be modified to use LONGTEXT without upgrading to 1.6 beta? What implications, if any, come with this switch to LONGTEXT? Any search implications?

[kleinerChemiker]

a) yes
b) should be no problems

[garvinhicking]

Hi!

The database only gets a little bit bigger, other than that, no problems are to be expected.

Regards,
Garvin

[kleinerChemiker]

2x2bytes per post. i think thats nearly nothing

[Don Chambers]

Finally found the time to tinker with this today.

Perhaps the upgrade should change body and extended to longtext? I had to do it manually for an existing site that I upgraded to 1.6 beta.

Testing in 2 different templates (one of my complex ones, and also Serendipity 3.0 by Carl)... These templates display the extended body as {$entry.extended}. Despite the change of body and extended to longtext, this smarty variable is still limited to approx 62k characters. However, if directly editing the entry, or viewing the record via phpMyAdmin - the entire entry does exist in the database with the new longtext column type.

[garvinhicking]

Hi!

Your problem might be related to other plugins, like maybe the Caching plugin. The sizes of entrpyoperties still have TEXT columns. For those, changing it to LONGTEXT might be a more considerable size increase, because this field can hold much more entries. I would need to do some research on that before switching it...

Regards,
Garvin

[Don Chambers]

I do believe it is the caching of entries via the extended properties plugin that is causing it to be clipped. If disabled, extended body is no longer truncated. My concern, however, is the performance impact of not using the cached body and extended body.

Let me know what, specifically, you might want to try or test.

[garvinhicking]

Hi!

Simply set your serendipity_entryproperties DB table to have "value" be also "longtext". (and then re-cache)

Regards,
Garvin

[Don Chambers]

Hi!

Simply set your serendipity_entryproperties DB table to have "value" be also "longtext". (and then re-cache)

Regards,
Garvin

That's what my instinct said to do, but you made me nervous with your comment above:

For those, changing it to LONGTEXT might be a more considerable size increase, because this field can hold much more entries. I would need to do some research on that before switching it...

You think it will have much impact?

[garvinhicking]

Hi!

You think it will have much impact?

As onli indicated, you should get a size increase by multiplicating the number of rows in your serendipity_entryproperties, multiplay it by two, and you should get the new bytes.

Say you have 2000 blog articles, each one usually has about 4-5 entryproperties. That means you have 10.000 entries inside entryproperties, this would mean an increase of 20kb in your database. That shouldn't be too hard, but before putting it in the official s9y release, we should test it

Regards,
Garvin

[Don Chambers]

I didn't do a "before & after" check of the table/db size.... but it does not sound too bad to me.

Oh, and Judebert committed a patch yesterday to the split entries plugin that corrects errors I reported above. I never have been able to communicate consistently with cvs! SVN is no problem, but cvs has always been a headache!