Fatal Error: Call to a member function getCollectionAttributeValue()

Permalink 1 user found helpful
I dropped the un-compressed folder into the site directory, CHOWNed it recursively to let Apache have control, and CHMODed 755 recursively.

If I point my browser to the root of Concrete, I get the following:

Fatal Error: Call to a member function getCollectionAttributeValue() on a non-object in /[sitepath]/concrete/elements/header_required.php on line 21

What's this all about?

I installed an earlier version of Concrete on an identical server (virtualized clone) a while back and had no trouble.

View Replies: View Best Answer
Mnkras replied on at Permalink Reply
Mnkras
C5 never has an install folder,

just go to the index.php file and it should guide you through the install proccess
DavidMIRV replied on at Permalink Reply
DavidMIRV
the root concrete/ directory is the core itself and is never accessed from the front end directly, everything you do is piped through index.php after you're installed and you have pretty urls enabled (and your .htaccess setup appropriately as it tells you to)..
MajikNinja replied on at Permalink Reply
Thanks for the responses guys... I may have gotten another PHP package confused with Concrete when it comes to the "Install" folder. I edited my original post and title to not include that issue.

However, I am still not able to get the root dir's index.php to run. PHP is working everywhere else on my system, and when I try to view that index.php, I get the error that I showed you in my first post.

I've also noticed that if I drill down into the directory structure and try to view any other .php file within Concrete, I get a blank white page that says "Access Denied". No HTML errors, no 404's... Just "Access Denied". Even the source code of the resulting page has nothing but the words "Access Denied" in it.

I have the directories CHOWNed and CHMODed properly... What am I missing? I really don't want to have to run Joomla or Drupal for this.

What am I missing?
MajikNinja replied on at Permalink Reply
BTW - I have made sure that I do have mod_rewrite enabled. I followed the guide at this address:

http://xmodx.com/install-apache-and-enable-mod_rewrite-ubuntu-linux...
nteaviation replied on at Permalink Reply
nteaviation
Maybe you got a corrupted download. Have you tried a fresh install? Also, check your logs. There may be more "clues" in there :)
Mnkras replied on at Permalink Reply
Mnkras
do NOT point your browser to <site>/concrete/

just point it to <site> where the index.php file is!
MajikNinja replied on at Permalink Reply
I have Concrete sitting in a folder that I created and named "Concrete"... not to be confused with the folder inside of the distribution called Concrete

<siteroot>/<my "concrete" folder>/<concrete root>

I downloaded the package from Concrete, tried it, got these errors, then deleted it.

I then downloaded the package from SourceForge, tried it, got the same errors, haven't yet deleted it.

Seems to me that there is either an issue with the package (unlikely) or there is some sort of issue with my LAMP stack.

However, I have various other PHP packages running on this and other Virtual Hosts on this same Apache. The host is Ubuntu (Karmic x64).

Thanks for the thoughts from all of you so far! Really hope one of you can tell me what I must have missed.
nteaviation replied on at Permalink Reply
nteaviation
You still getting the exact same error:

Fatal Error: Call to a member function getCollectionAttributeValue() on a non-object in /[sitepath]/concrete/elements/header_required.php on line 21

that you listed above when trying to install from <siteroot>/<my "concrete" folder>/
MajikNinja replied on at Permalink Reply
Yes, still getting the same error. I will post my Apache and PHP configs shortly.
MajikNinja replied on at Permalink Reply 2 Attachments
My configs are attached here. Look for the little paper clip icon at the bottom of this post.

I scrubbed my actual domains and replaced them with site1, site2, etc, in order to post them to this public forum. The virtual host/domain that I am wanting to run Concrete under is called SITE3 in this config.

For the record, there is no other version of Concrete running on this LAMP.

The configs are saved here as a TXT file to make it easier to open.

The php.ini you are seeing here is the main one from the /etc/php5/apache directory. I do not have a specific php.ini for this, or any other virtual host on this LAMP.

Hope this will help.
nteaviation replied on at Permalink Reply
nteaviation
I'm suspicious of the path:
/[sitepath]/concrete/elements/header_required.php

It should be:
/[sitepath]/concrete/concrete/elements/header_required.php

I would think.
MajikNinja replied on at Permalink Reply
I just did that for testing - you know, install into a subfolder and make sure that it works before I wipe the existing website and re-install Concrete into the site root.

But just to be sure, I just created another virtual host and dropped Concrete into the site-root the way you are supposed to. And I STILL get the exact same error.

Also, my log files aren't showing anything interesting related to this except that exact same PHP error that I keep talking about. So for some reason, PHP is really not happy with something in the Concrete code. WHY is the big question.
nteaviation replied on at Permalink Best Answer Reply
nteaviation
Are you running php4 compatibility mode? C5 does not like it. See:

http://www.concrete5.org/community/forums/installation/pre-installa...

Maybe that is the culprit. It may be this line in your php.ini:

; Enable compatibility mode with Zend Engine 1 (PHP 4.x)
zend.ze1_compatibility_mode = On
nteaviation replied on at Permalink Reply
nteaviation
On a further note from php.net (Default is OFF)

http://php.net/manual/en/ini.core.php...

zend.ze1_compatibility_mode boolean

Enable compatibility mode with Zend Engine 1 (PHP 4). It affects the cloning, casting (objects with no properties cast to FALSE or 0), and comparing of objects. In this mode, objects are passed by value instead of reference by default.

Warning
This feature has been DEPRECATED and REMOVED as of PHP 5.3.0.

Looks promising :)
MajikNinja replied on at Permalink Reply
Hmm, that does smell pretty good. Nice find ;)

I seem to remember that that there was some PHP package I installed for a client that required that ZEND to be enabled...

Is there a way to disable that ZEND for just this virtual host? Think I'm gonna start Googling for that answer... I'll race ya to it ;)
nteaviation replied on at Permalink Reply
nteaviation
Put this in your .htaccess may work:

php_flag zend.ze1_compatibility_mode 0

I win! hehehehe
MajikNinja replied on at Permalink Reply
I did that, but still getting the error. :(

During my Googlging, I saw that disabling ZEND in an .htaccess file just doesnt work really well for some reason.

So let's do this the other way... There is only one virtual host that needs to use ZEND, so I think I need to disable ZEND globally, and find a way to ENABLE it in the .htaccess for just that one host.

Make sense? Back to Google...
nteaviation replied on at Permalink Reply
nteaviation
Rats! ok, that's just strike one :) i'll "web scrounge" a little more also.
MajikNinja replied on at Permalink Reply
Thanks bud :)

I should point out too that I DO have AllowOverrides set to ALL in my global PHP.ini. So the .htaccess files DO have the ability to override the global directives, it's just that the ZEND thing doesn't seem to want to be disabled once it's been invoked in the global config.
nteaviation replied on at Permalink Reply
nteaviation
I wonder if you can put the

php_flag zend.ze1_compatibility_mode 0

in your httpd.conf within the virtual host directive. Maybe apache/php will like that?
MajikNinja replied on at Permalink Reply
My vhost directoves are actually in the apache2.conf file... and I did try that, but didn't get anywhere.

As luck would have it, my boss has now told me to switch to Joomla for this client... so I won't be actively pursuing this issue anymore. BUT, I can see how this particular issue might be something that other webhosting people may run across if the are running an Apache LAMP.

Sure hope this conversation continues. Thanks for your help!!!!! I think we've contributed our fair share :)
nteaviation replied on at Permalink Reply
nteaviation
Yea, Apache2.conf, not httpd.conf (that's Redhat, Fedora, CentOS, etc...) It' is most likely not going to be an issue, since php4 comaptibilty mode requirements are not used very often.

Best of luck with your future projects.

P.S. Thanks for the Karma :)
MajikNinja replied on at Permalink Reply
No problem guy, you deserve the karma.

For documentation's sake, I can tell you what I was running that required that stupid ZEND layer...

It was the "h2desk" package fromhttp://www.h2desk.com. Its a help desk package that runs in PHP.

Cheers!