Search

@nils, @johanna I would really like to see this happening and am more than willing to donate to the cause. one question though: what will happen if you not even reach the first funding goal? can you refund the donations? will you start work anyway? would it be an alternative to use something like kickstarter or startnext for this kind of venture?

what will happen if you not even reach the first funding goal? can you refund the donations?

Yes, we'd refund donations in this case.

will you start work anyway?

No.

would it be an alternative to use something like kickstarter or startnext for this kind of venture?

While you can support Kickstarter campaigns from all over the world, you have to live in the US, UK, Canada, Australia, New Zealand or The Netherlands to create a campaign. As we are a German studio, this is not an option for us.

I considered Startnext but it requires a pitchvideo and a lot of other things in order to actually start a campaign. It's a good option for larger projects in my eyes but too time-consuming for smaller ones.

Please dont miss the point that most of folks here are professionals, and as professional, means we make profit with the tool. None particular initiative with economical intents deserve to be discarted, but the opposite, need to be incentived.

The community offers a free tool with a lot of voluntaire work, but still need to be economic sustentability (for they users/contributors). This topic is not supposed to be polemic, everyone is free do work as they wish, respecting the system licence, and if this is not fundamental on the core.

The crowdfunding initiative is a pretty nice way to go. The developers ask for support and folks who can donate do, not for themselves, but to the entire community. The commercial support I defend is "commercial support", like very pontual demand we have from clients, not bug fix or community support.

I hope you guys can see how beneficial this can be.

Symphony is an open source and free product, and over the years, I would have loved to have charged for my time that I ploughed into the product and community, but didn't because of that single point; Free.

Free isn't why I use Symphony.

I'd rather pay a reasonable fee for the core and certain extensions if this would ensure someone's actually continually working on this stuff.

Members extension was last updated in December 2012, for example.

Yes, we'd refund donations in this case.

ok, cool. i'm in then :)

I considered Startnext but it requires a pitchvideo and a lot of other things in order to actually start a campaign. It's a good option for larger projects in my eyes but too time-consuming for smaller ones.

right, hadn't thought about the overhead.

This one is sure practical. I use SSM a lot and would love to see the SBL finally with a similar UI.

I understand the spectre of views. If I had the sleek skills, I would help manually. So I help how I can. This project (also Symphony in general) deserves it for the idea it offers and brings to people.

I had an idea to ask also some clients about this. I kind of like this idea. I will see what will be possible.

I hope this will be available for the folks.

Let's round it to 200 € :-) Never used Symphony for a real project (sadly), but I've been lurking around this forum and Symphony generally almost from the start. I'm hoping to build some sites on Symphony in the near future, so this extension will certainly come handy.

I don't have any problems supporting this, it's true that many extensions do have roots from agency or client work which fund development, so this is no different in my eyes.

In past (and present) jobs, I've seen extensions quoted from a couple of hours to a week's work, so the sum that is being asked here is very reasonable for tackling a complex, yet common use case.

The core Symphony project will likely always be free unless another backer comes into the fray. It's likely that any commercialisation of Symphony would come from advertising, support, hosting or consulting before a licensed, private build.

In the meantime, the community should be able get a return working on Symphony, whether that's through their everyday client work, or in their spare time developing extensions. For some the return is joy or the idea of giving back, for others it's money as it helps keep the food on table and a roof over their families head.

Look forward to seeing what you come up with Nils + Johanna :)

As for Factory, it's hoped it will be used for the documentation, so it's definitely not a waste.

I'm pleased to see the area of relationships/assciations being given this consideration.

A few questions:

  1. 500€: Work on the Association UI will begin in a private repository only donators will have access to.
  2. 1000€: Work on the inline editor will begin and the Association UI will be made available to everyone.
  3. 1500€: Work on nested and sortable Data Source output will begin.
  1. What happens if only the first funding goal is reached? The way 1 is worded doesn't stipulate that anything will actually be finished. (Same for 2 and 3.) And will whatever is created eventually be made available to everyone even if funding goal 2 is not reached, and under what licence?
  2. Will this project allow for associations between sections with large numbers of entries without loading all entries into the admin page, which is crippling performance- and ui-wise?
  3. Sorting of associated entries is massively more important to me than nesting data source output, and I'd argue it could be for the majority of users as nesting is more of a convenience whereas sorting provides an important feature that is sometimes a must-have. Is there any chance the sorting can be given more priority than data source nesting?

Thanks to everyone supporting this project so far!

  1. What happens if only the first funding goal is reached? The way 1 is worded doesn't stipulate that anything will actually be finished. (Same for 2 and 3.) And will whatever is created eventually be made available to everyone even if funding goal 2 is not reached, and under what licence?

The first step is to create an UI to search, find, discover and attach entry from a related section. But we think that archieving all three goals is desirable in order to handle associations thoroughly. That's why we said "we'll start working" on it, because we hope to reach the final goal. The three defined components will work independently, so if we only reach the first goal, there will of course be a working end product.

Regarding the licence: The components will be released under MIT licence as I noted above as soon as the second goal is reached (the discussion about commercial licences is a separate, general discussion). It will only be available to funders, if we don't reach that goal.

  1. Will this project allow for associations between sections with large numbers of entries without loading all entries into the admin page, which is crippling performance- and ui-wise?

Yes, that's where Selectize come into play that offers the needed features (remote loading of data).

  1. Sorting of associated entries is massively more important to me than nesting data source output, and I'd argue it could be for the majority of users as nesting is more of a convenience whereas sorting provides an important feature that is sometimes a must-have. Is there any chance the sorting can be given more priority than data source nesting?

Sorting is easier to implement than nested output so this will be done first. We'll discuss details and general priorities with the project supporters.

First goal reached!

Association UI has just been funded.
Thanks a lot to all supporters.

Development will begin next week. All sponsors are kindly asked to send us their Github names so we can add them to the private repository.

Thanks for your answers and sorry for getting back to this so late - funding is on it's way!

Yes, the idea is to add an UI select box to the section editor which lets you choose the desired view on a per field basis (for select boxes, tags lists and SBL fields).

In my eyes, it's a good idea to have a unified concept to select UIs but the different UI should not be bundled in one big extensions. It's easier to maintain small extensions, so I'd create one extension per UI (e. g. one based on Selectize, one providing image grids etc.). The Association UI extension can be used as a prototype for other UI extensions (clone it, adapt it to your needs, publish it).

Sounds great and a quite the way I think about this task too :)

But regarding your following statement I have two more questions:

Additionally, Symphony could be updated to offer a way to register UIs for associative fields (SBL, select boxes, tags lists). But I actually think this is not necessary if extensions follow the same concept how to attach interfaces – setting the needed standards is part of this project.

1) Wouldn't you think updating the 3 concerned extensions ("Select Box Link", "Select Box" and "Tag List") to be capable of handling different UIs and ordered associations by core instead of hijacking them with the UI-Extensions would be the cleanest solution? I'd really love too see the handling of different UIs beeing developed as a kind of field-plugins/addons that hook into a UI-Management provided by the fields itself instead of going the skinning/hijacking way where a "Select Box" is turned into "Not a Select Box anymore" by a UI-Extension. That's the way this had to be done in Symphony most of the time (like using "Multiselect to Checkboxes") and it always felt kind of wrong to me.

2) The logical consequence of this solution would be to rename these fields - if they were to be interface agnostic their names should be so too. "Association Field", "Select Field" and "Tag Field" might be names to go with. I do realize that renaming a field as important as SBL is throwing up a lot of questions regarding Updating and Documentation, but if a new standard for handling association interfaces is to be designed now I'd really love too see this done as clean and consistent as possible. The way this will be done now propably won't change that soon and it would be sad to miss the chance to make this update as future-proof as possible.

Taking this road would imply to include basic UI-Management in the core and making it free for everyone from the beginning - independent of reaching funding goal 2 or not. Which I strongly support as in my eyes the basic possibility to switch UIs for these field-types should not depend on how much funding money is raised right here and now.

I'd too love to hear what others think about this, as I consider this to be a quite important aspect of the whole story.

@Nils: As mentioned in my first post I already built a kind of "proof of concept" regarding the points stated above - if you want to have a look I could clean it up a little and post it on github on monday (or tuesday... am a little short of time right now). The UI-views itself are pretty rough, but UI-Management works as described. And though my PHP-skills aren't that great, I'd love to help out with this as far as possible.

That's the idea, yes. Symphony Duplicators and Selectize both offer sorting features, so this should not be hard to implement.

Would be great if this could be done with Symphony tools... Selectize seems to rely on jQeryUI for this.

Roman, you can send us an unpolished version privately, if that saves time for you. I'll reply to your other points later (we are currently out of office due to the public holiday / long weekend here in Germany).

@nils, got full confidence in you and this project
Gonna fund soon when my budgets let me...
A steady relationship feature is invaluable for me since i rely 100% on symphony.
Keep up the good work!

@Nils, thanks for the clear answers. Congrats on reaching the first goal and all the best with this.

We are back after a long weekend and like to thank all who have supported this project so far! We have now collected 990€ and so we are pretty close to our second goal.

If you've donated to this project, please send us an e-mail with your Github account name so we can add you to the repository.

I'll get back to all of you who contacted us over the weekend soon (thanks for your kind words by the way!).

Second goal reached, third to come!

We just reached our second goal and Goldwiege announced to fund the rest. Thanks everyone for your support. We are starting work on the association interface on Github this week: https://github.com/hananils/association-ui

Third goal reached!

We just reached the third goal. Thanks a lot to Goldwiege.

Just a short update to everyone following this project. Work on the new extensions began last week and is spread across four different repositories:

Discussions are currently taking place in the first repository's issue tracker at https://github.com/hananils/association_ui_selector/issues.

There are a few things that now need to be adressed on core level first and this is what we tackle right now.

To everyone who likes to help out testing:

Association UI Selector is feature complete and available on Github, https://github.com/hananils/association_ui_selector/releases. You'll need the latest code from Symphony's integration branch and Association Field instead of SBL in order to use it.

Comming up next: Association UI Editor.

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