Upgrade 1.8.2 to 1.9.2 Problem
Upgrade 1.8.2 to 1.9.2 Problem
Hi!
After upgrading cmsms from 1.8.2 to 1.9.2 my Site is looking like that http://neu.edelsteinengel.de but it should look like that http://edelsteinengel.de
php_error.log says "PHP Fatal error: Call to a member function Active() on a non-object in /PathToWebRoot/MenuManager/MenuManager.module.php on line 262"
After upgrading or while upgrading php_error.log says "PHP Notice: Indirect modification of overloaded element of cms_variables has no effect in /PathToWebRoot/admin/header.php on line 37
[14-Dec-2010 10:13:27] PHP Fatal error: Cannot assign by reference to overloaded object in /PathToWebRoot/admin/header.php on line 37
"
I tried different themes but no one works.
A blank new installation of 1.9.2 works fine but I don't know how to transver sitecontent from old to the new version.
On admin-area all looks fine and works.
Any ideas?
heiko
After upgrading cmsms from 1.8.2 to 1.9.2 my Site is looking like that http://neu.edelsteinengel.de but it should look like that http://edelsteinengel.de
php_error.log says "PHP Fatal error: Call to a member function Active() on a non-object in /PathToWebRoot/MenuManager/MenuManager.module.php on line 262"
After upgrading or while upgrading php_error.log says "PHP Notice: Indirect modification of overloaded element of cms_variables has no effect in /PathToWebRoot/admin/header.php on line 37
[14-Dec-2010 10:13:27] PHP Fatal error: Cannot assign by reference to overloaded object in /PathToWebRoot/admin/header.php on line 37
"
I tried different themes but no one works.
A blank new installation of 1.9.2 works fine but I don't know how to transver sitecontent from old to the new version.
On admin-area all looks fine and works.
Any ideas?
heiko
Last edited by heiend on Tue Dec 14, 2010 9:38 am, edited 1 time in total.
Re: Upgrade 1.8.2 to 1.9.2 Problem
I'm in the same boat. I did a fresh install with 1.9.2 to a test site, so far so good. However, when I tried to upgrade CMSMS 1.8.2, my site crashed. So I had to asked my hosting company for a restore since they couldn't resolve the issue. So I'm a bit hesitate to upgrade again after reading your comment. Will wait for the expert and hopefully to find a solution for it.
Re: Upgrade 1.8.2 to 1.9.2 Problem
I can confirm these upgrade problems. I'm suffering from this too 
I hope that someone finds a solution for this soon.
Amendra

I hope that someone finds a solution for this soon.
Amendra
Re: Upgrade 1.8.2 to 1.9.2 Problem
First place I would look is in extensions module manager to make sure no extra modules needed upgrading, like CGExtensions, etc...
Re: Upgrade 1.8.2 to 1.9.2 Problem
Yes, that was my idea too
which I did. I uninstalled all extensions which I don't need. But it didn't work. I deleted the core files and the standard extensions and replaced them with new fresh install several times but to no avail.
I remembered that I updated another site some days ago in smaller steps - from 1.8.2 to 1.9.1 to 1.9.2. That went smooth - more or less. But it didnt' mess up the front pages like today and in one big step.
Edit: That doesn't work either. I just upgraded from 1.8.2 to 1.9.1 - same problem.
Maybe it's interesting to know that the whole header doesn't get parsed. The HTML output starts with the body tag and gets interrupted at the menu tag.
Permissions are not a problem because I'm on a local Windows machine (XP SP3) with Apache 2.2.14 installed. Here is my configuration for testing purposes:
----------------------------------------------
Cms Version: 1.9.2
Installed Modules:
* Album: 0.9.4
* CMSMailer: 2.0
* MenuManager: 1.7.4
* ModuleManager: 1.4
* News: 2.11
* nuSOAP: 1.0.2
* Search: 1.6.8
* ThemeManager: 1.1.3
* ContentAliases: 0.6.11
* pisearch: 1.82
* FileManager: 1.0.3
* FCKeditorX: 1.1.0
* TinyMCE: 2.8.2
* FormBuilder: 0.6.2
* ImageUpload: 0.1.2
* TranslationManager: 0.7.8
* AdvancedContent: 0.7.1
* Gallery: 1.4.1
* MultiDomains: 1.3.1
* MySQLManager: 1.2.5
Config Information:
* php_memory_limit:
* process_whole_template: false
* output_compression: false
* max_upload_size: 128000000
* default_upload_permission: 664
* url_rewriting: mod_rewrite
* page_extension: .html
* query_var: page
* image_manipulation_prog: GD
* auto_alias_content: true
* locale: de_DE
* default_encoding: utf-8
* admin_encoding: utf-8
* set_names: false
Php Information:
* phpversion: 5.3.1
* 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: 60
* output_buffering: On
* safe_mode: Off (False)
* file_uploads: On (True)
* post_max_size: 128M
* upload_max_filesize: 128M
* session_save_path: C:\Programme\Web-Tools\Xampp\xampp\tmp (0777)
* session_use_cookies: On (True)
* xml_function: On (True)
Server Information:
* Server Api: apache2handler
* Server Db Type: MySQL (mysql)
* Server Db Version: 5.1.41
----------------------------------------------
Thank you!
Amendra

I remembered that I updated another site some days ago in smaller steps - from 1.8.2 to 1.9.1 to 1.9.2. That went smooth - more or less. But it didnt' mess up the front pages like today and in one big step.
Edit: That doesn't work either. I just upgraded from 1.8.2 to 1.9.1 - same problem.
Maybe it's interesting to know that the whole header doesn't get parsed. The HTML output starts with the body tag and gets interrupted at the menu tag.
Permissions are not a problem because I'm on a local Windows machine (XP SP3) with Apache 2.2.14 installed. Here is my configuration for testing purposes:
----------------------------------------------
Cms Version: 1.9.2
Installed Modules:
* Album: 0.9.4
* CMSMailer: 2.0
* MenuManager: 1.7.4
* ModuleManager: 1.4
* News: 2.11
* nuSOAP: 1.0.2
* Search: 1.6.8
* ThemeManager: 1.1.3
* ContentAliases: 0.6.11
* pisearch: 1.82
* FileManager: 1.0.3
* FCKeditorX: 1.1.0
* TinyMCE: 2.8.2
* FormBuilder: 0.6.2
* ImageUpload: 0.1.2
* TranslationManager: 0.7.8
* AdvancedContent: 0.7.1
* Gallery: 1.4.1
* MultiDomains: 1.3.1
* MySQLManager: 1.2.5
Config Information:
* php_memory_limit:
* process_whole_template: false
* output_compression: false
* max_upload_size: 128000000
* default_upload_permission: 664
* url_rewriting: mod_rewrite
* page_extension: .html
* query_var: page
* image_manipulation_prog: GD
* auto_alias_content: true
* locale: de_DE
* default_encoding: utf-8
* admin_encoding: utf-8
* set_names: false
Php Information:
* phpversion: 5.3.1
* 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: 60
* output_buffering: On
* safe_mode: Off (False)
* file_uploads: On (True)
* post_max_size: 128M
* upload_max_filesize: 128M
* session_save_path: C:\Programme\Web-Tools\Xampp\xampp\tmp (0777)
* session_use_cookies: On (True)
* xml_function: On (True)
Server Information:
* Server Api: apache2handler
* Server Db Type: MySQL (mysql)
* Server Db Version: 5.1.41
----------------------------------------------
Thank you!
Amendra
Last edited by Amendra on Tue Dec 21, 2010 2:14 am, edited 1 time in total.
Re: Upgrade 1.8.2 to 1.9.2 Problem
Okay, so now after a long period of extensive testing: It's definitely the MenuManager It kills the whole header parsing (for whatever reason) and breaks at the aforementioned line. The moment I deactive the menu call within the template the rest of the page gets parsed as it should be.
The second factor is the old database. For testing i connected my other two 1.92 installs (both of them running without problems) with the old database from 1.82. Guess what? They show the same error in the frontend!
On this second test series I deactivated all modules before the upgrade that either didn't ship with the core or were known to be fine with an update (as experienced from another update on a different site). I cleaned the database from all leftover tables of the deactivated modules and deleted them from the module folder.
These are the modules which i kept activated:
Album 0.9.4
CMSMailer 2.0
MenuManager 1.7.4
ModuleManager 1.4
News 2.11
nuSOAP 1.0.2
Search 1.6.8
ThemeManager 1.1.3
ContentAliases 0.6.8
FileManager 1.0.3
TinyMCE 2.8.2
FormBuilder 0.6.2
TranslationManager 0.7.8
AdvancedContent 0.5
Gallery 1.4.1
The moment I deactivated the MenuManager module everything was fine again - apart from the missing menu, of course
Okay, guys, now it's your turn. I'd be happy if you could find the problem's source.
And please excuse my clumsy english, it's not my native tongue and it's nearly five in the morning...
Good night!
Amendra
The second factor is the old database. For testing i connected my other two 1.92 installs (both of them running without problems) with the old database from 1.82. Guess what? They show the same error in the frontend!
On this second test series I deactivated all modules before the upgrade that either didn't ship with the core or were known to be fine with an update (as experienced from another update on a different site). I cleaned the database from all leftover tables of the deactivated modules and deleted them from the module folder.
These are the modules which i kept activated:
Album 0.9.4
CMSMailer 2.0
MenuManager 1.7.4
ModuleManager 1.4
News 2.11
nuSOAP 1.0.2
Search 1.6.8
ThemeManager 1.1.3
ContentAliases 0.6.8
FileManager 1.0.3
TinyMCE 2.8.2
FormBuilder 0.6.2
TranslationManager 0.7.8
AdvancedContent 0.5
Gallery 1.4.1
The moment I deactivated the MenuManager module everything was fine again - apart from the missing menu, of course

Okay, guys, now it's your turn. I'd be happy if you could find the problem's source.
And please excuse my clumsy english, it's not my native tongue and it's nearly five in the morning...
Good night!
Amendra
Last edited by Amendra on Tue Dec 21, 2010 4:03 am, edited 1 time in total.
Re: Upgrade 1.8.2 to 1.9.2 Problem
I copied MenuManager.module.php from 1.8.2. to 1.9.2 and now the pages get parsed but still without the Menu.
Re: Upgrade 1.8.2 to 1.9.2 Problem
So everyone here is getting the same error messages as the OP?...
This is just from upgrading a good working 1.8.2 to 1.9.2?...
I'm asking because I will try to reproduce it...
This is just from upgrading a good working 1.8.2 to 1.9.2?...
I'm asking because I will try to reproduce it...
Re: Upgrade 1.8.2 to 1.9.2 Problem
I get a similar error, just upgraded 1.8.2 to 1.9.2, not the same but looks like it may be related:
Fatal error: Call to undefined method cms_content_tree::getRootNode() in ..../modules/MenuManager/action.default.php on line 108
Fatal error: Call to undefined method cms_content_tree::getRootNode() in ..../modules/MenuManager/action.default.php on line 108
Re: Upgrade 1.8.2 to 1.9.2 Problem
Ok, so my current code is:
{cms_module module='menumanager' start_element=$h_position collapse='0' number_of_levels='1' show_root_siblings='1'}
if I remove the start_element thing it eliminates the error but, of course, doesn't generate the submenu I want.
Thoughts?
EDIT: changing $h_position to $node->hierarchy produces the same error I was seeing before.
{cms_module module='menumanager' start_element=$h_position collapse='0' number_of_levels='1' show_root_siblings='1'}
if I remove the start_element thing it eliminates the error but, of course, doesn't generate the submenu I want.
Thoughts?
EDIT: changing $h_position to $node->hierarchy produces the same error I was seeing before.
Last edited by phrique on Wed Dec 22, 2010 1:05 am, edited 1 time in total.
Re: Upgrade 1.8.2 to 1.9.2 Problem
The $node-> stuff only works inside a menu template not in a menu call...
What outcome are you looking for when it outputs that menu tag?...
What outcome are you looking for when it outputs that menu tag?...
Re: Upgrade 1.8.2 to 1.9.2 Problem
Sorry to interrupt this talk, but I would like to share my new test result.
@ Dr. CSS : This massive error occured with 1.9.1 as well, as I tested yesterday. I'm sure it has to do with the new database schema.
I haven't tried 1.9.0 since 1.9.1 was already out when I realised the new version
Versions from 1.7.1 onwards didn't have any problems with upgrading to 1.9.x.
It may help to know that my old database was first created in November 2006. In these times I used Latin1 character set, both on the collation and as a field character set. Since then every upgrade was quite smooth, with smaller hickups now and then which I can't recall anymore
By this time of upgrade the database was on utf8_unicode_ci, both in collation and field character sets. My $config['default_encoding'] and my $config['admin_encoding'] are both 'utf-8', $config['set_names'] setting to false instead of default true didn't help either.
For the last 6 hours I tried to understand what happened.
I thought the error could originate from the new character set structure applied with this upgrade. For one reason: Whenever I cleared the four content tables and re-inserted the default content shipped with version 1.9.2, all went smooth and the content was shown like normal, even with all other tables still bearing old content. All menus rendered as normal, the pages didn't got broken. The moment I re-inserted my old content, the menu manager went ballistic again.
Here is a list of things I tried without success:
1. Comparing the sql structure of the old and the new database, especially the four content tables.
My old structure looked like this:
You can see, there are lots and lots of 'COLLATE=utf8_unicode_ci' and completely different key names.
It's somewhat different than the new structure (here only shown for 'cms_content':
2. I deleted these four tables, created them again with the new structure and re-inserted the old content, even deleted the (now new) index keys and created them again by hand.
No difference, same error as before.
3. I compared the content of 'cms_content' and the field types.
The field 'secure" was NULL in my old table and 0 (zero as an integer) in the new one. I changed all NULL to 0.
No difference, same error as before.
3. I tried to mix the old with the new content by appending some old content with phpMyAdmin. That worked for a moment, but then CMSms started to number consecutively the content in the page tree, in a deeply wrong way. From now on all pages and chapters started with the Number 2 besides the home page. My Goodness!
So I deleted every content again, re-inserted the originally shipped content and inserted some fresh pages. That worked, but now my old content is gone. Completely unacceptable of course, since I have to upgrade two very old databases anytime soon - one with 400 pages for a private project and one with over 200 pages for a client.
For now I have to stick to version 1.8.2.
I sincerely hope that you'll find a safe and working way to upgrade.
Edit at 03:49 in the morning local time:
I could provide a test sql database if you need it. I would send you a pm with a download link if you want
Oh and by the way: Within this test database I tried to delete some pages, but that was not always possible. Especially pages with subpages created this error: Fatal error: Call to a member function Id() on a non-object in D:\Projekte\CMSms\1b_192mix\admin\multicontent.php on line 150
It was not reproducable which particular page type wouldn't get deleted, it was completely random.
Thank you for your time!
Amendra
@ Dr. CSS : This massive error occured with 1.9.1 as well, as I tested yesterday. I'm sure it has to do with the new database schema.
I haven't tried 1.9.0 since 1.9.1 was already out when I realised the new version

It may help to know that my old database was first created in November 2006. In these times I used Latin1 character set, both on the collation and as a field character set. Since then every upgrade was quite smooth, with smaller hickups now and then which I can't recall anymore

By this time of upgrade the database was on utf8_unicode_ci, both in collation and field character sets. My $config['default_encoding'] and my $config['admin_encoding'] are both 'utf-8', $config['set_names'] setting to false instead of default true didn't help either.
For the last 6 hours I tried to understand what happened.
I thought the error could originate from the new character set structure applied with this upgrade. For one reason: Whenever I cleared the four content tables and re-inserted the default content shipped with version 1.9.2, all went smooth and the content was shown like normal, even with all other tables still bearing old content. All menus rendered as normal, the pages didn't got broken. The moment I re-inserted my old content, the menu manager went ballistic again.
Here is a list of things I tried without success:
1. Comparing the sql structure of the old and the new database, especially the four content tables.
My old structure looked like this:
Code: Select all
CREATE TABLE `cms_content` (
`content_id` int(11) NOT NULL,
`content_name` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`type` varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
`owner_id` int(11) DEFAULT NULL,
`parent_id` int(11) DEFAULT NULL,
`template_id` int(11) DEFAULT NULL,
`item_order` int(11) DEFAULT NULL,
`hierarchy` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`default_content` tinyint(4) DEFAULT NULL,
`menu_text` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`content_alias` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`show_in_menu` tinyint(4) DEFAULT NULL,
`collapsed` tinyint(4) DEFAULT NULL,
`markup` varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
`active` tinyint(4) DEFAULT NULL,
`cachable` tinyint(4) DEFAULT NULL,
`id_hierarchy` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`hierarchy_path` text COLLATE utf8_unicode_ci,
`prop_names` text COLLATE utf8_unicode_ci,
`metadata` text COLLATE utf8_unicode_ci,
`titleattribute` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`tabindex` varchar(10) COLLATE utf8_unicode_ci DEFAULT NULL,
`accesskey` varchar(5) COLLATE utf8_unicode_ci DEFAULT NULL,
`last_modified_by` int(11) DEFAULT NULL,
`create_date` datetime DEFAULT NULL,
`modified_date` datetime DEFAULT NULL,
`secure` tinyint(4) DEFAULT NULL,
PRIMARY KEY (`content_id`),
KEY `content_alias` (`content_alias`,`active`),
KEY `default_content` (`default_content`),
KEY `parent_id` (`parent_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
-- --------------------------------------------------------
CREATE TABLE `cms_content_props` (
`content_id` int(11) DEFAULT NULL,
`type` varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
`prop_name` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`param1` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`param2` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`param3` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`content` text COLLATE utf8_unicode_ci,
`create_date` datetime DEFAULT NULL,
`modified_date` datetime DEFAULT NULL,
KEY `content_id` (`content_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
-- --------------------------------------------------------
CREATE TABLE `cms_content_props_seq` (
`id` int(11) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
-- --------------------------------------------------------
CREATE TABLE `cms_content_seq` (
`id` int(11) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
It's somewhat different than the new structure (here only shown for 'cms_content':
Code: Select all
CREATE TABLE IF NOT EXISTS `cms_content` (
`content_id` int(11) NOT NULL,
`content_name` varchar(255) DEFAULT NULL,
`type` varchar(25) DEFAULT NULL,
`owner_id` int(11) DEFAULT NULL,
`parent_id` int(11) DEFAULT NULL,
`template_id` int(11) DEFAULT NULL,
`item_order` int(11) DEFAULT NULL,
`hierarchy` varchar(255) DEFAULT NULL,
`default_content` tinyint(4) DEFAULT NULL,
`menu_text` varchar(255) DEFAULT NULL,
`content_alias` varchar(255) DEFAULT NULL,
`show_in_menu` tinyint(4) DEFAULT NULL,
`collapsed` tinyint(4) DEFAULT NULL,
`markup` varchar(25) DEFAULT NULL,
`active` tinyint(4) DEFAULT NULL,
`cachable` tinyint(4) DEFAULT NULL,
`id_hierarchy` varchar(255) DEFAULT NULL,
`hierarchy_path` text,
`prop_names` text,
`metadata` text,
`titleattribute` varchar(255) DEFAULT NULL,
`tabindex` varchar(10) DEFAULT NULL,
`accesskey` varchar(5) DEFAULT NULL,
`last_modified_by` int(11) DEFAULT NULL,
`create_date` datetime DEFAULT NULL,
`modified_date` datetime DEFAULT NULL,
`secure` tinyint(4) DEFAULT NULL,
`page_url` varchar(255) DEFAULT NULL,
PRIMARY KEY (`content_id`),
KEY `cms_index_content_by_content_alias_active` (`content_alias`,`active`),
KEY `cms_index_content_by_default_content` (`default_content`),
KEY `cms_index_content_by_parent_id` (`parent_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
No difference, same error as before.
3. I compared the content of 'cms_content' and the field types.
The field 'secure" was NULL in my old table and 0 (zero as an integer) in the new one. I changed all NULL to 0.
No difference, same error as before.
3. I tried to mix the old with the new content by appending some old content with phpMyAdmin. That worked for a moment, but then CMSms started to number consecutively the content in the page tree, in a deeply wrong way. From now on all pages and chapters started with the Number 2 besides the home page. My Goodness!
So I deleted every content again, re-inserted the originally shipped content and inserted some fresh pages. That worked, but now my old content is gone. Completely unacceptable of course, since I have to upgrade two very old databases anytime soon - one with 400 pages for a private project and one with over 200 pages for a client.
For now I have to stick to version 1.8.2.
I sincerely hope that you'll find a safe and working way to upgrade.
Edit at 03:49 in the morning local time:
I could provide a test sql database if you need it. I would send you a pm with a download link if you want

Oh and by the way: Within this test database I tried to delete some pages, but that was not always possible. Especially pages with subpages created this error: Fatal error: Call to a member function Id() on a non-object in D:\Projekte\CMSms\1b_192mix\admin\multicontent.php on line 150
It was not reproducable which particular page type wouldn't get deleted, it was completely random.
Thank you for your time!
Amendra
Last edited by Amendra on Wed Dec 22, 2010 3:03 am, edited 1 time in total.
Re: Upgrade 1.8.2 to 1.9.2 Problem
I want to display the menu items under the current page. In other words, if my pages looked like:Dr.CSS wrote: The $node-> stuff only works inside a menu template not in a menu call...
What outcome are you looking for when it outputs that menu tag?...
A
> 1
> 2
> 3
and I was on page A, I'd expect to see 1, 2, and 3 in the menu.
This has always worked up until now.
Re: Upgrade 1.8.2 to 1.9.2 Problem
I just completed an upgrade from 1.8.2 to 1.9.2 with no problems. It was actually a very basic site with no extra modules installed. After upgrading I created a couple test pages...did some reordering and everything worked as expected for me. I have about a dozen left to do so I'll check for anything out of the ordinary. I have a couple 1.6x's that I'd like to update so I'll try those a little later.So everyone here is getting the same error messages as the OP?...This is just from upgrading a good working 1.8.2 to 1.9.2?...I'm asking because I will try to reproduce it...
Re: Upgrade 1.8.2 to 1.9.2 Problem
@phrique
Most times it would be start_level='2' like...
http://multiintech.com/defaultcontent/i ... e=top_left
Most times it would be start_level='2' like...
http://multiintech.com/defaultcontent/i ... e=top_left