3

My mental model of the content for the website I am developing with Bolt is, that there are "sub pages":

  • each page(the content type) is related to one "sub page"
  • each "sub page" has its own menu and can use its own template
  • the url for a page should look like /{sub_page_slug}/{page_slug}

In the docs I found the section about Taxonomies and it sounds to me like the "grouping" taxonomy is what I want.

So I added the following to my taxonomy.yml:

pagegroups:
    slug: pagegroups
    singular_slug: pagegroup
    behaves_like: grouping
    options: { main, work, others }

this with the correct addition in the contenttype.yml lets me assign a page to a "sub page" aka pagegroup. (To be able to have additional information for a page group, I also have a "pagegroup" content type, where the slug mathes the entry in taxonomy.yml.)

To allow routes like /others/stefan and /work/currently I added the following to routing.yml:

work_page_binding:
    path: '/work/{slug}'
    defaults: { _controller: 'Bolt\Controllers\Frontend::record', 'contenttypeslug': 'page' }
    contenttype: pages

others_page_binding:
    path: '/others/{slug}'
    defaults: { _controller: 'Bolt\Controllers\Frontend::record', 'contenttypeslug': 'page' }
    contenttype: pages

But to make it work with the templates and menus, all pages in a page group have to use the correct template, so the correct menu gets displayed.

I imagine there must be a more dynamic way for the routing:

pagegroups_page_binding:
    path: '/{pagegroup}/{slug}'
    defaults: { [???] }
    contenttype: pages
    restrictions:
        pagegroup: [???]

that has the following advantages:

  • it would check the list of configured page groups, so the only thing to add is the entry in taxonomy.yml, instead of new routings for every page group (of course configuring the pagegroup content element entry and the menu for it still has to happen)
  • in the template the correct pagegroup content element is set, so that I could simply write menu(pagegroup.slug) instead of duplicating templates for each page group

Can somebody suggest how to get started with it?
I'm happy to write a custom Controller if that is the best way. If it is, where should I put it?

I can imagine this use case is not that rare and it would be great to put this into an extension, but I'm not sure how to get started with it, and if the extra level of abstraction is going to get in my way of how to resolve the actual problem.

One important thing is also: I want to be able to update bolt, so I dont want to modify existing classes...

It feels like asking more then one question, feel free to answer to whatever part you have an idea.

karfau
  • 638
  • 4
  • 17

1 Answers1

1

At the moment this is trickier to do than it should be, the good news is that thanks to a big refactor of the controllers the next version of Bolt will be much more flexible and simpler to extend.

To get it working now, you can make a static method that returns a pipe separated string of the content groups, here's a quick example:

First in routing.yml:

contentgrouppage:
    path: '/{contentgroup}/{slug}'
    defaults:
        _controller: 'controller.frontend:record'
        contenttypeslug: page
        contentgroup: '<put your default value here>'
    requirements:
        contentgroup: 'My\Routing::getTaxonomyGroups'
    contenttype: page

As you can see we ask a class My\Routing and a method getTaxonomyGroups to return a list of allowed values, this method looks like this:

    use Bolt\Configuration\ResourceManager;

    /**
    * 
    */
    class Routing
    {

        public function getTaxonomyGroups()
        {
            $app = ResourceManager::getApp();
            $groups = $app['config']->get('taxonomy/categories');

            $urls = [];
            foreach ($groups['options'] as $slug => $name) {
                $urls[] = $slug;
            }


            return implode('|',$urls);
        }
    }

As you can see, the static hack to get the current app object isn't ideal, and will be deprecated next version, but it's a problem that those routing requirements currently have to be static methods, whereas next version you'll be able to specify a service eg: controller.requirements

Ross Riley
  • 826
  • 5
  • 8