Is it possible to use strait PHP in our templates along side of Twig and or instead of Twig?
If so how does one go about it?
No this is not possible.
If you really need PHP, you can write a plugin with one of the following:
craft.myPluginHandle
$this->renderTemplate(...)
{% hook %}
tag is placed.Why Twig anyway?
The question to use php in templates comes up every once in a while, but there are good reasons for not using it.
For example if Craft changes its code you don't have to worry about your templates. The upcoming update of the Yii framework would force you to rewrite all your templates if they were written in php.
There is also a great article from Fabien Potencier on this topic -- tl;dr php is too verbose for templating.
In craft 3 it is actually possible.
{{ craft.app.view.evaluateDynamicContent('phpinfo();') }}
As you can see above, php code is passed as string to evaluateDynamicContent function. On inside, evaluateDynamicContent is just running eval
function.
Now, even if you can do this, doesn't mean that you should. Before doing this, consider if you have other alternatives for doing what you want to achieve. Using php code inside template can run you into all kind of unpredicted security issues.
I personally love separating querying and templating concerns and Craft's Twig implementation doesn't allow that very well. Writing queries inside templates doesn't sit well with me anymore after years in web development, so I went on to develop a small hidden plugin for Craft that allows a similar experience as Laravel's View Composers for Blade (hidden plugins start with an underscore character, they shouldn't, display in Craft's admin). In such, you can create a class that has the same name as your template to pass data to it before rendering. You can look it up here: https://github.com/guimauve-creative/craft-twig-view-composers
This allows to create PHP classes with a "compose" function where you can store some logic to abstract it from your view. It's not a controller per se because it runs at a higher level, when the request has already been treated, so that's why it's called a "view composer".
<?php
/**
* Basic view composer for the templates/index.twig file.
* To create a view composer for a subfolder, simply replicate the structure here.
* Ex.: templates/blog/_entry.twig -> composers/blog/Entry.php
*
* Element queries are made with PHP to
* avoid using their twig counterparts
* @see https://craftcms.com/docs/4.x/element-queries.html
*/
namespace guimauve\composers;
use craft\events\TemplateEvent;
use craft\elements\Entry;
use Craft;
class Index
{
/**
* @param TemplateEvent $event Object passed by View::EVENT_BEFORE_RENDER_TEMPLATE
* @see https://github.com/craftcms/cms/blob/a1b232ea1888f131bb7626a5bdaff0f5fa2f4469/src/web/View.php#L1891
* @see https://github.com/craftcms/cms/blob/2eac9249964ccc553bf841c79b9ee44d58f16b61/src/events/TemplateEvent.php
*
* @return void
*/
public static function compose(TemplateEvent $event)
{
$locations = Entry::find()->section('shop')->relatedTo($selectedCity)->with([
[
'featuredImage', ['withTransforms' => ['x870']]
]
])->collect();
$event->variables['locations'] = $locations;
}
}
In other words, what this plugin does, is basically just look inside a specific folder if there's a class that contains a file with the same name of the template that's being executed. For "templates/blog/_entry.twig", it will look, load and execute a "compose" function on a PHP class if it's found at "composer/blog/Entry.php".
The compose function receives the only variable that we had access to which is the TemplateEvent $event variable, but lucky for us, this variable contains all the data that craft has pre-parsed for the template and we can graft anything onto it through the "variables" array index. If I collect blog entries, for example, and add them to the $event->variables['blogs'] array index, it'll be available in my twig templates as "blogs". Since all the database query functions we usually see in Twig are available in PHP too, we can use these counterparts and keep our code as clean as possible with better separation of concern.
Happy coding!