0 users online. Create an account or sign in to join them.Users

Search

Just a general idea for an extension, no idea how hard it would be to implement.

I know it’s been talked about before in various forms, but what if you had a pretty basic extension/field that was called “Parent Child” basically it would be a Select Box Link field with one exception, it would help to reorder the “listings” for that piece of content, and show some indented relationships.

Would something like this be possible? Would make a world of difference for organization and helping clients understand the relationships they’re creating.

I’ve added a few mockup screenshots below:

Parent Child Field Link to Screenshot

Parent Child List Link to Screenshot

Seriously? No one else has any interest in this? What do you do about sites that have deep hierarchies of pages? I’m basically talking about making an add on like Structure for ExpressionEngine. Can your clients really understand how to find and edit the right content when it’s organized by date or order and everything is all mixed up?

I missed this the first time round. I’m having a hard time figuring out what you’re proposing — are you suggesting an indented Pages list, or is the mention of pages more incidental? I believe there’s an extension somewhere (that I couldn’t find just now) that adds a “Children” column to the Blueprints > Pages table so you can click through to view child pages.

But from your screenshots, are you proposing a way to show related entries inline? So in your screenshot the first row “About MK” has two children. Normally there would be “2” in the Select Box Link column, but you’re suggesting replacing the column and actually pulling these two entries in underneath, indenting?

I’m thinking this only works for Select Box Links where they are recursive, i.e. they point back to the same section.

I’m guessing you have a specific use case for this?

Sorry, I was so careful in my first post to not use the word “pages”, but I wasn’t in my 2nd post. Yes, I’m referring to entries not pages.

Yes, what I’m proposing is that you could relate entries in the same section to each other with parent/child relationships. Then, organize the “listings screen” to show these hierarchical relationships.

Most page-based CMS’s work this way, but lack flexibility. The strength they have, however, is that an author can log in, find their content in a way that makes sense to them, and edit it without having to page through 60 entries in either date order or another order.

That’s why I mentioned Structure, which is EE’s version of this idea. EE is an “entry-based” CMS like Symphony, but Structure makes it work like I’m talking about. It has been wildly popular within the EE community.

A lot of websites I make are “mostly hierarchical” where the majority of entries are organized under their parent entries. So I usually set up a section called “Pages” or something like that and create a field called “Parent Page” which allows me to do this, and still keep few goofy sections like a news section, products section and a contact section separately organized.

Anyway, seems like functionality I would use.

I think this could be done, but I think it’s pretty limited outside of the threaded scope, such as comments and page relationships. If your PHP is ok and your not afraid to tinker, you could start with the SBL field and try your luck!

I think the threading on the Section Index page introduces some challenges with pagination, sorting and filtering.

Do you limit the rows by 17 (Symphony Default) parent item’s, or 17 rows in general? If the Parent has 22 children, 16 will show on Page 1 (Parent + 16), but then what should happen on Page 2? Redisplay the Parent and the remaining 6 children?

If you sort the Index, should it just Sort the Parent’s? Or sort the Parents and then the Children under the parent? Likewise for filtering.

This is eminently do-able with an addition to the SBL field. You could inject the child entries into the “publish” table using JavaScript:

  • on page load parse the SBL column to build a list of the “count” hyperlinks
  • load up each of these hyperlinks with an XMLHTTPRequest and parse the response to get the rows
  • inject these into the main table with some tweaked styling

It wouldn’t be as snappy as doing it PHP-side, but I don’t think Symphony provides sufficient delegates for customising the publish tables to this extent.

Here’s a quick example:

I created a section “Entries” with Name (text), Description (text) and Parent (SBL) fields. I created three entries Entry 1, Entry 2 and Entry 3, then a few children of each (i.e. Entry 1.1 and Entry 1.2 are children of Entry 1):

Example 1

With a little JavaScript and CSS I pull in the child entries and modify their styling (hack!).

Example 2

Rough and ready JS:

(function() {
    $ = jQuery;
    $(document).ready(function() {

        $('tbody tr').each(function() {

            var row = $(this);          
            var sbl_column = row.find('td:last a');
            var count = parseInt(sbl_column.text());

            if (sbl_column.length && count > 0) {

                $.get(sbl_column.attr('href'), function(response) {
                    var children = $(response).find('tbody tr');
                    children.addClass('child');
                    row.after(children);
                    reapplyZebra();
                });
            }       

        });

    });

    function reapplyZebra() {
        $('tbody tr:odd td').css('background-color', 'transparent');
        $('tbody tr:even td').css('background-color', '#F5F5F4');
    }

})();

And a little CSS:

tr.child td:first-child:before {
    content: "2192";
}

The drawbacks here are that:

  • children are shown in the main table as well. They could be hidden using JavaScript, but as Brendan says this will screw up sorting, pagination etc.
  • you can’t re-order them, so the Order Entries extension wouldn’t apply here
  • there’s a horrible hack to re-zebra-stripe the table once complete (which is down to a Symphony CSS bug)

To go any more complex than this the chances are the extension would need to provide its own custom page in the backend to reproduce the publish table functionality, rather than trying to inject the entries into the existing public table.

But it’s an interesting idea that could lead to innovation in Symphony 3 perhaps.

Nick, thanks so much for the time spent on this. It’s a great start. I might be able to wrap it into an extension that applies the Javascript and styles it a bit further. Unfortunately, I don’t know enough PHP to really get my hands dirty with this.

I think what you’ve accomplished does 90% of the functionality, but I suppose of the lack of ordering entries could get to be problematic. Maybe even a deal breaker?

I was trying to think how it would work as it’s own custom page, I suppose it wouldn’t be such a bad thing, because this section of content would work differently than other sections of content, so it might kinda make sense. The extension settings could allow you to name the navigation as appropriate?

Is there anyone else who’s interested in this idea?

The Nested Cats extension did something similar for 2.0.7, but it doesn’t work with 2.0.8. I’m sure some of the functionality could be lifted somehow?

If I tried to accomplish this not as an extension, but moreso as a frontend admin page that looked like a backend page, would there be a way to replace 1 section’s “Content Listing”? Like maybe through some .htaccess trickery?

Anymore movement on this…?

Built a basic parent field here: http://symphonyextensions.com/westynz/parent_field/

Was only a quick solution for a need we had internally, so please put any feature requests on github :)

The relationship itself can be achieved with a Select Box Link pointing back to the same section. But I'm intrigued as to how you approached the hierarchy view...

Hey Nick,

Thats the setup we had originally, but we had some users select the parent as itself, and therefore got our custom datasources into an infinite loop - obviously other ways around it, but this suits what we are doing quite well.

Im not usually a fan of similar fields being created to do similar things, mainly due to the fact that in situations like this, the code is around 70-80% the same. But In this situation, I would rather get other people's ideas/thoughts to see where it goes :)

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