Geeklog Forums

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!

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

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.

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.

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:


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:


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



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:

http://dev.mysql.com/doc/refman/5.0/en/blob.html

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.

-m