Twig

[porl]

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.

[ryan]

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.

That's up to you and your time resources. The simpler you make it for people to install, the more likely it is to get used. I like to make modules as turn-key as possible, so that things can start working without having to do anything other than click 'install'. Obviously, how far that can be taken depends on what the module is for. But if you can safely undo everything with an uninstall() method, then building an install() method to handle installation is good. On the other hand, if it will be difficult to automatically uninstall(), then you may be better off providing good installation instructions (rather than a turn-key install) so that people have a better understanding when/if it comes time to uninstall the module.

[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?

[ryan]

Thanks for your updates to this module, and for posting to the modules directory.

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?

My opinion is that the more you can help the user, the better, so long as it's something that can be removed in the same way during an uninstall(). If it's something that would be more tricky to uninstall, then maybe better to let the user create it so that they also have some ownership if/when it comes time to uninstall.

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)?

Just to confirm, you want to have a way to prevent ProcessWire from throwing an exception when a method is called that it doesn't recognize?

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?

You could definitely override it for any given class, by extending the class and defining your own __call() method, but that will only affect calls to that particular class, and I'm thinking that's not what you want. It will be relatively simple for me to make PW's behavior (as to whether it throws an exception or not) configurable, so that may be the best bet, unless there's some way for Twig to catch the exceptions and continue normally.

[porl]

Thanks for your updates to this module, and for posting to the modules directory.

No problem. I've been busy with other projects so didn't get the chance to do much unfortunately. Hopefully I can get some more work done on it.

My opinion is that the more you can help the user, the better, so long as it's something that can be removed in the same way during an uninstall(). If it's something that would be more tricky to uninstall, then maybe better to let the user create it so that they also have some ownership if/when it comes time to uninstall.

This is what I thought. My main issue is determining what to do if the user has files in the views directory. Should I remove it anyway (I don't think this is the best bet); give user a message stating that it should be removed if they no longer use it; or give some way (checkbox) for them to select to delete it on uninstall? Personally I like the last option, so is this something that is relatively easy to do in an uninstall routine? Is there another module that has user interaction in the uninstall method that I can look at for reference?

Just to confirm, you want to have a way to prevent ProcessWire from throwing an exception when a method is called that it doesn't recognize?

Yes. At first I thought this behaviour would cause more potential issues than it solves, but it would definately make templates cleaner (there are many cases where it is unclear whether you can use, say, page.image or you have to use page.get('image'). This makes things a little messy and difficult to debug due to the fact that variables might be called from inherited templates. There is an 'if defined' type function in Twig, but this method itself can trip ProcessWire's exception.

You could definitely override it for any given class, by extending the class and defining your own __call() method, but that will only affect calls to that particular class, and I'm thinking that's not what you want. It will be relatively simple for me to make PW's behavior (as to whether it throws an exception or not) configurable, so that may be the best bet, unless there's some way for Twig to catch the exceptions and continue normally.

If you don't think it is feasible to do it in the module itself then I guess if you are happy to add the configuration option it would help a lot.

By the way, I know I said this before but I am continually impressed by your friendly and open involvement with the community here. This is what Open Source is all about. Thanks again.

[ryan]

This is what I thought. My main issue is determining what to do if the user has files in the views directory. Should I remove it anyway (I don't think this is the best bet); give user a message stating that it should be removed if they no longer use it; or give some way (checkbox) for them to select to delete it on uninstall?

I would probably just do as you said and give them a message. You could also have the module refuse to uninstall until they remove the directory by throwing an exception:

if(is_dir('/path/to/views/')) throw new WireException("Please remove your /path/to/views/ dir before uninstalling."); 

Yes. At first I thought this behaviour would cause more potential issues than it solves, but it would definately make templates cleaner (there are many cases where it is unclear whether you can use, say, page.image or you have to use page.get('image'). This makes things a little messy and difficult to debug due to the fact that variables might be called from inherited templates. There is an 'if defined' type function in Twig, but this method itself can trip ProcessWire's exception.

I have added this update to the dev branch if you want to try it out:

https://github.com/ryancramerdesign/ProcessWire/commit/bd5e549bc187a91cda47330181d5481674c41003

[porl]

Works perfectly thank you. I won't update the module 'officially' until the config option is in the normal branch (so people don't need to check out the dev branch to use the module) but my testing shows it has fixed the problem.

Thanks again.

[ryan]

Great, glad that worked. I'm putting a lot on the dev branch this week but will pull it all in next week. My internet access isn't all that consistent this week, so figured I'd avoid any unnecessary master commits temporarily.

[porl]

No worries. I'm in no rush to update the module online. I have a few 'housekeeping' things to do with it first anyway. Adamkiss suggested packaging Twig itself with the module (assuming the license allows it) which would make for less installation steps, and I also need to do the install/uninstall routines still as I haven't had any time to do so yet.

[porl]

I've updated the module with some configuration options and (hopefully) clearer instructions.

It is using functions from the development branch of ProcessWire but they are for convenience in template design and can be worked around (using things like page.get('field') instead of page.field for instance) if you need to run it on an older build before the development code gets merged.

If there are no bugs that people find then you could call this 'finished' (ignoring any future enhancements) and should be pretty stable now. Hopefully someone finds it of use. I've been making some test sites and will be definitely using it for at least two production sites I will be starting work on soon.

[hafa]

hey guys, any update on this? i struggle with php so being able to use twig in pw would be a joy for me! 

[Pete]

Welcome hafa

This post on the previous page has the link to download: http://processwire.com/talk/topic/1421-twig/?p=12807

Since porl says in his last post he considers it final unless anyone sport any bugs and nobody has replied since, I'd say it should be pretty stable

[owzim]

Is anyone using this in production? What about PW caching? Is it untouched by this?

[porl]

Hi hafa and owzim

I haven't been on here in a while as my work commitments were with things other than web development. I have been asked to once again look into migrating our company's old site to something new (which will very likely be ProcessWire with the Twig templates) so I will be looking at this again.

I haven't yet tried the module with the latest build of ProcessWire but unless Ryan has made some major changes to things I can't imagine there being an issue. I will of course test it properly when I get to working on the site and make any updates if necessary.

As for it's interaction with the cache I admit I am not sure. Twig caches itself to "raw" PHP code, which I believe has quite good performance, but beyond that I have not tried anything.

Let me know if there is anything more you'd like to know and assuming my work priorities don't get shifted on me again I will hopefully be able to look into it

[suntrop]

Can anyone tell me where to enable extensions? Can't find a yml file or any config in the module itself

[onjegolders]

Hey guys, picking up an old thread here but I was interested if it would be possible (in theory at least) to use PW's $page->save functionality whilst still using the Twig module?

I've had a fair bit of joy with most of it so far 

{{ session.redirect('/about') }}

 for example works great. This was leading me to hope I may be able to use the full power of PW still whilst keeping things clean with Twig.

Has anyone managed to do this successfully or would I have to revert to pure PHP to carry out certain PW tasks?

Thanks!