How do you identify fields for complex page layouts?

[Boost]

Hi,

I'm finding it tricky to identify fields to be used in a template for pages with a more complex layout. For example. Following this tutorial, https://mauricius.dev/basic-processwire-website-workflow-part-one/ is quite easy. But in a more 'real life' layout, it is not straightforward. How do you do that?

Cheers

[flydev]

Hello, the following is quite an opinionated use.

On complex layout, where the fields might also be re-used on differents templates, I tend to give as name to my fields `text1`, `text2`, `text3` ... and override the Label on template basis.

 

[gs-df]

You can use FieldsetPage to reuse fields on the same page on different sections
https://processwire.com/blog/posts/processwire-3.0.73-and-new-fieldset-types/#fieldset-page-fieldtypefieldsetpage

[aagd]

For very complex templates I (miss)use the Auto Template Stubs module, to manually copy/paste a list of all used fields to the template head comments, so if there are a lot of generic fieldnames (as flydev recommended above), I don't have to look them up all the time. The module creates the whole info in separate files, very easy to copy & paste. If you need fields inside a Repeater, they're also available in separate files. Looks something like this then:

/**
 * Template: contact (Contact)
 *
 * @property string $title Page Title
 * @property string $text_ml_01 Headline
 * @property string $textarea_ml_01 Body
 * @property Pageimages $images_01 Images
 * @property Pagefiles $files_ml_01 Files
 */

[gebeer]

12 hours ago, flydev said:

Hello, the following is quite an opinionated use.

On complex layout, where the fields might also be re-used on differents templates, I tend to give as name to my fields `text1`, `text2`, `text3` ... and override the Label on template basis.

 

I'm also reusing generic fields in my templates with renamed labels. Keeps the DB cleaner. I use custom page classes, a great feature that was introduced in 3.0.152 to map those generic field names to more meaningful properties. This way I get intellisense in my editor and don't have to look up the mappings of generic field names to meaningful ones. Here's an example page class:

<?php namespace ProcessWire;

use RockMigrations\MagicPage;

/**
 * Custom page class that provides properties/methods for pages with template glossary-item
 *
 *
 */

class GlossaryItemPage extends DefaultPage {
	use MagicPage;
	/**
	 * holds the glossary term
	 *
	 * @var string $term
	 */
	public $term;
    public $hide;
    public $exclude;
    public $tooltip;
    public $meaning;
    public $description;


	// set custom properties in loaded
    public function loaded()
    {
        $this->set('term', $this->title);
        $this->set('hide', $this->checkbox);
        $this->set('exclude', $this->checkbox2);
        $this->set('tooltip', $this->text);
        $this->set('meaning', $this->text2);
        $this->set('description', $this->rte);
    }

	/**
	 * Magic Page hook for clearing cache for terms from module Glossary
	 *
	 */
	public function onSaved() {
		$this->wire->cache->delete(Glossary::CACHE_NAME);
	}

}

The property->fieldname mapping happens in the loaded() method. you can comment the property definitions so you get some meaningful info with code intellisense.

In the template where I want to use pages with template glossary-item, I define the type for those pages to get intellisense:

/** @var GlossaryItemPage $p */
<?= $p->term ?>

Some notes on the page class code:

The GlossaryItemPage extends DefaultPage. My DefaultPage class is a base class for all other page classes which holds generic methods that I want to have available in all page classes

I'm using @bernhard's fabulous RockMigrations module which, apart from migrations, provides MagicPages. This makes it super easy to add commonly used hooks to your page classes.

I have a Glossary module installed which handles migrations and logic for the glossary. In the migrations for that module I define the custom field labels in the template context:

                'glossary-item' => [
                    'fields' => [
                        'title' => [
                            'label' => 'Name of the Term',
                        ],
                        'checkbox' => [
                            'label' => 'Hide',
                        ],
                        'checkbox2' => [
                            'label' => 'Exclude this term from parsing',
                        ],
                        'text' => [
                            'label' => 'Text Shown in the CSS Tooltip',
                        ],
                        'text2' => [
                            'label' => 'Meaning',
                        ],
                        'rte' => [
                            'label' => 'Description of the Term',
                        ]

All in all this is a very structured approach. It surely takes some extra time to setup. But this pays back, especially for larger, more complex projects. It took me quite some time as PW developer to come to this kind of setup. I started out with very simple procedural code. I wish I had all these tools available when I started out developing with PW that we have now (page classes, migrations etc.) thanks to this great community. Everyone here has their own approach and workflow. So you will surely get some inspiration.