Jump to content

Recommended Posts

I think for certain profiles like the blog profile there could be a template switcher, but its use would be limited because as soon as you change the template files themselves too much it would begin to fall apart.

I think for certain profiles it does make some sense though as a way to get started quickly with a different design.

There is also the opportunity if you're bundling the templates folder to have a different layout entirely for a certain profile too, which is nice and flexible.

I think what needs to happen first is for there to be more than just one template for the blog profile for example and then we're talking.

Share this post


Link to post
Share on other sites

Yes, I can't see how you would employ the traditional idea of themes.

Profiles are not an alternative because they are not applied retrospectively.

The nearest I could see is if a developer created a range of profiles that used exactly the same styling system, and then created alternative themes - but that would not work outside of that environment and you would only have to play with the profile a tiny bit for this to stop working.

None of this I see as a problem, because I don't see ProcessWire as being aimed at that part of the market place.

Although the growth of profiles will be important, it really is in a subtly different way than people choosing WP because they found a nice theme:

  • They show what is possible,
  • They give starting points for less techy developers (like me!)
  • They are short cut starters for more techy developers (who are naturally lazy)
  • They provide framework variations

Interestingly, I think there is more value in developing "module" plugins to give quick functionality - styling from scratch can be very quick; creating functionality can be laborious sometimes.

For instance, a simple blog module would come with fields, page hierarchy (including category and tag selectors), templates and template files (as much split out into "inc" files as possible), all laid out in a very neutral way.

I would be "almost" usable out of the box, but would really require styling and fitting into the existing site structure.

These would be labour saving rather than instant solutions though - probably created by a developer to help themselves.

But then, that is how PW started years ago!

Share this post


Link to post
Share on other sites

Greetings,

I agree with Joss...

One of the central reasons that ProcessWire is so great is specifically becuse it does not have a "templating system." This might be uncomfortable for people who expect plug-and-play templating frameworks like you get in Joomla or WordPress, but in fact with ProcessWire you have the whole design world as your "template system." Yes, it assumes that the HTML/CSS/JS is not done for you.

Of course, it is possible that the ProcessWire community could develop a library of layouts and styles that could be used in projects, but -- and I think this proves the main point about ProcessWire templating -- those layouts and styles would be applicable beyond ProcessWire!

Joss -- interesting idea for project-based modules... Perhaps we could one day group modules into "sets": blog sets, news sets, community sets, etc? These sets could help people build certain kinds of ProcessWire sites faster, and you could pick and choose among them for your project.

But back to templating: I came here from the Joomla world, where templates are a constant hindrance to open designs. I hope ProcessWire never goes down that road!

Thanks,

Matthew

Share this post


Link to post
Share on other sites
Nate, I don't see how front-end themes could come from just adding template engine.

I don't recall saying front-end themes could come from just adding a template engine. In fact, my last post (see next quote) for the most part tried to move away from the original title of this topic to what is was meant to be about from the start which was finding ways to make things easier on users. The template engine was an idea though, yes, off topic from Ryan's original post as I remember it; I see that now.

Bringing up template engines was only one idea to help make things easier for people though, I'm sure there are many other ideas as well.
PW is much more flexible in it's data modelling than WP and markup generation (just like EE is) and that is the reason there cannot be traditional "themes" that can be just switched.

I agree with this and mentioned something to that extent in my last post as well.

With that said, I guess I don't know what the original topic from Ryan was about anymore to be honest because PW isn't really setup to be easier than WP rather, by design, to allow freedom to model data among other things like you said. I'm going to have to re-read that topic again I guess.

@Joss I think Drupal does something similar with their profiles in regards to having a set of profiles which are module based though, also theme based. That of course isn't like WP and is a one time install just like PW would be as I remember it.

It is however a good idea to allow people to quickly setup common sections of a site like a blog to help keep things DRY. So, site profiles which aren't necessarily theme based that could be installed at any point one needed them would be nice. Client needs a blog now, you just grab the "blog module/s based profile" and go.

I seem to remember seeing a module which would help for quickly setting things like this up though, I don't remember for sure. EE has something similiar which may never see the light of day but, you can still check it out here.

Share this post


Link to post
Share on other sites
I don't recall saying front-end themes could come from just adding a template engine. In fact, my last post (see next quote) for the most part tried to move away from the original title of this topic to what is was meant to be about from the start which was finding ways to make things easier on users.

Sorry, I misread your last post. 

It is however a good idea to allow people to quickly setup common sections of a site like a blog to help keep things DRY. So, site profiles which aren't necessarily theme based that could be installed at any point one needed them would be nice. Client needs a blog now, you just grab the "blog module/s based profile" and go.

I have been thinking about that a lot lately. I think that to get PW more popular "one click features" like blog, news, products etc are great idea. There are few things that slow down that road currently:

  • Export and import of templates & fields - that will be huge time saver when creating such a modules (if you take a look my shopping cart checkout module, there is quite a lot code just for field/template/page creation)
  • Field duplication: should each feature bring their own fields, like blog_body or re-use existing ones? If the latter, then we might need to increase the amount of "default" fields. Maybe as simple as adding few more fields to starting profile.

Share this post


Link to post
Share on other sites

A solution might be to create a profile with some common elements, blog. sliders, galleries, portfolio, etc.. using something like twitter Bootstrap or Zurb Foundation for example. Then have a couple of different stylesheets to "customize the look".   You get the same effect as a "theme".  People could easily install the profile, customize the site stylesheet , add content, and be up and running. 

 PW is not WP and that is a great thing.

  • Like 1

Share this post


Link to post
Share on other sites

Hi,

Brand spanking new to ProcessWire and I must say I am very impressed so far.

My background is 24 years in non-web development, and recently working with Joomla, WP, Drupal, custom PHP and learning Laravel.

I would like to suggest that this is not "syntax" question as it is just as easy to learn <?php echo $somevar ?> as it is to learn {{ somevar }}. However, as a developer who is working on a team with a designer, I really believe it is important to separate out display from logic. It is too easy to give a designer with limited PHP experience the requirement to use PHP to create their template (WP anyone?). We all know what happens with a missing ; in a PHP script... BLANK SCREEN. This is totally unacceptable in a team/enterprise environment and also, I think it is a flawed design decision.

I understand that PHP was initially disigned as a template language, but it has moved beyond that at this point and PHP5 is a decent programming language. So, we are really saying that we expect designers/users to actually know and understand a full programming language when all they want to do is create an HTML template that has some placeholders to put their content.

Laravel was mentioned in an earlier post. I think it is a brilliant product and it includes Blade, a templating language. Why? Because it is important to allow non-PHP developers access to this awesome technology while still allowing the developer full access to the framework.

I work on small teams with a designer and a moderately competent user. As it stands, I would not let my user or my designer have too much control over the PHP so that means more work for me so I don't get the 3am phone calls saying the site is down because they missed a ; or a closing >.

This is a project with HUGE potential and I think KUDO's are deserved to everyone involved, especially Ryan for having a brilliant vision and forsight. Let's not make this a "geek" only tool but be inclusive to others by allowing an alternative to PHP as the templating language. Think beyond a one man shop and this product has tremendous potential.

My 2 cents!

Anthony

Share this post


Link to post
Share on other sites

This isn't meant to disagree with what you've just said, more just understand the processes people follow when working in teams.

Why would you let your designer work on templates in your final system at all? The way I do it when working on my own sites is to build templates separately and then copy and paste the HTML into the ProcessWire templates, which to me seems sensible over letting a designer do tweaks on the actual system. Where I've worked in a team this was also the preferred way of doing things - the dev would be the one to actually insert the final HTML into the template files.

This is definitely more about me not knowing other people's processes than anything else though so please do weigh in with your experiences.

The other thing to bear in mind is that even with a templating engine they could still type PHP into the template files so it wont stop them, but on the bright side if you don't tell them they can then they're less likely to do it :)

And welcome to ProcessWire Anthony.

Share this post


Link to post
Share on other sites

Also worth noting is that porl has created a Twig module here: http://processwire.com/talk/topic/1421-twig/?fromsearch=1 and there is a Smarty module somewhere on the forums recently too so you could try both of those out.

I can't see either being the default though because the system is designed to make few/no assumptions about the end user, but there are a few options there at least :)

Share this post


Link to post
Share on other sites

I agree with Pete.

In my opinion, the "Designer" or "Front-end-guy" should do his stuff in plain HTML/CSS/Js. Then the dev copy paste this into a Pw-Template and makes it work there.

A Pw template does not only output static html, most of the time you combine this with your fields assigned or you need to display data from any Pages anywhere on your site. This again is a task for the developper, maybe you must create new fields or queries before. Then you can mix this with the code from the designer.

Using a Template language, you have the same problem: If the designer messes up the tags, ther Parser will throw an error and your template isn't displayed.

That said, I don't know this workflow because where I worked, I received a .psd and had to do the front- and backend coding myself.

Share this post


Link to post
Share on other sites

In my huge team of one, I work like Pete - I design away from the final environment, even if that means pencil and paper. 

The results of that I put into the system.

But in reality, just like my proper job of a composer/sound engineer/producer, the system has become very blurred with creative people doing technical jobs and technicians doing creative jobs.

When I first started in the seventies, this was only just happening really - there were still the sound engineers who got fussy about non-engineers touching the faders (especially in the BBC which was stuffed with idiotic union members who were not even good sound engineers).

But the technology changed this with the result that a lot of professional music is composed at home by untrained engineers - and it is good stuff too!

The whole point about languages like PHP is that as natural languages they are meant to be easy to use by non technical users. They are intentionally designed to blur the boundaries to make the design process more coherent.

Now, obviously keeping some separation makes debugging much easier and allows for redesign without changing the mechanics, but I don;t think that means there should be no trespassing at all on each others territory.

Personally, I don't see a problem with that as long as the end product goes through some QC and fulfils the brief.

Also, on a purely selfish note, I am only just beginning to get my head around PW as it is - without learning yet another syntax! :) (Old brain does not absorb stuff as easily as it used to)

Joss

  • Like 1

Share this post


Link to post
Share on other sites

Agree with all above, but even with the workflow you referred, I don't think PHP is more dangerous than a template engine sintax because in that case, all the PHP will have to be very simple as you will have to implement a trully MVC system, right? If so, because all the complex logic will be out of the "view" files, you will always have very simple and not dangerous PHP code for the designers to work with:

<?= $page->title ?>

or at the most:

<div>

<? foreach($page->children as $child): ?>

<h3><?=$child->title?></h3>

<p><?=$child->body?></p>

<? endforeach; ?>

</div>

Share this post


Link to post
Share on other sites

Very neat, Diogo :)

Or you just wrap the entire lot in a function that has very minimal markup that can be bent with CSS and then shove it into your template:

<div class="myBigContainer">

<?php loadPageRubbish(); ?>

</div>

Share this post


Link to post
Share on other sites

Hello there, @artaylor, and welcome to the forum!

Just like Pete above, I've got absolutely no problem with template engines - as long as they stay out of my way :)

What I do have to disagree with is the general idea that template languages makes things simple and programming languages difficult. Template languages generally start with a good idea ("separate code / logic from markup / view") but eventually end up re-creating much of native functionality and only making things more complicated for everyone. Designers still need to learn new (template) language and developers not previously acquainted with that particular template engine have to do the same just to keep up and provide often necessary support.

Just take Twig as an example; it's really quite amazing how complicated structures any moderately resourceful designer can create with relatively simple tools like macros, conditional logic, variables - especially when combined with template inheritance and horizontal reuse.

I also strongly disagree with your notion that designers would need to know and understand "a full programming language" simply to create HTML template with some variables. Exactly why would they need to do that, if all they need is echo and some simple control structures? How would this part be so different when using a template language instead of PHP?

Based on what you've said there some template languages seem to be pretty fault tolerant, but I can't help wondering if that's really a good thing - I mean, why shouldn't there be an error if something is clearly broken? What if it causes misleading information to be spread out, UI to be broken or any number of other problems?

One thing I do see value in is sandboxing, though. Like you pointed out, sometimes it's necessary to set limits for the amount of damage an inexperienced designer (or developer) can unintentionally cause. This is a good argument for template languages, though I'd still argue that most of these issues can be avoided altogether.

Pete and others have already provided valid solutions above. Another important thing is to never make changes on live environment. That's just plain wrong and will definitely cause problems eventually, no matter how skilled folks you've got. You can also provide designers with a simple checklist of things to a) do, b) not do and c) be careful about. IMHO that's much better than making everyone learn yet another language.

All that said, there's clearly a lot of interest in template engines around here nowadays, so you can be sure that eventually you won't have to teach another row of PHP to a designer. I still honestly wish that more designers could get over their phobia of these evil programming languages and realize that they're not that bad after all. This is one of the reasons why I won't ever advocate disguising or wrapping PHP (or any other "programming language") with something that's ultimately just another layer of complexity :)

Edit: even though this post is already horribly long, I just had to add that the way I see it such things as "pure" programmers, front-end guys or designers rarely exist in the world of modern web development - and that's a good thing. Learning what others do and how they do it, even if it's just the basics, can benefit everyone. No one benefits from tightly set roles, such as "designer can't write PHP, period." :)

Edited by teppo
  • Like 4

Share this post


Link to post
Share on other sites

ProcessWire is actually the first iteration of this CMS that doesn't rely on a template engine. And Dictator CMS (the grandaddy of ProcessWire) was entirely template engine based, with no PHP API or PHP support at all.

I'm no stranger to template engines. While there are benefits to template engines, my own experience has been that the benefits are largely perceived rather than experienced. There are also some tangible benefits too. But how many of those tangible benefits apply varies greatly from system to system. ProcessWire has a nice API, but most CMSs do not. For many of those CMSs, the template engine is what makes the system accessible (or at least, more accessible). Expression Engine is an example. In those systems, template engines are providing a huge benefit by isolating the developer from having to use a complex or crappy API. Nobody would use these systems without the template engine. But in a system like ProcessWire, a template engine is redundant, less capable, and ultimately more complex layer of overhead. 

Most of the time, we do not want that kind of extra overhead in ProcessWire. In our context, the only real benefits of a template engine are if you have some kind of syntax preferences (PHP is not always the prettiest syntax) or if you want to have a jail. There are some valid reasons to have a jail, as pointed out earlier… but I prefer education to jail. :) Still, I understand the reasoning and can't say it's always wrong. Just that it's wrong for a core default. There's also that benefit of perception. If one perceives there are some other benefits to a template engine, they will seek out systems that have them, even if perception isn't always reality. 

I believe strongly in the benefits of our current approach and API. I feel these benefits are far greater than what comes from any template engine. And I've discussed them at length many times in many places, so I won't rehash that all here. But I've always wanted ProcessWire to support template engines, just not to require one. So I like what I see with the Twig and Smarty modules. Actually, the Smarty module seems like it would be especially simple to work with, since it bolts in so quickly and easily. I hope to see more in this area and am always willing to do whatever it takes to support add-on template engines (we even added a hook or two to support the Twig module).

While I personally don't need these template engines and sometimes question their value, I also very much support them in ProcessWire as modules. Perception is powerful, and we're trying to grow our audience. Likewise, there may be some that have template engine preferences beyond just perception. Anything that opens a door for more people is a good thing. While ProcessWire's core isn't and won't be built around a template engine dependency, we fully support use and implementation of them as modules. And I'm also willing to add any new core hooks or capabilities necessary to support the development of such modules.  

  • Like 2

Share this post


Link to post
Share on other sites

Wow. I did not expect this much response. I think it says a lot for the community and the passion behind Pw.

As I mentioned, I am very new to Pw so it is possible that once I get to know it better I will agree that a template language is completely unnecessary. Also, I have no problems with it being a module that can be loaded if needed. I certainly don't think it needs to be in the core. So, if there are modules that already exist then I am satisfied. For example, I hate TinyMCE is totally screws up my code. So, I don't use it, but it is there for those that want to. That is one of the things that I see with Pw that I like.

Thanks for all the feedback and comments!

Now, for my own enlightenment, I am interested in where you all draw the line between Design and Development. In my current situation, my designer knows HTML and CSS (he obviously knows design too). So, in my thinking, that is the demarkation point. I should not need a copy of Photoshop to develop and he should not need to load debugging tools, etc to design. He provides clean HTML/CSS and I fill the templates with data. That is why I feel it is important that the designer can modify the templates and not just hand them off to me to implement.

The user is expected to handle the data so why are we keeping the designer away? Is this not a 3-way partnership? I know that some of you are one-man shops and totally capable of doing it all, but I am trying to understand this from a small team perspective. I have done the last few sites in MODX Revolution and the designer was fine with being able to modify the templates and leave all PHP to me. If he needed something specific, he could ask and the same for me. The user just entered the content. It seemed to work well and balance out the work.

My musings... I will probably look back on this message and laugh at my Pw naivety. It's all good and thanks again for being so responsive and open.

Anthony

  • Like 3

Share this post


Link to post
Share on other sites

I cant speak from the web development world, but having been in the advertising, film and music worlds for 35 years I can speak for the web's great ancestors.

I think there is a huge difference between specialisation and isolation. 

In the industry I come from, although we do have dedicated technical roles, most roles are specialisations out of choice from people that start from pretty much the same point - a runner, mostly! :)

So, the the recoding engineer, voice over director, video editor, film writer, producer, advertising creative director, could have all been the same person originally.

That sort of evolutionary career path produces something that is vital in some of the huge, multi-million dollar projects I have been involved with over the years (often just in tiny way)

We all understand what each other does. 

That does not mean we could do each other's jobs, but we can bring our particular specialisation as a perspective. So as a sound person, I might pick up a visual edit that has not worked. An editor might notice a glitch on the sound track that I have missed.

This is all despite the fact that the unions over the years have tried to stop people knowing (let alone doing) each others work. 

So, basically I believe that there should be a team - between the client, the developer and the designer (and possibly the often neglected marketing/pr guru). And although each should bring their specialisation to the table, they should appreciate each other's perspectives and career-informed opinions.

To communicate those it helps if they understand each others work. And if that means the designer phoning the developer and saying "how can I grab that bit of data so I can play with it," then all the better. 

Sometimes treading on each other's toes is the beginning of being able to dance together...

Joss (2013) :)

Share this post


Link to post
Share on other sites

This was maybe already mentioned somewhere before, I haven't read all the posts.

In my opinion, a Template Enginge makes sense in a MVC environment where the view is clearly separated from the logic in the controller and does not accept PHP.

Usually it works like this:

<?php
//In Controller
$showNav = true;
$pages = query("SELECT * FROM....*");
$view->assign('pages', $pages);
$view->assign('showNav', true);

//In View
{if $showNav}
  //....
  {foreach $pages as $page}
    //...
  {/foreach}
{/if}
?>


In ProcessWire, you have the freedom: a Template can be just the controller and fetch another template for the output – or it can directly output Markup. Or you can mix those things up and leave the sometimes-overrated MVC-stuff.

I think for most projects it's fine to find a way between.

Personally, I wouldn't use Smarty in ProcessWire because when the Pw-Template is actually a Smarty-Template, where to put the PHP stuff? Where can I use the awesome Pw-API to search my content? Of course you can write smarty functions and assign variables in smarty, but this makes it again complicated. That said, I used smarty a lot and think it's great, especially the template inheriting stuff! But not in ProcessWire :)

Share this post


Link to post
Share on other sites

@Wanze, the logic-view separation makes all the sense in the scenario that Antony referred, but to me it's perfectly possible to keep PHP very discrete inside the HTML with the PW sintax.

@Anthony, your team's workflow seems perfectly logical and healthy to me, but it still implies some understanding of what each other do. You show understanding for the designer's work when you worry about letting him have his code as clean as possible of PHP, and he has to show some understanding of your work by trying to understand how some basic but important programming things work. He has to know how a loop works and where his HTML should go inside it, or how a condition works, etc... and if he gets that on a template engine, he will also get it with PW as long has you are careful to keep all your complex code on another file.

Share this post


Link to post
Share on other sites
Now, for my own enlightenment, I am interested in where you all draw the line between Design and Development. In my current situation, my designer knows HTML and CSS (he obviously knows design too). So, in my thinking, that is the demarkation point. I should not need a copy of Photoshop to develop and he should not need to load debugging tools, etc to design. He provides clean HTML/CSS and I fill the templates with data. That is why I feel it is important that the designer can modify the templates and not just hand them off to me to implement.

Creation of markup and CSS isn't technically a design task in the traditional sense, unless the designer literally designs in markup and CSS (a trend I like). Perhaps that comes from the places I've worked, but front-end development was always a development task. The designers dealt with concepts and visuals, not code (markup, css, Javascript and template engines are all code). I think there is more of a blurred line now though, that's a good thing… I've always liked having my hands in both. But I work with a few design firms that outsource development to me, and all provide me with layouts (whether photoshop or some kind of flat image type). I've never had a designer provide me with code... though maybe my experience is isolated there. Photoshop is both a design and development tool. I don't know many web developers that can do their job without some kind of image manipulation tool like Photoshop. So I would disagree with "I should not need a copy of Photoshop to develop". But I know different companies do it different ways. If you've got designers doing front-end development, that's great, but they are working with code, doing development. If they are producing good quality markup and CSS, and really know how to design, they are a "web designer/developer". That term is what defines most of our audience here. Your company should give those designer/developers a raise. :) 

So lets say that's your workflow. I agree with Diogo that this sounds healthy… so long as the designers know their front-end code as well as a dedicated web developer.

The "logic" that people use in ProcessWire templates is largely presentational logic. If you are trying to follow an MVC pattern, presentation logic is still a component of the view layer. I think this distinction is important. ProcessWire is already handling the business logic. It doesn't really matter whether you are dealing with a PHP API or a template engine, as the tasks are going to be the same.

ProcessWire templates can also be used for business logic. Typically we don't want to be processing forms, saving pages, etc., in the places we are generating markup for output, even if you technically can. There are a lot of good approaches one can take to separate concerns. If using an MVC approach, then you would isolate your presentation logic and markup to a separate view, like we do with the Blog profile. (Though in the Blog profile we really do this more for demonstration purposes, as there's not much in the way of business logic.) If you take this approach, you are using your ProcessWire templates as controllers and dedicating other files as views. You can use the TemplateFile() class for views, as the Blog profile does, or you can use some other template engine like Twig, Smarty, etc. I think that this approach may provide the right balance of separation for the environment you've described. But I'm not sure it's worth the overhead unless building some real business logic (like an application) rather than a traditional web site. 

Personally, I wouldn't use Smarty in ProcessWire because when the Pw-Template is actually a Smarty-Template, where to put the PHP stuff? Where can I use the awesome Pw-API to search my content? Of course you can write smarty functions and assign variables in smarty, but this makes it again complicated.

I'm not sure about the Smarty module, but the Twig module seemed to have the entire PW API available to it. 

  • Like 1

Share this post


Link to post
Share on other sites

Just thinking about what Ryan says about the real (or perhaps old) place for the line should be so that the devs also take care of html and css as well as serverside leaving the designer to come up with the concept.

Working like that does open the doors for great design to be sourced from outside of the web design world, bringing in some of the older or more specialised but brilliant designers that have not got involved because they know nothing about html (and have no time/interest in learning)

Years ago I applied for a job doing sound for a games company. My CV includes sound credits on several feature films, work on massive launches for X-Files movie and British Airways, sound-effects design for TV, film, radio drama (which is probably more applicable) and more, and voice director on thousands of productions.

Plus, I am a credited music editor and composer.

BUT, I don't know any C++ or C# and so on.

Sorry, said the idiot at the company, noting my lack of programming skills, we don't see what relevance your experience has to games. 

Their loss (and their subsequent game sounded awful), but it did demonstrate how easy it is to lose out on valuable knowledge, skills and creativity if you put the importance of technology above the needs of the product.

So, perhaps Ryan's observation has huge relevance even today.

Personally I still believe the pencil and paper is still the most powerful concept design tool there is.

Share this post


Link to post
Share on other sites

@joss: don'f forget the vital design tool called a restaurant napkin. ;)

@ryan: thanks for your input. I have to say your experience would far eclipse mine in the web development world so I will take a solid look at how things are being done and perhaps move that line...

In general, I am working my way through my first PW project. It is more challenging than I thought it would be, but I think that is because I am making it more difficult that it needs to be and I need to "grok" this more fully. I keep thinking how I would do it in MODX then having to re-think it. It is coming along, albeit slowly.

Thanks for all the feedback. Excellent forum!

Share this post


Link to post
Share on other sites

Let us know if you run into any issues or need to ask how to do something the "PW way" - usually you'll get a quick response and that certainly helped me transition from MODx to PW a few years ago :)

Share this post


Link to post
Share on other sites

@joss: don'f forget the vital design tool called a restaurant napkin. ;)

Ah, the modern, healthier version of the back of the fag packet ... er , cigarette packet (What do you mean, we aren't all Britons in here?)

In general, I am working my way through my first PW project. It is more challenging than I thought it would be, but I think that is because I am making it more difficult that it needs to be and I need to "grok" this more fully.

Now this I completely relate too. I keep adding bits because I wonder "how do I do this?" or "I wonder it this will work?"

Great fun, but I am worried about my productivity!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Mithlesh
      Changing it to null
    • By Mithlesh
      Hi, I have one URL - writerrelocations.com/contact-now/

      I have one issue where my header Image is appearing again after the contact form, for your reference:



      I have checked my processwire template section where have not added any Image field besides Header Image, attaching the same for the reference:




      PLEASE help me to get rid of the image below contact form

      Waiting for the swift response!

      Thanks
       
    • By DooM
      Hello,
      I'm working on something like "structure generator" for my own needs which is run after clean installation of PW to create basic structure, fields, install modules, remove unnecessities, etc.
      I'm trying to remove site/templates/scripts and site/templates/styles folders, but I'm out of ideas already. When I try PHP's unlink function, it says that the path doesn't exists, which is obvious, because it will try to delete those folders under FileCompiler folder. This is probably because PW compilation process? I'm initializing this mine "structure generator" in ready.php.
      Do any of you guys have any idea how to get rid of those folders? My styles and scripts folders are separated, so I don't need those two inside templates folder.
      Thanks for every advice. 🙂
    • By MoritzLost
      I have recently started to integrate Twig in my ProcessWire projects to have a better separation between logic and views as well as have cleaner, smaller template files as opposed to large multi-purpose PHP-templates. Though there is a Twig module, I have opted to initialize twig manually to have more control over the structure and settings of the twig environment. This is certainly not required to get started, but I find that having no "secret sauce" gives the me as a developer more agency over my code structure, and better insights into how the internals of the libraries I'm using work.
      Framework like Drupal or Craft have their own Twig integration, which comes with some opinionated standards on how to organize your templates. Since Twig is not native to ProcessWire, integrating Twig requires one to build a solid template structure to be able to keep adding pages and partials without repeating oneself or having templates grow to unwieldy proportions. This will be an (opinionated) guide on how to organize your own flexible, extensible template system with ProcessWire and Twig, based on the system I developed for some projects at work.
      Somehow this post got way too long, so I'm splitting it in two parts. I will cover the following topics:
      Part 1: Extendible template structures How to initialize a custom twig environment and integrate it into ProcessWire How to build an extendible base template for pages, and overwrite it for different ProcessWire templates with custom layouts and logic How to build custom section templates based on layout regions and Repeater Matrix content sections Part 2: Custom functionality and integrations How to customize and add functionality to the twig environment How to bundle your custom functionality into a reusable library Thoughts on handling translations A drop-in template & functions for responsive images as a bonus However, I will not include a general introduction to the Twig language. If you are unfamiliar with Twig, read the Twig guide for Template Designers and Twig for Developers and then come back to this tutorial.
      That's a lot of stuff, so let's get started 🙂
      Initializing the Twig environment
      First, we need to install Twig. If you set up your site as described in my tutorial on setting up Composer, you can simply install it as a dependency:
      composer require "twig/twig:^2.0" I'll initialize the twig environment inside a prependTemplateFile and call the main render function inside the appendTemplateFile. You can use this in your config.php:
      $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; Twig needs two things: A FileSystemLoader to load the templates and an Environment to render them. The FileSystemLoader needs the path to the twig template folder. I'll put my templates inside site/twig:
      $twig_main_dir = $config->paths->site . 'twig'; $twig_loader = new \Twig\Loader\FilesystemLoader($twig_main_dir); As for the environment, there are a few options to consider:
      $twig_env = new \Twig\Environment( $twig_loader, [ 'cache' => $config->paths->cache . 'twig', 'debug' => $config->debug, 'auto_reload' => $config->debug, 'strict_variables' => false, 'autoescape' => true, ] ); if ($config->debug) { $twig_env->addExtension(new \Twig\Extension\DebugExtension()); } Make sure to include a cache directory, or twig can't cache the compiled templates. The development settings (debug, auto_reload) will be dependent on the ProcessWire debug mode. I turned strict_variables off, since it's easier to check for non-existing and non-empty fields with some parts of the ProcessWire API. You need to decide on an escaping strategy. You can either use the autoescape function of twig, or use textformatters to filter out HTML tags (you can't use both, as it will double escape entities, which will result in a broken frontend). I'm using twig's inbuilt autoescaping, as it's more secure and I don't have to add the HTML entities filter for every single field. This means pretty much no field should use any entity encoding textformatter. I also added the Debug Extension when $config->debug is active. This way, you can use the dump function, which makes debugging templates much easier. Now, all that's left is to add a few handy global variables that all templates will have access to, and initialize an empty array to hold additional variables defined by the individual ProcessWire templates.
      // add the most important fuel variables to the environment foreach (['page', 'pages', 'config', 'user', 'languages', 'sanitizer'] as $variable) { $twig_env->addGlobal($variable, wire($variable)); }; $twig_env->addGlobal('homepage', $pages->get('/')); $twig_env->addGlobal('settings', $pages->get('/site-settings/')); // each template can add custom variables to this, it // will be passed down to the page template $variables = []; This includes most common fuel variables from ProcessWire, but not all of them. You could also just iterate over all fuel variables and add them all, but I prefer to include only those I will actually need in my templates. The "settings" variable I'm including is simply one page that holds a couple of common settings specific to the site, such as the site logo and site name.
      Page templates
      By default, ProcessWire loads a PHP file in the site/templates folder with the same name of the template of the current page; so for a project template/page, that would be site/templates/project.php. In this setup, those files will only include logic and preprocessing that is required for the current page, while the Twig templates will be responsible for actually rendering the markup. We'll get back to the PHP template file later, but for the moment, it can be empty (it just needs to exist, otherwise ProcessWire won't load the page at all).
      For our main template, we want to have a base html skeleton that all sites inherit, as well as multiple default regions (header, navigation, content, footer, ...) that each template can overwrite as needed. I'll make heavy use of block inheritance for this, so make sure you understand how that works in twig.
      For example, here's a simplified version of the html skeleton I used for a recent project:
      {# site/twig/pages/page.twig #} <!doctype html> <html lang="en" dir="ltr"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>{% block title %}{{ '%s | %s'|format(page.get('title'), homepage.title) }}{% endblock %}</title> <link rel="stylesheet" type="text/css" href="{{ config.urls.site }}css/main.css"> </head> <body class="{{ page.template }}"> {% block navigation %}{{ include("components/navigation.twig") }}{% endblock %} {% block header %}{{ include("components/header.twig") }}{% endblock %} {% block before_content %}{% endblock %} {% block content %} {# Default content #} {% endblock %} {% block after_content %}{% endblock %} {% block footer %}{{ include("components/footer.twig") }}{% endblock %} </body> </html> All layout regions are defined as twig blocks, so each page template can override them individually, without having to touch those it doesn't need. I'll fill the content block with default content soon, but for now this will do. Now, templates for our content types can just extend this base. This is the template for the homepage:
      {# site/twig/templates/pages/page--home.twig #} {% extends "pages/page.twig" %} {# No pipe-seperated site name on the homepage #} {% block title page.get('title') %} {# The default header isn't used on the homepage #} {% block header %}{% endblock %} {# The homepage has a custom slider instead of the normal header #} {% block before_content %} {{ include('sections/section--homepage-slider.twig', { classes: ['section--homepage-slider'] }) }} {% endblock %} Note that I don't do most of the actual html markup in the page templates, but in individual section templates (e.g. section--homepage-slider.twig) that can be reused across content types. More on this in the next section.
      We still need to actually render the template. The page template (which will be the entry point for twig) will be loaded in our _main.php, which we defined as the appendTemplateFile earlier, so it will always be included after the template specific PHP file.
      $template_file = 'pages/page--' . $page->template->name . '.twig'; $twig_template = file_exists($twig_main_dir . '/' . $template_file) ? $template_file : 'pages/page.twig'; echo $twig_env->render($twig_template, $variables); This function checks if a specific template for the current content type exists (e.g. pages/page--home.twig) and falls back to the default page template if it doesn't (e.g. pages/page.twig). This way, if you want a blank slate for a specific content type, you can just write a twig template that doesn't extend page.twig, and you will get a blank page ready to be filled with whatever you want.
      Note that it passes the $variables we initialized in the _init.php. This way, if you need to do any preprocessing or data crunching for this request, you can do it inside the PHP template and include the results in the $variables array.
      At this point, you can start building your default components (header, footer, navigation, et c.) and they will be included on every site that extends the base page template.
      Custom sections
      Now we've done a great deal of setup but haven't actually written much markup yet. But now that we have a solid foundation, we can add layout components very easily. For most of my projects, I use the brilliant Repeater Matrix module to set up dynamic content sections / blocks (this is not the focus of this tutorial, here's a detailed explanation). The module does have it's own built-in template file structure to render it's blocks, but since it won't work with my Twig setup, I'll create some custom twig templates for this. The approach will be the same as with the page template itself: create a "base" section template that includes some boilerplate HTML for recurring markup (such as a container element to wrap the section content in) and defines sections that can be overwritted by section-specific templates. First, let's create a template that will iterate over our the Repeater Matrix field (here it's called sections) and include the relevant template for each repeater matrix type:
      {# components/sections.twig #} {% for section in page.sections %} {% set template = 'sections/section--' ~ section.type ~ '.twig' %} {{ include( [template, 'sections/section.twig'], { section: section }, with_context = false ) }} {% endfor %} Note that the array syntax in the include function tells Twig to render the first template that exists. So for a section called downloads, it will look look for the template sections/section--downloads.twig and fallback to the generic sections/section.twig. The generic section template will only include the fields that are common to all sections. In my case, each section will have a headline (section_headline) and a select field to choose a background colour (section_background) :
      {# sections/section.twig #} {% set section_classes = [ 'section', section.type ? 'section--' ~ section.type, section.section_background.first.value ? 'section--' ~ section.section_background.first.value ] %} <div class="{{ section_classes|join(' ')|trim }}"> <section class="container"> {% block section_headline %} {% if section.section_headline %} <h2 class="section__headline">{{ section.section_headline }}</h2> {% endif %} {% endblock %} {% block section_content %} {{ section.type }} {% endblock %} </section> </div> This section template generates classes based on the section type and background colour (for example: section section--downloads section--green) so that I can add corresponding styling with CSS / SASS. The specific templates for each section will extend this base template and fill the block section_content with their custom markup. For example, for our downloads section (assuming it contains a multivalue files field download_files):
      {# sections/section--download.twig #} {% extends "sections/section.twig" %} {% block section_content %} <ul class="downloads"> {% for download in section.download_files %} <li class="downloads__row"> <a href="{{ download.file.url }}" download class="downloads__link"> {{ download.description ?: download.basename }} </a> </li> {% endfor %} </ul> {% endblock %} It took some setup, but now every section needs only care about their own unique fields and markup without having to include repetitive boilerplate markup. And it's still completely extensible: If you need, for example, a full-width block, you can just not extend the base section template and get a clean slate. Also, you can always go back to the base template and add more blocks as needed, without having to touch all the other sections. By the way, you can also extend the base section template from everywhere you want, not only from repeater matrix types.
      Now we only need to include the sections component inside the page template
      {# pages/page.twig #} {% block content %} {% if page.hasField('sections') and page.sections.count %} {{ include('components/sections.twig' }} {% endif %} {% endblock %} Conclusion
      This first part was mostly about a clean environment setup and template structure. By now you've probably got a good grasp on how I organize my twig templates into folders, depending on their role and importance:
      blocks: This contains reusable blocks that will be included many times, such as a responsive image block or a link block. components: This contains special regions such as the header and footer that will probably be only used once per page. sections: This will contain reusable, self-contained sections mostly based on the Repeater Matrix types. They may be used multiple times on one page. pages: High-level templates corresponding to ProcessWire templates. Those contain very little markup, but mostly include the appropriate components and sections. Depending on the size of the project, you could increase or decrease the granularity of this as needed, for example by grouping the sections into different subfolders. But it's a solid start for most medium-sized projects I tackle.
      Anyway, thanks for reading! I'll post the next part in a couple of days, where I will go over how to add more functionality into your environment in a scalable and reusable way. In the meantime, let me know how you would improve this setup!
×
×
  • Create New...