Leaderboard

I recommend using either Textile or Markdown if you need to support this type of stuff in your image/file descriptions. For instance, in Markdown you would make bold text **like this** You'll need to run your image/file descriptions through Textile or Markdown before outputting them. So can do that like this. I'll use Markdown in this example since the module is already in the core. $markdown = $modules->get('TextformatterMarkdownExtra'); $description = $page->image->description; // your image description $markdown->format($description); echo "<p><img src='{$page->image->url}' alt='' /> $description</p>"; We'll likely add internal support for these Textformatters for image/file descriptions in the near future, so that you don't have to do the above if you don't want to.

Porl, tested out here and seems to work great! Thanks for your work with this. I did run into an error with the paths during installation, though not sure others will as it might have been user error on my part. However, I recommend updating the way reference paths. Don't bother with creating $this->dirname. Instead, do this: // replace this require_once $this->dirname . '/Twig/Autoloader.php'; // with this: require_once $this->config->paths->PageTwig . 'Twig/Autoloader.php'; // replace this $loader = new Twig_Loader_Filesystem($this->dirname . '/../../views/'); // with this $loader = new Twig_Loader_Filesystem($this->config->paths->templates . 'views/'); // replace this array('cache' => $this->dirname . '/../../assets/cache/twig/', // with this array('cache' => $this->config->paths->cache . 'twig/', Also some questions/comments about this: /** * initialises each field of $page. this is overkill but can be used if you don't want to keep * adding individual fields to the controllers. */ function twig_init_fields() { foreach ($pages->fields as $field) { $twig_vars['page']->$field = $page->$field; } } I don't think that your current twig_init_fields() function will work, because the $pages variable is out of scope. Besides, I think you wanted that to be $page instead? If so, you'd want to use wire('page') since $page would also be out of scope in that function. But even if that's the case, I'm confused because when you set $twig_vars['page'] = $page; shouldn't you then be able to already access all the properties of $page? For the same reason, are these lines in twig-test.php even necessary? $twig_vars['page']->body = $page->body; $twig_vars['page']->title = $page->title; It doesn't seem like they should be. But then I tried commenting out the first one for $page->body; and got an error about Page::body() being a non existing function. So it looks like Twig is doing an isset($page['body']); and if it returns false it's trying to call $page->body() as a function. Now it all makes sense. I think I will update the Page::__isset() function to return true when a valid field for the page is requested. That would solve this and prevent you from having to initialize any variables in this manner. And make PW more template-engine friendly, as I'm assuming others may work like this too. Just tried updating Page::__isset() and it does seem to resolve it. Btw, the reason that you wouldn't want to do something like twig_init_fields() is that it would cause all of the page's data to be loaded, regardless of whether it would be used. This would cancel the benefit of PW's on-demand/selective data loading. Your module has me wondering if it wouldn't be a lot simpler for people to use if the Twig parsing happened automatically on the template fields without them having to delegate views, setup $twig_vars, include twigdefaults.php, or call $page->twig->render manually. What if your /site/templates/*.php could just be your Twig views, ready to go? I'm thinking it may be possible with something like this in an autoload module: public function init() { $this->addHookBefore('TemplateFile::render', $this, 'hookRender'); } public function hookBeforeRender($event) { $templateFile = $event->object; $filename = $templateFile->filename; // use some condition to know which templates should use Twig // here we just use filenames that start with "twig_", but might be more elegant to configure which // templates use twig in the module configuration or something if(strpos($filename, 'twig_') !== 0) return; // init twig require_once $this->config->paths->PageTwig . 'Twig/Autoloader.php'; Twig_Autoloader::register(); $loader = new Twig_Loader_Filesystem($this->config->paths->templates); $twig = new Twig_Environment($loader, array('cache' => $this->config->paths->cache . 'twig/', 'auto_reload' => true)); // substitute a pre-defined placeholder file to replace the original template file // so that TemplateFile::render() is actually rendering our placeholder instead: $templateFile->setFilename($this->config->paths->PageTwig . 'placeholder.php'); $templateFile->set('twig_filename', $filename); // original template filename $templateFile->set('twig', $twig); // twig instance } Then the contents of the placeholder template: /site/modules/PageTwig/placeholder.php <?php $twig_vars = Wire::getAllFuel()->getArray(); echo $twig->render($twig_filename, $twig_vars); I haven't tried this yet, but I think it may work. If I get a little more time here in the next day or two to try this stuff rather than just write about it, I'll definitely give it a try unless you get to it first.

The LanguagesPageFieldValue (and getLanguageValue function) are only applicable to multi-language fields. The only multi-language fieldtypes there are at present are TextareaLanguage, TextLanguage and PageTitleLanguage. Language alternate fields are an entirely different thing. It is nothing more than one field substituted for the other. For instance, 'image_de' would be substituted for 'image' when the user's language is 'de' and 'image_de' is populated. That's all there is to it. There aren't any other classes or functions to think about behind the scenes with language alternate fields. With language alternate fields 'image' and 'image_de', if you don't want fallback of 'image' to 'image_de' to occur when 'image_de' is populated and the user's language is 'de', then turn off output formatting, or retrieve the value with $page->getUnformatted('image'); Your example was trying to retrieve the value in 'de' regardless of the user's current language. So if that's what you are trying to do, then just access 'image_de' directly, i.e. $img = $page->image_de; or a non-language specific version: $img = $page->get('image_' . $user->language->name);

Here's the next version of the Blog Profile. This one incorporates the simpler structure I mentioned earlier, exactly as outlined. Please let me know how it works for you. To install, download a fresh copy of ProcessWire and replace the /site-default/ directory it comes with, with the one in the attached zip: blog-site2.zip Thanks, Ryan