Symphony.

Does anybody know what happened to the Subsection Field extension? On Github I find this:

Description: Depreciated. A real sub section field for Symphony.

“Depreciated” (sic!) doesn’t sound good to me.

Are there any alternatives around?

Maybe Bi-Link Field?

The Bi-Link field may be similar from a technical point of view, But if you think about usability, it’s rather different. I’d like to build an “author’s interface” – “hey, let’s quickly add some pictures to this article!” That’s what the subsection idea is about – making it easy for authors.

I’d love to have a solution that works like the Subsection Field extension: You can simply add (new) images to an article without leaving the article’s publish page.

We should care for this. This is essential to Symphony. We can’t tell people that we have the most flexible system all around and then give up on this issue…

So I’d love to know why the Subsection Field extension is deprecated. What’s the problem with it? Could someone take this over?

The next release of the Bilink field addresses those usability concerns michael-e, unfortunately it hinges on the next release of Symphony.

I am unsure about why the Subsection Field has been deprecated, but it has been for nearly as long as I’ve worked with Symphony shrug

I can’t answer questions about the Subsection Field, but I think Nils talked at some point about abstracting Mediathek a bit further to work with all kinds of sections (not just attachment-based ones). That workflow would be similar for authors.

But this raises a broader issue that michael-e hints at: Symphony needs more robust relationship management among sections (something I’ve been hoping to help scope out but haven’t had time). Currently, fields that handle relationship-building include not only the logic of the relationship but also the workflow, the UI, the data-handling, the output, and so on. What worries me is the thought that, over time, we’ll end up with a whole slew of separate relationship fields that have slightly different approaches to each of these bits.

I think we need solution to relationship-management that isn’t so tightly coupled to specific field types. And I think we have to go beyond basic parent/child relationships to things like “has,” “has many,” “belongs to,” “belongs to many,” “has and belongs to many,” and so on. Special extensions could even provide additional relationship types as necessary, like “extends” for example. I’d love to see a really elegant solution to handle all this, but haven’t given it enough thought to have a formal proposal yet.

Maybe that’s something we can discuss for a future version of Symphony?

I can’t answer questions about the Subsection Field, but I think Nils talked at some point about abstracting Mediathek a bit further to work with all kinds of sections (not just attachment-based ones).

Mediathek 2 has been abstracted this way. So you can use it to link sections even if you don’t have a single upload field.

The subsection is depreciated mainly because I found some rather bad bugs with it, it has also been so long since I found them that I cannot remember what they where.

Time and bugs means it’s no good.

Thanks, buzzomatic. No good news to me.

(The Mediathek is an admirable extension, but it does not offer the simple “per-article” approach that the Subsection Field did.)

So at the moment we have alternatives, but no replacement.

I think we have to go beyond basic parent/child relationships to things like “has,” “has many,” “belongs to,” “belongs to many,” “has and belongs to many,” and so on

Hell yes.

Hi michael-e,

Did you find a true alternative to de subsection field? This extension will be the perfect solution to perform a translation solution in a multilingual site.

Submit a master entry in default language, and after enter the translations in different languages in the same page.

If do you have a good alternative please let me know.

Thanks.

@guillem_l: No, I am afraid that still there is no replacement for this extension. I was thinking about picking it up, but I was afraid of some “dangerous” behaviour. bozzomatic talked about “rather bad bugs”…

This is definitely something the core team should think about. While for developers section links may seem easy to work with, the workflow feels rather wonky to authors.

@guillem_l: That said, I wouldn’t see this as a perfect solution for multilingual content. You might be lost in relationships… I’d think about building it rather “natively”, perhaps using the Duplicate Entry extension.

@michael-e: Thanks for your advice, I will take it in consideration, but I don’t like the idea of has duplicated entries in different languages without a relationship. There’s no way to know if the entry has a translation or not, and could be messy for an author deal with duplicated entries in a news section for example.