Jump to content

Confused about Markup Regions - Best practice


Yipper
 Share

Recommended Posts

Hi everyone,

I just started using ProcessWire this weekend and try to get an overview over everything. I'm a bit confused about output strategies and markup regions, because I saw a lot of different approaches and couldn't really tell which the current recommended one is.

Somehow I ended up like this:

_main.php
<body class="">

        <!-- Header -->
        <?php include "_header.php"; ?>
        
        <!-- Navigation -->
        <?php include "_navigation.php"; ?>
        
        <!-- Main -->
        <main class="">
            <?= $content ?>
        </main>
        
        <!-- Footer -->
        <?php include "_footer.php"; ?>
</body>

 

_header.php - ..and on the other layout _*.php files, just using HTML inline php like this:
<header class="">
	<a href="<?= $home->url; ?>">
	</a>
</header

 

1-home.php for the home page template
2-about.php for an about page template - numbered for better overview - using $content .="" for markup regions
<?php
namespace ProcessWire;
$content .= "<h1 class=''>{$page->title}</h1>";
$content .= "<div class=''>{$page->introduction}</div>";

1. Can you please tell me if this is a good way (in late 2024) to structure templates?

2. A problem that I have with the $content .="" approach is that code highlighting and automatic code formatting doesn't really work in VS Code for me then (could be a setup problem).

Thanks in advance for tips and best practices

Link to comment
Share on other sites

I would recommend Markup Regions over storing markup in PHP-variables, because then you can work with actual markup and have good code highlighting and autocomplete.

Also, try using custom page classes for the business logic of your templates. This was a huge game changer.

And you could also use RockFrontend and LATTE - which I would recommend, because in my opinion it is better to use a "real" template engine and not PHP for writing markup.

  • Like 1
Link to comment
Share on other sites

@YipperI struggled on this topic in my first project too. I used delayed output strategy for the first prototype. Then I did a rewrite over a weekend with all the stuff I‘ve learned in the meantime and restructured code into Page Classes and switched from PHP templates for the view part to Latte template engine where it made sense.

Fun fact. To overwrite some template parts (e.g. navigation, footer) until guests logged into the frontend, I used Markup regions on the login page to overwrite the default template parts, which shouldn‘t be visible for guest or spam bots.

Lessons learned. It‘s more important to get started then overthinking which strategy to use. You will learn a lot and some of the available strategies may come handy later, once you know, how and where you can make use of it. 

Edited by cwsoft
  • Like 1
Link to comment
Share on other sites

At first I used regions, then markup regions, and I found that I wasn't happy about performances. I did some benchmarks and noticed that the time consumed to render the page was growing faster than the amount of data to render. For example, if I double the data, rendering may take 3x the time (just a random number, I don't remember values, but I think I saved them in a text file). That's why I switched to Twig, Twig is slower for small content but is robust with big content.

And I like how it's easy with Twig to write clean readable code, reuse twig fragments several times, import, extend, include, embed... there's a lot of choice, and no performance issue when including twigs into twigs.

For very small html snippets that I use everywhere in the site, and are closely related to a page/template, I also have a method on my custom page classes, that calls a "Renderer" instance associated with this page and print some HTML. I use it for example for the user cards that are displayed on almost all pages of the previous site I did:

<div>{{user.renderer('card')}}</div>

 

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...