TaxonomyArchiveGenerator doesn't pass taxonomy siblings list

[carbontwelve]

Using a Taxonomy archive page with the following frontmatter:

---
title: Category Archive
use:
    - blog_categories
generator:
    - TaxonomyArchiveGenerator
    - PaginationGenerator
pagination:
    provider: blog_categories
    perPage: 3
---

You would expect to be able to see a list of taxonomy siblings passed through to the view being able to be displayed via $blog_categories with the current pages items being displayed via $blog_categories_items. This is a side effect of me attempting to keep the use system simple.

A workable fix should be by adding a Taxonomy view helper class that gets attached the view containing all the taxonomy siblings and the items requested for the current page.

[carbontwelve]

There is a Taxonomy class already built for use by the ContentType class. It doesn't get passed to the view, instead on line 51 of ParseContentTypes the response of its public getFileList() method gets assigned to the File data array with the key following the template {taxonomy_name}_items.

Additionally within TaxonomyArchiveGenerator on line 29, the quick fix introduced by 069755f6890f505c08b9a85284499f1518942b5e passes in the result of array_keys passed over the Files {taxonomy_name}_items data entry.

There are two routes that could be gone down:

1. Re-purpose the Taxonomy class, currently it needs it's constructor tidying up as there are a few lines of dead code, then have it function in a similar way to ViewFile in that it has a getFile method for plucking a linked File from the projects compiled items list. This has the down side of converting a class originally intended for the back-end layer, as a class that works both on the back-end and in the front-end.

2. Create a new TaxonomyItems class that gets populated with the getFileList() method from Taxonomy (or possibly is the return type of that method); this class will contain helper methods for use in View templates in a similar fashion to ViewFile.

[carbontwelve]

I have added the following todo items:

• line 85 of ContentType
• line 51 of ParseContentTypes

[carbontwelve]

This needs a unit test writing.

[carbontwelve]

So, as of f218c6df7352c424080df61131ca7f4e6a11cfc1 there is a unit test checking the TaxonomyArchiveGenerator class functionality.

On pages generated by TaxonomyArchiveGenerator their data with key {content_type}_{taxonomy_name}_items will be set to an array containing the output of Taxonomy->getFileList() one new page is generated each by TaxonomyArchiveGenerator for each classification; this eventually gets converted into ViewFile[] by the Compile class.

This meant that up until 069755f6890f505c08b9a85284499f1518942b5e pages that where generated by TaxonomyArchiveGenerator where unaware of their sibling taxonomies and did not have their {content_type}_{taxonomy_name} set to anything. 069755f6890f505c08b9a85284499f1518942b5e fixed that by setting it to an array of the relevant content types classifications for the given taxonomy.

On a regular page that uses {content_type}_{taxonomy_name} (e.g. index.phtml in build_test_23); {content_type}_{taxonomy_name} will be set to the output of Taxonomy->getFileList(); this eventually gets converted into ViewFile[] by the Compile class.

This means that for example index.phtml will have {content_type}_{taxonomy_name}_items that contains the entire output of Taxonomy->getFileList() where as each page generated by TaxonomyArchiveGenerator is the sub array for each classification and as such is unaware of sibling classifications.

View helpers such as $this->getTaxonomy() when accessed from either index.phtml in the above example or within a page generated by TaxonomyArchiveGenerator should return the same thing - this is the crux of this issue - what should it return?

[carbontwelve]

The view helpers $this->getTaxonomy() and $this->getTaxonomyItems() which are yet to be written should return a class that acts upon the content of the page data {content_type}_{taxonomy_name}_items.

On a page generated by TaxonomyArchiveGenerator; $this->getTaxonomyItems() should return the wrapper class TaxonomyItems which get constructed with the pages {content_type}_{taxonomy_name}_items data. Whereas $this->getTaxonomy() will look up the pages content_type and return a ViewTaxonomy object that gets constructed with the content types taxonomies.

On a regular page e.g the above index.phtml example, $this->getTaxonomyItems() should still return the wrapper class TaxonomyItems; $this->getTaxonomy() will also behave in the same way as displayed on a page generated by TaxonomyArchiveGenerator.

The issue with regular pages is that {content_type}_{taxonomy_name}_items contains all classifications for a taxonomy in an array, where as TaxonomyArchiveGenerator generates one page for each classification. e.g:

index.phtml.blog_categories_items : ['misc' => array[...], 'other' => array[...], ...] generated.phtml.blog_categories_items : array[...] one each for array keys above.

Generated pages also contain data with key taxonomyName which $this->getTaxonomyItems() will use; if that variable is not available then it will need to be passed in as an optional argument, e.g. on index.phtml you will need to call $this->getTaxonomyItems('misc') where as the generated page for the misc classification will only need to call $this->getTaxonomyItems().

[carbontwelve]

Having reflected upon this, I now do not think that TaxonomyArchiveGenerator should attach any helper class containing the pages taxonomy and that this issue was actually fixed by 069755f6890f505c08b9a85284499f1518942b5e.

There should be a $this->getTaxonomyItems() helper for use on pages within content types that have taxonomy configured (e.g. the default blog content type) However the addition of that functionality should be its own issue.