{"id":5452,"date":"2026-04-21T00:00:52","date_gmt":"2026-04-20T16:00:52","guid":{"rendered":"https:\/\/www.6ebook.com\/?p=5452"},"modified":"2026-04-22T01:11:02","modified_gmt":"2026-04-21T17:11:02","slug":"kadence-theme-building-tutorial","status":"publish","type":"post","link":"https:\/\/www.6ebook.com\/en\/kadence-theme-building-tutorial\/","title":{"rendered":"Kadence Theme Building Tutorial: Complete Solution from Gutenberg to Product Templates, Custom Article Type Pages and Mega Menu"},"content":{"rendered":"

If you've been using Elementor to build WordPress websites for a long time, and you switch to Kadence Theme + Gutenberg<\/strong> for the first time, you'll probably have a very strong feeling of discrepancy: the pages are fine, but when you come across \u201cstructured content\u201d such as article archives, WooCommerce product details, product category pages, Mega Menu, breadcrumb navigation, and mobile filtering, you'll realize that Kadence is not the same as Elementor at all. Category pages, brand pages, Mega Menu, breadcrumb navigation, mobile filtering and other \"structured content\", you will find that Kadence's thinking is not the same as Elementor's. The current boundaries of Kadence's official capabilities are also very clear: the theme structure relies more on Hooked Elements<\/strong>, and WooCommerce's deeper templates rely on Kadence Shop Kit's Product Templates (Woo Templates)<\/strong>, rather than the same set of visualizations as Elementor. template logic as Elementor does, rather than wrapping all pages in the same set of visualizations.<\/p>\n\n\n\n

This article is not a general introduction to Kadence, but a complete review based on a recent real trade showroom project we did. The client's requirements were very clear:The whole site try to use WordPress native Gutenberg editor, do not use Elementor, the requirements of lighter, more stable, more conducive to SEO, and post maintenance costs should be low.<\/strong> It is also because of this project that we went through the key issues of Kadence theme order page, article system, product templates, brand page, Mega Menu, breadcrumbs, Off Canvas Sidebar for mobile and so on. The final conclusion was straightforward:Kadence is perfectly capable of making complex websites, but only if you accept that it's a native WordPress logic of \u201ctheme global structure + block content + dynamic templates\u201d and not a stand-in for Elementor.<\/strong><\/p>\n\n\n\n

Why Kadence was chosen for this project instead of continuing to use Elementor<\/h2>\n\n\n\n

The project ended up with Kadence, not because Kadence is fancier than Elementor, but because the client wanted something that wasn't \u201cfancier\u201d but lighter, more structured, and more maintainable over time<\/strong>. Theme itself is responsible for the global structure and theme layer capabilities, Kadence Blocks are used to enhance the Gutenberg layout, Hooked Elements are used to take over the one-page, archive, and content insertion positions, and WooCommerce product page, archive, and product card templates are taken care of by WooCommerce Templates, which are part of the Kadence Shop Kit. Templates of Kadence Shop Kit. In other words, Kadence's system division of labor is more clear than Elementor, which is suitable for foreign trade sites, enterprise sites, product display sites and other sites that emphasize more on structure and maintainability.<\/p>\n\n\n\n

From the perspective of project execution, this choice has been proved to be right later on. It's true that the page editing experience is not as \u201cWYSIWYG\u201d as Elementor, but the structure of the site will be cleaner: single pages will be handled in Pages, articles will be archived in Archive, product templates will be in Woo Templates, and custom content types will be in CPT + Dynamic Content. In other words, Kadence<\/strong> is better suited to building a site as a \u201ccontent system\u201d than as a bunch of drag-and-drop visual pages. <\/strong><\/p>\n\n\n\n

Kadence build the most important thinking switch: pages, templates, dynamic content to be handled hierarchically<\/h2>\n\n\n\n

After moving from Elementor to Kadence, the first thing we had to do was not to learn a certain functionality, but to change our way of thinking. In Elementor, we used to do things in the same way: homepage, article templates, product pages, archive pages, almost all of them can be taken over by Theme Builder. But in Kadence, this way of thinking will hit a wall very quickly. Because Kadence's best practices are actually layered:Regular pages go to regular pages, articles go to the article system, WooCommerce goes to WooCommerce, and custom content types go to CPT.<\/strong><\/p>\n\n\n\n

To take the simplest example: home page, about us, contact us, services page, FAQ, these pages are still essentially \u201cstandalone content\u201d, and the most standard approach is to build the pages directly in Pages<\/strong>, and then build the content with Gutenberg \/ Kadence Blocks. Kadence Blocks. They don't need to be forced into a templating system for the sake of \u201ctemplating\u201d, because a templating system is better suited to managing a \u201cuniform structure of similar content\u201d rather than the individual content of each separate page. Kadence's official documentation on Hooked Elements and Template Elements essentially emphasizes that templates are better suited for reusable structures and that content should remain in the content itself.<\/p>\n\n\n\n

What to do with regular pages: Single pages under Kadence should still be in Pages.<\/h2>\n\n\n\n

The home page, about us, contact us, and several service pages in this project were all ultimately done directly in Pages<\/strong> using the Gutenberg editor. Why is this the most stable way to do it? Because these pages are more like \u201ccontent containers\u201d and don't rely on archival queries, single-article loops, or dynamic fields for products. What you really need to control: content widths, header hierarchies, image blocks, button styles, graphic layout, responsive layouts - Kadence Blocks is designed to solve these problems.<\/p>\n\n\n\n

In the process of implementation, the way we actually use is: first unify the whole station's color, font size, button style, Section spacing and content width, and then build Hero, Selling Points Area, Product Recommendation Area, FAQ, CTA and other modules in the page. The biggest benefit of doing this is that common pages are always simple, and when customers want to change copy, change images, or add blocks, they don't need to understand complex template inheritance relationships. <\/strong> This is one of the most important principles that we've learned since switching from Elementor to Kadence: don't think about templates when you can solve a problem directly on the content page.<\/p>\n\n\n\n

How to build an article system: the correct relationship between News pages, category pages and Post Archive.<\/h2>\n\n\n\n

The post system is another key part of this project. A lot of users who are doing blogging for the first time under Kadence get confused: is the News<\/strong> portal a regular page, an article page, or a category page? <\/strong> What we ended up doing was to create a normal page called News<\/strong>, and then go to Settings \u2192 Reading<\/strong> and designate it as a Posts Page<\/strong>. itself recognizes posts pages through the page_for_posts<\/code> option, which is the most standard way to get blog entries.<\/p>\n\n\n\n

In this way, \u201cNews\u201d becomes the entry point for blog listings, while \u201cIndustry News\u201d and \u201cCompany News\u201d continue to exist as categorized archive pages<\/strong>. <\/strong>. In other words, these three types of pages essentially belong to the article archive system<\/strong>. Kadence's article archive templates and Archive Content substitution logic are naturally suited to handle this kind of structure: a main blog page, plus multiple category pages, share the same archive system, just in the title, description, breadcrumb, and query results.<\/p>\n\n\n\n

Here's an important detail to remember: Posts Page is not the same as a normal page. <\/strong> Once News is set up as a posts page, it's more like a \u201cblog container page\u201d, where the main content displayed on the frontend is the list of posts, not the body of the text you're filling out in that page editor. A lot of WordPress developer documentation and community experience has also emphasized over and over again that a Posts Page is more like a container than a normal standalone content page.<\/p>\n\n\n\n

Why the breadcrumbs on the article category page often don't automatically bring up the \u201cNews\u201d layer?<\/h2>\n\n\n\n

There is a typical phenomenon in this project: Brand single page breadcrumbs can be displayed as Home \/ Brands \/ brand01<\/strong> when has_archive<\/code> is turned on, but the article category page is often displayed as Home \/ Industry News<\/strong> instead. <\/strong>, but the article category page tends to only show up as Home \/ News \/ Industry News<\/strong>, instead of automatically becoming Home \/ News \/ Industry News<\/strong>. It's not that Kadence is wrong, it's that WordPress's hierarchical perception of the CPT archive and Posts Page is not a set of logic<\/strong>. The CPT's has_archive<\/code> is part of the native structure, while the Posts Page is just the blog's CPT's has_archive<\/code> is part of the native structure, and Posts Page is just a blog entry, it's not a natural parent for all category archives.<\/p>\n\n\n\n

So, if you see the breadcrumb missing the \u201cNews\u201d layer in the article category page, it's normal, and Kadence officially supports switching the breadcrumb engine to other engines such as Yoast, Rank Math, SEOPress, etc. This is also because different engines don't handle the blog layer in the same way. Kadence officially supports switching breadcrumb engine to other engines such as Yoast, Rank Math, SEOPress, etc. This is also because different engines don't have the same way to deal with blog layers. For blogs, if you are very concerned about Home \/ News \/ Category Name<\/strong>, it is usually more stable to switch to a SEO breadcrumb engine that is more suitable for customizing the hierarchy, or manually fill in the links in the archive template than to continue to rely on the built-in breadcrumbs of Kadence.<\/p>\n\n\n\n

WooCommerce Product Detail Pages: Don't Hardwire Plain Elements Anymore!<\/h2>\n\n\n\n

This was one of the most critical cognitive shifts of the entire project. At first we tried building templates in Kadence Elements and then taking over WooCommerce single product pages with Replace Single Post Content<\/strong>, which looked a lot like the Elementor days of \u201capplying a template\u201d, but it quickly became clear that this was the wrong way to go. This seemed to be similar to the Elementor-era \"apply a template\" approach, but it quickly became clear that this was not the right way to go. Here's why: WooCommerce single product pages are not just article content pages, they have their own complete product template structure. <\/strong> Kadence officials have now made this very clear - WooCommerce related templates should go Kadence Shop Kit's Product Templates (Woo Templates)< <\/strong> instead of replacing the product page content area with a regular Template Element.<\/p>\n\n\n\n

In the end, we adopted the right program:<\/p>\n\n\n\n