Which setup of the modules-plugin is the field assuming is in use?

[digiltd]

I am struggling a little with setting up modules correctly, could someone document how the modules-plugin should be setup in order for the field and plugin to work together.

The readme at https://github.com/getkirby-plugins/modules-plugin talks about two methods of setting up.

Option 1

site/blueprints/default.yml

title: Default
pages:
  template:
    - module.text
    - module.gallery

Option 2

site/blueprints/default.yml

title: Default
pages:
  template: default
  build:
    - title: _modules
      uid: modules
      template: modules
...

site/blueprints/modules.yml

title: Modules
pages:
  template:
    - module.text
    - module.gallery

Does it make a difference which I use or is there one option I should be using in order for the field to work correctly?

In the readme for this field when you mention the blueprint, is that to go in the blueprints created in either of the options?

For example do I put them in the default blueprint..

site/blueprints/default.yml

title: Default
pages:
  template: default
  build:
    - title: _modules
      uid: modules
      template: modules
fields:
  modules:
    label: Modules
    type: modules

I am fairly competent with Kirby and the general use of blueprints, snippets, fields, templates and controllers. But I am finding the concept of these modules hard to implement and would appreciate a little more information if possible.

At the moment without the field when I create a new page it then creates a folder "_modules" and then I open that folder, and then add another "page" choose the template and then fill in the content.

The above workflow does seems a little complicated, but I can just about get my head around it and what is actually happening. But the idea of a "page within a page within a page" is not something I would want or expect a client to have to deal with.

Hopefully someone can explain a little on how these modules should be used. Thanks

[lukaskleinschmidt]

You can actually use both approaches. The field will check weather you used option 1 or option 2. Personally i like the second approach more because it is a cleaner in the content folder. Especially when you have subpages on top of the modules.

The field should always be initiated in the blueprint of the page.

Option 1

site/blueprints/default.yml

title: Default
pages:
  template:
    - module.text
    - module.gallery
fields:
  title:
    label: Title
    type: text
  modules:
    label: Modules
    type: modules

Option 2

site/blueprints/default.yml

title: Default
pages:
  template: default
  build:
    - title: _modules
      uid: modules
      template: modules
fields:
  title:
    label: Title
    type: text
  modules:
    label: Modules
    type: modules

When you use option 2 i would recommend adding the modules field to the site/blueprints/modules.yml as well. This is because the subpage that contains the actual modules is accessible in the panel. You could also use Gloabal Field Definitions so you don't have to duplicate the field.

site/blueprints/modules.yml

title: Modules
pages:
  template:
    - module.text
    - module.gallery
fields:
  title:
    label: Title
    type: text
  modules:
    label: Modules
    type: modules

A different approach could be to hide the panel breadcrumb with a custom panel.css. Something like that.

.breadcrumb-link[title="_modules"] {
  display: none;
}

At the moment without the field when I create a new page it then creates a folder "_modules" and then I open that folder, and then add another "page" choose the template and then fill in the content.

The above workflow does seems a little complicated, but I can just about get my head around it and what is actually happening. But the idea of a "page within a page within a page" is not something I would want or expect a client to have to deal with.

That is the main reason why i created this field so the client is able to manage modules on the page where they actually appear.

Hope i was able to answer some of your questions. Please let me know when i missed something.

[seehat]

You could also hide the _modules subpage in the panel sidebar-list:

.sidebar-list a[data-helper="_modules"] {
  display: none;
}

[lukaskleinschmidt]

Thats correct. Also i would recommend using the hide option for that.

title: Modules
pages:
  template:
    - module.text
    - module.gallery
hide: true
fields:
  title:
    label: Title
    type: text
  modules:
    label: Modules
    type: modules

I think there should be some kind of demo or example configuration. I try to put something together.

[seehat]

This is a much better approach. I forgot, that _modules is a page, which can be hidden. Perfect, thx!

[digiltd]

Thanks, some great advice.

@lukaskleinschmidt Can I suggest an change to the first line "This field was built to extend Kirby Modules Plugin by providing a more user friendly interface to the plugin." as "built on top of" suggests it might be a forked version or was inspired by.

Thanks again.

[lukaskleinschmidt]

Will do that.

[medienbaecker]

I recently noticed that the subpage builder does not build the modules container when changing the template of a page instead of creating a new one.

So when using the approach mentioned by @lukaskleinschmidt you should also add the following hook to your config.php:

kirby()->hook('panel.page.update', function($page) {
  if ($page->template() == "default" AND !$page->children()->has('modules')) {
    $page->children()->create('modules', 'modules', array(
        'title' => '_modules'
    ));
  }
  elseif($page->children()->find("modules")) {
    $page->children()->find("modules")->delete(true);
  }
});

This creates the modules page automatically when the page uses the default template and gets updated. This also triggers when the template is changed. When the page uses another template, the modules page gets deleted.

You'll have to change the template name(s) according to your setup.