Wanze

And if the path is hashed, how should the browser find the CSS file? Can you please provide a link to a description of this feature from October CMS?

Hi Nukro, The only hookable method is ProcessList::execute(). This means you'd have to hook after this method and copy all logic which is a lot of code to duplicate. Another approach that could work is something like this: Hook before ProcessList::execute() and temporarily assign the content of your desired field to the summary field Hook after ProcessList::execute() and undo the above again Cheers

ProcessWire does not separate backend and frontend user, it's up to you if you allow a user to access the backend. So the frontend dashboard could work like this: The user registers on the frontend and you create a ProcessWire user with all given information. This will also assign a unique ID to the user object. Create a template "dashboard" where you grab the user-ID via urlSegment1 Display any stuff you want in this template Cheers

Hi godmok, Welcome here You don't find any users because the user template is access protected and the guest user does not have "view" permission. You can either change this or skip the access check in your selector by adding "check_access=0". And your second question: Yes there's a difference between $pages->find and $pages->get. The latter assumes that you're very specific about getting a single page and therefore also returns pages that are unpublished/hidden/no-access. Hope I don't forget anything here Cheers

You're welcome! Let me know if you need additional features that would fit into this module.

@reno Yep, it also respects the $config->pagefileExtendedPaths setting, e.g. it creates a folder for each page ID or a nested folder structure, if the setting is enabled. Cheers

Sounds useful, I will take a look at it. I think it should already be possible as you can load any ProcessWire template and render it, e.g. Edit: Actually I think the code won't work as the hook to modify the rendered output is attached to Page::render(). It should be possible to move the hook to TemplateFile::render() $chunk = new TemplateFile($config->paths->templates . 'intro.php'); $chunk->foo = 'bar'; // Can be forwarded to Twig in intro.php $chunk->render(); // This should return the output of the intro.twig template file But I never tried it, so not 100% sure it works. A little wrapper on the module class wouldn't hurt though, e.g. $factory->loadController('intro.php'). Perfect, please send a pull request (target dev branch) I'll update ProcessWire and Smarty engines and notify the author of Jade as well. Nice, please send Do you see any benefit in having multiple Twig versions available to choose from? Cheers

Hi justb3a, The module provides the following functionality to load any view (partial), populate the variables and render its output. $factory = $modules->get('TemplateEngineFactory'); $partial = $factory->load('partials/intro.twig'); $partial->set('post', $post); $partial->render(); I know that this is not a direct solution to your question. I don't know TemplateDataProvider myself, but I guess you'd have to write some helper functions to achieve the same functionality. My approach would probably be to prepare the output already in your blog.php template file, where you're getting the posts. Something like this: // In blog.php $blogs = array(); foreach ($pages->find('template=blogs') as $blog) { $partial = $factory->load('partial/intro.twig'); $partial->set('blog', $blog); $blogs[] = $partial; } $view->set('blogs', $blogs); // In blog.twig {% for post in posts %} {% post.render %} {% endfor %} The module definitely needs an update so that multiple variables can be passed to the view.... Cheers

What are you displaying on this site where you get this count? Any field that is not configured as "autoload" will require one select query per page where you access the field. So if you have 20 fields on a template and you're displaying each field for 100 pages in a loop, this would produce about 100*20 = 2000 queries.

Hi Ralf, I would do this by passing the internal position of the file in the array, e.g. foreach ($pdffiles as $i => $pf) { $content .= "<a href='{$page->url}?fid={$i}' title='{$pf->name}'>$pf->name</a> ($pf->filesizeStr)<br />"; } Then you can grab the file with this ID: if ($input->get->fid) { $file = $page->file->eq((int) $input->get->fid); if ($file) { $file->download(); } } Cheers

Hi Sérgio, As your "normal" template files inside "site/templates" act as controllers, any file you prepend (_init.php) or append (_main.php) works there too. I use the _init.php file to pass any global variables to my loaded view, e.g. main menu items. You can store your assets anywhere you want and reference them like you did before, you just do this in the view. If you want to try out the module a bit, I suggest to follow the mini tutorial here: https://github.com/wanze/TemplateEngineSmarty#best-practices This is for smarty, but it should work for other template engines as well. Cheers

Hi folks, I quickly tested locally with ProcessWire 3.x and it worked by disabling the file compiler for the external mpdf library. I need to test a bit more, especially the multi language support of the module, before I commit a new version. But if you want to make it work in the meantime, here you go: Add // FileCompiler=0 to the first line after the php opening tag in the file /site/modules/Pages2Pdf/mpdf/mpdf.php Delete the folder /site/assets/cache/FileCompiler/site/modules/Pages2Pdf to make sure the module files are recompiled Now generating and downloading PDFs should work Cheers

No, they don't need Template Data Provider for any reason, those modules are not related. In fact, the template factory works the same as the description of your implementation. You also have a $view API variable available, which connects you to the template engine (Twig, Smarty, Jade at the moment). The controller logic stays the same, because the module abstracts this in a way that it's the same for any supported template engine. But as you said, the syntax of your "views" is different depending on the template engine. Latte and Twig don't use the same syntax, so you'd need to adjust that. That being said, I think it's uncommon to switch the template engine during a project

Hi guys, Thanks for reporting those errors. I'll find some time to make this module 3.x compatible in the next few days, I guess disabling the new FileCompiler for the external mpdf library should do the trick.

Check the output that is returned from the Ajax request, maybe you get a hint what's causing it server side, e.g. PHP warning or HTML message. You can do this for example in chrome with with the dev tools under "Network". Select the XHR request and choose "Response".

Well because this functionality somehow best belongs to the $session API variable

Hi Metaphora, Well that's strange, I guess this has to do with ProcessWire's FileCompiler in 3.x. I'll take a look at it in the next days. Cheers

Hi, Where are those URLs in the form domain.xy/index.php?it come from? Because you shouldn't see this form. It's used internally by ProcessWire to handle the request from a "normal" url that is made from one or several page names.

Hi Peter, Did you clear your browser cache? That my help. If not, check the javascript console for any errors. Cheers

Check the MySQL character set of your database or fields and change it from "latin1_swedish_ci" to "utf8_general_ci". But don't do this without backup / testing first

Hi Sradesign, Finally could look at the implementation, turned out that you must enable tracking by values explicitly like this: $p = $pages->get('/'); $p->setTrackChanges(Wire::trackChangesOn | Wire::trackChangesValues); $p->title = 'new value'; var_dump($p->getChanges(true)); die(); Worked for me then, hope it helps! Cheers

Global variables are against the principle of object oriented programming. LostKobrakai made a good point. One could always write something like this: $_GLOBALS['page'] = "I'm a string page"; and your code breaks... If you're in a class derived from wire, the cleanest way to get the API variables is like this: $this->wire('page'); $this->wire('sanitizer'); // They could also be accessed directly, but then you're not 100% sure if the member is overwritten with something else $this->page $this->sanitizer The global wire function is there to access the API variables in (global) functions, or static methods when you're in a class. You don't even need to reassign them to local scoped variables, just use them like so: echo wire('page')->id; ... or if you really want local variables with a one liner, write a little wrapper like this: function getApiVars() { return array( wire('page'), wire('pages'), wire('sanitizer'), ); } // And then list($page, $pages, $sanitizer) = getApiVars(); Or another possibility would be to inject them into your class/method, if you don't subclass Wire. Cheers

To get the old value(s), you can call the getChanges method like this: // If you need the old value(s) also $u->getChanges(true); Looking at your code, I see that you are assigning input from POST directly, without sanitizing. Check out ProcessWire's $sanitizer API variable. Cheers

Argh the problem is that calling Page::save() does reset the trackChanges by default. I corrected my example above. So you either need to get the changes before saving or save your user object like so: $user->save(array('resetTrackChanges' => false)); Cheers

ProcessWire tracks changes on properties, so you could do something this: // After submitting your form with POST, set the new values to your user object $u = $users->get('myUser'); $u->of(false); $u->set('field1', $sanitizer->text($input->post->field1)); $u->set('field2', $sanitizer->text($input->post->field2)); $u->set('field3', $sanitizer->text($input->post->field3)); // Now assume only field2 and field3 changed $u->getChanges(); // --> Returns you array('field2', 'field3'); // If you need the old value(s) also $u->getChanges(true); $u->save(); Hope it helps! Cheers