but then I would still need {{pagecontent}} in my template, and does that mean id also have to have the page_module too?
Is that how the page module works? or does everyone set up with a template for each layout?
the reason is I add my modules as sections, and that section span the full width of the display. This is so I can easily design that section, but I would rather the client if needed, be able to add modules to the page rather than the template.
Hi @luke
I’m not sure I fully understand the method you described - and it does sound a bit different to how I do things… but the bottom line is; you do you.
There really isn’t a right or wrong approach if it works for you and you understand it.
That’s the beauty of Treepl. It’s flexible, so there are multiple ways of doing things depending on what works best for the project and/or for you and your clients.
The main concept I consider when setting up the CMS structure is what I’d call ‘Abstraction’. So, grouping or segmenting things that; belong at a higher level, need to repeat/be used again, are unique/one-offs, should be kept away from the client, should be accessible to the client, things that can be controlled by logic, etc…
Also, looking at how the Treepl templates are structured should give you an idea of a fairly typical approach and how that might compare to your own.
Are these for the module only? {% component type: “module”, source: “Page”, layout: “Page Detail” %}
As the {{ pageContent }} tag cannot have different layouts?
Also, I did check out treepls new Coffee template for bootstrap.
It is a landing page setup as custom modules.
This goes back to a point I’ve made before about custom modules should be on all plans. Why limit anyone to the pre-made modules?
As a non-member(double-costs) If I was to use this template for a client here in Australia, they would be paying $60AUD mth then I’ve also gotta make money on top of that, for a landing page is pretty steep.
Ah, ok.
So “Pages” and “Folders” are essentially just modules like any other - but they are nested modules. Like the ‘Galleries & Sliders’ module and ‘Blog’ module.
So there is a parent module (“Folders”) and a child module (“Pages”).
Both modules have their own ‘Layouts’ and in this case, the “Folders” module just needs a ‘detail’ layout in order to render either content saved against the folder item OR, if no content, the contents of a child page (you can adjust the logic here to show the desired child page - or anything else for that matter).
But you could add a ‘List Layout’ for “Folders” as well and list out folders if you wanted to.
Likewise, “Pages” generally only need a ‘Detail layout’ since we tend only to resolve to the page item itself and not list them out - but you can list them also if needed - which is exactly what the ‘Site Search List’ layout is.
Regarding the landing page template; I agree, using Custom Modules probably wouldn’t be cost-effective in most cases. But I’d also argue that you shouldn’t need Custom Modules for a landing page - utilising the built-in modules, or simply hard-coding the content should be sufficient.
If it’s more of a ‘single-page site’ than a landing page that requires more control of more content then the extra cost is warranted.
Why Custom Modules aren’t available in all plans - economics. Treepl needs to make money and Custom Modules are an advanced and powerful feature. Most SAAS models introduce their premium features in higher plans.
And in comparison to BC, where WebApps were ONLY available in the top tier plan, Treepl has provided greater access across their plans.
However, looking more closely at all the built-in modules, and other features, and how they work. You’ll be surprised at how far you can push them to do other things if needed, without having access to Custom Modules.
Going back on this @Adam.Wilson do you tend to create a lot of content templates for each and every page or do you create more pages than content templates and put your modules on the actual page?
In most cases, I try to only have 1 Content Template (to avoid repeating code), and instead, try to use logic (via Liquid) to render the code/modules/etc. for certain pages.
For example; let’s say you have a handful of Member pages that require a different template/layout, and they are in a Folder called ‘members’. Instead of having another template for those pages, I’d have Liquid conditions checking if the URL contains /members/ then render member layout code, else render regular page code.
Doing it this way does it slow down the site at all? Arent you taking away the workload off the server and placing it on the page load, tell me if that’s a silly question?
Also was this one of the videos Tim and yourself went through in one of the treeouse meetings?
No, that’s a good question. But I don’t think it really has a performance hit as Treepl is built for processing Liquid for most things anyway.
But I’m also not doing anything too extreme with this. Usually just simple IF statements.
If the template needed to be significantly different for something then I’d probably opt to use a separate Content Template. But in most cases, there are only small differences needed and the core components (header, footer, styles, scripts…) all remain the same.
I don’t believe we’ve discussed this particular topic during Treehouse, but we can certainly bring it up in the next one.
This was the meeting I was talking about Treehouse Online Meetings | Treepl CMS Partner Community and after watching it again it’s actually what I was trying to explain on creating a template for each page. Then having so many templates and keeping it tidy
Is that Meeting #29 you are referring to (Multi-lingual Sites)?
But yes, there are multiple ways to do things, and any particular way is not right or wrong. Whatever works for you and the client/project at the time.
My advice would be to try different things and experiment. See what works best for you.
My mindset is to use logic to automatically do as much as possible, rather than rely on a user to select the right ‘thing’ or add the right module in the right way, as this usually leads to errors and frustrations. I just want clients to manage content, not the site structure/design/layout, etc.
@luke, do you have a specific goal or requirement you are trying to achieve? That may help others offer more detailed info and/or code. @TimL might be able to offer some further insight into how his custom module setup is going.
I can give you further insite in my concept if you like, @luke. The bottom line for me is: how is the site structured and how does the client want to maintain their site. I give you an example: you have a standard page layout with a header, page title, main content, sidebar and footer. Sidebar can hold different elements depending on the page’s purpose.
Version #1: The client doesn’t want to touch the site so you could use the system page module and set up some content templates with different items in the sidebar, maybe different types of page title layouts and maybe even different footers. You apply changes to page layouts by choosing the right content template for the page or create a new template if needed.
Version #2: The client absolutely wants to maintain their site. You would not want to let them do this by dealing with a lot of content templates. So you create an advanced custom module for pages and folders to replace the system one. This way admins can use custom properties to control the content of the sidebar, style of the page title etc. And you can set it up self explanatory using the tool tips for help texts. I did this to the extend that clients can control the opacity and color of the filter on their banner images ;-).
Of course you can also choose #2 if you maintain the site for your client just to make it easier for yourself …
Thanks for all that info @TimL and @Adam.Wilson
The client doesn’t really jump on the portal much it was more for me and learning best way to structure layouts as I was creating a lot of content templates (basiclly one every page). I did think of placeing my section blocks and modules in the page but that wouldnt be a clean way to do things I dont think.
Didn’t really think I needed to create modules for pages etc but maybe ill give your setup a try after this site is finished.
Not sure if this is a good idea or not but what if the content templates had a module area {{moduleContent}} like the {{pageContent}} area on the templates?
Then when you create a page there is a code area to place modules and includes etc. That will display only for that page and only where you place the {{moduleContent}} on the template.
This will minimise creating templates for every difference of the pages.
