HTML Logo by World Wide Web Consortium ( Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS. ocPortal 9 is superseded by Composr 10.

Head over to for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.

Creating Hierarchical Catalogs

Login / Search

 [ Join | More ]
 Add topic 
#76261 (In Topic #15736)


Can you use a data field to create the hierarchy?

The documentation at shows the quick way to create a hierarchy. I am assuming the slow way is to manually set up the relationships–either by adding at the right place or by moving entries.

My question is whether you can automatically select where something fits (that is, the right level, by a field within the catalog entry). For example, if the catalog was for "places" and each entry contained state, city and location plus a field for type which would identify if the entry was a state, city, park, business, or "other"), could that type field be used to assure that a park, business or other was at the third level (under first state and then city)?

The alternative would be to just enter all the data without a hierarchy but set up the search/display such that type was used. I am looking at "the ocportal way".

As an aside but clearly related, geeks tend to program around misunderstandings. A prime example is how Drupal (at least through version 6) has evolved. Thousands of modules. Many duplicate others and the functionality of many others could have been implemented using what already exists. (For any Drupal geeks out there, the Views module is a prefect example of something that can do what at least 100 other modules have been written to do.)

My questions are certainly coming from an ocportal novice. My hope is that others have these same sorts of questions and that by asking now, there will be a lot less programming around misunderstandings here.
Back to the top

Basically you either would be doing something very exact, writing some very specific schema and interfaces - in which case you'd write a new module and encode rules as PHP.

Or, you'd be mapping your own concepts onto ocPortal concepts. Sounds like some of your entity types could be categories, and some could be entries. The fact an entry has to be in a category kind of adds the constraint you want, especially as you can remove submit permission from some categories.

Places > California > Los Angeles > Pizza Express

Places being the root category. California and Los Angeles being categories (probably California has submit permission not enabled). Pizza Express being an entry.

In the next version there'll be the ability to add custom fields to categories, not just entries, which will help. Currently that's shared across all catalogues, it'd be kind of nice to be able to have different catalogues having their own custom fields for their categories, but that's not an option yet.

Become a fan of Composr on Facebook or add me as a friend. Add me on on Twitter. Support me on Patreon
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about Composr whenever you see the opportunity or support me on Patreon.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying Composr on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
There are too many online users to list.
Control functions:

Quick reply   Contract

Your name:
Your message: