CMS Made Simple Forums

Whenever I edit content in the Content Manager and click the Preview tab, I always see this instead of the page preview:

Just wondering why this is? Thanks.


----------------------------------------------
Cms Version: 2.1.6
Installed Modules:
AdminSearch: 1.0.2
Banners: 2.9.1
CGBlog: 1.14.1
CGExtensions: 1.53.17
CGJobMgr: 1.3.4
CGSimpleSmarty: 2.1.6
CMSContentManager: 1.1.4
CMSMailer: 6.2.14
Captcha: 0.5.3
DesignManager: 1.1.1
FileManager: 1.5.2
FormBuilder: 0.8.1.4
JQueryTools: 1.3.9
MicroTiny: 2.0.3
ModuleManager: 2.0.5
NMS: 2.12.2
Navigator: 1.0.3
News: 2.50.6
Search: 1.50.2
ThemeManager: 1.1.8

Config Information:
php_memory_limit:
max_upload_size: 100000000
url_rewriting: none
page_extension:
query_var: page
auto_alias_content: true
locale:
set_names: true
timezone: Europe/London
permissive_smarty: false

Php Information:
phpversion: 7.0.1
md5_function: On (True)
json_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_ALL: 24575
E_STRICT: 2048
E_DEPRECATED: 0
test_file_timedifference: No time difference found
test_db_timedifference: No time difference found
create_dir_and_file: 1
memory_limit: 128M
max_execution_time: 60
register_globals: Off (False)
output_buffering: On
disable_functions:
open_basedir:
test_remote_url: Success
file_uploads: On (True)
post_max_size: 100M
upload_max_filesize: 100M
session_save_path: /tmp (1777)
session_use_cookies: On (True)
xml_function: On (True)
xmlreader_class: On (True)
check_ini_set: On (True)
curl: On

Performance Information:
allow_browser_cache: Off (False)
browser_cache_expiry: 60
php_opcache: Off (False)
smarty_cache: Off (False)
smarty_compilecheck: Off (False)
smarty_cache_udt: Off (False)
auto_clear_cache_age: On (True)
Server Information:
Server Software: Apache
Server Api: cgi-fcgi
Server Os: Linux 3.2.83 On x86_64
Server Db Type: MySQL (mysqli)
Server Db Version: 5.7.16
Server Db Grants: Found a "GRANT ALL" statement that appears to be suitable

Permission Information:
tmp: /var/sites/m/m.co.uk/public_html/tmp (0755)
tmp_cache: /var/sites/m/m.co.uk/public_html/tmp/cache (0755)
templates_c: /var/sites/m/m.co.uk/public_html/tmp/templates_c (0755)
modules: /var/sites/m/m.co.uk/public_html/modules (0755)
uploads: /var/sites/m/m.co.uk/public_html/uploads (0755)
File Creation Mask (umask): /var/sites/m/m.co.uk/public_html/tmp/cache (0755)
config_file: 0444
----------------------------------------------

I did consider this might be due to PHP session variables not working, since line 80 of index.php is checking to see if a session variable is set. So I did a test of this by creating two files:


session-test1.php: session-test2.php: The test worked fine though; the random number stored in the session variable in session-test1.php is displayed correctly when session-test2.php loads, so I can't figure out what's going wrong with CMSMS Content Preview.

I experience the same trouble with my Web site. The content preview is showing 'preview selected, but temp data not found'.

Stranger yet, I have made a copy of the site on a virtual Ubuntu lamp and the preview is working correctly.

Did you find out how to correct this?

Thanks

I wonder if this is normal chmod permission for
session_save_path: /tmp (1777)

jmbezeau wrote:Did you find out how to correct this?

No, my content manager preview tab still produces the error message instead of the preview content.

I would watch the developer console for javascript errors and 500/404 errors etc. in the network panel.

I think you're having javascript and/or mod_security issues. or something like that.

JohnnyB wrote:I wonder if this is normal chmod permission for
session_save_path: /tmp (1777)

You're definitely on to something there. I created a new directory called "sessions" with drwxr-xr-x permissions in my home directory, then I pointed PHP's session.save_path directive to that directory. Sure enough, the preview tab now works.

Not sure where the "blame" lies, but at least my preview tab is functional now.

I've looked into my host's PHP configuration a little bit more, and they have set this by default:
If I'm reading it right, those settings mean session garbage collection will never be performed, and so sessions will keep piling up in /tmp. It's wholly possible I suppose that as a result they are using alternative means of garbage collection, and quite possibly one that is breaking the sessions used by the preview tab.

Since I'm now managing the sessions folder in my home directory, I'll switch session.gc_probability to the PHP developer's default value of 1, so that garbage collection can run occasionally.

Likely that the permissions of your host's /tmp/ directory are set wrong. The permissions prevent access to applications running on their user accounts. Unfortunately, all you can do is specify your own /tmp directory like you did. Glad it worked.

Unfortunately a new issue has arisen. After changing the PHP session save path to a directory in my home directory, I find that when I edit a content page and click "Submit", the page takes around 100 seconds to reload.

That's bad enough by itself, but additionally when the page finally reloads the content manager displays the list of pages with the page I just edit locked by me for 60 minutes with no option to steal the lock. So the only way to re-edit the page after that is to clear all content locks from the options menu. The same thing happens if I click "Cancel" when editing content.

I think I'll revert the changes and set the session save path back to /tmp, since breaking the content preview tab is now the lesser of two evils!

I've also managed to verify that PHP session files are being generated by using this code:
It lists tons of sess_* files from various users, but every file is only readable and writeable by the file owner (the process which read/writes must be running as each site's owner, suEXEC). I can see some of the PHP session files are mine, so I am able to write to that directory.

So I'm still puzzled as to why content preview is broken when session save path is set to /tmp, and also puzzled as to why I see the bad effects I saw when setting session save path to my own directory.

You might try a session save path above your public_html

so, if you have a path like, home/your-account/public_html/
do something like create a /tmp/ inside of /your-account/

But, the right thing to do is to contact your host and verify that PHP configs and user permissions are set correctly. It is weird to me that they are setting a Sticky Bit (the leading 1 in 1777). Typical permissions would look like 0777

I would question that and since you know that it works on a different server, you can safely assume that the server environment is not set correctly.

JohnnyB wrote:You might try a session save path above your public_html

so, if you have a path like, home/your-account/public_html/
do something like create a /tmp/ inside of /your-account/

That's what I did, I created a folder called sessions in my home directory, i.e. the directory above public_html. I did not give it the sticky bit.

JohnnyB wrote:But, the right thing to do is to contact your host and verify that PHP configs and user permissions are set correctly. It is weird to me that they are setting a Sticky Bit (the leading 1 in 1777). Typical permissions would look like 0777

I don't see why the sticky bit would be an issue since all it does is prevent other people moving or deleting my temp and session files, which is a sane configuration for a shared environment. And suexec means the session files in there are owned be me.

From Wikipedia:

https://en.wikipedia.org/wiki/Sticky_bit wrote:Without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of the file's owner. Typically this is set on the /tmp directory to prevent ordinary users from deleting or moving other users' files.

In any case, I have verified that the session files are being created in there, and are being deleted after an hour or so.

JohnnyB wrote:I would question that and since you know that it works on a different server, you can safely assume that the server environment is not set correctly.

But equally I can change the session save path to a directory of my choice with and give it any permissions I choose, and I still have the issues I mentioned in respect to Submit/Cancel taking 100 seconds, as well as the lock issue.

It's most likely to do with server configuration I agree, however I don't think the sticky bit is the issue, nor can I work out why my customised session save path creates the issues it does, so I don't feel I have anything concrete to challenge the web host with.

Ideally I would create a very simple piece of code which would break the session variable in the same way as the content preview tab does, but I haven't been able to create any such code.

Maybe obvious but be sure to clear the cache from the system maintenance screen anytime server configs change. As far as the sticky bit, it sounds like it would be ok. What has your host said? There should be a php error log or Apache log that can be looked at to see the actual problem.

Without something specific to test and to reproduce, it is challenging to know what is going on. I don't know if it is a common issue or confirmed bug. So, my gut tells me there may something unique happening in your case.

JohnnyB wrote:Maybe obvious but be sure to clear the cache from the system maintenance screen anytime server configs change.

Cache cleared, no difference.

JohnnyB wrote:What has your host said?

I don't feel I can raise it unless I have more proof something is broken with their configuration. My website works 99% fine, so given it is just affecting a very small element of the website's function, they will most likely put it down to a bug in CMSMS rather than something fundamentally broken in their system which is affecting all users. Aside from the preview tab, my sessions in CMSMS seem to work fine.

JohnnyB wrote:There should be a php error log or Apache log that can be looked at to see the actual problem.

I have access to both logs, they show no issues. This is the Apache log when the preview tab is loaded unsuccessfully, maybe there's a clue in there:

JohnnyB wrote:So, my gut tells me there may something unique happening in your case.

It's also affecting the other user reporting the issue in this thread, "jmbezeau". I suppose we may be sharing the same web host.