Craig,

It's a MySQL issue, rather than a b2evolution issue. Each post is saved in a single field in a table called evo_posts. There is a limit on the number of bytes stored in a single text field.

I realize that your project is currently using post pages to simulate manuscript pages, but from a database efficiency point-of-view, it would be better to have each page be in a separate field (or post) rather than just crammed into one.

A quick search on "mysql text field limitation maximum bytes" has yielded [url=http://simon.incutio.com/archive/2002/08/01/mysqlTextLimits]this page[/url] which says:

MySQL text limits
Today's scary discovery: MySQL TEXT fields have a limit of 65,000 bytes. If you insert anything larger than that in to a normal TEXT field mySQL will silently truncate your data without telling you (meaning software checks are probably a good idea). MEDIUMTEXT will store 16 million characters and LONGTEXT can handle over 4 trillion, but this information does not appear to be readily available in the online mySQL manual (although it is hinted at in this table). Something to bare in mind when designing database applications.

Posted 1st August 2002 - 12:24 | Categories: PHP, Open Source

I'd recommend in your back office "settings" tab - display only one post per page, archive on a post-by-post basis. You could even give your post titles chaper & page numbers and then the archive would be a list of pages.

Hope this helps. Sounds like an interesting project.

-stk

Thanks for the help.
Well. Sounds like I have a dilemma then.

What I was hoping to do is create one blog called "Library" and then I would post several old books relevant to my topic in that one blog. That way I would only have one link from the main blog to the "library" blog, and then several books on that blog.

I'm not sure if I can accomplish that with the one page per post method, because then each book would have to be a seperate blog, then I would need to create a library blog to link to each of those book blogs.

But I would only want the "library" blog to appear in the list of blogs, not each individual book.

This may take some thinking.

It sort of sounds like some of this linking structure could be done more cleanly using a links menu rather than multiple blogs. There are various ways to get links into your blog, even complex menu trees can be added to your skin templates without having to produce too many blogs.

I'm not sure if I'm completely understanding your ultimate goal, but maybe we can help you find a nice workable solution.

Well, for a number of reasons I don't want to modify the template - not the least of which is that I don't feel like struggling with that... but also because the template is used for other things and I wouldnt want global changes, Essentially I just want this library to be one small section that is not the main focus of my site... but just an add-on.

As I think about it, the seperate blog for each book thing might work, and just have those not appear in the blog list, then create a "library" blog to link to the book blogs with a short description of each book, and have that library blog appear in the blog list.

Which leaves only the problem of navigating the pages of the books, it won't be very elegant... plus I'll have to modify the dates of each page/post so that the book pages appear in the correct order rather than reversed.

Sheesh. Caint nuthin' ever be simple? :(

You can reverse the order of the posts very easily - it's a setting in your stub file, which means you would have to use stubs to do it. Anyway you can change from newest on top to oldest on top, which would work for that particular detail of your mission.

19th century book eh? A book about blogging pre-internet perhaps?

Easy? Well... ;)
I'm really trying to avoid anything that requires thinking.

I guess I should get around to using stub files.

I have found a very easy way of reversing the order of posts which is ideal for "book" type postings or chronological events. Just add

?order=ASC

to your Blog URL and then either make that the link to get to the blog or make the most recent message posted something like:

Click here to view these posts in chronoloical order

an example URL

http://neukol.org.uk/teesblog/index.php/voyage?order=ASC

Thanks Steve, thats an interesting idea...

Would work in some ways, though people who came to the blog through a search engine would still get the stuff in reverse order.

I had the same problem:

folks coming to http://neukol.org.uk/teesblog/index.php/voyage

was fine if they were folloing teh story as it unfolded. Now it would make no sense so I've put a link to basically turn teh blog"upside down" so folks can read from start to finish. Best way to describe this is to go to teh site

This can be done without modifying the url when you use stub files. search for ASC and stub, make sure you select the bottom radio button to search for all words. If you still can't find it (and I'm 99% sure it's easy to find), I'll dig out an old stub file with this in.

Craig, et.al.,

Interesting. I have finally become verbose enough that I too, ran into the silent truncation at 65,000 characters for a post. (I am posting a 10-day trip log in a single, multi-paged post).

When I originally discovered mySQL had a text limit, little did I know that when I posted the source of this information, I also posted a solution.

Using myPhpAdmin, it's possible to edit the post_content field structure in the evo_posts table, changing it from TEXT to either MEDIUMTEXT (which can handle 16 million characters) or LONGTEXT (which can handle over 4 trillion characters) ... as reported by Simon Willison in [url=http://simon.incutio.com/archive/2002/08/01/mysqlTextLimits]this article[/url].

In any case, I've changed mine to 'mediumtext' and (so far) have not suffered any ill effects. I don't know what kind of performance hit I'll experience, but for the average visitor, I doubt it will be significant, though it would be interesting to benchmark the difference.

Anyway, I thought I'd chime in again on this topic.

Cheers,

-stk

If you're going to make each page or chapter its own post, then you could use categories for the books. This is nice, especially since b2evolution supports nested categories.

FYI - I've had this fear that b/c mySQL ungraciously lops off text longer than 65,000 chars AND b/c I changed my "post_content" type to "mediumtext" (to allow for more) that I would LOSE the tail end of these long posts everytime I upgraded.

WHEW! I didn't. The "mediumtext" change has stuck through the upgrade from Paris -> Dawn and from Dawn -> Phoenix!

Wahoo! :D

And then BLAM ... upgrading from Phoenix (v1.6) to Summer Beta (v1.8) ... the post_content field was "autotragically" converted to "text" and (just now discovered by a reader who alerted me to an XML error) some posts (not sure which ones) have been ungraciously truncated at the "TEXT" character limit. :> >:-< :> >:-<

I am not a happy camper.

I know this is a waaaaaaay old thread but this is my problem too right now.

I can't seem to find a evo_post table though? has it changed now...?

Hey your version number is really important in this type of stuff!

Assuming the latest and greatest, evo_items__item would be the table and post_content would be the field. It is currently a mediumtext field, so change it to a longtext field I guess. I can never figure out what has which limit in that stuff.

Oh wait I don't have to figure it out. http://www.xnote.com/howto/mysql_field_types.html already did :)

Be careful on an upgrade too, b/c I once upgraded it and it was reset back to the default (medtext). Didn't notice till one day someone commented that one of my super long, multi-day journals ended abruptly.

Had to go back to an old backup and copy/paste the post_content back, using PMA, for every "super-long" post I had.

I'm very unconfident with MySQL, and although I now see the table, I don't see clearly how to change it.

Doing this from memory...

After you select your database you get a list of tables in both the left and right. Click on the evo_items in the left to make it expand. Now click on evo_items__item on the left. That should make the structure of that table show up on the right. Find the row for "post_content" and click on the edit icon over there on the right side of the right half of the page. There you will see some stuff, including a dropdown box that identifies the field as a MEDIUMTEXT. Select TEXT then click 'go'.

Oh and of course have a backup of your database before you begin. If you do nothing will go wrong. If you don't everything will fail.

I don't know if this is possible, but switching to mediumtext for 3.1 - final seems like it would be a big win for users.