2

I hope this question does not sound to banal: I am currently switching to Craft CMS and I am used to build my HTML/CSS/JS templates as static pages with dummy content.

This (seemingly?) has 3 advantages for me:

  1. I have an early, clickable prototype, presentable to the client before I have to touch any CMS
  2. I am not forced to insert real content via the CMS yet
  3. It gives me a very clean Git Repository for the frontend without any CMS dependencies yet

The disadvantage is of course that I have to manually split my static pages up later to work with Craft CMS (or any other CMS) templating logic.

Thus I was wondering how you approach templating, especially with Craft: Whether you start directly building your frontend from scratch in Craft’s Templates folder or if you start independently, and do the splitting of files every time as a necessary step …

Any suggestions?

4

We used to do what you are doing, for a good many years - it was especially helpful when we didn't know what CMS we were going to use yet, or when we had a front end specialist (hello) who would send the files off to the back end specialist for implementation.

However, with Craft, we've found that the front-end people can use it well enough to not need a 'back end specialist', so we find ourselves no longer doing site builds as front-end assets first. It's just faster and easier to build the HTML/CSS/JS from inside the Craft templates.

We also used to (and still do for larger projects) build a completely non-styled "blueprint" of the website. The objective was to ensure that the site structure was correct - here's an example: http://example.bp.myvcsite.com/

That was/is part of our whole approach where we split things into blueprint; visuals; static build; CMS integration: http://example.myvcsite.com/

3

Tobias: I don't think there's a "right" answer for everyone.

What I do find is that Craft "gets out the way" a lot more. Craft's file structure and Twig templates aren't that far away from just static HTML.

You can actually throw an index.html file inside Craft's templates folder and Craft will serve it just fine. All the stuff you need to grab from the database just won't pull in. Then when you're ready to break out the header and footer into the _layout template and hit the CMS, it's ready for you.

Unlike other CMS, for example WordPress, where it expects a theme to work in a certain way and live in a certain folder structure, Craft is a bit more flexible in this respect. (In WP land can change these defaults of course and use something like Timber but that's getting off track.)

We try to get a lot of the content roughed in as early as possible because it can dictate design decisions. A lot of designers work backwards and make content fit the layout. I find Craft fits our "content first" methodology a bit better.

We still produce static comps, get design approval and then build from those but a lot of people design in the browser because they find it faster and can show off a responsive design better. I'd argue Craft is no better or worse in this respect. I tend to switch from "design mode" to "programming" mode; when a design I created is set, then I figure out how to make it work, oftentimes incorporating the content we setup with the client at the same time. In this way, we are able to show the client a more "complete" website. At that point, we're just tweaking image and copy.

2

Interesting question. I think one answer depends on the speed of fidelity, ie that point at which you need to show something to a client AND how much fidelity they need ( ie in terms of completed visual design). I'm still finding the sweet spot and doing it both ways depending upon project time and budget.

I do think there is a lot of merit for building it in html/css within craft as it enables resources like js and sass, images etc to be more ready to go.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.