Search

I wonder how to use the new section link functionality. As far as I see, it only allows to generate entries based on already existing entries in the "related section".

Wouldn't it be better if I could create "empty values" for the relationship as well?

Let's take the image section in the default installation. I can not create image entries right away and define the relationship later. (At the moment, I can not even change the related article later, but I think this issue will be addressed soon.)

Think a bit further, about a "related articles" issue. I see no solution for that at the moment. Once I relate a section to itself, I can not even create new articles!

(I know you could simply define a dynamically filled select box for choosing related articles. But in this case this is no permanent relationship – there is no system ID stored, so renaming the article will destroy the relationship.)

So how do I solve the "related articles" issue in S2? Am I missing something here? Any ideas?

I haven't put too much thought on your question just yet - it's 2 am right now. However, I just want to quickly add this:

In Symphony 2, the section link is essentially a glorified text input. If you check a filtered section table, it basically has the "parent id" appended on the URL. With that filter value, when you create an article, that value gets put into the section link field (and to be extra nice, Symphony looks up the id and puts the title value in).

So given that, it's possible (but obviously not entirely user friendly) to simply have a text input that stores id number(s).

This doesn't really solve your problem, but I thought I would add this tidbit in and hopefully help people get a better grasp of Symphony's inner workings.

Let aside the "related articles" issue, I still wonder if the functionality for images I see in the default installation might be improved. Wouldn't it be good to create and upload images first, "linking" them later? This would mean an empty value for the link, of course. (I do not know if there might be database problems.)

Think a bit further, about a "related articles" issue. I see no solution for that at the moment. Once I relate a section to itself, I can not even create new articles!

Couldn't you just create a select box with multiple select option that is populated with the articles of the article section ("Dynamic Options")?

Yes, but this would never be a "permanent" link. Only title handle will be stored. If you change an article's title, the relationship is gone.

In Symphony 1.7 you could set the parameter allow_primary_field_handles_to_change to 1 in config.php, which was half a solution. Indeed title handles did not change anymore, but it was still possible to rename the titles, thus destroying the match between titles and their handles. In Symphony 2 even this option is not avaliable.

Section links in Symphony 2 are stored via IDs, an that's by far the best way to build relationships. So I hoped this feature would be more flexible than it is at the moment.

I'm in agreement with Michael here. Take, for example, a situation where I have a set of book reviews, which are stored in a "Reviews" Section, and a separate "Books" Section. The former is self-explanatory. The latter is a place where I can record more metadata about the book: its authors, editors, translators, edition, publisher, year of publication, ISBN number, etc. (This is drawn from an online magazine I'm in the process of developing and editing.)

First, I have a section link to Books in the Reviews Section. This is quite within the parameters of the section link as it is embodied in Symphony 2 Beta. A Book "object" should be associated with a Review "entry" via a section link, because this association is meant to be permanent. (See Michael's post above, number five, for more details on the lack of permanency in the select options.) But here is where the system starts to break down. After being associated with a particular review, the same Book "object" cannot be associated with another review. I could finesse my way past this problem by making the Book "object" the parent, and the Review being section linked to it, which would allow me to have multiple reviews of the same book. However, this would to a degree prevent me--at least based on my understanding of the current limits of the section link--from having a single review that covered two or more books, as would be the case if we were comparing and contrasting different viewpoints on the same subject matter by reviewing two books on the same subject, e.g. Freakonomics and The Logic of Life.

I could partially finesse it again by using a separate section for each, with a select options field in Reviews to establish a quasi relationship, but that wouldn't work very well because there would be no permanent database level link between the two items. If I changed any titles, it would no longer link to it. Whereas, a permanent link to an ID in the database (which would not change, I gather), would keep its relationship no matter what happened.

Another area where I might want to create a permanent association/relationship would be in the case of authors of a book. Let's just say we have 2 books, Winterlong and Waking the Moon, both by the same author, Elizabeth Hand. They're in the "Books" Section. I have another Section, "Authors". The problem is that when I create an author entry "Elizabeth Hand", I have to use a select option field populated with the entries from Author, which shares the same problem as Michael describes, and which I also noted in my 3rd paragraph. Otherwise, I end up creating multiple "Elizabeth Hand"s in the database, when in reality there's just one author. (I want a separate section for authors because I'm using it to store further metadata, date of birth, publication history, aliases, etc. Not to mention, I have a mind that someday it may be interesting/nice to generate views that rely primarily on the author: e.g. a page with the biographical data of the author and a list of books written by the author, in chronological order, etc.) It's vexing.

I can name further examples: a Movie "object" with section links to actors, actresses, writers, directors, producers, etc.

The way I see it, the problem lies in the fact that there are multiple ways that these sections link to one another: a movie has many actors, actresses, may have many writers, producers, etc. An actor has many movies. A writer has many movies.

I just want to go on record as saying that I think this is a very important issue and one for which I hope that a solution is found. It's all about the relationships.

Oh how I long for the simplicity of Rails' :has_many and :belongs_to (and :has_and_belongs_to_many)...

Here's a quick tutorial on DS Parameter Output, which might shed some light on this discussion:

Firstly, imagine that the Section Link field does not exist in 2.0. Erase it from your memory.

The concept behind param output is piping of data from one DS to another. The canonical example is getting all comments related to a single entry: Say we have an entry_permalink DS which takes its handle from a URL parameter and outputs a value that our comments DS is filtered by. This value could be the entry's title, ID, or any other field value of the entry so long as each associated comment contains a matching value to be filtered by.

(Of course, param output can be used in lots of other ways too, like categories, related entries, all comments on the lastest 5 entries, or entries from two different sections sharing a common tag/select box value. Each of these differ in performance/efficiency, but that's a tutorial for another time.)

Now to construct an efficient relation between our "Entries" and "Comments" sections, each comment needs a text input (or tag list for many-to-many) field into which we must write the ID of its associated entry. This is fine from the front-end where this field is added automatically by the XSLT, but from the admin it requires that I firstly discover then copy/paste the ID of the related entry in order to successfully create a comment. To make this easier, we could use the title of the entry instead since it would be easier to remember, but using strings rather than IDs does not make for efficient DS queries. A select box populated by the Entries>Title field would be much easier to use, but only if the number of entries is small.

So the problem is really about the workflow, not the concept or capabilities of Symphony. We added the Section Link field (not to be confused with its 1.7 namesake) to make it somewhat easier to create relations by ID, but clearly the present solution is awkward. Originally we'd planned to allow nestable subsections (using, unsurprisingly, the Subsection JS module from sections/DSs), but due to technical reasons with error handling and the field API's abstraction/encapsulation this turned out not to be possible. We do have one other solution brewing, which I think will be a huge improvement to the workflow, but you'll have to wait a couple of weeks while we get it done.

Thank you very much for the light. Now I see that it is just a matter of having the right user interface. Once we have this (and I am sure you will bring up a great, "Symphony-like" solution), param output/handling will be a killer feature.

So are you guys saying that the current problem associated with entries that could have multiple section links is temporary? Is the interface to make this more intuitive simply not yet complete? I posted a question about this issue in another thread hoping somebody would be able to clear it up for me, but after reading this thread, it appears I may not be as clueless as I thought I was.

Thanks for the clarification, Scott. Glad this is on the team's radar, and glad to hear you've got a solution in the works. I'm sure like everything else you guys do it'll be dynamite.

@insidertravels, I replied to your question on your original thread. I'm a bit sleepy now, so I hope my explanation made sense, but if not I'll give it another shot when I'm more alert.

Is the interface to make this more intuitive simply not yet complete?

Due to how abstract the current implementation is, the task of coming up with a convenient interface for this which works for all the different ways it might be used is actually quite tricky. Usually convenience and versatility are at opposite ends of the scale, but I have a feeling the combined minds of the Symphony team and anyone else interested can come up with something.

Is this why I dont get this to work? That I'm not using DS Parameter Output to link my DS's?

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