Search

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?

Maybe an (internal) integer-valued build-number could be helpful. When it’s integer you can do calculations like “it worked for all builds between x and y” much easier.

about() could have a new field like “works-with”, taking a list of single build-numbers and intervals (i.e. works-with="100-300,310-400"), the highest allowed value being the official build on release.

Hm just a thought that came to my mind: one could use release-timestamps as build-numbers, creating the “highest compatible Symphony build-no” from the extensions relase date.

I think a special field for “doesn’t work with” will make things unnecessarily complicated, simply leaving out certain values will do the same.

public function about() {
    return array(
        'name'          => 'Extension Name',
        'type'          => 'Type',    
        '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',
    );
}

This thread will be a tremendous help as we put together the new Extensions area.

So is there anything we should start implementing in our extensions?

So is there anything we should start implementing in our extensions?

Not just yet. We’re still working out some of the details. We’ll let you all know as soon as we have something.

Thanks for the update, czheng!

About multiple forks of an extension, I think the best idea would be to track only the original ‘master’ fork of a project extension. If users decide they want to try possibly buggy code, they can switch to the fork themselves.

Plus, if they don’t know how to switch to the fork, they probably shouldn’t be testing out the code in the first place :)

I’m guessing the new release of mediathek 2b has caused issue with this git very valuable repository.

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

When I’m attempting to update submodules everything runs fine until it gets to the mediathek directory and then I receive a fatal error:

fatal: reference is not a tree: 2ff390cecfaef93f35b89306979d43bd30bc9c50
Unable to checkout '2ff390cecfaef93f35b89306979d43bd30bc9c50' in submodule path 'mediathek'

If I might be doing something wrong, please correct me.

To make this more generic I’d suggest changing github to something like repository or source.

I’ve been thinking about compatibility this morning and I couldn’t find the original thread so I’ll add my thoughts here. We tend to think of compatibility as backwards i.e. “this extension requires a minimum of 2.0.2”. This suits the scenario where new extensions are popping up all the time and developers decide to use them on older websites. This doesn’t happen too often (in my experience) because I seldom return to old sites to build on them. Indeed this way round is rather like Firefox plugins whereby I may still be using Firefox 3.0 but I see a cool new extension that would make my browsing better but it requires 3.5. In Symphony, and web development, how often does this happen? Do you build a site and six months later see an extension and think “ooh, my site needs this”?

To me it seems like this relationship is reversed in web development terms. An extension almost needs to define both its minimum and maximum Symphony version: “works for 2.0.2 to 2.1”, since it may not work with 2.2 until tested. This puts the onus on the extension developer to check the extension on new major versions (2.0, 2.1, 2.2 etc.).

By means of example: my Publish Filtering extension (modified from Rowan’s excellent ideas) now no longer bundles jQuery so requires Symphony with jQuery included (roundabout 2.0.2 or so). However because the extension relies on certain HTML hooks within the Symphony UI, I cannot guarantee these will always be available since the HTML may one day be tweaked, cleaned or whatever. So should I provide a minimum of 2.0.2 and a maximum of 2.0.* and assume it could break on future major versions (2.1) until manually verified?

Setting an upper limit would make it much easier to see which extensions are 100% compatible with my Symphony version, but it also means that every extension needs to be re-tested with each new Symphony version.

So my rambling point is that it seems that the biggest problem is not backwards compatibility (solved with a required minimum Symphony version) but of forwards compatibility and extensions breaking down the line as Symphony advances and evolves. Is this a responsibility of the extension developer to not use anything too “hacky” and non-standard to reduce the chances of things breaking, or the core development team to tread even more lightly when making functionality or core code changes?

This puts the onus on the extension developer to check the extension on new major versions (2.0, 2.1, 2.2 etc.).

Agreed. Minor point releases should not break extensions unless the extension is a hack.

Setting an upper limit would make it much easier to see which extensions are 100% compatible with my Symphony version, but it also means that every extension needs to be re-tested with each new Symphony version.

Yup, agreed.

So my rambling point is that it seems that the biggest problem is not backwards compatibility (solved with a required minimum Symphony version) but of forwards compatibility and extensions breaking down the line as Symphony advances and evolves. Is this a responsibility of the extension developer to not use anything too “hacky” and non-standard to reduce the chances of things breaking, or the core development team to tread even more lightly when making functionality or core code changes?

Also, I think there needs to be better communication between Symphony developers and extension developers to solve the forward compatibility issue (i.e. need to make a,b and c changes for 2.3 compatibility).

@bauhouse,

I, too, am having the same issues that wjnielsen is having. I’m cloning a fresh copy of Symphony 2.06 and am cloning a fresh copy of your extensions library and when I got to run git submodule update --init in the extensions folder created by this library, it dies when it tries to read the mediathek entry. Here is the error that is generated…

fatal: reference is not a tree: 2ff390c
Unable to checkout '2ff390cecfaef93f35b89306979d43bd30bc9c50' in submodule path 'mediathek'

I posted this error under the issues section in github for this library.

That appears to be one of the finicky things about Git submodules. If one breaks, it completely stops the update process. I know this worked before, and I haven’t changed anything, so it’s a little bewildering.

Here’s the quick fix: Remove the offending submodule from the index, then run the update for the rest of the submodules:

git rm --cached mediathek
git submodule update --init

I’ve got some new extensions to add, so I’ll see if I can fix the mediathek submodule path at the same time.

I know this worked before, and I haven’t changed anything, so it’s a little bewildering.

I had some trouble while uploading the Mediathek beta branch and had to revert commits. Maybe this changed something for the whole repository that is now causing your problems.

Ah, could be. Not a problem. I’m looking forward to the final release of Mediathek 2.0. Looks like a killer extension, but since it’s in beta, I’m linking to your master branch for now.

I think I was able to fix the submodule path. If you’ve already followed my instructions above, you can reverse the change by issuing the following command:

git checkout HEAD .

Then update any missing submodules:

git submodule update --init

Just updated with the latest extensions.

Thanks much for your help bauhouse.

Glad to help.

Updated to the latest releases and versions - 116 extensions: http://github.com/bauhouse/extensions/tree/master

Wow, 116? The Symphony boat is sailing fast!

Well, with silly little ones like Version and Site Name, maybe it doesn’t count.

Now that I’m going through the extensions to create sets, I realized I omitted some others that I have in my library that might be useful for others trying out the Members extension:

  • Members
  • Library
  • Export Install File

I’m going to include the members branch of the Export Install File extension that includes the Members tables in the install.sql file.

Symphony CMS Extensions Library - Members Set

http://github.com/bauhouse/extensions/tree/members

This is a set of 30 Symphony CMS Extensions for use with the Members extension, packaged as a collection of submodules. The Members extension has been developed by the Symphony Team for developing a Symphony CMS site with a front end user authentication system for site members.

Last updated: 12 August 2009

Symphony CMS Extensions

A listing of the included submodules, by name:

Usage

Download this set of extensions by cloning the repository, creating a new branch called “members”, and updating the submodules.

mkdir extensions
cd extensions
git init
git remote add origin git://github.com/bauhouse/extensions.git
git pull origin members
git submodule update --init

That’s it. Now you can work with this subset of extensions instead of the entire library. If you want all of them, and you’ve already updated them, just checkout the master branch and they’ll all magically reappear in your extensions directory. Fun, eh?

Edit: Updated Git commands to avoid creating empty directories for all available extensions in the master branch.

Hmm. My bad. Upon further testing, I’ve discovered that because these are all submodules, Git doesn’t actually remove the directories. It only removes the files when you switch to a different branch. So, you’re left with a bunch of empty directories. I’m going to have to rethink this.

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