I’m setting up a page which has a couple of entries to show from one channel and the rest of the content on the page comes from another channel. Since I haven’t (yet?) run into issues with the following setup, I’m not sure if it’s okay to do it this way, or sooner or later it is gonna cause problems:
{exp:channel:entries channel="main"}
this fills the page in with content
{exp:channel:entries channel="review"}
fills in a sections of the page with content from review channel
{/exp:channel:entries}
continues to fill in the page with content from main channel
{exp:channel:entries channel="review"}
fills in some sections of the page with content from review channel
{/exp:channel:entries}
fills in rest of the content from main channel
{/exp:channel:entries}
The idea behind this is to not repeat the tags so many times on the page that I get lost in it (and maybe miss a closing tag or two by mistake) as the page’s html is very long and complex. The other option is obvious - simply repeat the main tag around the section tags as many times as needed, but that can get messy on a very long page.
Is it okay to do it this way or it’s a big no-no?
Hi Rob, thanks for the suggestion.
Relationship fields won’t work in my case as I need to make the channel’s entry publish form as easy to fill in as possible (its for people who have no idea about how ee works, it’s a white label website where client’s gonna create pages on their own) - eg. for the “main” pages’ navigation I simply pull the entries from the same channel called “main”.
Fluid field might help but that’s pretty much just a cosmetic thing, am I right?
A Fluid field is for publishing using multiple “sub” fields that you assign. A fluid “sub” field can contain any type, Text, Radios/Checkboxes, RTE, File, Grid, Relationship and so on. When you publish to a Fluid field you use the available “sub” fields to build up page content in chunks, you can use each “sub” field as many times as you need and in whatever order is required.
https://docs.expressionengine.com/latest/fieldtypes/fluid.html
I think we are steering away from the original question, I appreciate the suggestions, but its a little bit of a different topic (grouping together fields). The page’s structure itself won’t change, only its content/topic - so one setup for the “main” page type is enough and no flexibility needed in the publish form in that regard.
My original version - one channel entry containing another channel seems to work just fine, am I gonna have issues with it later if I continue to use it this way? Since the ee docs doesn’t mention anything like this on the channel entries page (or any other part that I’ve read so far) I have no idea if its safe to use it this way, or I should not put one channel in another channel - the page content does not require it, its just easier to set up for the html.
Yes, I think it’s ok as long as you are closing each tag. Actually, you could get away with using just one closing tags (did that by mistake or had some missing in my first EE usages, and it still worked), EE seems to detect that sort of error at least with some things, but technically it’s wrong as you are not closing each one and the software could get confused with nested tags.
Performance wise it’s not the best approach and I would avoid that design, try not nesting channels if possible. But it will work, and you can use that approach until you can clean up things or reorganize content better in the future.
It is understandable that not everyone can move around entries or fields and have to use something like that if content structure was not organized before, or you are taking over a site which does not have a proper organized structure for content.
I found out that coding things is not the hard part in most software, platforms or websites but the design of how everything will play together in the future. I take a huge amount of time trying to design things first before actually going live because stuff like that come to bite you at some point. As Rob suggested, you might slowly plan to avoid this type of approaches by restructuring data.
As for confusing things in the code, try using tab spaces and comments. Having each closing or opening parameter below each other is confusing. Try using tabs spaces for nested content parameters tags. I also love to comment things like that with Start and End comments, since EE comments are not rendered to the user, it’s safe to use them as long as you are ok with having a blank space in the rendered code where the comment sits.
The reason to avoid this is that while it might work now fine with channel entries, maybe you want to use some add-on in the future or parameter that does not like nested channels. But at least channel entries are very flexible in what they allow inside, as most content in EE lives inside a channel entry anyway.
But don’t let this trick you. It’s more or less fine for channel entries as they are very robust and heavily tested, but other tags like comments and others don’t like this and will not work.
Thanks vw000!
The page structure won’t change, but theres no guarantee to that either (lets say I come up with a “pro” version later or something) so I guess it’s better to do it now than have headaches later.
I can add html comments to sections to make it easier to overview - thats gonna be removed with minifying anyways (as far as I remember).
I was referring to EE comments, not HTML comments. EE comments are only visible to you (developer or designer) just like other EE parameters, they are not rendered in the browser side.
As for content design, I mean website structure. This content should be in that channel, that content in that channel…
From what you posted, it seems you need to pull content from different channels but still need them visible in the same page. This means that content most likely should be in the same channel instead and not different channels like your example.
If you make an example of what you are trying to build, others here can suggest the best design approach on how content should be saved inside Expression Engine. And yes, you should take time to plan for this, it will save you a huge amount of time once you are building the templates since content will be better organized. Make notes, try to see how things will look in the end pages, then read the docs on all things you can use, even embed templates.
The nice thing about EE is that you can do the same stuff in many ways. There is not one way to do it, but many ways. Maybe something should be a channel entry, maybe something is better in a comment. Maybe something is better in one template, another in a hidden template used to embed…in another main template.
Just remember that you can put as many things into a channel entry as you want. That does not mean you have to use everything in that post every time. You can just use some stuff in one page, but everything else in another, while it’s still one single channel entry. I was very confused about this initially because most old tutorials from years back come from the concept EE being designed as a blog site, hence a channel entry is a blog post. But if you think of channels as different sections for content, and an entry as a placeholder for data, it makes more sense.
My best suggestion is just to start writing pages as static HTML as you would normally do with manually creating pages, then slowly start to take pieces apart and put them inside Expression Engine as required.
Not everything should be inside EE either. Example, you mentioned a main channel. Does that content change all the time? If not, there is no need to have it inside EE. Having content in channels makes only sense if you are letting others edit that content frequently, or you need to do some dynamic stuff with that. I don’t put things that rarely if never change inside a channel. I might just put them in a template and manually change the code if required.
This is the reason I purchased EE many years back. I did not want a system that forced me to put everything inside the CMS. I wanted to be able to create regular HTML files and only when required use the features of the system.
Yes, actually this is my fourth ee site so far, so I’ve learned a lot from past mistakes and lack of planning/understanding ee, this site is planned pretty smartly now (I think).
The website’s structure contains two kinds of pages that covers at least 90% of the whole website (+ the other 10% or so: about, terms, etc): - “Main” page - contains mostly text sections for seo and a list of (category filtered) reviews - “Review” page - which has all the information about the product itself
So yes, the content on the main pages comes from both channels. The tricky thing in the whole website is that it’s a white label product (rebrandable, resellable). This means it needs to be stupid easy to fill with content and to create new pages (both main and review) for someone who never used ee before - and they all will be non-developers, but content creators.
Main pages in this setup look like this: “main” channel entries are listed in the menu and footer, these pages are to be named with the pages add-on (for nice urls) and filled in with content, and for the review section on each main page theres a text field to set a category as a filter - which I already set up to pull content from the review entries with category urls. (this is required as categories also need to be flexible if the client wants to create their own categories and filter the reviews based on that category)
Review pages are not beautified with the pages add-on, just simply …domain.com/review/the-product so these can be generated by simply creating a new review entry, pretty straight forward.
I think this setup makes it pretty easy to create both review and main pages - which is really important for future clients to be able to build their websites on their own (with a short guide on how to do it), and the remaining pages like about us, terms and conditions etc. are gonna be single static pages (probably one channel each limited to 1 entry).
vw000 makes some great points.
Reading through what you’re trying to achieve what I’d do is set up a dummy site and test various approaches to see which ones are going to work best for you, that gives you a chance to test assumptions for what the site needs both now and in the future as the site expands.
You may already do this:)
So, I’ve tried the above (having tags for all parts of the page that is split in topic which is about 5 sections in the html) and I’m actually having performance issues now - my bet is on the amount of channel:entries tags appearing on each “main” page - I’ve set all of the tags to disable=”categories|pagination|member_data|category_fields|relationships” but it did not help too much, the page loading is pretty slow now, about 2-3 seconds (it was around 0.4 before adding all of the ee tags needed).
Any ideas on how to fix this?
I do listen to reason, so I started using relationship field for a few of the areas that made sense - it made the page a little faster, but I still have one thing to tackle which I can’t really wrap my head around: how do I create a menu from the main page entries without an extra channel:entries call (or actually 2 since its both in the header and the footer)? It was like this before, worked fine but now I need to get rid of it as it slows down the page:
{exp:channel:entries channel="main" orderby="order_on_page" sort="asc" dynamic="no" limit="8" disable=”categories|pagination|member_data|category_fields|relationships”}
<li><a href="http://{page_uri}">{title}</a></li>
{/exp:channel:entries}
The page I need this for is already wrapped in a “main” entries tag since the whole page’s content comes mostly from that channel (plus the additional relationship stuff and a fetch). This can’t be done with relationship tag as first of all it doesn’t feel too intuitive to force users to fill in the menu for each page - it should be automatic based on the entries of the main channel, and second of all relationship field ignores the page itself which it appears on, only the other entries are showing when I try to add menu items.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.