Page 3 of 4

Re: Fatal error: Call to a member function getContent()

Posted: Wed Nov 16, 2011 12:57 pm
by Bilmartech
Seriously.. My heart stopped this morning when I saw this error! I immediately came here to see if there was a thread about it and found this one! Cleared the cache and it's fine!

I just want to say thank you guys so much! This was a lifesaver!

Re: Fatal error: Call to a member function getContent()

Posted: Wed Nov 16, 2011 6:54 pm
by psy
Did some digging in the cms_selflink code. The line on which it's failing, 283 refers to the dir='start' option. I'd forgotten that on this site, I'd used the NCleanBlue template as the basis which has:

{cms_selflink dir="start" rellink=1}
{cms_selflink dir="prev" rellink=1}
{cms_selflink dir="next" rellink=1}

in the <head> section for accessibility.

I've since deleted these tags from my template. Can only wait and see if this workaround solves the problem.

HTH
psy

Re: Fatal error: Call to a member function getContent()

Posted: Thu Nov 24, 2011 2:34 am
by psy
Hi

Removing the {cms_selflink} tag stopped that error being thrown however the site crashed again today. This time SEOTools was the culprit although the GetContent() error was the same.

The site on which it's happening for me has been using CMSMS for 3 years without issue. It was only after a major rebuild and upgrade to 1.9.4.3 that the problem arose.

I believe the root cause is the new task to clear the cache introduced in CMSMS 1.9 and I've been trying to find a common link between all the posters on this topic.

The only thing I've found is that we all (or those that I could trace, eg Australia, Sweden and Kenya) are in time zones ahead of GMT.

Here's my theory...

In index.php:

Code: Select all

  else
    {
      // as far as we know, the output is cachable at this point...
      // so we mark it so that the output can be cached.
      header('Expires: '.gmdate("D, d M Y H:i:s",time() + $expiry * 60).' GMT');
      $the_date = time();
      if( $contentobj->Cachable() )
  {
    $the_date = $contentobj->GetModifiedDate();
  }
      header('Last-Modified: ' . gmdate('D, d M Y H:i:s',$the_date) . ' GMT');
    }

  cmsms()->set_variable('content_obj',$contentobj);
  $smarty->assign('content_obj',$contentobj);
The Last-Modified date doesn't appear to make allowances for local time. It just converts the local time to a string. Depending on the actual time the file was modified and the GMT difference and only in time zones ahead of GMT, this could result in an invalid date, ie the Last Modified date is later than the GMT real date.

In include.php, each time a page is loaded it calls the CmsRegularTaskHandler that executes the ClearCache task once a day which in turn calls the clear_cached_files method in class.global.inc.php.

This method uses the php function getMTime() - get modified time - that doesn't make allowances for local time zones either and because we've entered an invalid date, the value is 0. That makes the IF statement TRUE and the file is deleted.

Meanwhile CMSMS is working in local time and thinks everything is hunky dory and trots off to retrieve the cached version. Of course, by now the cached file doesn't exist and the whole thing goes pear-shaped.

As mentioned in previous threads, manually clearing the cache from the Site Admin section temporarily fixes the site however it doesn't offer a long term solution.

This may also explain why:
  • - Members of the Dev Team based in North America (behind GMT so the situation would never arise) can't reproduce the problem
  • - Forum members from Australia (GMT +10) are most susceptible and hence vocal in this topic thread.
  • - The problem appears to be erratic
Of course I could be completely wrong and if anyone has any better ideas, please say so. Dev team??

It's a real showstopper for me.

psy

NB: Although my site most affected by the problem is running 1.9.4.3, other comments indicate it's happening in 1.10 and 1.10.1 and I couldn't find anything in the Release Notes or Change log for 1.10.2 to say the issue is fixed.

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

Cms Version: 1.9.4.3

Installed Modules:

CMSMailer: 2.0.1
FileManager: 1.1.0
MenuManager: 1.7.6
ModuleManager: 1.4.2
News: 2.11.4
nuSOAP: 1.0.2
Printing: 1.1.2
Search: 1.6.10
ThemeManager: 1.1.4
TinyMCE: 2.8.4
CGExtensions: 1.27.1
CGSimpleSmarty: 1.4.8
Archiver: 0.2.4
CGCalendar: 1.8.3
CompanyDirectory: 1.10.8
FrontEndUsers: 1.16.2
CustomContent: 1.7.3
HostedVideoAlbums: 2.2
FormBuilder: 0.7
JQueryTools: 1.0.10
SelfRegistration: 1.6.13
SEOTools: 1.2
Showtime: 2.0.5
Statistics: 1.1.3
Gallery: 1.4.4
CGPaymentGatewayBase: 1.0.11
CGEcommerceBase: 1.3.5
Orders: 1.13
Products: 2.15
Cart: 1.8.1
FRTaxes: 1.1.1
CGGoogleMaps: 2.1.4
CGFBApp: 1.0.3
CMTicketSales: 1.0
Promotions: 1.0.14
SameCountryTax: 1.1.1
eWAYHosted: 1.0
CGMyOrders: 1.0
PaypalGateway: 2.3.5
FEUToBigCommerce: 0.1


Config Information:

php_memory_limit:
process_whole_template: false
output_compression: false
max_upload_size: 20000000
default_upload_permission: 664
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.2.17
md5_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_STRICT: 0
memory_limit: 32M
max_execution_time: 30
output_buffering: On
safe_mode: Off (False)
file_uploads: On (True)
post_max_size: 20M
upload_max_filesize: 20M
session_save_path: /tmp (1777)
session_use_cookies: On (True)
xml_function: On (True)


Server Information:

Server Api: cgi
Server Db Type: MySQL (mysql)
Server Db Version: 5.0.92


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

Re: Fatal error: Call to a member function getContent()

Posted: Thu Nov 24, 2011 2:47 am
by Bilmartech
I'm not sure one way or the other if you are on the right track.. but i am in North America and my time zone is -5 GMT if that helps to narrow down anything on your end..

I can also say that I have been running the site for over a year and never experienced this issue until the last post I did. I am running 1.9.4.3 "Faanui" and this is the only major thing that changed for me along with the CGextension 1.27.1 upgrades if that helps.

Re: Fatal error: Call to a member function getContent()

Posted: Thu Nov 24, 2011 3:47 am
by calguy1000
I personally don't think your issue is related at all to timezones or anything else. I think it is related to a pure database corruption issue of some sort.

Unfortunately.... unless somebody can provide exact steps for me to reproduce the problem (browse to this page on your site doesn't help). I can't tell you if it is fixed or not.

Re: Fatal error: Call to a member function getContent()

Posted: Thu Nov 24, 2011 6:58 am
by psy
Thanks Calguy and Bilmartech for your quick responses. Blows my time zone/cache theory out of the water.

Calguy: happy to give you whatever you need including a copy of the database.

Exact steps to recreate the issue: Enter the URL in the browser address bar and hit enter. Obviously this doesnt help at all.

The site gets around 2000 visitors a day and the page will load perfectly 1000s of times over several days and then boom!

That's what lead me to look into the time zone/cache thing.

Bilmartech: Your site was an upgrade. So was mine, in steps from 1.6.7 to 1.9.4.3, ie not one big leap. Maybe upgrading is the common factor?

Calguy: Any ideas as to where I should start looking in the database would be much appreciated.

Thanks
psy

Re: Fatal error: Call to a member function getContent()

Posted: Thu Nov 24, 2011 7:02 am
by gocreative
psy wrote:Bilmartech: Your site was an upgrade. So was mine, in steps from 1.6.7 to 1.9.4.3, ie not one big leap. Maybe upgrading is the common factor?
Mine was an upgrade too. Never had the problem before upgrading.

Re: Fatal error: Call to a member function getContent()

Posted: Sat Nov 26, 2011 2:10 am
by psy
After much more digging, I've found similarities between the point of failure in both {cms_selflink} and {SEOTools}.

The trail begins in index.php at:

Code: Select all

		if( isset($config['process_whole_template']) && $config['process_whole_template'] === false )
		  {
		    $top  = $smarty->fetch('tpl_top:'.$contentobj->TemplateId());
		    $body = $smarty->fetch('tpl_body:'.$contentobj->TemplateId());
		    $head = $smarty->fetch('tpl_head:'.$contentobj->TemplateId());
		    $html = $top.$head.$body;
		  }
		else
		  {
		    $html = $smarty->fetch('template:'.$contentobj->TemplateId());
		  }

The content object looks first for the template id in the cache. I know it gets it as the page is partially rendered before crashing.

The next step is to process the template which if cached, is in tpl_top php and inc, tpl_body php and inc and tpl_head php and inc.

If the files aren't cached and CMSMS knows they're not cached, it builds them from scratch. All good so far and that's why manually clearing the cache temporarily resolves the problem.

However, if there are multiple requests and one of the requests triggers the ClearCache task and it has not finished, another of the requests, maybe milliseconds apart, is under the impression that the cache files still exist, and it's possible that they do.

The failure happens when a Smarty object, in this case cms_selflink or SEOTools, goes to retrieve contentcache.php which contains the serialized hierarchy tree AND IT'S BEEN DELETED.

cms_selflink contains the call:

Code: Select all

$content =& $flatcontent[$i]->getContent();
where $flatcontent[$i] should be a HierarchyManager object but it failed to instantiate.

SEOTools calls:

Code: Select all

$curcontent =& $curnode->GetContent();
where $curnode should be a HierarchyManager object but it failed to instantiate.

When the getContent() or GetContent() method is called, the error message reports exactly what happened, ie "
Fatal error: Call to a member function getContent() on a non-object".

While I've scrapped my time-zone theory, I still believe the problem is time and cache related rather than a database corruption issue and if that is the situation, the busier a site is, the more likely the crash will occur.

I hope this helps in finding a solution.

psy

Re: Fatal error: Call to a member function getContent()

Posted: Fri Dec 16, 2011 3:41 am
by psy
Bump - Help please anyone?

My site just crashed for the 9th time since Nov 10 - and it's only moderately busy.

Removing SEOTools wont solve the problem as the next smarty tag that needs a Hierarchy Manager object is MenuManager.

psy

Re: Fatal error: Call to a member function getContent()

Posted: Thu Dec 22, 2011 2:12 pm
by MFF
Hi,

I have a new website since septembre with the 1.9.4.2 "Faanui" version. I have the same problem... I have many other websites with older versions and never had problem...

Somebody knows if this problem happen with 1.10.2 version ?

PS: excuse my bad english...it's not my first language

Re: Fatal error: Call to a member function getContent()

Posted: Tue Jan 10, 2012 12:14 pm
by psy
Doh! Happened again twice in the last two days.

As good a feature is as caching, how do I turn it off? I've tried all the recommended settings and nothing works.

Even if my theory is wrong, is there no one in the dev team that can offer a solution?

[solved] Re: Fatal error: Call to a member function getConte

Posted: Mon Jan 30, 2012 9:09 am
by psy
There were lots of red herrings on this one, including the cms_selflink issue.

I've since discovered that SEOTools is about as incompatible with CMSMS v1.10+ as you can get! Which is a shame cos it was a fantastic module up until then. While the Fatal Error was the most obvious, there were other problems as well.

For anyone interested, I have forked the project in the Forge with a module called SEOTools2 that works with CMSMS 1.9+.

The most major change made was to remove all references to HierarchyManger objects (code is marked as Deprecated anyway).

The other biggie was to ensure that ALL pages are registered in the seotools2 table, not just those that were manually edited in the SEOTools2 admin area. Now when the module goes looking for an active page, it will find something, not nothing.

Hope this helps
psy

PS: Thanks Calguy for suggesting I look in the database. It wasn't a database corruption, it was a database omission. The stuff needed to perform the function simply was not there.

Re: Fatal error: Call to a member function getContent()

Posted: Wed Feb 15, 2012 7:55 am
by psy
Doh, doh and quadruple doh!!!!

This time the culprit was MenuManager which uses hierarchy manager objects and also specifically calls the serialized content hierarchy tree in the cache directory.

While some of the SEOTools issues were database related, this is NOT. The cause is 100% code related and part of the core.

Seriously folks, what do I need to do to get a resolution to this problem?

psy :(

Re: Fatal error: Call to a member function getContent()

Posted: Wed Feb 15, 2012 6:19 pm
by MFF
It was really "problematic" to have this problem... I try something just to see what it going to happen...

Browser Cache Settings
Browser Cache Expiry Period (minutes): 0

Server Cache Settings
Remove cache files that are older than the specified number of days: 1


I don't notice any problem else and THE problem did not reapear !

I think it's not probably a good thing to put the browser cache to 0 but it was a test...and I dont had any problem after... What can I think after that ?

Re: Fatal error: Call to a member function getContent()

Posted: Wed Feb 15, 2012 6:41 pm
by calguy1000
a: The browser cache expiry will not have anything to do with this problem.
That effects headers that tell the browser how much time it can use that page without re-requesting it from the server.

b: The 'delete cache files older than N days' may effect the problem. However it should not effect it unless:
i: absolutely no content pages are being changed
ii: the site is under significant load
and then only when the contentcache.php file is older than N days old and at the first request of a page after that file is deleted.

more likely:
You have a plugin, UDT, or module that is clearing files it should not be. There are some modules that I kinow of that are clearing cache files on each request, or after certain events.... and that is a bad thing to do.

so:
Check your UDT's and 3rd party modules/plugins to make sure that they are not messing with the cache.