Edit Page Content timeout / submit issues

[LCarson]

Hi,

Following a recent hack and web host switch I've had a problem on a clients site. There was no issue before the hack but now when editing a web page's content the 'Apply' button doesn't work at all and clicking the 'Submit' button begins loading and eventually times out to receive a Fatal Error.

Other sections of the CMS admin work fine without issue.

The error received when clicking submit is:
Fatal error: Maximum execution time of 60 seconds exceeded in /home/acfbcoma/public_html/lib/classes/class.contentoperations.inc.php on line 462

I've tried many things taken from suggestions on other forum post including works to php.ini and config.php files but had no success.

I've also contacted the web host and was instructed edit php.ini file which I'd already done.

Checksum verification (1.11-english-checksum) seems fine too. Install files missing as they've been deleted.

I feel like I've tried everything and have spent a long time looking into this so any help would be appreciated.

CMSMS version 1.11 "Galapagos"
System Information:
----------------------------------------------

Cms Version: 1.11

Installed Modules:

CMSMailer: 5.2.1
CMSPrinting: 1.0.2
FileManager: 1.4.0
MenuManager: 1.8.2
FormBrowser: 0.4.2
ModuleManager: 1.5.5
Search: 1.7.6
ThemeManager: 1.1.7
FormBuilder: 0.7.3
TinyMCE: 2.9.10.1
Printing: 0.1.1
MicroTiny: 1.2.3
CGExtensions: 1.30
FrontEndUsers: 1.18.1
News: 2.12.7

Config Information:

php_memory_limit: 64M
process_whole_template: false
output_compression: false
max_upload_size: 24000000
url_rewriting: mod_rewrite
page_extension: .html
query_var: page
image_manipulation_prog: GD
auto_alias_content: true
locale:
default_encoding: utf-8
admin_encoding: utf-8
set_names: true

Php Information:

phpversion: 5.3.10
md5_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_STRICT: 0
E_DEPRECATED: 0
memory_limit: 64M
max_execution_time: 60
output_buffering: On
safe_mode: Off (False)
file_uploads: On (True)
post_max_size: 24M
upload_max_filesize: 24M
session_save_path: No check because open basedir active
session_use_cookies: On (True)
xml_function: On (True)
xmlreader_class: On (True)

Server Information:

Server Api: litespeed
Server Db Type: MySQL (mysql)
Server Db Version: 5.1.62
Server Db Grants: Found a "GRANT ALL" statement that appears to be suitable

----------------------------------------------

[staartmees]

add to your config.php

Code: Select all

ini_set('max_execution_time', 120);

[LCarson]

Thanks for the reply staartmees.

I inserted the code into the config.php file but unfortunately still get the same error.

System information below following recent tweeks.
Any other suggestions greatly appreciated.

----------------------------------------------

Cms Version: 1.11

Installed Modules:

CMSMailer: 5.2.1
CMSPrinting: 1.0.2
FileManager: 1.4.0
MenuManager: 1.8.2
FormBrowser: 0.4.2
ModuleManager: 1.5.5
Search: 1.7.6
ThemeManager: 1.1.7
FormBuilder: 0.7.3
TinyMCE: 2.9.10.1
Printing: 0.1.1
MicroTiny: 1.2.3
CGExtensions: 1.30
FrontEndUsers: 1.18.1
News: 2.12.7

Config Information:

php_memory_limit: 64M
process_whole_template: false
output_compression: false
max_upload_size: 24000000
url_rewriting: mod_rewrite
page_extension: .html
query_var: page
image_manipulation_prog: GD
auto_alias_content: true
locale:
default_encoding: utf8_general_ci
admin_encoding: utf-8
set_names: true

Php Information:

phpversion: 5.3.10
md5_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_STRICT: 0
E_DEPRECATED: 0
memory_limit: 64M
max_execution_time: 120
output_buffering: On
safe_mode: Off (False)
file_uploads: On (True)
post_max_size: 24M
upload_max_filesize: 24M
session_save_path: No check because open basedir active
session_use_cookies: On (True)
xml_function: On (True)
xmlreader_class: On (True)

Server Information:

Server Api: litespeed
Server Db Type: MySQL (mysqli)
Server Db Version: 5.1.62
Server Db Grants: Found a "GRANT ALL" statement that appears to be suitable

----------------------------------------------

[staartmees]

but now "max_execution_time: 120"

If you'r on shared hosting, time-out problems are common when you have to share resources with a 'busy' website.

It sometimes helps when you change your DNS in your modem/router.

[fredp]

Cms Version: 1.11
...
session_save_path: No check because open basedir active
...

Hi,

Not sure if this is related to your timeout problem, but it appears that open_basedir is set. Do you see a warning about this under Site Admin>>System Information on the Admin Console?

[LCarson]

Thanks alerting me to this fredp.

Yes there is a warning about the Session Save Path showing in system information.

I've tried inserting this into the php.ini file but the error is still persisting so I may not be using the correct path. I've contacted the web host to check the exact path for this and am awaiting a reply.

In the php.ini file I inserted this; trying many different paths ie full root directory and created another folder with chmod 777 etc ...

session.save_path = "tmp/cache"
Also tried:
php_value session.save_path "tmp/cache"

Hopefully this can be sorted out soon.

[staartmees]

my hosting - one.com - also has "session_save_path: No check because open basedir active" and cmsms works like a charm.

[LCarson]

Interesting thanks staartmees.

Still waiting on web host to reply re Open Basedir etc.

Could it possibly be something corrupt following the site hack?

Regards

[staartmees]

you could always reinstall your cmsms. First make a backup of your existing site and database. Second ftp the cmsms-files to your server and start the installation. But at the end do not install the tables, content and themes.

[LCarson]

I've reinstalled the cms a couple of times previously in an attempt to fix the problem but without success.

This leads me to think it could be a corrupt file ... I just created a copy of the site on another server to try and get it working correctly but the page edit content area still times out when clicking submit. Same issue with apply too.

This site copy doesn't have the session save path warning either.

Thanks

[fredp]

.../home/acfbcoma/public_html/lib/classes/class.contentoperations.inc.php on line 462

If you're still having trouble, there are a couple of things you might try just to collect a bit more information about what may be going on with the timeouts...

1. If you click Update under Update page hierarchy positions:, on the Site Admin>>System Maintenance page and the Cache and content tab of the Admin console, does the operation complete or timeout? Also, how many pages were found, under Content status?
2. If you go to the EventManager, under Extensions>>Event Manager, and if digits appear to the right of the Core events ContentEditPre or ContentEditPost, click on the digits to display what handlers are defined for these events, then post the results in a reply to this topic.

[LCarson]

Thanks fredp,

When clicking the 'update page hierachy positions' button the page does timeout.
It shows 57 pages found.

Also here are the results for ContentEditPost:

ContentEditPost
Sent after edits to content are saved.

Parameters
'content' - Reference to the affected content object.
Event Handlers
1. Module: MenuManager
2. Module: Search

ContentEditPre had no digits.

Regards

[fredp]

...
When clicking the 'update page hierachy positions' button the page does timeout.
It shows 57 pages found. ...

Thanks. These tests were an attempt to see if your timeout problem is isolated to a particular operation or more general in nature. It would appear that the issue is not constrained to ContentEdit alone, since it also happens when just rebuilding the hierarchy positions in the db.

...
ContentEditPost
...
Event Handlers
1. Module: MenuManager
2. Module: Search

ContentEditPre had no digits.

Nothing unexpected here. I just wanted to see if some other modules or UDTs were handling these two events and possibly slowing things down.

Say, does it actually take ~120 seconds for the timeout to occur?

Longer than 120 might be expected since max_execution_time doesn't include db query time, etc. -- at least on linux/apache...

The set_time_limit() function and the configuration directive max_execution_time only affect the execution time of the script itself. Any time spent on activity that happens outside the execution of the script such as system calls using system(), stream operations, database queries, etc. is not included when determining the maximum time that the script has been running. This is not true on Windows where the measured time is real.

Shorter than 120 seconds might mean that your setting is being ignored (check phpinfo) or you're hitting a different timeout someplace else, like your web server. I haven't used the litespeed web server. Perhaps you could check if there are relevant timeout settings there.

Wish I could have been more help.
fredp