Closed dmoyagoal closed 5 years ago
Alright, there are a couple of different issues going on here, so I'll address them one at a time.
The taxonomies plugin doesn't add any special data to any pages, so to actually access that data you need to get it from somewhere other than directly on the page
object. That "somewhere else" is by using the find()
function, which is a standard mechanism for looking stuff up from Orchid's internal index. This function works from anywhere, and the behavior will always be the same regardless of which page is being rendered or which template it is called from.
A lookup from the find()
function (and the other internal linking functions) use the same 3 parameters to find what you're looking for:
itemId
- typically the "title" of a page, but is ultimately determined by whatever created the collection. In the case of Taxonomies, the itemId
is a "term" key. In many cases, this is the only parameter that's required.collectionType
- generally the key for the plugin that created the collection. This is what's logged during the build. For example, for Indexing [100: taxonomies]
, taxonomies
is the collectionType, and using this will restrict the lookup to that plugin, to be sure the right thing is returned (and also improve performance).collectionId
- This is rarely needed, but can be used to differentiate between the same thing matched in multiple collections. For example, if you have the same "term" value in more than one taxonomy, this can help you make sure you get the right page from one taxonomy and not the other.Now, in the snippet I added to the other issue, it includes itemId=page.collections|first
in the find()
function. That page.collections
is nothing magical, it's just a property defined in the page's Front Matter. Anything you put in a page's Front Matter, or that is pulled in from an Archetype, can be accessed just like that. For setting up your taxonomies, you should have use page.tags
, page.productos
, page.documentos
, or page.idioma
instead of page.collections
, to match what you've set up in taxonomies.yml
.
Another thing to note is that the Taxonomy collections being empty in the admin panel is currently an open issue (#212). So you won't see anything in the admin panel for it currently, but they will get matched in the template.
Currently, there is nothing like Hugo's UglyURLs
parameter in Orchid, but if you specify the page title in it's Front Matter, that will be left alone. I can work on adding that feature, but my recommendation is to manually add the page titles to your Front Matter, or to rename the files to so that Orchid will infer them correctly by using just dashes or camelCase in your filenames, but not both.
For the names being mangled, Orchid tries it best to turn the filename into something readable, but in the end it is pretty naive: it will first split on dashes, underscores, and by camelCase in the filename, and then capitalize each resulting piece. In particular, the camelCase splitting is done by the Apache Commons-lang3 library's StringUtils.splitByCharacterTypeCamelCase()
method, and the split you're seeing is the intended functionality of that function. The javadoc for that method shows that ASFRules
will split to ASF Rules
, and similarly it will keep Rm
together as a capitalized word rather than the GR
.
Generally-speaking, it is poor practice to use both dashes and camelcase in your filenames. Most filesystems and webservers are case insensitive, and you might get unexpected 404s and other strange issues when relying on letter case in your filenames (I've definitely run into issues of this sort on GitHub Pages before). It's also better for SEO to use just dashes and all lowercase, as search engines (and Orchid!) are better able to infer the individual words in the filename.
Hopefully that all makes sense!
Thanks again, that helped a lot. My understanding on how objects are populated with values was severely lacking. I'll take into account your advice on naming as well.
I post here my solution for other people who find a similar problem. Finally I assigned the taxonomies as archetypes for each page collection as above (it works adding them at the page front matter too), and included the following at the headers.peb template. It controls for the availability of terms for each taxonomy, and loops over taxonomies that accept several values.
<ul>
{%- if page.productos is not empty -%}
<li>
Producto:
{% for prod in page.productos %} {{ anchor(prod) -}} {% endfor %}
</li>
{%- endif -%}
{%- if page.idioma is not empty -%}
<li>
Idioma: {{ anchor(page.idioma[0]) -}}
</li>
{%- endif -%}
{%- if page.documentos is not empty -%}
<li>
Documento: {{ anchor(page.documentos[0]) -}}
</li>
{%- endif -%}
</ul>
I have a problem with taxonomies not being available from pages, I don't know whether it's a bug or just a function not supported. I've tried using the snippet for templates that you posted at Issue 50, but it wouldn't work: ( https://github.com/JavaEden/Orchid/issues/50 )
Unfortunately, the code you provided doesn't render anything, and the 'for' loop isn't executed, not even once. I have created the following taxonomies at
taxonomies.yml
, and the templates using them behave as if they are empty:The admin page shows that these taxonomies are created, and they are visible at the "manage" dialog under Collections, but they have size 0. However, the Taxonomy base page shows all the pages that I have included through an archetype in the config.yml configuration shown below; they just aren't included as variables in the templates. These are the values I have assigned to my collections at config.yml:
Besides, I have problems with the automatic treatment of names for pages and collections; the product names are variations of CamelCase, and they get mangled by being separated at wrong places (for example GRm is a product name composed of the particles "GR" and "m", but it becomes "G" and "Rm"). Is there some parameter to disable this conversion and have all names unchanged, like the 'UglyURLs' parameter in Hugo?
Thanks for your support!