Snippets / chunks / blocks / template inside templates

[piranha]

Some way of creating reusable content that could be loaded from within a template or within a field in a page.

The example site uses include files, but this is not very designer friendly. Something that can be edited in the admin site will be excellent.

Another solution could being able to embed a template inside a template, maybe this can be done already but I haven't notice.

[Adam Kiss]

re: include template in template:

  <?php include('another-template.php'); ?>

That's all you really need.

re: designer friendly: (subjective) if designer needs to edit code, learning a little PHP needed might only help him. However, there probably will be later (currently isn't) some template language

re: editable partials/chunks: currently, there isn't one place, where you could easily manage it. However, I solved it twice so far – once I did another PHP file included, and once I did another page template, consisting of fields like 'footer', 'advanced_headline', etc.

Adam

[ryan]

Includes are an important part of templates, and they are about as simple as it gets. When you do the include, I suggest you put a "./" in front of the filename, i.e.

include("./header.inc"); 

Yes it'll probably work without the "./", but it will force PHP to search all of it's include paths. Whereas if you put a "./" in front of it, it will only check in your /site/templates/ dir (which is more likely what you want).

[piranha]

Included files are fine. They work.

But it could still be nice to have an explicit way of doing this by having something like snippets, chunks, blocks, partials or whatever name you like. Please consider something like this in the future.

[ryan]

Snippets will be supported with a module, and you'll be able to define whether you want it to process PHP or not. I'd rather not have a bunch of confusing terminology like chunks, nuggets, snippets and such, and rather just have one term for them all: snippets.

I understand the desire for snippets, though admittedly feel it crosses the line away from best practices, splitting your markup into different places. Whereas include files are clean, simple, are kept in one place, and don't need to be eval'd when they contain PHP. I also think it's a bad practice for people to be editing any sort of code in the CMS itself. The CMS is not the right environment for it (your markup and/or code editor is), nor is a live site the place to be messing with the code (this should be a dev/staging/offline task).

But the intention with ProcessWire is to adapt to a developer's needs rather than enforce my opinions on best practices, so a snippets capability is something you can count on in the future.

Thanks,

Ryan

[piranha]

Hi Ryan

You are right that the CMS itself is not the best place to be editing the code, but so many CMSs do it like this that this is what we initially expect. 

Maybe is just a thing of documenting / explaining a bit more how do you expect people to do in the guides.

Thanks

[ryan]

I understand that other CMSs have places where you might edit code in the CMS, and I also understand there is a convenience factor in many cases. But the main reason why I want to support snippets is actually to encourage sharing of code snippets. It's feasible that we can have a library of snippets that people can just paste in, and this is accessible to anyone. This is the area where I think the snippets may be worth the compromise of their downside. But I will do as you suggested and document why people might want to avoid using snippets for custom site-specific code, or plugging things into live sites.

Thanks,

Ryan

[theoretic]

Think this (truly interesting) subject needs some clarification.

"Chunk" is a term from ModX CMS word. In ModX "chunk" means a piece of HTML markup which can be reused on different pages via inclusion into templates and/or via placing a reference to it into page fields.

OK, Processwire appears to have a dead-simple solution: we can just "include ./path/to/chunk.php" anywhere in the template files. Great for developpers, bad for content editors. They cannot edit chunks from inside backend.

In fact, content editors have no need to use "templates inside templates" and other stuff concerning development, not content editing. They just need a possibility to edit some pieces of HTML code via backend. The typical example is the contact info in footer area. Phones and emails can change, and it's obviously a content editing task to change them, not a development tack. And, yes, Marco's module doesn't resolve the problem, it just helps to separate logic and presentation.

Personally i think that the absence of "chunks" editable from backend is a rare point where Processwire is some steps behind ModX.

[Martijn Geerts]

In ProcessWire we have Hanna Code and it uses almost the same syntax as in MODX except those are snippets and chunks in one.

Hanna code runs from disk, while MODX snippets are eval()'t. (is that a good word ? )

You could also create a page with a footer template and just render that page in your template with $yourpage->render(). After a while you will discover more options to do things, just give your self the time .

[tpr]

I think that the possibilities that a ckeditor provides for content editors is just enough, if not too much in some cases.

[Christophe]

For your "typical example" of "the contact info in footer area", you can, for example, just:

• create a Contact information page (that is hidden),
• insert <?=$pages->get('/contact-info/')->body?> wherever you want in _foot.php, or elsewhere.

That's it. The content editor edits the body field of the Contact information page.

There's no need for a template for this page normally.

If you define (in _init.php, for example):

$contact_info = $pages->get('/contact-info/')->body, you just have to use $contact_info wherever you want.

It could be anything of course. Not just a CKEditor textarea body field.

[Pete]

What Martin said two posts above - for folks looking for some familiarity moving from MODx, the Hanna Code module is definitely your friend as its really powerful and you can use these codes inside any textarea field that you have set to parse Hanna Codes.

[SwimToWin]

Keeping template snippets / functions in the code can be achieved with ob_start / output buffering. Note how you can inject the $page object into the function - and continue using the ProcessWire API inside the function - that's highly useful.

This solution works with your IDE and is based on vanilla PHP. Compared to Hanna Code, this solution allows you to keep all code in the file system. Compared to heredoc and nowdoc, this solution allows you to use PHP / ProcessWire code in the snippet. It's almost like using the Twig and Smarty template engines only it works out of the box, it doesn't add additional overhead and you don't need to learn a proprietary template language.

functions.php:

function uk_subnav_pill($title,$page,$selector) {

  if($page->children($selector)->count>0):
  ob_start(); ?>

  <li class="uk-active">
      <a href="#"><?=$title?>	<span uk-icon="icon: triangle-down"></span></a>
      <div uk-dropdown>
          <ul class="uk-nav uk-dropdown-nav">
              <?php foreach ($page->children($selector) as $p): ?>
                  <li class="uk-list-hyphen">
                      <a href=#<?=$p->name?>><?=$p->title?></a>
                  </li>
              <?php endforeach; ?>
          </ul>
      </div>
  </li>

  <?php return ob_get_clean();
  endif;
}

include your functions file in init.php (I use the delayed output template file strategy but of course the function file can also be included directly in the template file - it's up to you):

include 'includes/functions.php';

Then call the function in your template file:

<ul class="uk-subnav uk-subnav-pill" uk-margin>
	<?=uk_subnav_pill('Foos',$page,'template=foo')?>
	<?=uk_subnav_pill('Bars',$page,'template=bar')?>
	<?=uk_subnav_pill('Bazs',$page,'template=bar')?>
</ul>