Loading...
 
Features / Usability

Features / Usability


Maximum length in blog posts and wiki pages?

posts: 6

Hi there,

does anyone know, if there normaly in version 1.7.8 exitsts an maximum length for blog pots and wiki pages?
I got that problem - do not really know, how many characters build the borderline, and it doesn't seem very regular, no it does, what it wants. If a entry is too long, the browser loads the page, leaving it white, although the loading process is done.

What the hell can I do? I would like to save documents with hundreds of rows, because I need Tiki for real enterprise usage.

There are many problems left --- later about it. :-).

Thank you,

Bye.

chris.

posts: 6

Sorry, but there's no way to accept no answer.
I can't work with an application, that doesn't save my work, because it's too long.
That's bullshit.

Sorry, but im very, very angry. ruh.


posts: 32 United Kingdom


Certainly in version 1.8.x Wiki pages are limited to around 65KB, pages over this just get cropped, IIRC. But this limit is easy to raise, it's just a case of changing the MySQL fieldtype to a type which supports more characters. Takes about 30 seconds in phpMyAdmin.

Regards,
Gray

posts: 6

Yeah, I already thought about that...
But I don't really know, I think someone here tried to use longtext as a fieldtype.

I'll try again.

Thank you.

posts: 8 United States
Ok...so can you be a bit more specific, how exactly to modify the database field to do so?
posts: 32 United Kingdom

Here's my tiki_pages table structure, along with the indexes, for my Tiki version 1.8.5 installation.

- phpMyAdmin SQL Dump
- version 2.5.5-pl1
- http://www.phpmyadmin.net
-
- Table structure for table `tiki_pages`
-

CREATE TABLE `tiki_pages` (
`page_id` int(14) NOT NULL auto_increment,
`pageName` varchar(160) NOT NULL default '',
`hits` int(8) default NULL,
`data` mediumtext,
`description` varchar(200) default NULL,
`lastModif` int(14) default NULL,
`comment` varchar(200) default NULL,
`version` int(8) NOT NULL default '0',
`user` varchar(200) default NULL,
`ip` varchar(15) default NULL,
`flag` char(1) default NULL,
`points` int(8) default NULL,
`votes` int(8) default NULL,
`cache` mediumtext,
`wiki_cache` int(10) default '0',
`cache_timestamp` int(14) default NULL,
`pageRank` decimal(4,3) default NULL,
`creator` varchar(200) default NULL,
`page_size` int(10) unsigned default '0',
PRIMARY KEY (`page_id`),
UNIQUE KEY `pageName` (`pageName`),
KEY `data` (`data`(255)),
KEY `pageRank` (`pageRank`),
FULLTEXT KEY `ft` (`pageName`,`description`,`data`)
) TYPE=MyISAM AUTO_INCREMENT=269 ;

Regards,
Gray

posts: 8 United States
Okay...that is easy enough. I am assuming that in order to make the same type of changes to a Blog or Article, the same type of changes would be made to the "tiki_blog_posts" and "tiki_articles" databases in the appropriate fields?

posts: 9 Greece

Changing the field type from TEXT to LONGTEXT seems to solve the issue (for now, at least) for me. There are some twirks with cached pages bombing with index-out-of-bounds errors, but overall it seems to work. I think this setting would make a sensible default.

-A


posts: 9 Greece

After a week of working with the new setting (LONGTEXT), I am now unable to add further content to my longest page. After editing the page, if I hit either "preview" or "save" Firefox just sits there (doesn't do anything, page does not get saved, stale editing session is left on exiting the browser).

With Konqueror I get more informative behavior: after hitting "save" or "preview", I get the message:
An error occurred while loading http://helios/tiki/tiki-editpage.php:
Connection to host helios is broken.

The server is running apache2, and is a 3GHz P4 box with 512MB RAM. Debian testing.

This doesn't seem to be quite the usual POST limit problem (I've increased that anyhow). 54863 characters in the page in question.

Any suggestions very welcome, as this will soon become a serious operational problem for a few users.

Cheers

-A

posts: 9 Greece

So I guess there is no resolution for this? At least a workaround, say a way to automatically create a new page called "BigPage_2" whenever the original one gets overflowed?

I can't believe people are living with this limitation, there must be a way around it.

Any enlightement very welcome!

-A


Upcoming Events

1)  18 Apr 2024 14:00 GMT-0000
Tiki Roundtable Meeting
2)  16 May 2024 14:00 GMT-0000
Tiki Roundtable Meeting
3)  20 Jun 2024 14:00 GMT-0000
Tiki Roundtable Meeting
4)  18 Jul 2024 14:00 GMT-0000
Tiki Roundtable Meeting
5)  15 Aug 2024 14:00 GMT-0000
Tiki Roundtable Meeting
6)  19 Sep 2024 14:00 GMT-0000
Tiki Roundtable Meeting
7) 
Tiki birthday
8)  17 Oct 2024 14:00 GMT-0000
Tiki Roundtable Meeting
9)  21 Nov 2024 14:00 GMT-0000
Tiki Roundtable Meeting
10)  19 Dec 2024 14:00 GMT-0000
Tiki Roundtable Meeting