Symphony.

I mentioned that

This would be a good time to create a feature to track extension compatibility.

Would it be possible to add an area for extension developers to note compatibility of their extensions with each release in the list of downloads?

Update: Here’s my Unofficial Symphony CMS Extensions Library

What about the possibility for people to “watch extensions” and see all compatibilities in a list, much like the forum-filter? :-)

What about adding compatibility information to the extensions about() array? I suppose this could be parsed by the download section to offer information here on this site. Furthermore it would be possible to check for compatibility issues before running update.php and prompt a note to the user which extensions need special care.

Nils: Great idea, I didn’t think about update.php! But how will it find out if a certain extension won’t work? One could ask extension devs to try out the RCs but then you won’t recieve feedback from all of them…

Also I doubt it will be possible to parse that data in the downloads-section.

Also I doubt it will be possible to parse that data in the downloads-section.

Well, the raw code of any extension.driver.php can be accessed on github. Shouldn’t it be possible to autodiscover these links and parse them?

By the way: does github have an API?

But how will it find out if a certain extension won’t work?

If this site would store the compatibility information fetched from github, the updater could phone home to check for incompatibilities and newer extension versions.

Resources on using the official GitHub API

Guides: The GitHub API

Symphony CMS Extensions Library

• Extensions Library

How about if we use GitHub to track extensions and compatibility. If someone adds or updates an extension, they add their extension to the list and submit a pull request to the extensions repository. The repository simply tracks a list of submodules. So if you want all the latest extensions, you simply clone this repository and update the submodules.

We can also have different branches, which contain different collections of extensions:

• Default
• Stable
• Development
• Experimental
• My Favourites

So each of us can have a list of favourites in our own branch repository that we can checkout for our projects.

Extensions Compatibility

I have started a test branch with an example list of extensions with compatibility information for each:

• Name (linked to GitHub repository)
• Description
• Author
• Version
• Release Date
• Compatibility

The compatibility can remain as n/a until verified by the community that the extension is compatible.

I forgot: I was going to add a “Type” or “Category” column.

• Field
• Data Source
• API Extension

Or something similar. What should the categories be?

How about if we use GitHub to track extensions and compatibility. If someone adds or updates an extension, they add their extension to the list and submit a pull request to the extensions repository. The repository simply tracks a list of submodules. So if you want all the latest extensions, you simply clone this repository and update the submodules.

I’m not sure if I like this idea. I see some problems:

Setting up submodules, cloning and all this git related stuff may be easy for some of us. Personally, I’m a visual thinking person and I really hate that git is a command line powered monster. I learned the basics to push and pull things but man how often have I screwed up a repository due to problems while pushing to and pulling from GitHub. And GitHub is nothing more than a visualisation of what’s in a git repository - nothing more.

If we like to have a working compatibility tracking, I think the needed information should reside inside the extensions themselves. E. g. in the about() array. A compatibility check should be done automatically by the system and it should offer an easy way to upgrade in the Symphony interface (at least a link to the download area).

Remember the green update icon in version 1.7? This was a nice an clean interface and it was tracking visually what was happening technically. That was the “Symphony way” for me which has been cut off when Symphony 2 was created. I know this was done to reduce clutter and to concentrate on the core features. But I thought these nice features (all those that were in the system wide drawer with calendar and search) will at least return as extensions. In my opinion these user interface candies should return for compatibility checkups.

If technically GitHub is used for this check-up: okay (I’m not sure if it’s a good idea to be dependent on GitHub in all areas though). But in the first place we need an idea of a good user experience. And for me git is not a good user experience if you are not a techie.

github does seem a bit over-engineered…

Really, wouldn’t this be pretty easy to with Symphony itself?

Alternatively, and I know this might be controversial…, but wouldn’t a third-party wiki work equally as well for documenting this kind of thing and other documentation? (I don’t doubt that you could build a decent wiki with Symphony but I personally think it would be better to focus on Symphony itself rather than building tools that could, arguably, be serviced better by other tools..) I guess an example of what I’m suggesting is Atlassian’s Confluence extension area.

Simon

I’m not keen on using Github for this at all — it’s a huge barrier to entry.

I think we need an integrated way of doing this, such that extensions define their compatible Symphony versions as Nils suggested in the about() or similar.

During an upgrade Symphony would report which extensions are out of date and ask the developer whether they want to continue or not (knowing it could break things).

If there was some way of tracking the current version number and compatibility (by using the Github API for example) the upgrade process could also tell you which version you need or the latest version, with a direct link to Github.

I think there needs to be tighter integration between these things — having a big list on Github feels like a step backwards.

Well, this is in no way a suggestion that this should be the official means of dispersing this information. More of a stop-gap solution in the interim, and an aid to developers who are accustomed to using GitHub.

I think the consensus is that we all want extensions compatibility checking, and updating, available through the Symphony admin, similar to the way it used to be with Campfire Services. The same goes for the core application and for workspaces/themes.

GitHub is not a tool that will appeal universally, so I would much rather see a Symphony native solution in the long run. More than anything, I just want to keep the dialog open about how create a better user experience for Symphony users who are looking for extensions.

At this point, we’re still waiting for a well-documented extensions API. I’m wondering whether we need an about method for the Extension class that provides more information than it currently does:

    public function about() {
        return array(
            'name'          => 'Extension Name',
            'version'       => '1.0',
            'release-date'  => '2009-07-30',
            'author'        => array(
                'name'          => 'Author Name',
                'website'       => 'http://example.com/',
                'email'         => 'author@example.com'
            )
        );
    }

Some extensions still contain a description variable, which seems to have been deprecated at some point. Do we also need variables for compatibility and type? If all extensions are to have a GitHub repository, there should also be a source variable that points to this repository.

So, I figured out a way to modify the content.systemextensions.php file to output a list with all the necessary information for a comprehensive list. But, since the $about array was created pre-GitHub, the array seems incomplete to me, because it is missing a link to the source on GitHub.

If I take code from the symphony/content/content.systemextensions.php file and modify the list view to output this instead:

            foreach($extensions as $name => $about){

                ## Setup each cell
                $github = $about['name'];

                if(isset($about['github']))
                    $github = Widget::Anchor($about['name'], $about['github']);

                $td1 = Widget::TableData($github);          
                $td2 = Widget::TableData($about['description']);
                $td3 = Widget::TableData($about['version']);
                $td4 = Widget::TableData($about['release-date']);   

                $link = $about['author']['name'];

                if(isset($about['author']['website']))
                    $link = Widget::Anchor($about['author']['name'], General::validateURL($about['author']['website']));

                elseif(isset($about['author']['email']))
                    $link = Widget::Anchor($about['author']['name'], 'mailto:' . $about['author']['email']);    

                $td5 = Widget::TableData($link);    

                ## Add a row to the body array, assigning each cell to the row
                $aTableBody[] = Widget::TableRow(array($td1, $td2, $td3, $td4, $td5), NULL);        

            }

Then, I am able to create a table listing of all the extensions.

If all extensions developers could include the description and github indices to the $about array, we could very easily have a complete list of extensions with links to their respective GitHub repositories.

public function about() {
    return array(
        'name'          => 'Type: Extension Name',
        'github'          => 'http://github.com/author/repository/tree/master',
        '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.',
        'requirements'  => 'Symphony 2.0.5',
    );
}

While we’re talking about it: what about splitting up name and type?
Concerning the requirements: what about extensions that do work in all versions but one, e. g. Symphony 2.0 required but not working in 2.0.2?

The Unofficial Symphony CMS Extensions Library

I’ve been fiddling around with these submodules for a bit, just testing how well the download works. I had encountered some issues before because I hadn’t properly updated the .gitmodules file, but now everything is working smoothly. It’s beautiful to watch all 107 extensions download without a hitch, all with a couple commands:

git clone git://github.com/bauhouse/extensions.git
git submodule update --init

@Nils, good points. It would be much more preferable to have the name and type split. Plus, for requirements, some extensions have dependencies on other extensions or libraries, and these should be indicated here. The dependencies might need to be an array of GitHub tree hashes.

Another issue is that there can be multiple versions of the same extension. Someone can fork, for example, the Content Mappings Extension. Does this become a new version? Should it be renamed? It could get really confusing, really fast. I think we need some guidelines or policies so this business of creating extensions doesn’t go off the rails.

• Naming conventions
• Requirements
• Best practices

Which is basically saying, is there something we can do to help get an extensions API documented?

@bauhouse Wow! Thanks for pulling that together!

@bauhouse and others… This thread will be a tremendous help as we put together the new Extensions area. Good work!