Html blob 'global_content_block_x' does not exist

[chandra]

Which database related entries do you have inside your config.php?

[Rolf]

Which database related entries do you have inside your config.php?

Nothing special I think... Do you have a hunch what could be the cause?

Code: Select all

<?php
# CMS Made Simple Configuration File
# Documentation: /doc/CMSMS_config_reference.pdf
#
$config['timezone'] = 'Europe/Amsterdam';
$config['dbms'] = 'mysql';
$config['db_hostname'] = 'xxx';
$config['db_username'] = 'xxx';
$config['db_password'] = 'xxx';
$config['db_name'] = 'xxx';
$config['db_port'] = 0;
$config['db_prefix'] = 'cms_';

$config['root_url'] = 'http://www.domain.com';
$config['url_rewriting'] = 'mod_rewrite';
$config['debug_to_log'] = 'true';
?>

[Rolf]

What I do see each time the problem occurs is a simularity in IP addresses in the messages that are in the error log. They are always from bots, like google and facebook. I can't explain that at all, might be just an unrelated coincidence...

Humm, so it can be a external problem after all... http://stackoverflow.com/questions/1288 ... shing-site

[paulbaker]

Which database related entries do you have inside your config.php?

Nothing special for me either:

Code: Select all

<?php
# CMS Made Simple Configuration File
# Documentation: /doc/CMSMS_config_reference.pdf
#
$config['dbms'] = 'mysql';
$config['db_hostname'] = '127.0.0.1';
$config['db_username'] = 'xxx';
$config['db_password'] = 'xxx';
$config['db_name'] = 'xxx';
$config['db_prefix'] = 'cms_';
$config['db_port'] = 0;
$config['root_url'] = 'http://www.example.com';
$config['timezone'] = 'Europe/London';
$config['default_encoding'] = 'utf-8';
$config['url_rewriting'] = 'mod_rewrite';
$config['page_extension'] = '';
$config['admin_dir'] = 'xxx';
?>

Humm, so it can be a external problem after all... http://stackoverflow.com/questions/1288 ... shing-site

That's interesting. I checked my raw logs for period 31 January onwards. The last crash of the site was on 5 February. But there was no mention of facebook in the logs until 11 February when there is a series of hits like this:

Code: Select all

69.171.237.15 - - [11/Feb/2014:04:56:27 +0000] "GET / HTTP/1.1" 200 95541 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"

[Rolf]

@Paulbaker I have seen similar with Google bots...

The Facebook bot possibility would explain why my site breaks when CGBlog article on the site appears. I use HootSuite to push the article to Facebook and

For those having the problem, what kind of hosting?

Looking at my pool of sites, I have isolated it down to one shared host provider. I've NEVER seen this issue across several much larger,busier and more customized sites on VPS's or dedicated servers spread across various versions of 1.11.x

When having limited shared hosts or small VPS's (like I have) the server might goes down for a moment or even breaks... Resulting in the html block not found.

But how to prove this? And if proven, how to solve it

[paulbaker]

the server might goes down for a moment or even breaks... Resulting in the html block not found.

I can understand the server having a short period of unavailability or perhaps the SQL server being unavailable for a split second. That would perhaps affect one visit but all subsequent visits (or a refresh-browser from the initial visitor) would work OK, wouldn't they? The server would have recovered from whatever temporarily stopped it working earlier.

But what we're seeing is a semi-permanent error that is only cleared by clearing cache.

[velden]

the server might goes down for a moment or even breaks... Resulting in the html block not found.

I can understand the server having a short period of unavailability or perhaps the SQL server being unavailable for a split second. That would perhaps affect one visit but all subsequent visits (or a refresh-browser from the initial visitor) would work OK, wouldn't they? The server would have recovered from whatever temporarily stopped it working earlier.

But what we're seeing is a semi-permanent error that is only cleared by clearing cache.

But if CMSMS writes the cache file during this error situation, you got your semi-permanent error don't you.

What about blocking those specific requests via .htaccess? Or would that 'kill' your sites social-media-wise?

[chandra]

Do you have a hunch what could be the cause?

My idea goes to modify config param 'persist_db_conn' to change the behaviour.

[mortenb]

Unfortunately I have the same problem. I do see some heavy traffic from unknown crawlers:

Unknown robot (identified by 'bot*') 34,226+1013 3.12 GB 26 Feb 2014 - 02:55
Unknown robot (identified by 'crawl') 23,350+99 1.77 GB 25 Feb 2014 - 22:56
Unknown robot (identified by 'robot') 16,412+70 1.54 GB 26 Feb 2014 - 02:55

Those are mainly webmeup and the "Royal Danish Library" who is saving Danish websites.

Someone closing in on a solution to this issue?

[Rolf]

I moved my website (for other reasons) to another web host. Lets see what happens...

[paulbaker]

Well the problem occured again. I did not get Rolf's mousetrap email, because the "<!-- Html blob 'PanelBAS' does not exist -->" is not the type of error that produces the "Ooops" error page.

I have had to remove all GCBs now because it kept happening on a live site and there was no way of me being notified, until I (or someone else) noticed the missing content.

BUT... before I removed the GCBs I took a full backup of the site and DB (snapshot if you like) whilst it was in this error state. This has enabled me to do some investigations.

When I look at the files in the snapshot, the only ones with modification dates/times close to the time the CGBs failed are a series of cache files in the tmp/templates_c folder. There is one file for each GCB. All the 18 GCBs on the home page each have a modification time/date of 10:26 on the morning that the site crashed.

One such file is called:
/tmp/templates_c/058e944f1e08e0f59398246c1c397fe32f28c988.globalcontent.PanelBMS.php

("PanelBMS" is the name of the GCB.)

Here is the contents of that file:

Code: Select all

<?php /* Smarty version Smarty-3.1.16, created on 2014-03-04 10:26:34
         compiled from "globalcontent:PanelBMS" */ ?>
<?php /*%%SmartyHeaderCode:41932080652f37a820d8479-69929424%%*/if(!defined('SMARTY_DIR')) exit('no direct access allowed');
$_valid = $_smarty_tpl->decodeProperties(array (
  'file_dependency' => 
  array (
    '058e944f1e08e0f59398246c1c397fe32f28c988' => 
    array (
      0 => 'globalcontent:PanelBMS',
      1 => 1393928794,
      2 => 'globalcontent',
    ),
  ),
  'nocache_hash' => '41932080652f37a820d8479-69929424',
  'function' => 
  array (
  ),
  'version' => 'Smarty-3.1.16',
  'unifunc' => 'content_52f37a820e7de1_82002951',
  'has_nocache_code' => false,
),false); /*/%%SmartyHeaderCode%%*/?>
<?php if ($_valid && !is_callable('content_52f37a820e7de1_82002951')) {function content_52f37a820e7de1_82002951($_smarty_tpl) {?><!-- Html blob 'PanelBMS' does not exist  --><?php }} ?>

There are 18 files like this; one for each of the 18 GCBs on the home page of the site.

Then I checked the error log. There is only one error logged on that morning and it is timed at the same minute that all the GCB cache files above were last modified, here it is:

[04-Mar-2014 10:26:34 Europe/London] PHP Warning: Invalid argument supplied for foreach() in /home/three6cu/public_html/modules/Twitter/lib/class.Tweet.php on line 204

Line 204 of that code in /modules/Twitter/lib/class.Tweet.php is the foreach in here:

Code: Select all

        public static function parseTimeline($entries)
        {
            $timeline = array();

            foreach ($entries as $entry) {
                if(is_object($entry))
                {
                    $timeline[] = self::createFromObject($entry);
                }
                else
                {
                    // TODO: FIX THIS ISSUE... Here I cannot do a ->asXML because it's not an object....
//                    $timeline[] = self::createFromXml($entry->asXml());
                }
            }

            return $timeline;
        }

(That's not my TODO comment, by the way).

There is a call to the Twitter module at the top of the home page before all the GCBs.

Here is the code from the same cache file now, whilst the site is working OK:

Code: Select all

<?php /* Smarty version Smarty-3.1.16, created on 2014-03-19 14:01:08
         compiled from "globalcontent:PanelBMS" */ ?>
<?php /*%%SmartyHeaderCode:12871125495329a324538d74-53344239%%*/if(!defined('SMARTY_DIR')) exit('no direct access allowed');
$_valid = $_smarty_tpl->decodeProperties(array (
  'file_dependency' => 
  array (
    '058e944f1e08e0f59398246c1c397fe32f28c988' => 
    array (
      0 => 'globalcontent:PanelBMS',
      1 => 1391687213,
      2 => 'globalcontent',
    ),
  ),
  'nocache_hash' => '12871125495329a324538d74-53344239',
  'function' => 
  array (
  ),
  'has_nocache_code' => false,
  'version' => 'Smarty-3.1.16',
  'unifunc' => 'content_5329a32455d4e6_64794632',
),false); /*/%%SmartyHeaderCode%%*/?>
<?php if ($_valid && !is_callable('content_5329a32455d4e6_64794632')) {function content_5329a32455d4e6_64794632($_smarty_tpl) {?><?php if (!is_callable('smarty_function_global_content')) include '/home/three6cu/public_html/plugins/function.global_content.php';
if (!is_callable('smarty_function_cms_module')) include '/home/three6cu/public_html/plugins/function.cms_module.php';
if (!is_callable('smarty_function_SocialBookmarking')) include '/home/three6cu/public_html/plugins/function.SocialBookmarking.php';
?><div class="Anchor"><a id="BMS" name="BMS"></a></div>


....rest of HTML/PHP removed....


<?php }} ?>

So - it looks to me like the Twitter module falls over and this breaks the GCBs...somehow?

I'm hoping this info helps someone cleverer than me solve the issue.

Here is my system info:

----------------------------------------------
Cms Version: 1.11.10
Installed Modules:
CMSMailer: 5.2.2
CMSPrinting: 1.0.5
FileManager: 1.4.4
MenuManager: 1.8.6
MicroTiny: 1.2.6
ModuleManager: 1.5.5
News: 2.14.2
Search: 1.7.11
ThemeManager: 1.1.8
CMSForms: 1.10.14
Twitter: 2.0.2
FormBuilder: 0.7.3
CGExtensions: 1.38.1
CGSimpleSmarty: 1.7.1
CGBlog: 1.10.3
TinyMCE: 2.9.12
Archiver: 0.2.6
Statistics: 1.1.3
SEOTools2: 1.2.1
Notifications: 1.1

Config Information:
php_memory_limit:
process_whole_template:
max_upload_size: 32000000
url_rewriting: mod_rewrite
page_extension:
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.4.21
md5_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_STRICT: 0
E_DEPRECATED: 0
memory_limit: 128M
max_execution_time: 120
output_buffering: 4096
safe_mode: Off (False)
file_uploads: On (True)
post_max_size: 8M
upload_max_filesize: 32M
session_save_path: /tmp (1777)
session_use_cookies: On (True)
xml_function: On (True)
xmlreader_class: On (True)

Server Information:
Server Api: cgi-fcgi
Server Db Type: MySQL (mysql)
Server Db Version: 5.1.73
Server Db Grants: Could not find a suitable "GRANT ALL" permission. This may mean you could have problems installing or removing modules. Or even adding and deleting items, including pages
Server Time Diff: No filesystem time difference found

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

[tristan]

So - it looks to me like the Twitter module falls over and this breaks the GCBs...somehow?

I'm hoping this info helps someone cleverer than me solve the issue.

Yup that looks like the exact same problem I had, also posted this as a bug on the Twitter module page but the author didn't acknowledge it being a problem with his module. Have switched to Calguys Tweet Module and haven't seen this problem since.

[velden]

Calguy suggested about a database things however this Twitter module does not seem to do ANY db query/update expect during (un)install.

It does however do some caching stuff and maybe that is not properly set when the procedure is not completed due to the warning above.

[mortenb]

Unfortunately I have the same problem. I do see some heavy traffic from unknown crawlers:

Unknown robot (identified by 'bot*') 34,226+1013 3.12 GB 26 Feb 2014 - 02:55
Unknown robot (identified by 'crawl') 23,350+99 1.77 GB 25 Feb 2014 - 22:56
Unknown robot (identified by 'robot') 16,412+70 1.54 GB 26 Feb 2014 - 02:55

Those are mainly webmeup and the "Royal Danish Library" who is saving Danish websites.

Someone closing in on a solution to this issue?

The Royal Danish Library has been asked to reduce the activity of their crawler which they agreed upon- Webmeup has been blocked. For now it seems to have fixed the issue.

Even though the cause is external it seems like the reason is a not too fail-safe caching system in CMSMadesimple.

[chandra]

It's not difficult to block unknown crawlers by using htaccess - ask Google .