Search

Any contributors around able to take a look at multi upload field? It's housed within 'Symphonists' group but is pretty neglected, couple of outstanding bugs make it pretty much unusable in 2.4 and 2.5.

Asking here as no one seems to have checked on the issues in Github.

As a side note, I've noticed a dangerous pattern that I thought I'd flag for discussion:

The number of people contributing to the core seems stable, and the quality of the work done on the core is high. However many of the extensions (even a few in the Symphonists group) just seem near-abandoned.

Given that it's a CMS that pushes pretty much all the functionality out to extensions this is a bit worry-some. Not much point in an awesome core if there's nothing to plug into it. Could we maybe see a bit more spread of time between the core and the extensions? I do what I can getting extensions up and running, but my PHP is limited and I feel like coming into new Symphony projects recently is risky, because I have no idea what is going to actually work and what's not.

From a practical perspective I'm at the point where I'm having to consider hanging my coat on a different CMS, which is a shame (huge one!), but pretty much unavoidable for anyone that wants to work in a production environment with Symphony and isn't willing or able to write all of their own extensions (or dedicate half their project time getting the existing ones up and running).

I don't want to stop using Symphony, but I also need access to a stable pool of extensions, with the knowledge that should something not work in the extension, that I won't have to wait potentially weeks for someone to look at it.

Do others feel this way or is it just me? What's the best way of dealing with this (admittedly complex) issue?

Do others feel this way or is it just me? What's the best way of dealing with this (admittedly complex) issue?

Not just you. Problem is, many of the extension developers left the community while their abandoned extensions still linger around. Or people (like myself) often develop extension for a particular project, release it as open source and move on, only updating the extension if needed for a new project.

What's the best way of dealing with this (admittedly complex) issue?

Part of the problem is already solved by our switch to semantic versioning with 2.5.0.

The core API must be backwards compatible and must not introduce breaking changes until we reach 3.0.0, all extensions working with 2.5.x should be working until 3.0.0 as well.

Another thing we should do is shut down the Symphonists organization. It's confusing to many people and sends the wrong message.

Really important extensions should be maintained by the core contributors under the Symphony CMS organization. This also means holding back major core releases until all first party extensions are tested and updated for compatibility.

Other extensions should be transfered to new maintainers or removed entirely. If people want to keep a copy of an abandoned extension, they can fork the repositories and keep a copy under their own account (or keep a local copy).

I don't want to stop using Symphony, but I also need access to a stable pool of extensions, with the knowledge that should something not work in the extension, that I won't have to wait potentially weeks for someone to look at it.

A lot of us around here are freelancers. I think it wouldn't be impossible to hire someone to update relevant extensions for you (my email address is on GitHub ;).

From a practical perspective I'm at the point where I'm having to consider hanging my coat on a different CMS, which is a shame (huge one!), but pretty much unavoidable for anyone that wants to work in a production environment with Symphony and isn't willing or able to write all of their own extensions (or dedicate half their project time getting the existing ones up and running).

Let me know when you find a feasible alternative...

Thanks for your thoughtful response Jens - some really good points and suggestions there - I'm inclined to agree with all of them.

Let me know when you find a feasible alternative...

:) If only it were that easy! And it would be very much a last resort - not something I'd want to do at all. I wouldn't want people to think I were being flippant, I love Symphony and the community, but extension maintenance is something I've noticed is an issue recently, and it's beginning to effect my projects, which is an issue for me. But I can't stress enough how unappealing re-treading the CMS scene is - I've used most of them already and hate all but a few.

Unfortunately for many of our projects hiring someone specifically to fix an existing extension isn't possible (although as others in the community will attest we're not adverse to commission bespoke extensions from time to time to handle a specific need - you'd be on my list, don't worry Jens!).

Other extensions should be transfered to new maintainers or removed entirely. If people want to keep a copy of an abandoned extension, they can fork the repositories and keep a copy under their own account (or keep a local copy).

I think this is part of where the issue is, but is in some ways an issue with how Github works. Perhaps if we were able to reclaim the extensions site it could have tools to help deal with this. An option to flag a dead extension, and 'apply' for ownership. Maybe even a dead-mans-switch to handle flagging abandoned code (at the very least the compatibility should be being updated). But of course even in these situations, we may still end up with extensions used by some, but without anyone willing to maintain them.

Although I don't personally crave a larger community (quality beats quantity) - perhaps these issues would be less frequent with one. Not that I have any suggestions as to how to increase the size of the developer pool - but I'd be interested to know if any of the core team have insights as to what puts off new users, or if there's something that causes them to drop-off too quickly. I'd be tempted to suggest it might be the whole XSLT thing… but as someone who actually likes XML/XSLT I'm not too keen to suggest it :) And of course as I'm sure we'd all agree (being web people) a flashy new website could potentially help initial conversion - looking fresh and up-to-date certainly helps with any concerns over how actively developed the platform is. And I know at least I'm a sucker for a pretty website.

But again, thanks for your response Jens, if the conversation continues I think that's a great start to it (perhaps a separate thread should be created, as I did kind of bolt it on a bit there…)

By the way, Brendan and others already did a really great job updating many extensions back in August.

But as long as there's no change in how things are organized and there's no clear ownership of abandoned extensions, we'll always run into the same problems over and over again.

People expect too much, and no one's in charge.

By the way, Brendan and others already did a really great job updating many extensions back in August.

Yup, I could be included within 'others' :) At least for some low-level stuff. But not part of that drive (which I hadn't seen actually), seems like that was a good move from Brendan!

Your point about semantic versioning is important though - if we can at least get the bulk of the used extensions in a maintainers hands (or appropriately flagged as dead) then I think we'd be in a better position moving forward. 2.4 seemed like a bit of a fumble to me (the release itself was buggy, and none of the extensions were updated for it), 2.5 seems like it's on a much better track.

Stop using extensions or at least limit the use. That is my approach nowadays. But I definitely feel the same as non 'back-ender'. The power of symphony, at least for me, is that it just gives data you can transform. Total freedom unlike some other systems.

Sometimes there is a need for an extension and is there the wish that it is in the core or at least maintained. But how to determine if an extension is the right one to be adapted in the core? Think of the whole discussion about the association field. So many people so many thoughts and needs.

The less, the better approach starts working for me, though it sometimes takes more time than I wish. But I guess that's the same for all the extension developers. Time and money, you got always to little.

It's a double edged sword. The more extensions that move into the core, the slower the release cycle and more 'stuff' in the core. Someones must have feature is the next person's bloat, hence why Symphony relies on extensions so much. Extensions are only pulled into the core if the demand is sensational or it's absolute must have feature for the majority.

Removing the symphonists repository is absurd. It would break every site that currently uses any of those extensions. It's not the path forward and doesn't fix anything, it simply moves the official responsibility of the projects to the core team. The core team has the resources to do the core work and not a lot more at this stage, so this move won't achieve results.

Apologies I haven't looked at the Multi Upload, I don't use this extension in any current project and honestly, debugging file uploads is a pain in the ass, so it's been at the bottom of the list.

There are 137 issues in the Symphonists repositories and unfortunately, I don't have the time to fix them all. I'm not the user of many of the extensions, so I'm also not the best person to dive in and fix them (or even know how to test them!), so all I can say here is if you're going to leave a bug report, leave enough information in it so it makes sense.

The changes in 2.4 and 2.5 are not monumental, but I understand they were brutal. We removed and cleaned up a significant number of misspelled functions, bad functions, files that don't meet convention, variables that are accessed incorrectly etc. Unfortunately those fixes usually result in spectacular failures that appear scary, but are actually simple to fix. The core team does it's best to document these changes to try and assist developers :)

That said, I can do a better effort of checking out the top Symphonists extensions and making sure they work. I'll do this for the 2.5.2 release.

@brendo

You are a gent, but admittedly getting you to do all the work isn't a great solution (for you as much as anything!) - as you say you have enough on your plate with the core.

Apologies I haven't looked at the Multi Upload, I don't use this extension in any current project …

Completely understandable. This has happened with a few extensions where I've poked at some of the core members for assistance - there just comes a point where there's no one else to turn to. Unfortunately it seems there are a number of extensions neither used by anyone (able to contribute) or maintained by anyone.

Currently all we really have is the compatibility flagging, but I think it leaves a lot to be desired - you're generally better off completely ignoring it at the moment. Even some core extensions don't flag their compatibility correctly.

Maybe it's time for a purge of sorts. New extension site, only containing extensions added by their authors. I have a feeling it would be far more streamlined (but at least maintained… for some time). Anything not updated for the current release gets relegated to some kind of 'Unmaintained' archive, along with an RFP for new ownership.

Removing the symphonists repository is absurd. It would break every site that currently uses any of those extensions.

Why would that break existing sites?

It's not the path forward and doesn't fix anything

At least people would know what to expect.

Currently we have a bunch of extensions no one is really responsible for, and people expect them to work, but don't know who's in charge (or assume the core team is).

The core team has the resources to do the core work and not a lot more at this stage, so this move won't achieve results.

Wouldn't that take the load off your shoulders if you no longer had to care about these extensions?

getting you to do all the work isn't a great solution

Exactly.

Maybe it's time for a purge of sorts.

+1

The current climate is actually forcing me to learn more about extensions and I have made a few work recently. The trouble is just because it "works" doesn't mean I'm following convention. Some things are convoluted.

I've been using the documentation and looking at other extensions to see where to change things to the more recent code.

So far with Paypal Payments and Twitter it seems people here were also fixing them up but I've done my own, probably messier versions.

There's a terribly convoluted part of my Twitter extension but I couldn't seem to get it to work any other way. Even though I thought it should. I'm sure there's a little abstraction that would tidy everything up. At the moment it works but I'm embarrased about it.

...and no one's in charge

Woo, anarchy! I've only been working with Symphony for a little over a year, but given that no one's in charge I feel empowered to ask a question or two to no one in particular :)

The core team do a wonderful job, and maintain and advance a product both me and my clients love. But it seems like far too few people are expected to deliver far too much. Given Symphony's strengths, isn't it apparent that the 'too few people' part of this is first and foremost a communication problem?

  • First of all, getsymphony.com doesn't do a great job of telling people how great Symphony is, and how powerful XSLT can be. This restricts how many new people (including potential developers) Symphony attracts.
  • Second of all, many of the people we do have in the community (myself included) don't know how they can help out, despite presumably having useful skills to offer (among us there's no shortage of frontend designers, but I imagine there are people with experience of copywriting, UI/UX, project managing, etc. too). Are we focusing too much on the lack of developer resource, when there are other big gaps?

It looks like the Factory project would have helped a lot in the first regard, and the project itself could have been used to address the second as it seems like there's a lot that the non-developer portion of the community could have been involved with. Sadly it appears to have died, or is at least in a very deep sleep?

Given how important that work would have been to fixing the communications problem, do we understand why it stalled? Can we learn from it and turn that understanding into something positive? Is it possible that, by beginning with research into what resource we do have in the community, we could map out a project (or several smaller projects) that would at least begin to address some of our communication problems (and take some of the pressure of the limited developer resource?

Feel free to tell me if you think I'm being naive (or just plain wrong), I won't be offended.

@John most of what you said is very true, I think there's a good understanding why things have stalled. First key people who used to be working for someone using symphony might have had opportunities to move elsewhere, albeit not using symphony so we lost out on some great talent.

Secondly apart from the core team, the really good guys are usually quite busy with their own work leaving very little time to dedicate. And most of us would only be able to develop/update something if that's incorporated within a client's or employer's budget. I'm planning to try find some time to help out when it comes to extensions and possibly the core, but it will depend on how busy I would be.

Feel free to tell me if you think I'm being naive (or just plain wrong), I won't be offended. - @johnpuddephatt

Quite the opposite! Very constructive post.

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