Symphony.

Opening links outside the iframe is one example. I’m just asking for reports of fields that do misbehave when used inside a subsection (maybe some components are hidden or only shown partly). I don’t know which problems may arise that’s why I’m asking :)

Some of the many upload fields will have the “link issue”. From the dark deep cellar of my brain at least these:

• Unique Upload Field
• Hashed Upload Field (I couldn’t find this)
• Uploadify

There might as well be problems with preview features, for example, but I have never used such fields. I hope the community can help on this topic.

I’ve been using the Unique Upload Field and so far haven’t noticed any problems with it.

I finally found some time to try the Subsection Manager extension. This is fantastic, Nils!

I’m doing my best to break it, but I haven’t tried anything too crazy yet. One thing that I did come across was a weird use case related to my messing around with the features to see what the extension does. I started to create a very simple To Do List ensemble to play around with the ability to create lists with to do items as subsection entries.

List entries have a single Name field, plus an Items subsection field. For whatever reason, I would start clicking in the “Browse…” search field to enter a Name, then click on the Create New button, which, of course, is wrong. Then, I would realize my mistake and enter name in the input field and click the Create Entry button. Here’s the bug: the entry does not get added to the selected items but gets added to the bottom of the unselected items list. When I click on the Save Changes button for the entry, the subsection item appears in the expected location at the bottom of the selected items list.

Another feature I thought might be useful would be to include the id of the subsection entries in the XML output. I’m thinking ahead to using this field on front end forms. This would require access to the entry id numbers. So, I’ve forked the repo and added the feature.

Thanks for testing the extension, Stephen. I’m aware of the bug concerning the creation of new items and I’m hunting for the source.

Another feature I thought might be useful would be to include the id of the subsection entries in the XML output. I’m thinking ahead to using this field on front end forms. This would require access to the entry id numbers. So, I’ve forked the repo and added the feature.

I’m currently working on that part of the extension as I like to move the list of included elements into the datasource manager directly. This will result in a few changes to appendFormattedElement() and I’ll implement your addition in this process.

Just given this a go for the first time. It has amazing potential :-)

I’ve logged 7 bugs on the issue tracker, as I thought it might muddy this thread. That said, one of them is definitely a duplicate of Stephen’s findings above.

Ah, now it gets complicated … Half of the bugs are listed on GitHub the rest in the extensions issue tracker on this site … I’ll go through those lists and check them for duplicates.

Oh, sorry mate. I read this in the first post.

…Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

Although the issue tracker on Symphony is lacking, I’ve been using it more and more to retrain myself, and get in the habit of using it.

I pushed a lot of changes to all three repositories today. Please have a look at it these changes and check if they really fix your issues.

The problem with newly created items not being added to both the selection and the queue seems to be fixed but I’m not completely sure about it.

Please report new bugs on GitHub: http://github.com/nilshoerrmann/subsectionmanager/issues. Thanks!

Nils,

Is there a way to get the (system) ID of the item to be included in the XML output? For example:

        <images items="1">
            <item id="27">
                ...
            </item>
        </images>

As of right now, it only outputs <item>...</item>

@brockpetrie, I ran into the same requirement for something I’ve been working on. You could clone my fork or make this change.

Thanks bauhouse, I appreciate it!

Oh, I’m sorry, I forgot to implement this in the latest changes. I’ll make sure that this addition will be part of the next commits.

I just pushed bauhouse’s addition to the main repository.

After some discussion with colleagues, this is quite a radical suggestion, so bear with me.

I am using the beta of this extension to build a list that could have up to about 30 selected items at any one time. I am hitting a UX wall whereby the stage takes up far too much vertical space:

• my page becomes long because the vertical space used by each selected entry is high
• I have about 100 entries in the search area at the bottom, and the fixed inner scrolling here (with a short height) makes it hard to find items

With Firebug I’ve modified some of the CSS rules and came up with this:

This puts the search, create/edit form and entry selection on the left; a list of selected entries on the right. This mitigates several problems I was coming up against:

• having the section in the Main column in Symphony resulted in a lot of unused grey space
• as I was selecting items from the bottom, them being added to the top was increasing the length of the top list, thereby pushing the bottom list out of view. I would therefore have to keep scrolling down to bring the bottom list back into my viewport
• as above, the position of the search box moves. In my screenshot it is static

Also, in my example above I propose that the iframe (create/edit) replaces the list on the left. This keeps the distinction clear between creating/editing, and selecting entries to use.

One thing I find confusing is the blue selection on the left is the same as the selection on the right. I understand why this is done (so when scrolling down the left column of possible entries I can see what has already been selected), but thinking more is seems like this is UI clutter — the blue selection, and the list on the right, are two UI paradigms representing the same thing.

I agree with your proposal Nick ;)

Okay, so this would be some kind of widescreen mode used for Subsection Manager fields in the primary fieldset, right? I think this is a great idea!

Any reasons why you have your queue on the left and your selection on the right? I think it would be more logical the other way around.

Also, in my example above I propose that the iframe (create/edit) replaces the list on the left. This keeps the distinction clear between creating/editing, and selecting entries to use.

That’s a point I’m not sure about and where I currently think that I don’t like the idea that much. But you can try and convince me to the contrary :)

One thing I find confusing is the blue selection on the left is the same as the selection on the right. I understand why this is done (so when scrolling down the left column of possible entries I can see what has already been selected), but thinking more is seems like this is UI clutter — the blue selection, and the list on the right, are two UI paradigms representing the same thing.

I have been thinking about the highlighting of the selected items while creating the new interface and this seems to be a double edged problem: if the selection is highlighted, it’s quite annoying if you have nearly all your items selected. If the selection is not highlighted, you can be lost in a long list when you only have a few item selected. Maybe this should be an option that can be switched on and off by the user (either in the preferences or in the interface itself)?

I agree with your proposal Nick ;)

Let me guess who is one of those colleagues Nick was talking to ;)

Thinking of it: it should be quite easy to implement this widescreen feature for manager instances in the primary fieldset using plain CSS.

Thinking of it: it should be quite easy to implement this widescreen feature for manager instances in the primary fieldset using plain CSS.

Partially. Although I am suggesting the iframe always sits on the left — when it opens it replaces the list under the search box.

Although I am suggesting the iframe always sits on the left

One of the reasons I’m not convinced of the proposed iframe positioning is that the described widescreen mode and the sidebar version that is currently implemented would handle it differently (inline versus overlay).