Symphony.

I’m working on an extension that provides a field with entries from another section. I’d like to fetch the data of the primary field and of all taglists belonging to this related section while building the field’s markup in displayPublishPanel().

Is there an easy way using SectionManager/EntryManger or so? All SQL statements I can think of seem overcomplicated to me at the moment …

In the end I need something like this:

array(
    [0] => array(
        [title] => This is my first related entry
        [taglist] => these, are, my, tags
    )
    [1] => array(
        [title] => This is my second related entry
        [taglist] => some, more, tags
    )
)

If there is more than on taglist, these should be present, too.

Any ideas how to achieve this?

I think Rowan uses EntryManager in this way in his Subsection field. If that’s not sufficient, then you could use Paul’s DatabaseManipulator (although it isn’t publicly documented yet). DBM is simply a wrapper around the Section/EntryManager classes, designed to make them easier to use.

$entries = DatabaseManipulator->getEntries(
    'articles',
    array(
        'title',
        'date',
        'published'
    ),
    array(
        'published' => 'yes'
    ),
    array(
        'limit' => 20
    )
);

// SELECT title, date, published FROM articles WHERE published='yes' LIMIT 0, 20

I use DBM in custom Data Sources and Events when I don’t have time to get my hands dirty with the SQL. That said, if it’s inside an extension you’re intending to release I’d recommend doing it the native Entrymanager/SectionManager classes.

I didn’t know the DatabaseManipulator yet - that an interesting extension.

That said, if it’s inside an extension you’re intending to release I’d recommend doing it the native Entrymanager/SectionManager classes.

I’m rebuilding my Mediathek field from scratch, making it more flexible and using jQuery instead of Mootools. So I’ll have a look at the Subsection field and see how he’s using the EntryManager.

Thanks, Nick!

Nils, can you say something about what your goals with the rebuilt Mediathek is?

Sure:

1. First of all, I don’t like the fact that Mediathek uses Mootools while Symphony is using jQuery. Mootools and jQuery aim to do the same things with different philosophies. While I prefer the Mootools way, I think two frameworks doing the same is just an overhaul.
2. Using the current Mediathek build, you have to specify a section and a title field - furthermore an upload field is required. This can be limiting. In the new version you just specify a related section: the primary field is used as title and the upload field is automatically discovered. If you don’t have an upload field in your related section - no problem, Mediathek will still work allowing you to use the field for things like a reference manager.
3. I think the interface in the content area has become a bit complicated. I’ll try to simplify it and allow the user to change the order of the selected items.
4. By know the Mediathek just returns the title and file information in data sources. In the new version it will use the build-in entry manager to return all fields belonging to the related section. This way there is no need to use a second data source if you need to fetch other fields than the title and file. Furthermore the XML structure will be exactly the same as in the rest of the system and no longer be custom made.

On my local copy everything PHP related works just fine but I haven’t started implementing #3. It may take a while: jQuery and I are not getting along well yet.

Cool, so it’s evolved to be like Rowan’s Subsection but specifically for file uploads? Love it! One of the things we’ve longed for is re-ordering of attached entries, so this will be a massive feature for me. Looking forward to it :-)

For those of you who are slow like me, here is a full example on how to use the database manipulator extension (after installing and enabling it of course)

                require_once(EXTENSIONS . '/databasemanipulator/lib/class.databasemanipulator.php');
            DatabaseManipulator::associateParent($this->_Parent);

            $entries = DatabaseManipulator::getEntries(
                'members', //the name of the section
                array(
                    'name',  //an array of all the fields you want to get data for
                    'email',
                    'phone'
                ),
                array(
                    'name' => 'Henry' //if you want to filter by anything, do it here
                ),
                array(
                    'limit' => 1 //a limit, obviously. 
                )
            );
            print_r($entries);

I’m extending this a bit further with a query-builder wrapper to make things more SQL-like. Here’s my first draft. Should get a release out and update DBM in the next week or so.

@nickdunn It does require ASDC library?

DatabaseManipulator does at present require the ASDC extension, yes. But in the future it might not.