Actually, Ryan, that didn't work (might be older version).

The code that I got to work is:

<?php
echo $c->getCollectionName();
?>

This works fine when outside of the Area object ($a). I am trying to fetch the stored value of an area object before displaying it. ie. NOT $a->display($c)

This post helped me find that. Thanks :)

WJ

For those finding this, the first way (Page::getCurrentPage();) is actually the "right" way to do it. You should avoid the use of the global $c variable whenever possible.

Not sure it didn't work, but if anybody has any problems with the first method post here and I'll assist.

James

Could you explain why we should avoid using the variable $c?

Already one year old message, but nevertheless... It is better to use a method, because the context might not have that variable `$c` defined. It is NOT automatically a global variable, but it might be context dependent.

Second issue of using a variable is that it might be overwritten (using something as ubiquitous as a letter `c` for a (pseudo) global variable is already giving me the creeps), but a method will never be overwritten in PHP.

While from a general programming perspective I agree it's nasty business to just grab a global variable 'out of the blue' and use it, but global variable $c being available as the page context in a template is actually a documented feature, meaning it won't just quietly change. The documented way of adding a block to your template includes "$a->display($c)" where $a was neatly declared in the template but $c is the famous global variable. So if that ever changed, it would break all C5-templates in existence. (And any file overwriting global $c in any part of the view process would break Concrete5). :)

Therefore, technically it's perfectly safe to access $c in a template file. You can even use it in a controller if you precede it with "global $c" but I guess that's getting on thinner ice.

I was explaining the other person't argument from a generic programming point of view, not focusing only on Concrete5 (or even PHP). In this narrow case of Concrete5 there is a singleton that can dangerously be overwritten whenever. If there was a class that provided it (and hopefully there is in the layout engine), overwriting the variable would break things in a very limited scope.

Also accessing the data via attributes rather than properties is more prone to unexpected behavior when accessing this sort of a global variable, somewhat bad design on the point of view of system architecture. But well, Concrete5 is written with PHP and ergo one should expect that it comes with its luggage.