porl

I've tidied up the install instructions and renamed the github repository to match the new name https://github.com/porl/TemplateTwig Should this thread be moved to the modules forum? Is there anything else I should make this module do? I was going to streamline the rendering of templates to require less 'setting up' in the template.php files but everything I thought of would have added restrictions on it's use and made assumptions that I think go against the philosophy of ProcessWire (assuming output will be generated directly to user's browser etc). I thought to make it so that it would create the views directory automatically if it doesn't already exist but is this considered a 'nice practice' for a module to do or is it best left to the user to create it? I have also submitted this to the modules directory so hopefully I have categorised it correctly. Edit: I spent a bit of time and tidied up the twig templates to make them follow the twig ideals better (less duplicated code and better inheritance). I still have a few places where I need to use the 'page.get("blah")' method rather than 'page.blah' so a way to override that behaviour discussed above would be nice. Is it possible to override this in the twig module itself (rather than requiring another core hack)? What I mean is to override the Wire::__call() method in the module rather than the core. Is this possible with something like a Before... hook?

This was the first thought I had as well.

I'm thinking of the usage of repeaters in a similar way (not the url part) by adding a repeater element 'paragraph'. It would have an optional title area (that would render as, say, a h4 element) and a body area. This way you don't have the users feeling so much a need to 'pretty' up their content area with custom header styling etc from the wysiwig tinymce functions. The other option I am considering is to just limit the tinymce options to predefined styles but that is off topic here.

As a suggestion for how to implement 'per field' permissions, I like the idea of having an option in all fields created for 'use permissions for editing this field' (which is off by default - meaning that most fields don't bother with permissions checking and also helping with backward compatibility). If this is on then there should be a field to enter the permission name. It should default to something related to the field's name (maybe field-[name] or something) but can be changed if required in the same way a page alias can. This would allow for both one-off permissions for fields (as mentioned above) and grouped permissions. As an example of what I mean, say that most site editors can edit certain customer info but not 'private' fields. The fields that are private may have the permission name set to 'edit-private-fields'. This means more than one field can now be controlled by one permission without making a complex interface, just like the page alias is usually out of the way and only changed if needed. Sorry if that wasn't clear; I'm tired and my brain is rambling

Is there anywhere that we can donate to Ryan as thanks for his work? Not only has he built an incredible system here but he is both helpful and humble in his interactions with us. Even if there is no plans for a donation function I just wanted to say thanks.

Hi Pete Looks like you posted just before I edited my post Repeaters should work, but I think they are a bit clunky compared to using a Page field that can have multiple pages selected for this case. I'm still new to ProcessWire and forget bits and pieces easily

I agree with diogo. I'd make a Race template that has a MultiPage field that link to Teams, and have the Team template have a MultiPage field linking to Riders. Edit: I meant to use the MultiPage fields rather than Pages in Repeaters. Cleaner interface that way and slightly cleaner setup and code.

I'm not sure to be honest. The problem I had was partially due to the way I was essentially 'porting' the basic-site directly from your php methods to twig methods (just as a 'proof of concept' so to speak). This isn't really the 'best practice' way of using twig and by changing it a little to be more twig-like (the workaround you mentioned) has removed the specific issue in my case. As I said I'm not sure if there are other cases where this fix would be relevant, but I would be leaning towards the side of leaving things as is unless it becomes an issue. As you said, there is very good reason to have processwire behave as it does and I don't want to be the cause of some strange bugs that people start getting because they turn the check off without realising what it does. Thank you again for your help. If I get time I might try to do a complete 'twigification' of the basic site profile rather than the hacky port I've done so far. On another note, is there anything the module needs in order to be clean enough to 'release'? An install routine that creates the twig directories for instance? I thought of putting them as configurable options but I'm not sure if it is worth it or not.

Ok after further investigating I found that the lines in Wire.php as below public function __call($method, $arguments) { $result = $this->runHooks($method, $arguments); if(!$result['methodExists'] && !$result['numHooksRun']) throw new WireException("Method " . $this->className() . "::$method does not exist or is not callable in this context"); return $result['return']; } are causing the error. Obviously this is intentional behaviour (and makes sense for 99% of cases) but is there a way to change this behaviour (similar to the isset() change) that can be enabled when using templating engines like twig that do their own tests for methods etc? Is this a bad idea? I am still not sure why the 'is defined' check appears to return true even when the property/method does not exist. The API reference page is here if it is of any help. OOH I just discovered something... In the 'compiled' template (the output php file in the twig cache) the line {% if page.summary is defined %} gets translated to the following: if (isset($context["page"])) { $_page_ = $context["page"]; } else { $_page_ = null; } As you can see it is only taking the 'page' part of the variable into account (ignoring the '.summary' part). I assume that Twig only does basic tests for variables and not their properties. This seems odd too me but I'm sure there are reasons that are beyond my knowledge With this in mind, is there any way to stop the exception being triggered (apart from removing or commenting out those lines) when Twig does it's tests? Thanks Edit: I just adjusted the templates to be more 'Twig-like' with regards to the page.summary field. I am using a block override in the pages that have one and just the homepage's summary by default. This gets around the issue in the case that I have. I'm not sure if the problem is still a valid issue for other use cases or not.

I did a little more digging after reading slkwrm's post and found the following: The case that I am getting this on is on the search page. This doesn't have a summary field (as you correctly guessed). the page.get("summary") I assume just returns null (may be wrong) and twig just treats it as 'empty'. When calling page.summary I get the error "Method Page::summary does not exist or is not callable in this context". I assume that the way Twig attempts the check for the summary property and summary() method is somehow triggering ProcessWire to give the error (and so Twig does not get to the point where it returns a null value). Is there any way to stop this from happening (not sure if it is ProcessWire itself catching the error or just formatting a PHP error) and allowing Twig to test these 'non existent' methods and properties? Edit: I just had the thought that since any overriding of the above behaviour is 'messy' then somehow making the Twig test of 'is defined' work correctly is probably better (sorry I forgot about this). By this I mean that the code block as follows executes the inside of the statement as if the 'is defined' has returned true: {% if page.summary is defined %} This text is rendered even though page.summary should not be defined in this case. any use of page.summary in here (instead of page.get("summary") will trigger an error but the 'if page.summary is defined' statement executes and evaluates as true. {% endif %} If the first statement returns false (as I believe it should in this case, as the search template on the default site has no summary field) then hopefully the code will not trigger an error as the contents inside will not execute. I think this is actually a larger bug than I thought (where the bug is though I have no idea, ie. Twig or ProcessWire or even my incorrect assumption of what 'is defined' should be).

It is working well, thanks. I am still having some issues where I can't access object properties directly (say page.sidebar) and have to use the get method (page.get("sidebar")) or it fails to execute. I'm not sure how to diagnose this, but I believe it is usually when the field is present but empty. As an example: $page->summary is a valid but empty field. twig gets this passed to it as page.summary {% if page.summary is defined %} {# this returns as true #} {%if page.summary is not empty %} {# triggers an error as below #} ... Error: Error Exception: An exception has been thrown during the rendering of a template ("Method Page::summary does not exist or is not callable in this context") As stated above, I can use page.get("summary") in these circumstances, but sometimes it is not clear which to use (an example is the layout.html.twig template which is extended by others - it is sometimes hard to know if page.summary will work on all pages). Any ideas? Thanks again for your time.

Wow, thanks! I'll have to give it a try tomorrow to see how it goes

Sounds great! I am really looking forward to seeing this one.

Any updates on this? I think it would be a great fit for a site I'm starting to work on now

sounds great I am looking forward to seeing how it works together. Thank you for all your help and input.

I think TemplateTwig is a great idea so I've renamed the module to this. If the __isset() method gets changed (or some other way of getting Twig to play nice here. I have no idea how difficult or useful it would be to 'override' Twig to use the has() function instead of isset(). Any suggestions?) then I think the module is essentially 'done' other than perhaps some install/uninstall routines. Is there anything that anyone thinks should go in them (create the views directory and optionally remove on uninstall...)?

This is looking really interesting, thanks! As others have mentioned, I think there are many of us that could learn from the way you would approach making a site for your clients. Is there any chance of another profile down the track that uses more of your 'tried and true' methodologies? Obviously I don't expect you to drop everything and start churning out code right away but I am sure I am not the only one that would love to see how 'The Creator' uses his own tools

I got the config variable working, but I had to add $this->config = wire('config'); to the init() function. I'm not sure this is a good idea but it seems to work. If I don't add this then print_r($this->config) or print_r($config) returns nothing. After adding it print_r($this->config) returns the config correctly. Am I missing something in the inheritance or is this normal? Also I noticed that the variables you have set assume the views folder lies underneath the templates folder (as opposed to next to it in the tree). This may have been the error you had initially. I think it makes more sense now to have it how you have it set so I have moved it there anyway. Edit: one other thing. Should I keep the module named as is or is there a better naming convention I could use (maybe RenderTwig)?

I tried to change the values as you suggested but I still run into errors on my test site. As I stated in a previous post I believe this is because I am using a .htaccess RewriteBase rule that starts with /~porl/. I think that php doesn't like require_once with paths like this (as the config variables seem to output the rule with the ~...). I tried changing it to /home/porl/... and the require_once started to work, but the site itself stopped working. If this is considered an edge case then I can just move my site out of the ~porl folder and do away with that rewrite rule, but I wanted to get the code working if someone else was in the same situation as myself if possible. If there is a better way to do this I'm happy to change it. I agree completely with the overkill of loading all fields (and you were right about the $pages typo). As you discovered the reason I had to call each field separately (or make the horrible full-loading thing) was because the way twig checked the fields made it give undefined errors if i didn't. If it is possible to fix the __isset() property to remove the need for this it would make things much cleaner. I have removed the field 'autoloader' in the meantime as I didn't want it there to begin with (hence the fact that I didn't call it from anywhere). I think this looks interesting, but I will have to admit it is a little out of my depth (especially with regards to my knowledge of ProcessWire workings so far). If it helps, the twig templates are now named with the following convention: [templatename].[templatetype].twig eg: basic-page.html.twig or user-list.json.twig etc. This might make it easier to detect a twig template (of any type, not just html output). On another note, I cleaned up the templates a little and made them a little more 'twiggy' (still not perfect but much better). I also added a template for the sitemap page, search page and the home page (this is just a copy of basic-page) to demonstrate replacing the entire front site with twig. I didn't touch the admin template of course but I don't think I'm going to rebuild the entire backend section just yet . Let me know what you think.

Here's my first attempt: https://github.com/p...ProcessWireTwig Sorry about the manual steps to get it going. I haven't had a chance to test things from scratch so let me know if I have left anything out of the README or if I have missed a file/setting. The example templates should essentially copy the basic-page.php template from the example site. It isn't pretty (especially the outer wrapper layout.html) as I just did a straight copy (rather than designing a site with Twig in mind) and haven't done any formatting tidy-up but should hopefully get someone started. Let me know what you think! Edit: Should I add code to the ___install() and ___uninstall() functions to create the views and cache folders (and delete the cache folder on uninstall)? Can the uninstall routine give a checkbox to choose to delete the twig views folder?

Twig seems to be doing the caching pretty well now that I set the options correctly. Is it considered good form to create a 'twig' directory in assets/cache or should I keep it out of there? As an exercise I ported the site files from the default install (not all of them but enough for basic-page.php pages to work). It wasn't too difficult, although there were a couple of small 'gotchas' there. It is working well enough that I am seriously considering using it for a real project. I'll tidy things up a bit and look into posting on github or something as apeisa suggested.

Thanks for the input I think the problem I was having with the htaccess is more to do with the way php executes require_once. I looked at the Comments module to see how php files were included in there and it is the same way I was doing (more or less) so I think I am ok. As for the caching it was a simple matter of passing Twig and auto_reload=true setting to the array when initialising it. This way Twig will regenerate a cache file if the source files are updated. It works perfectly. Would there be any interest here in me attempting to tidy the module up a bit? It still has some hard-coded assumptions which I don't like but since I am new to ProcessWire I'm not sure how to correctly approach them.

Woo! Progress!! I fixed the main bug and it is now working. A couple of limitations so far. No easy way to clear the cache, which is in a bad spot to begin with. Is there any way to integrate Twig's cache with PW's? At the moment I have just made a cache folder under my site/views folder. As the cache needs to be regenerated every time the template.php or twig view files are edited are there any suggestions for making this a simple process? I thought maybe have some url/page/?cache=clear get function? Would this be easy to do? Still have the __DIR__ paths in the module itself. I found out the problem with the $config->urls variables was to do with my .htaccess rewritebase having a ~porl at the beginning. I couldn't find an easy way around it (changing it to /home/porl broke other things so I don't know how else to do this setting. Any ideas?). Apart from that it seems to run brilliantly.

Is this what is meant by full text searching? Is there something about PostgreSQL's search that is lacking for ProcessWire? I am just curious, not trying to push the issue or anything.

Really interesting developments. Is there somewhere with information on the reasoning for sticking to PHP5.2 compatibility? I can understand that bug fix releases etc need to keep it as such, but would it not be holding things back in the long run to keep supporting 5.2 as new features are added?