Welcome to Geeklog, Anonymous Monday, June 17 2024 @ 12:07 pm EDT

Geeklog Forums

Static page editor does not return all content!

Status: offline


Forum User
Registered: 05/14/08
Posts: 6
Hello all!
I've got the latest stable release of GL installed, along with the following plugins:
Caching (from GLLABS), and Media Gallery.

With and withou tthe caching enabled, and even with using the default professional theme, it seems that the static page editor just does not want to return all content for editing! Instead it seems to stop after part of the page and then cuts off the rest!

I'm using SQL Server 2005 as the backend, so not sure if that has anything to do with it.
Also, I notice that with EVERY story I enter, if nothing is entered into the body text, Read More always shows 2 words....but nothing is there!

Also, the Who's Online block never worked (disabled it anyways), but when creating new blocks, they never show up when enabled!

Status: offline


Site Admin
Registered: 01/12/02
Posts: 13073
Location:Stuttgart, Germany
There's a size restriction for content on MS SQL for technical reasons and it's pretty low. 5000 characters, I think.

So that would explain the cut-off pages. No idea about the other issues, though - I don't have any actual experience with running Geeklog on MS SQL.

bye, Dirk

Status: offline


Forum User
Registered: 05/14/08
Posts: 6
I'm confused then as to why the actual static page shows up correctly when its created, but then can't return the code in full?
Is there anything I can do with SQL or the geek code to fix this?


In fact in SQL the content field shows the text in its entirety...seems like its something on the geeklog side.

Status: offline


Forum User
Full Member
Registered: 08/29/05
Posts: 985
As a work around, if you don't need the ability to edit the staticpage online, you could move the code in the static page to a function in your lib-custom.php (or a file that you "include" from lib-custom) and then the staticpage would just be a call to the function.

Obviously this doesn't help if the people you want to be able to edit the page can't update files on your website. But if it's just you doing the editing, this should get you rolling until the MS SQL problem is figured out.

Status: offline


Forum User
Regular Poster
Registered: 10/18/05
Posts: 78
Location:Cary, NC USA
Adding to Joe's comment above, the following technique is also perfectly acceptable for the PHP staticpages, and works around the content field size limitation:

Text Formatted Code

global $_CONF;
$spid = 'ThisStaticPagesID';  <- matches Static Page ID
include $_CONF['path_html'] . '/sp/' . $spid .'php';

I typically name the script after the staticpage id, just so I can keep them straight, and set $spid accordingly. The 'include' code inherits the var scope you have defined above (it knows about $_CONF, $spid, etc. declared in the page itself).

Your included script can also include/require other things, and the only requirement is that you set the return variable equal to the HTML content you're trying to generate (standard PHP staticpage think), so that your staticpage option 'execute PHP (return)' actually results in somethings. Also when utilizing this methodology, while the PHP staticpage content does not need to be surrounded by <?php ?>, your included script does.

This does of course require that you create a directory to hold the scripts (you may want to protect this with .htaccess and a zero-length index.html) and manage the PHP staticpage scripts via FTP/file-transfer, rather than within GL itself.

I personally find this to be slightly more convenient, as then I can use the PHP editor of my choice rather than the Advanced Editor (which is OK, but others are much better).

Regarding your specific problem, I suspect this is related to the type of string variable that the SQL response is CAST to, and how the Advanced Editor (fckeditor) is dealing with it. fckeditor also inherently thinks you're creating HTML, and not PHP.

To be clear, the staticpage content is stored in gl_staticpage as field sp_content, type = 'text', which allows for a string up to 65535 characters. Therefore, if your PHP script is longer than this, it will be truncated.

Even so, I thought it curious that GL was treating fields of type 'text' differently. For instance, in /public_html/article.php, we are retrieving story content from table gl_stories (fields introtext & bodytext) with a CAST to type 'text', eg:

Text Formatted Code

$sql['mssql'] = "SELECT STRAIGHT_JOIN s.sid, s.uid, s.draft_flag, s.tid, s.date, s.title, CAST(s.introtext AS text) AS introtex
t, CAST(s.bodytext AS text) AS bodytext, s.hits, s.numemails, s.comments, s.trackbacks, s.related, s.featured, s.show_topic_icon, s.
commentcode, s.trackbackcode, s.statuscode, s.expire, s.postmode, s.frontpage, s.in_transit, s.owner_id, s.group_id, s.perm_owner, s
.perm_group, s.perm_members, s.perm_anon, s.advanced_editor_mode, "
     . " UNIX_TIMESTAMP(s.date) AS day, "
     . "u.username, u.fullname, u.photo, u.email, t.topic, t.imageurl "
     . "FROM {$_TABLES['stories']} AS s, {$_TABLES['users']} AS u, {$_TABLES['topics']} AS t "
     . "WHERE (s.uid = u.uid) AND (s.tid = t.tid) AND (sid = '$story')";

Yet in /plugins/staticpages/functions.inc, we see sp_content - also of type 'text' - retrieved without the CAST:

Text Formatted Code
$spsql = "SELECT sp_id,sp_title,sp_content,sp_format,owner_id,group_id,perm_owner,perm_group,perm_members,perm_anon,sp_php,sp_inblock,sp_help FROM {$_TABLES['staticpage']} WHERE (sp_centerblock = 1)" . COM_getLangSql ('sp_id', 'AND') . ' AND ' . $moresql . $perms . " ORDER BY " . $sort;

Significant? Perhaps not, but still a difference in how 'text' fields are handled, and more importantly, SQL implementations are deprecating the use of the text fieldtype, and are now recommending the use of varchar(n).

See: http://msdn.microsoft.com/en-us/library/ms187993.aspx

You may also find some interesting reading here, and even though it applies to MySQL, may also apply to other SQL server implementations. First the URL:


Halfway down the page:

The maximum size of a BLOB or TEXT object is determined by its type, but the largest value you actually can transmit between the client and server is determined by the amount of available memory and the size of the communications buffers. You can change the message buffer size by changing the value of the max_allowed_packet variable, but you must do so for both the server and your client program.

Anyway - in my mind the best way to avoid all of this unpleasantness is to utilize the sp_content only for short PHP scripts, and use the 'include trick' for very long scripts.


All times are EDT. The time is now 12:07 pm.

  • Normal Topic
  • Sticky Topic
  • Locked Topic
  • New Post
  • Sticky Topic W/ New Post
  • Locked Topic W/ New Post
  •  View Anonymous Posts
  •  Able to post
  •  Filtered HTML Allowed
  •  Censored Content