Search

Discontinuing Support for Subsection Manager

We know that Subsection Manager is an essential tool for many Symphony users. Nevertheless, as of today we are discontinuing support for Subsection Manager on Symphony 2.3. Subsection Manager 3.0 Beta will still be available in its current state but it will neither receive any updates nor will it be released as a final version.

Let me explain why.

Subsection Manager started as a small side project under its first name Mediathek purely to handle small image galleries. It has since been growing into a very complex relationship management tool. Still, the interface was conceived for small amounts of images and files and fails miserably on large data sets.

There exist different approaches for relationship management in Symphony extensions. They are all quite similar (while looking at relationships from different angles) and are all working around the same flaws of the Symphony core (UI, Data Source output, caching). We have been talking about this during the first two Symposiums in 2010 and 2011. In Cologne we compared the different approaches and concluded that it won't be that hard to merge them and create a unified concept bundled with the core.

Still, nothing has happened ever since.

Johanna and I are working as designers. We are no programmers, PHP or MySQL developers. But this is exactly what's needed to create a reliable and scalable relationship management with interchangeable user interfaces. We hope that the deprecation of Subsection Manager will join forces in the community and help focussing on a unified solution.

How to move on?

If you are using Subsection Manager 3.0 Beta on Symphony 2.3, continue doing so. Everything that is working right now will still work tomorrow.

If you are a developer have a look at this:

Recently, John (@designermonkey) has started to work on a concept for a unified core relationship management:

All it needs is a bit of man power and programming skills. Please join the discussions, please help fixing relationships in Symphony and please let's finally bring it into the core.

Wow, this is sad to hear. I'm very new to Symphony and when looking into a new CMS solution a number of things are always on your mind such as the core features providing the ability to do what you'll likely need it to do, along with extensions which add essential functionality you'll likely need on a day-to-day basis. Subsection Manager was soon identified as one of those fairly pivotal extensions. I also had slight doubts about the longevity of available extensions in maintenance and support and have noticed that many aren't ready updated to be compatible with the latest versions of Symphony. Losing such a pivotal one such as Subsection Manager not only deals a hammer blow to asset relationships but also makes me concerned about what others may suddenly go by the wayside whilst I'm depending on them for live sites.

I can completely understand with Nils in that it's an extension which has grown beyond it's intended scope and extension developers put in a lot of voluntary time to develop and maintain extensions and I sympathise with Nils in that after a lot of talk there doesn't seem to have been a lot of action as a result. I first heard came across Symphony when meeting @bauhaus at @media conf in London 2010 en route to the Symposium the next day. I was intrigued by Symphony and started playing around with it along with keeping in touch with what was discussed at the Symposium that year. At the time the combination between the extra learning curve and feature-set required didn't quite suit my needs for client work but the plans sounded awesome! A kept checking back and a year or two later it doesn't seem that a lot has happened in that time, especially when compared to other CMS's and in light of new ones coming out of the woodwork. I don't mean this to sound like harsh criticism because I love the philosophy of Symphony, it's approach to handling content, it's flexibility, and it's community. I'm just concerned that maybe there needs to be more of a fixed roadmap or someone taking control at the helm to really drive things forward?

I've been using Laravel this past year and the speed of development has been immense. Taylor Ortwell is a one man wrecking machine. Laravel 4 is on the verge of being launched it's taking off into hyperspace—it really is quite impressive and setting the standard. The documentation is second to none, key contributors have been assigned to core team members who have written extensions, books, and produced screencasts incredibly quickly. I'm not comparing Laravel to Symphony as they're completely different products but operating on the same model in it being open source relying on volunteering efforts for both growth and support. Laravel seems to have more structure with Taylor at the helm as the visionary and the core team members doing a fantastic job—also all voluntary and in their spare time—to promote, and enhance Laravel which is growing at an immense rate. Taylor is essentially sponsored by UserScape in a similar role to that of Soario now. I guess I'm just wandering what the difference is and how this can be improved? As Nils suggests, extension developers are limited by the core and if that doesn't move then it becomes an uphill struggle.

I see such similarities between the two communities and the same potential in both but sad news such as this makes me nervous in placing full trust in it for the long term. I'm just not sure where things are heading. It seems that it really needs someone to take the bull by the horns and drive things forward to build momentum.

I don't mean any of this to sound overly critical because I have a lot of respect for Symphony and the work that people have put into it but I'm just posing some questions. I'm new to Symphony and still in need of a lot of guidance myself but I'd love to have the confidence to make the jump and use it more or less exclusively for client work and get to the point where I can contribute. It's just the confidence that is lacking and these announcements don't go to help that.

What Nils has done is the right move. It's certainly unnerving knowing that an extension of such importance will not see continued improvement. However, our reliance of the extension is exactly why there has been very slow movement of tackling the section relationship problem in the core.

Section relationship is a core problem and we also know how we can solve the problem. Nils' decision to draw the line will force the team to pull this problem up the priority list instead of continuously pushing this down the list as we have done for the past couple of years.

As mentioned, the subsection will continue to work, and the discontinuation does not mean the extension is disappearing right now. Hopefully it will be enough to tide us over until we have proper support for section relationships in the core.

and have noticed that many aren't ready updated to be compatible with the latest versions of Symphony.

This is not true at all, we have a vast number of extensions that are updated for the latest version of Symphony. symphonyextensions.com is tracking 272 extensions, the vast majority of which are 2.3 compatible.

A kept checking back and a year or two later it doesn't seem that a lot has happened in that time, especially when compared to other CMS's and in light of new ones coming out of the woodwork.

Symphony 2.3 was the biggest milestone release that I'm aware of (at least since I started using it in early 2010) and I'm a bit miffed that you've dismissed all of the developer hours that went into this release as 'not a lot happened'.

I'm just concerned that maybe there needs to be more of a fixed roadmap or someone taking control at the helm to really drive things forward?

Myself and Brendan have been trying to iron out a roadmap for development for the foreseeable future (about 6 months ahead), but this isn't always easily available for the wider community to see, and I agree that there needs to be more visibility here. Someone is going to be working on the core full time next year, and this will mean that development will be more active from then on.

As Nils suggests, extension developers are limited by the core and if that doesn't move then it becomes an uphill struggle.

The core is under active development, albeit slow, and it is moving forward. Without developer time though, the speed will remain consistent as it is, so having a full time developer on this next year will improve things. This developer will be sponsored by Soario.

but sad news such as this makes me nervous in placing full trust in it for the long term.

I don't understand why you feel this way. I see this deprecation as a step forward for Symphony. As Nils has stated, relationships in the core is a must, and keeping the SSM in active development only hinders this requirement, as people will always choose this over developing the core.

It seems that it really needs someone to take the bull by the horns and drive things forward to build momentum.

I completely agree here, which is why I, Brendan, and other community members, have tried to keep momentum going on the issue tracker. Sadly, like most others, commitments, full time employment, family etc etc take priority.

Just finally, Symphony is a small community, granted. This has a two-fold effect; One that development will be slow, as a small community has less time available in active development hours. Two, that the support available within the community is awesome. Awesome. I have never come across a community so active and helpful as the like minded developers here. I would class some of these people as friends, more so than some of the people I know in real life (sad I know ;o) ).

While things like Laravel are great, and it's great to see they have documented thoroughly, they are still young, and have a lot of buzz at present. Symphony has been around for a while and is still moving forward. The only downside is the lack of documentation, which I know we are also working on fixing. Once the Symphony Factory is completed, we will be starting to populate more sites with content related to Symphony, so, patience is a virtue here.

I hope I've answered some of your questions, and alleviated some concerns? If you have any suggestions about how to proceed, we are always listening. :o)

Well good things can come from bad news I guess and I'm sure Symphony will rise to fill the demand in some capacity. Hopefully that happens sooner rather than later as it could leave quite a void in between.

On a sidenote, what's the best way to keep up to date with the issues highlighted, the working focus of the team, the latest updates, roadmap, and future plans for Symphony? It can be useful to see more of a timeline for a bigger picture and if Nils has a clear picture of what's planned and when it's planned for then maybe he'll be happy to provide support to fill the gap in the meantime? It can help to keep everyone working towards defined goals.

Nils' decision to draw the line will force the team to pull this problem up the priority list instead of continuously pushing this down the list as we have done for the past couple of years.

Thanks for mentioning that Allen, I know that this is the prime reason for this deprecation.

I'm not sure if you had time to go through the Documents @designermonkey had prepared prior to Nils actually saying that the extension is getting deprecated. Also this does not mean that Subsection manager will not be updated - other community members might provide 'updates' to keep compatibility until one is able to migrate the links into the symphony core.

@designermonkey Thanks for alleviating the concerns. I mean no disrespect or offence. Regarding extensions on the whole, yes, I've noticed that the popular extensions do seem to be keeping pace. It's slightly confusing that there's an extension section on this site and on the syphonyextensions.com site too which can show differing information and be a little confusing though. I've come across a few which have looked to be potentially very useful but were either abandoned or never left experimentation phase which is a shame.

Regarding the Symphony releases, again I meant no offence and haven't been around long enough to know how significant each release has been so I apologise. I was referring more from the outside in and looking at it more from an individual viewpoint relating to noticeable features. Obviously as highlighted above and on several recent threads the core being so lean it's very important to optimise and improve the underlying code which is something which isn't so visible on the surface but takes significant work none-the-less.

Myself and Brendan have been trying to iron out a roadmap for development for the foreseeable future (about 6 months ahead), but this isn't always easily available for the wider community to see

That's great. From the recent discussions on various threads and from the Symposium there clearly seems to be ideas but it could be useful to see these plotted somewhere for the community at large to see—and possibly help with. Otherwise, as highlighted in this thread things get overlooked and developers can lose hope with providing support as the issues aren't being dealt with.

The core is under active development, albeit slow, and it is moving forward. Without developer time though, the speed will remain consistent as it is, so having a full time developer on this next year will improve things. This developer will be sponsored by Soario.

This sounds very promising. It was actually the email from Soario that peaked my interest again and finally motivated me to jump right in and use Symphony for a commercial project. This will no doubt be a positive move. So is Brendan going to be the full-time developer?

I don't understand why you feel this way. I see this deprecation as a step forward for Symphony.

Indeed, and I'm sure it will invoke a positive reaction. I guess I was just a little nervous because I've hesitated making a bit jump across for a while and now I've started ploughing in the hours this past couple of weeks in learning and experimenting as well as speccing out 3 projects to run on Symphony. I'm just going whole hog because that's the best way to learn it just makes you a little edgy. :) It was just a combination of various recent threads where there are testing issues highlighted, needs for rebuilds of the core, database connectivity to rewrite now serious issues highlighted with relationships, and support for a top extension being dropped. (Note: I know it's not all doom and gloom, I'm just summarising for brevity and explaining the compound effect when already a little edgy. I wouldn't be her now if it was that bad :) ).

the support available within the community is awesome. Awesome. I have never come across a community so active and helpful as the like minded developers here.

Totally. And this is a massive plus. I'll certainly be needing the help and advice of the community along the way and can hopefully pay back in kind once I start getting more proficient.

As for going forward it would be great to see some kind of roadmap along with issues and priorities. Maybe also some organised way of allowing the users and community to vote on issues and features they would like to see using something such as UserVoice? That way you could get a clearer picture of what's important to both developers (associated with the core) and end users (from a client perspective) and be sure not to overlook any areas in need of attention?

Thanks for the info, much appreciated.

As @gunglien pointed out: We have been preparing a lot of stuff in the background. We have been talking about things via mail, chat or in person. When I'm saying "Nothing has happened!" I mean: nothing has been implemented yet. Deprecating Subsection Manager will force us to actually do this.

I pointed out that I'm not a PHP or MySQL developer: this is where SSM struggles the most. If the core handled the actual connections between entries, fields or extensions would only have to deal with the UI. Complex extensions like this one could be split up into multiple single task interfaces which would simplify the maintenance a lot. Furthermore, UIs would be interchangeable so the user could switch the mode how relationships are displayed while developing a site.

Johanna and I will be actively working on the UI part.

As for going forward it would be great to see some kind of roadmap along with issues and priorities.

Agreed.

Smart move. And I like the proposal by @designermonkey on how the relationships should be managed going forward.

Would something like a subsection-manager-field-to-core-link-field-converter be feasible then?

Subsection Manager stores relationships similar to Select Box Link so this shouldn't be a problem to port the relationships. I'm not sure about sort orders: this depends on how something like this will be implemented in the core.

Ok thanks, sounds promising enough :)

How does the subsection manager sort its entries under 'browse', they seem completely arbitrary to me? Any way to change what it sorts them by?

It should be alphabetically.

Any way to change what it sorts them by?

That certainly depends on the version you are using.

By the way: please keep in mind that this extension is deprecated.

Hi Nils,

Sure I appreciate that it's deprecated now, but as the site was built years ago there was no way to see into the future to avoid using it :) I'm not asking for an update, just some help.

Currently it's not sorting alphabetically, any kind of sorting would be great, but as I say, it's arbitrary. Anything that you know of that could cause this? Sounds like it could be a bug.

It starts alphabetical, numbers, from 0-9, then l, r, s, but then it drops back to j. So I'd describe it as 'mostly alphabetical' :)

Aha, this looks suspicious.

alt text

I wonder if this blank entry is causing an issue - their image catalogue needs a good cleaning out, might end up fixing itself - looks like there's been some corruption or something at some point.

has anyone had any trouble with the sudden nulling of relation_id of all entries?

Nothing we experienced so far.

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