Symphony.

Added Localisation Manager

Finally have some time to catch up. Skimmed through 7 pages of forum posts and came up with a list of extensions to add and update. It’s amazing what you can miss if you haven’t had time to check out what’s going on for a few weeks.

• Add Address Field
• Add Email Field
• Add Duplicate Entry
• Add Param Pool to XML
• Add URL Segments
• Add Date Modified Field
• Add Image Cropper Field
• Update Populate Entry
• Update Localisation Manager
• Update Date and Time
• Update Increment Number Field
• Update Mediathek to 2.0
• Update PayPal Payments
• Update Order Entries
• Update Expression Field

I’d like to come back to this (modified) proposal:

public function about() {
    return array(
        'name'          => 'Extension Name',
        'type'          => 'Type',  // a comma separated list, e. g. field, event, interace ...
        'repository'    => 'http://github.com/author/repository/',
        'version'       => '1.0',
        'release-date'  => '2009-07-31',
        'author'        => array(
            'name'         => 'Author Name',
            'website'      => 'http://example.com/',
            'email'        => 'author@example.com'
        ),
        'description'   => 'A brief description of this extension.',
        'compatibility' => array(
            '2.0'          => false, // false = incompatible, not set = unsure
            '2.0.6'        => true   // true = compatible
        )
    );
}

Especially the introduction of the type element would help cleaning up the Symphony interface by introducing a new column in the extension overview and removing this information from the extension name.

Is this something we could and should start implementing in our extensions?

This looks like a sound suggestion to me mate. It follows the new Symphony extensions structure too.

If type is comma-delimeted, how do you envisage being able to build the full name (e.g. “Field: Map Location”) in the extensions list, if an extension contains multiple. For are you suggesting removing this entirely and adding a new column to the Extensions list for Type?

One thing I have found recently is my email being picked up by spambots reading README files. For this reason I plan to stop putting my email in READMEs (which will also discourage personal emails requesting support, instead of using the forum/issue tracker).

If type is comma-delimeted, how do you envisage being able to build the full name (e.g. “Field: Map Location”) in the extensions list, if an extension contains multiple. For are you suggesting removing this entirely and adding a new column to the Extensions list for Type?

Yes, that’s my suggestion. If you think of the Mediathek: it is currently named Field: Mediathek but that’s not everything is does (it’s an interface, too). So I thought simply renaming it Mediathek and adding the different types as a tag list in a separate column would clearify this – and I think there other extensions that would profit of this change/addition.

The email address could be optional.

The latest version of the Date and Time field implements this as follows:

    public function about() {
        return array(
            'name' => 'Date and Time',
            'type' => 'Field, Interface',
            'repository'    => 'http://github.com/nilshoerrmann/datetime/',
            'version' => '1.3',
            'release-date' => '2010-01-15',
            'author' => array(
                'name' => 'Nils Hörrmann',
                'website' => 'http://www.nilshoerrmann.de',
                'email' => 'post@nilshoerrmann.de'
            ),
            'description'   => 'A field for single dates, multiple dates and date ranges',
            'compatibility' => array(
                '2.0.6' => true,
                '2.0.7' => true
            )
        );
    }

Just a note: I believe we’ll be adopting this, or something very very close to it. Will post an official spec when I get the rest of the API docs together. In the meantime, developers should feel free to implement it as Nils has done here…

Craig, it would be nice if the type information could be implemented as a new column in the extension overview with each type linking to the related download area on this website.

Attachments:

sym_extension-overview.png

Thanks, Nils. For 2.1, we’ll be looking at small things we can do to improve the UI, and I’ll make sure we look at doing more with the new extension info we’ll be capturing.

Great! Will 2.1 feature an interface evolution or are you planning a redesign?

There’s probably not enough time for us to make major changes, so we’ll be looking for the “low-hanging fruit” so to speak… little things that we can do to improve user experience in the backend and give the UI a light refresh.

A major redesign, with deep structural changes, will come with version 3.

For 2.1.0 a simple link from the backend to the extension page, woudl have been nice; that way you can easily check if there is a newer version. Often when you update an install you forget about the core extensions also need to be updated. Or maybe in the docs it shoudl be adviced, replace all these extensions (core ones) its likely that they are newer. And check your other extensions for an update…

I assume that the compability list uses the last versions, would be good if it had version numbers too