Wanze

The name property is not translated, it is a unique identifier for a page together with the parent_id. You should not build urls manually like this, you should use the following method: $page->localUrl() See: https://processwire.com/api/ref/page/ Edit: The name is translated as well, but calling $page->name always returns the (unique) name of the default langauge. Use $page->localName() to get the translated name of a language.

The echo/var_dump in combination with die() or exit() is a quick and simple way of doing it. You can check out the TracyDebugger module. A more sophisticated solution would be to use an IDE for development, for example PHPStorm, which offers to debug with breakpoints, in combination with xdebug. However, the setup is not thaat easy

Can you find out on which browser this is happening? I remember having this problem once when a JQuery plugin was sending the ajax requests - of course only with an ancient version of Internet Explorer

@godmok Thanks for the hint on this, I will update this check with a threshold on the string length. Regarding a newer version of mPDF: Actually the dev brach of the module already contains mPDF 6.1.0, thanks to the work of @gingebaker However, I didn't find time to test it out yet. I really want to support a more recent mPDF version in the master. Cheers

@microcipcip I suggest to debug your variables/code on the PHP site, not in twig. All the variables that are available in twig are passed from your controller and they are available there too. In your example, you try to dump multiple Language objects, I also guess that this is too much to handle for twig. The 'languages' variable corresponds to the ProccessWire $languages API variable, so you could var_dump() a language object in your controller. In general: Twig should only be used to organize your markup and display variables. If twig templates contain more complex logic code, this should be moved to the controller or a module/class, depending on how you organize your code. Cheers

I'm sorry for the empty post above; somehow I'm not able to write in the editor when editing And submitting the post was by mistake I don't understand your question, could you post some example code and explain in more detail what's the problem? The module should only attempt to render your page with smarty, if there exists a "myTemplate.tpl" smarty template to the corresponding "myTemplate.php" ProcessWire template.

@Sephiroth

It is a PHP file containing the translation keys. You could also enter the translation values for the default language, but I prefer to work with keys on code level so I can translate them to different values for each language in the ProcessWire backend <?php __('show_video'); // Video ansehen __('more'); // mehr __('case_studies'); // Case-Studies __('call_us_for_advise'); // Rufen Sie uns für eine unverbindliche Beratung an! __('map'); // Anfahrt __('contact_form'); // Kontaktformular __('overview'); // Übersicht

Hi Andreas, Here is one way of how I'm doing it in combination with the TemplateEngineFactory + TemplateEngineSmarty modules. Basically I'm storing all my translation keys in a php file "strings.php" using this file as textdomain. Values are translated in the ProcessWire backend. Then I'm using an autoload module which adds a translation function to smarty: <?php class SmartyTranslationExtension extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return array * */ public static function getModuleInfo() { return array( 'title' => '', 'version' => 100, 'summary' => '', 'singular' => true, 'autoload' => true, ); } /** * Initialize the module * * ProcessWire calls this when the module is loaded. For 'autoload' modules, this will be called * when ProcessWire's API is ready. As a result, this is a good place to attach hooks. * */ public function init() { $this->addHookAfter('TemplateEngineSmarty::initSmarty', $this, 'hookSmarty'); } /** * Wrapper to return a translation from a given translation file * Default keys are in /site/templates/translations/strings.php * Note: The translation is returned in the current language of the user object * * @param string $key * @param string $file * @return string */ public function txt($key, $file = 'strings') { $string = __($key, "/site/templates/translations/$file.php"); // We remove any html encodings to allow HTML tags in our translations return wire('sanitizer')->unentities($string); } public function hookSmarty(HookEvent $event) { $smarty = $event->arguments('smarty'); $smarty->registerPlugin('function', 'txt', array($this, 'txtSmarty')); } public function txtSmarty(array $params, $smarty) { $file = isset($params['file']) ? $params['file'] : 'strings'; $key = isset($params['key']) ? $params['key'] : '<MISSING TRANSLATION KEY>'; return $this->txt($key, $file); } } Now, I can output my translations in a smarty template like this: {txt key="hello_world"} --> Outputs translation value (DE, EN, FR...) corersponding to hello_world key Note that this only works if you are using the TemplateEngineFactory module together with smarty as engine. Hope it helps! Cheers

@gmclelland I try to answer the questions in the same order as your questions: The module offers a hook which can be used to customize all twig objects returned by the factory, TemplateEngineTwig::initTwig(). I'm not sure if you're familiar with how ProcessWire's hooking system works? There is a module from @justb3a which adds some extensions to twig: https://github.com/justb3a/processwire-twigextensions. The extensions are also loaded via composer inside the module's folder, not on the root level. I suggest to take a look how this module works and then customize it in order to fit your needs. No, you would need to register a function in twig which takes care of outputting translated strings. A simple solution would be to translate the strings in your controller and pass them to twig. Yep I definitely should do that! Merry Christmas!

Hi, There are different solutions to do this. You could check in your Controller (ProcessWire-Template) if the request is ajax and pass a variable to twig, if a header/footer should be rendered: // In controller: $showHeader = true; if ($config->ajax) $showHeader = false; $view->showHeader = $showHeader; // In your template (sorry I don't know the exact twig syntax) :) {% if showHeader %} {% endif %} Or, if you have enabled that ProcessWire API variables are available in your twig templates, you should be able to use $config directly in twig I usually create partial views if I need to output some content multiple times in different context: // In your controller if ($config->ajax) { $partial = $factory->load('partials/my-page-ajax'); $partial->page = $page; echo $partial->render(); exit(); } As @microcipcip mentioned, you could also make use of urlSegments or plain GET variables to output HTML or JSON based on the urlSegment/GET variable. Cheers

@LimeWub How do you mean it sets the things to the outer page view? It shouldn't do this A child page can be rendered on its own, just use your block.php as controller and corresponding smarty template as view. If you need to display content from other pages, you should use chunks or partials. In your example, I would create a chunk for a block and render it as many times as you need in your page.tpl template.

@LimeWub Please post in the existing TemplateEngineSmarty thread next time. The problem is that the global "$view" API variable provided by the factory is still associated with the page you're currently viewing, which is using "page.tpl" smarty template. Meaning if you are using $view in your block.php controller, this $view still points to "page.tpl". You can use chunks or partial templates in this case, here's a quick possibility with chunks: $blocks = $page->children("template=block"); $blockHTML = ''; foreach ($blocks as $block) { $chunk = $factory->chunk('block'); $chunk->page = $block; $blockHTML .= $chunk->render(); } $view->set('blockHTML', $blockHTML); Note that I'm passing the block page as variable "$page" to the chunk, so I'm faking the locally scoped $page variable from ProcessWire. Usually I put my chunks into a subfolder chunks, so I don't mix them up with "regular" controllers/views. Does it help? Cheers

As mentioned in my post, as far as I know, you need to render your image in a regular <img> tag inside the PDF template. This means that you'd need to save the image before on the disk or use a base64 encoded string, though I don't know if the latter works in mpdf.

You need to use addHookAfter instead of addHook, hope this helps! Cheers

@microcipcip Yep you need the dev branch of Pw as well, because the commit adding the relevant feature for the FileCompiler is not yet merged into master.

@microcipcip @eangulo@spiria I pushed a potential fix to the dev branch of this module which should fix the errors with compiled templates. If anyone has the time to test it out, here's what you need to do: Get the newest version of the dev branch of ProcessWire Get the newest version of the dev branch of this module Delete your FileCompiler = 0 comments in the twig templates (maybe) Delete all files under /site/assets/cache/FileCompiler It's hard to test for me, as I never got such errors - I think it depends on the content of your twig templates. However, I'm positive since there were no longer twig templates compiled in the cache of the FileCompiler. I hope it works! Cheers

You would need to store the piechart as image somewhere and use a regular HTML <img> tag to display it in the template of your PDF. Is it possible for Google Charts to store images on the file system? Though a server side app generating the piechart would probably be simpler in this case.

In this case you can make use of partial templates or chunks. Eg: $view->set('menuActive', $page->name); $portfolio = $page->children->get('template=portfolio'); $portfolio_partial = $factory->load('partials/portfolio'); $portfolio->set('title', $portfolio->title); $portfolio->set('body', $portfolio->body); $view->set('portfolio', $portfolio->render()); Hope this helps! Cheers

@Besen The _init.php file isn't processed when loading views. Basically this file is only loaded by ProcessWire when you load a ProcessWire template file (controller). So in the current situation, _init.php was called before your basic-page.php controller was loaded. I'm not sure what you're trying to do, could you elaborate a bit? Do you want to render a portfolio in your current basic-page template?

@SubMon I assume you are using ProcessWire 3.x? Check out this comment: You need to disable the FileCompiler for your twig templates. There's currently no way for the module to tell the compiler to ignore these files, so at the moment this seems like the only solution. However, there is a pull request open to support this and I hope it's getting integrated soon. Cheers

Yeah it won't work sorry... so in this case my solution would be to use the same controller/template for your home page and special page. Still not sure if I understood you correctly though.

Hi Besen, So if you visit the homepage of your website, you basically want to display the same as when you visit your special page? Why not use your special page as homepage (thus moving controller logic from site/templates/special.php to site/templates/home.php) and also the smarty template? Otherwise you could try the following: Rename home.tpl to home.tpl.temp - The factory won't attach hooks to delegate the rendering to smarty, as no template is found In your site/templates/home.php controller add the following: echo $pages->get('/special-page/')->render(); I'm not sure if it works though... Cheers

@microcipcip What is the extension for your twig template files, .html? Unless set in the site/config.php file, ProcessWire's FileCompiler should not compile .html files. I'll look into it and try to find a way to disable the compiling in the module itself.

@Matt_P It sounds like you always get a cached PDF. Try enabling the debug mode or change the cache time to "0" in the Pages2Pdf, then you should actually see your settings taking place. As for the image, can you share your code? Be aware that CSS support is limited when rendering the PDF, that's why you should load a separate CSS file containing the styles just for the PDF's. Cheers