0 users online. Create an account or sign in to join them.Users


I have read about this a while ago, but I can’t seem to find the discussion anymore..

A project I am currently working on can be described by two sections: “articles” and “articles inside a file”. Because their structure is almost the same (except for a file in the last), I would really like to merge them into one section, mostly because this makes merging and filtering the data a lot easier.

I could simply have a selectbox, and an optional textarea, and give the editors the advice: “Well, just don’t use the category textbox if you are entering a new article. That textbox is only used for articles inside a file”. But that would be a modX-like solution (which is the main reason for me to switch).

So, what I would really like, and again, I have read about this, is the textbox simply not to show up if the selectbox doesn’t have the “file” value.

Do you remember where the discussion was? Or do you think I should develop a new extension for this? If so, any wishes?


Yes! That’s the one!


From the other thread:

Tangential, but possibly related, is the sort of functionality where you can display different bits of a form depending on a select box value. What I have in mind here is: say you’ve got a section called Publications. There’s a ‘Type’ select box and depending on what type is selected, you display a different subset of fields, or different labels for fields, that sort of thing. But I guess that’s a different thing entirely.

Since this is exactly what I am after, but still quite different from what the other topic is about, I think this is still the best place to discuss this.

For my project, I don’t need anything fancy at all. Just one field that is either hidden or displayed depending on the value of a selectbox. This could be fixed by a few lines of specific javascript, but I think this might come handy in other projects as well, so I should probably make an extension of this.

What do you think is the best way to handle this? How should it work?

There are two separate problems here:

  1. Grouping fields within a section
  2. Changing the visibility of groups based on the value of a field

Both problems are tricky, but trying to tackle both at once might be insane.

So is there anything that gets you halfway there? Thankfully, yes.

Nick Dunn’s Publish Tabs extension already handles the first problem. So the easiest answer might be to toggle the visibility of publish tabs based on the selection(s) in a select box field. If the option values match the titles of the tabs it’ll be even easier because there’s almost no additional logic to be defined by the user. You could even allow multiselect for advanced toggling of one or more tabs.

Anyway, just a thought…

I agree with the Publish Tabs option, it would just be a matter of adding a custom JS file to the head with an extension. This couldn’t be done on a publicly available file as it would be custom to each install.

Not very difficult though IMHO.

My initial thought was to work from the picker provided by the new Email Api (in the preferences pane).

That way, grouping wouldn’t be needed, and only one class has to be added to each “dynamic” field.

It will require a few changes to the JS though, as right now it identifies the fieldsets to hide by their id, so multiple fields wouldn’t work.

Either way, I will look into the publish tabs, as they sound very promising too!

But you’d still have to find a way to specify the field(s) to hide and show, and assign them to a particular option. I don’t see, then, how you get around the problem of grouping, even if you only want to toggle one group.

My plan was to write a bit of javascript to add a new checkbox to every field when the filter-select is added. Something like: “Show/hide this field based on the value of {name}”.

Then, if the checkbox is selected, a selectbox saying: “hide if / show if” and a textarea would do the rest.

That way it would be a per-field filter, so all the normal rules for fields would still apply (they can be in random order, etc). Shouldn’t be too hard, should it?

But how do you handle all the possible values of {name}? Imagine you’ve got a select box for, say, “type”…

  • Text
  • Image
  • Video
  • File

And you’ve got some fields that need to show when the type is ‘Image’, and others that need to show when the type is ‘File’, and so on. How do you handle that?

Use convention. If you have the above values in a select box then you could have tabs of the same name, and the extension is the glue between. I’m not sure you’re going to get something generic enough to be useful, there are no many possibly complex possibilities!

What you proposed is precisely what I proposed.

I will put together a few photoshop mockups, maybe they will make more clear what I mean.

And you’ve got some fields that need to show when the type is ‘Image’, and others that need to show when the type is ‘File’, and so on. How do you handle that?

Because this is exactly what it will be able to do.

Just check the checkbox for the field that needs image, select “show” from the selectbox and type “image” in the textbox.

The same goes for the field requiring “File”. Check the checkbox, select “show”, type “File” and you are set.

These checkboxes will be added to the config panel of each field (using a little JS magic) when the filter-select is added, so quite a lot of complex combinations will be possible.

Again, I will pop up some photoshop magic. Maybe that will make things more clear.

I have photoshopped a quick mockup of what I am trying to build.

alt text

In the image, you will see three fields, the top field is the select box which is used to filter on. The field itself is hidden because I couldn’t fit it on a printscreen otherwise;)

Assume it’s name is type.

In the bottom there are two other fields, those fields are hidden/shown depending on the selection of the selectbox. In this example I have used two input fields, but the added options can (and will) be added to any field.

Does this clear up anything?


Because I was going to need this anyway, I have created a proof-of-concept extension which already works quite well.

The code is on github, I will pop out a screencast in a few minutes.
Please remember this is only a proof of concept. I have not yet done the styling, or the section editor javascript.

Let me know what you think!

I put together a quick screencast of what I had in mind.

Again, please let me know what you think!
ps: the styles are only tested on firefox (yet), so problems may occur with other browsers.

That’s cool, I’ll try it on a 2.1 build later this morning.

It does still require the new js changes, so it only works on 2.2 (for now;))

It does still require the new js changes, so it only works on 2.2 (for now;))

Unfortunately yes :( Nice extension anyway!

I put together a quick screencast of what I had in mind.

Well done, Huib! It’s going to be very useful :)

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.1
  • 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