Search

A new extension, "Selectbox Link Field Plus" is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

SelectBox Link Field Plus

What does this extension do?

This extension extends the functionality of the Selectbox Link Field-extension.

The extended functionality is:

  • It adds a button to the selectbox link field to create a new entry on-the-fly.
  • It provides the possibility to use different views, depending on what you are using it for (see 'View').

Requirements

This extension requires that you have the Selectbox Link Field-extension in your extension folder, since it extends those classes. Just having the directory in your extensions-folder is enough, you don't have to enable it.

Different views

Different situations require different views. For example, if you want to connect entries from a news-section or a blog-section, you want to display them differently than if you would use it for an image gallery. See the different views in the views-folder for how views are handled and how you can create your own views.

Created a new view? Share it with us and make this extension better!

I created this extension to provide an alternative for the Subsection Manager. While it has helped me with a lot of projects, it's happening more and more that I run into the limitations of the design of SubSection Manager. For example, things like:

  • User interface design: the accordeon-approach just isn't working for large sections of data like an image gallery for example. Providing only a small thumbnail and one picture for each row.
  • Bugs: the spinner that keeps on rotating when trying to create a new entry or after saving an existing entry, the entries that keep expanded.
  • The dependencies on other libraries like Stage.

This has moved me into creating a new extension, which extends the already given functionality of the SelectBox link-field. It only adds 2 extra features:

  1. Create new entries on the fly.
  2. Give a possibility to use different views.

I tried to use as much as possible the functionality already provided by Symphony, therefore minimizing the risk of bugs. For example:

  • The 'Create new'-option opens in a popup, which is an iFrame of a complete Symphony page. Therefore you don't have to lose layout or functionality that other field provide with JavaScript.
  • The extension extends selectbox link field-classes, so functionality like sorting, filtering etc. are handled within that extension.

Views are seperated. The extension comes with 2 views:

  1. Default View, just like the Selectbox Link-field.
  2. Gallery, which demonstates a simple gallery.

@kanduvisla

Ha, thanks! :D

I don't want to spoil the party: But in the long run it would have been better to join the discussion before releasing another extension that's trying to handle relationships:

We have a situation where we have to create a real solution for relationship management in Symphony. And we have to give it a new name.

Michael said wise words at the Cologne Symposium: Something like Subsection Manager was the worst thing that could have happened to Symphony – it stopped the progress of fixing the core behavior (e. g. Section Link / Selectbox Link). I fear that this is true for this extension as well.

(Now you can slap me, if you like.)

I was following the issue of the relation-field, because I also think that that is a better way to go, but all of a sudden the topic was closed and a relation-field was opened. I haven't had time to dive deeper into it, and give my opinion, but I'll see if I can chip in my 2 cents.

I agree that Subsection Manager isn't the best way to go and I applaud the creation of a better all-round extension, but untill then, I have clients that are in demand of website with a user-friendly backend. Therefore I was in need of a fast solution that provided the functionality I needed, that SSM and SBL didn't provide.

But in the long run it would have been better to join the discussion before releasing another extension that's trying to handle relationships

Maybe, but this is the best way to get ideas out. Giel has taken the SBL to be "the core way" for relationships, and has extended it to provide new functionality. There are similarities to this and the long theoretical discussions about relationship management, so I'm really glad this has surfaced as something to play with.

Thanks Giel, I'm looking forward to trying this out :-)

This sounds very interesting, kanduvisia - thanks for releasing. I'll give it a go soon as it may fit in very well with a new site I've started.

oooh SBL+, Giel, thanks for releasing. Playtime :)

Therefore I was in need of a fast solution that provided the functionality I needed, that SSM and SBL didn't provide.

I totally understand that. This is how most extension start to exist and I really appreciate your work. I just think it's the wrong moment for a public release :)

Maybe, but this is the best way to get ideas out.

Nick, you are right and wrong here. It is a great contribution and it would have been perfect to have this repository linked in the current discussion on Github. But I think a public release here in the forum is not good at the moment.

We won't come closer to an unified solution this way.
Just keep my words in mind if you revise the state of relationship management in two years from now.

But I think a public release here in the forum it not good at the moment.

I don't agree, the discussion has stagnated over and over again a no one has the inclination/ability to try new things. The best way to try ideas out is release them in the wild and see what works.

We are a very long way off getting this right, and if people need these things, then that is what extensions (proof of concept IMO) are for.

Well done. Although, can you also join the discussion... ;o)

Surely that's the beauty of open source - we can choose to work with whatever is available at the time without having to wait for things to be officially incorporated and released. I'd hate for peoples' work to be hidden away just because there is already an effort on to improve things behind the scenes.

We won't come closer to an unified solution this way.

Why would this extension negatively affect the other development?

But I think a public release here in the forum it not good at the moment.

The fact that there is an ongoing discussion in the developer channels of symphony doesn't mean that there should be some kind of "freeze" on new extensions. A lot of users aren't even aware of the discussion.

Besides that, Giel's extension actually brings functionality to symphony that was not available like this before. The funny thing is hat it isn't even "yet another relation" extension since it extends an existing core extension.

We won't come closer to an unified solution this way. Just keep my words in mind if you revise the state of relationship management in two years from now.

The discussion is very important and has high priority, i agree, so lets go here and make sure the 2-years-from-now prophecy does not come true ;-)

Non of the current ways of doing relations is perfect and the -new- way will be something completely different, lets focus on that without forgetting that we have what we have today and we cannot just walk away from this.

Why would this extension negatively affect the other development?

Because this is what Subsection Manager did.

@nils I think SSM gave everyone the idea that you solved the entire issue, now we know it didn't. I think that things will go different this time...

@nils: I don't wait for my extensions to have a public release. The fact is that, community feedback spots bugs better and faster than I could do in my own. The same goes for suggestions for functionality.

I understand that there is an ongoing discussion about relationship management, but I agree with Zimmen that this doesn't mean there should be a 'freeze' on extension development. Trust me, as soon as relationship management is solid, this extension will be adjusted to fit those needs, or even be obsoleted. But until then, I think this extension could help a lot of developers crafting their websites.

Also, I don't believe that this extension delays the find of an unified solution. I think even the opposite: extension development is a good reflection of where developers are using Symphony for. This provides insight and new ideas to keep the discussions on 'how to improve Symphony' going. If all developers would stop developing extensions because there is talk about some core changes, now thát would delay the direction in which Symphony is going.

@kanduvisla: Thanks for releasing this. I will give it a go!

@designermonkey: I well remember that during the discussion in Cologne I asked "Do we all agree that this is the way to go?". Nobody said "no". So I don't really understand your latest comments on the topic. If you did not get our point, I am sorry. But are you really that sure that Huib, Nils and I were just talking bullshit? You could have told us face to face.

In the meantime, as @kanduvisla noticed, the original discussion has been closed and there are more and more people intending to "build something similar, but much better", based on completely different ideas, maybe driven by special client demands or certain experience which I don't share. So I think that our original, simple yet powerful idea has been killed.

This makes me sad, because Huib, Nils and I had a very good feeling that our idea might improve things in a timeframe of "weeks" (not "years"), at the same time being rather future-proof. This is probably also the reason for Nils to talk about the "wrong time to release another solution".

Things have changed. After the frustrating discussion on Github I have no intention whatsoever to put any more energy in developing our relations idea.

So now I have the choice between the extremes: "Waiting for a long time" (until some other guys build a completely new relations concept into the core, new fields etc. — which I actually never needed... and I don't even know if the workflow will be any better than it is now) versus "getting something now" (an extension extending the SBL, improving the author workflow). If that is the choice, I surely go for the latter (so I somehow agree with Nick on that point).

Sorry, @Nils, I really understand your point. I am just too frustrated to fight for it anymore. And no matter how engaged I could have been in our solution, I'd still honour @kanduvisla's work.

more and more people intending to "build something similar, but much better"

I never wanted to built something similar. I for one applaud the concept of forking existing extensions, collaborating and improving existing ones. That's what makes open source so great! I just had an idea like this for a while since there were no existing extensions that provided this.

I've made great use of SSM, I use it in almost all my projects, but as time goes by and experience in Symphony grew, it didn't fit the needs anymore. So I had to create something that could provide the functionality of SSM, while providing a good UI for my client (because the UI of SSM was not always the best one for the situation).

In my opinion this is evolution: We use Symphony and its extensions on a daily base, processing feedback from our clients, experiencing stuff ourselves, and improving it on the way. The extensions and the development community is continually evolving to provide better solutions with a leaner UI to work with.

Another obvious step in evolution is the development of Symphony itself. New ideas and thoughts arise, and we have to continually ask ourselves questions: "Is this the right way to go?", "Is this the most user friendly approach to do this?", "Who are more important, our developers or our clients?". This calls for a continues stream of ideas, thoughts and feedback. Extensions are one way how ideas can be expressed, so are discussions like this one.

After the frustrating discussion on Github I have no intention whatsoever to put any more energy in developing our relations idea.

I'm sad to hear this. Too bad I wasn't on the Symposium to share my thoughts on the matter, nor did I actively participate in the discussion in Github (although I read it and was quite enthusiastic about it). But given what I said above: don't give up on this, if we all put our heads together we can come up with some great stuff! Even if it is to share ideas, thoughts and keep the discussion going.

Michael, wow, strong reaction there. I can understand the frustration. Obviously there has been a lot of talk about the subject, ideas have been put in motion and there is a future proof thingy somewhere that is in such a state that releasing similar-subject-extensions is considered as bad timing.

I'd like to hear about this simple yet powerful idea, I couldn't find it in this forum nor on the github discussion. I was not in cologne to hear about all this. And I am not alone in that regard. Hell, I'm new to the entire discussion since I thought, like Giel, it was closed.

I regarded SSM as the definite solution for a while, only to run into it's limitations. When I read Tony's proposal I got hopeful and excited but I realize that his path is long, hard, straight to the core and certainly not something that is done in a matter of weeks... Hence my interest in the solution you guys came up with.

Again, I can understand your and nils's frustration here but I, for one, had simply no idea what was going on in this matter, openness, whether it be on features or security issues, is something that I sometimes miss in the Symhony developer community.

That doesn't mean I am hugely appreciative of everything you guys have done for Symphony already, there are quite a few projects that i couldn't have built the way they are without your work so please, don't stop!!

more and more people intending to "build something similar, but much better"

I never wanted to built something similar.

Ah, sorry, I was not referring to your extension with this comment (but to the Github discussion).

Nice work Giel. Looking forward to giving it a whirl and looking at how you abstracted 'views'. Thanks :)

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