I'm posting this in the beta forum because I'm working from version 2.

My initial impression was that sectionlink was a way to avoid repeating information, such as categories (or images) that would be used in more than one section. For instance, if I made a section called journal that allowed the author to select applicable categories/images to go with each individual entry. The problem with making a custom field in the journal section itself is that first, I'll have to re-enter the custom field data for each section, even if the categories are identical, and second, clients (who have only author permissions) won't be able to add their own categories at will using the Publish tab.

But when I tried to add a sectionlink to the Categories section from the Journals section, it didn't work the way I anticipated. The create new button disappeared, which now leads me to believe that sectionlink is for display purposes only. Is this a bug, or is it really supposed to do this? Or am I understanding this feature incorrectly? I hope I've explained myself well enough.

To add entries to a section that has a section link to another section, you must go to the table overview of entries for that section and click on the hyperlink under the appropriate column heading.

Section links are illustrated with the articles section in the default template. Both comments and images each have a section link that links them to the articles section.

Section links work a little differently in 2. The reason images are implemented with a section link in the default template is so that an article can have an undefined/undetermined amount of images. It's not predefined in the articles section how many images can be uploaded. That's the beauty of it.

The downside is that images must be uploaded after the initial creation of an entry. You could put a file upload field in the articles section, but you would not be able to associate metadata (i.e. other fields) with that image.

So, the create new button disappears because each entry in a section that is linked to another section must be linked to an entry in the section linked to.

OK, I did a small test and figured out what you're talking about. But does that mean that an entry can't have more than one category?

To me, the most intuitive way to do a section link is to have a select list of all available categories on the create entry page for the section.

So, if I want to make sure an author doesn't get confused, should I hide all sections from the Publish menu except the ones that are section links?

Section Links as people know from Symphony 1.7 still exists in version 2. It is however repurposed.

I think that this change is a positive move towards ease of understanding for new users, unfortunately veteran Symphonians may require some adjustment.

Here is an example to achieve the result of the old section link link way:


I want to create two sections: Articles and Categories and I want Categories to be section linked to Articles just like version 1.7.


  1. Create your categories section with all your relevant fields.
  2. Create your Articles section with all your relevant fields and:
  3. Create a select box, multi-select box or a tag list and populate the values dynamically from the Categories section.

Section Link Differences

The term Section links, although called the same in v1.7, is an entirely new concept. Some may argue that the term isn't appropriate given the use in v1.7, but I would argue that Section Links in v2 is what it ought to be.

The way section relationships work in v1.7 is really just, "please populate this field with the values of another section".

Over the course of the beta period, we will endeavour to provide explanations and tutorials to help developers get a grasp of Symphony 2.

1.7 section links are essentially just field links. I agree too that section links in 2 is an appropriate name.

Field links, that's a good way to look at it.

Today, while squeezing my mind searching for clues as to the tags list, I was thinking of some possible improvements for the datasource editor.

I created a section called "Keywords" with two custom fields: the value of the keyword and a section link which points to "Articles". This way I can associate one or more keywords with one or more articles, that is what I was looking for. Then, I built a datasource based upon "Keywords" grouping results by the values of each keyword and including just the XML element related to the section link.

Thus, In the "Included elements" box I've got three rows: pagination, keyword and article. However, article is a false custom field since it just links togheter two sections, nothing more. What I need on my site is to show all the published articles as lists grouped under each tag. For instance:

foo (3):
    * Foobar
    * Barfoo
    * Barbaz

baz (1):
    * Barbaz

bar (3):
    * Foobar
    * Barfoo
    * Barbaz

At the moment I have to create a datasource with a list of all the articles published on my site and then gear XSLT in order to let these results match with the handle attribute of the XML-equivalent of article, but it looks a little hardcoded.

So, woudn't be better if, in the datasource editor, were also listed -as nested entries- the custom fields of the section linked by article? E.G.:

Included Elements

It would make things easier, even if I guess it takes a little to achieve that kind of thing without stumbling on some undesired loops.

Hoping to be still in topic (also not looking completely insane :P).

However, article is a false custom field since it just links togheter two sections, nothing more.

You could output the article IDs as a parameter output and filter your articles based on the list of IDs.

Could you be clearer? I mean, my XML tree looks just like this:

    <section id="13" handle="keywords">Keywords</section>
    <tag handle="gasp" value="Gasp">
        <entry id="135">
            <article section-id="6" section-handle="articles" link-id="110" link-handle="an-example-draft-article" />
        <entry id="133">
            <article section-id="6" section-handle="articles" link-id="109" link-handle="a-primer-to-symphony-2s-default-theme" />

I was wondering how could be included also one or more custom fields (E.G. title) from each of the linked articles in order to get a XML structure as the one below:

    <section id="13" handle="keywords">Keywords</section>
    <tag handle="gasp" value="Gasp">
        <entry id="135">
            <article section-id="6" section-handle="articles" link-id="110" link-handle="an-example-draft-article">
                 <title>An example draft article</title>
                 <!-- Anything else? -->
        <entry id="133">
            <article section-id="6" section-handle="articles" link-id="109" link-handle="a-primer-to-symphony-2s-default-theme">
                 <title>A primer to Symphony 2's default theme</title>
                 <!-- Anything else? -->

At the moment the DS editor seems to be unable to perform such a task. Am I wrong?

You won't be able to have it nested like what you want, but you can still obtain the relevant information based on the linked ids (via param output). However, in XSLT you can draw the relationships between 2 elements by a common key value using the xsl:key instruction.

Does that help?

Yes, it does. It seems like I was trying to make my life harder. :D

Thank you for the advices. :)

So, I have to make sure I'm using the correct section as the parent in order for section links to work as intended? That I understand, I think.

For example, the section I want to link to multiple entries from multiple sections is the one I have to link to from within the custom fields of all the other relevant sections? So this would be things like categories, keywords, tags, images, etc. In other words, the pieces of data that are to be repeated?

I'm sorry I'm having such a time with this, for some reason, I keep thinking that I can only link an entry to a single Category and it's tripping me up. It almost seems backwards to me. I realize it's me, not Symphony, that's the problem.

OK, is the following scenario correct?

  • Let's say I create a section called Entries that will be where authors input the bulk of their content.
  • Then, I create another section called Tags that will organize the entries.
  • Next, I add a section link to Tags from within Entries.
  • So now, authors cannot use Entries from the Publish tab, right, so they have to create go through Tags instead.
  • The author wants to create an entry with a Tag of photography but also wants that same entry to have a Tag of photoshop.

This is where I get confused. The problem is that now the entry has already been created in photography. And when you look at the input screen for that entry, the Section Link doesn't show a select menu at all. It just lists the applicable Tag. OK, so we go back to the Tags screen again. We click on photoshop to see what happens. It takes us directly to a new Untitled entry input screen. So, if we want to add an entry with a Tag of photoshop, we have to create a new entry instead of linking this Tag to the already existing entry that also has the Tag of photography. So how does a regular author (not a developer) achieve this? Dynamically generating drop-down menus isn't going to work for an end user. I can barely wrap my own head around it at this point.

By the same token, what if there's another section called Image that is also linked to Entries in the same way. We want to allow authors to link any number of images to a single Entry without trouble. Here we run into two problems.

  1. The same problem as with the Tags issue above.
  2. The fact that we have to create new Entries from the Tags screen or the Images screen, but once an entry is created in one place, how do we then attach that same entry in the other place as well?

Does my dilemma make any sense? Am I missing something? Is a really important piece of this puzzle flying over my head? I'm sorry I'm having so much trouble with this.

Don't blame yourself for the confusion; there are many huge conceptual differences between 1.7 and 2. All will become clear when documentation is available.

Head to Blueprints > Components > Data Sources and take a look at the "Articles" and "Comments" DSs. Pay particular attention to the "Parameter Output" section on Articles and how Comments is using that parameter ($ds-articles) as a filter.

If the Comments section didn't use a section link field but instead contained a text input field with the same label, everything would work exactly the same. Section link fields are used here because it's a pain to have to enter the ID of the related article each time you create a comment. Section links are simply a convenience (or shortcut) for what otherwise could be done with a little more effort.

Select boxes are usually a good choice for entry->category association, such as the Categories multi-select field in the Article section. Combined with param output, any field type can be used to link data across different sections or within the same section, with many-to-many or one-to-many relationship, in any direction. All that's required for this technique to work is that the two associated entries share some common data.

For now section link fields are rather confusing and difficult to get used to, and they will be revised or replaced (hopefully at least renamed) in a future beta build.

Thanks to everyone for the help. Your explanations really helped me figure out where I was going wrong.

I just did another test with a clean install of revision 3.

I think I was trying to use Section Link backwards. I was thinking I needed to place all of my section link custom fields in Articles. I now see that it's the repeated sections that should have Section Link custom fields in them. What I was trying to do was just the opposite. That's why nothing was working out for me, and it appeared I could only add a single entry from a single Section Link section. I hope this makes sense.

I was looking for the Section Link lists (drop-down menus, or whatever) to appear on the entry input screen for the main section to which they were linked. It didn't even occur to me to look for any other way to do it. I think that may have been my problem.

I now see that when I go to the blueprints for the Images section, it allows me to choose multiple items from the Related Section field. That's what I was missing before. It wasn't working the way I was doing it because I was trying to link Images to Articles from within the Articles section instead of within the Images section.

I have some other related questions, but I want to do some more testing before I ask something silly.

Great. I think I've just confused myself again.

I'm having trouble discerning the difference between when I should be using Section Link and when I should be using a dynamic Select Box.

Regarding the way each custom field type records data and links entries/sections, is there a definitive example of when I would choose one over the other?

For example, why not add a custom field to Articles as a Select Box with Dynamic Options instead of using a Section Link to Images? Does this method record only the chosen dynamic field and not record the actual record id# for the entry (which would allow displaying other data from the entry in addition to the single field chosen in Dynamic Options)?

I think I remember somebody posting about this before, but I think I must have been tired because I glossed over it without giving it much thought. I'll have to go back and re-read all of the responses to my posts. Don't mind me, I'm just thinking out loud. Hopefully, the official documentation will be released soon.

Once I solidify the logistics of this particular issue I'm having with linking sections together, I think I'll pretty much have everything under control.

I'm having trouble discerning the difference between when I should be using Section Link and when I should be using a dynamic Select Box.

Use a select box when the number of possible things you're linking to is fixed and small (like categories). If you used a select box instead of a section link for Comments->Articles, it would be problematic to find the right article amongst a list of 100+. That's pretty much the only reason that section link fields exist.

OK. That helps. So, in other words, there's really no difference in the way the data is recorded/linked. It's just a difference in the method of input in the interface.

So I'm assuming, then, that there will be a way to convert from one to the other. So, if I have a Select Box that I anticipated would only have a maximum of 25 entries, but it actually ended up growing much larger, then I would be able to somehow change the Select Box into a Section Link without having to start all over again with the data entry?

I know you said fixed, but no matter how much I think a certain list is fixed, it somehow always evolves.

Unfortunately you won't be able to convert between field types. Section Links record their relationship data as IDs (like a foreign key in database speak) and dynamic fields record their data as literal values (i.e. Peanut, Apple).

OK, so I'll keep that in mind when designing site structure, using Section Link for anything that needs to remain explicitly linked.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details