Symphony.

Weee, thanks for looking into it.

Please post any future issues/suggestions on GitHub's issue tracker.

@eKoeS I have just implemented this extension and really like that it allows me to expose some 'Website Preferences' to authors.

In my case I use 3 separate static sections.

Now (excuse my potentially dumb question) I'd obviously like to pull these 'Website Preferences' into my templates but I'm wondering about the best way to do so.

Secretly I was hoping your extension would expose some 'unified' DS or something so that I could attach 1 'Custom Preferences' DS to my pages and access all entries for the static 'sub-sections'.

It seems, however, this is not possible and I need to attach a separate DS for each static (sub)section, correct?

If not: how do you expose your Custom Preferences to pages?

It seems, however, this is not possible and I need to attach a separate DS for each static (sub)section, correct?

That's right, unfortunately you have to attach each DS separately because Custom Preferences only takes care of the esthetic part (that is, grouping preferences in a single page).

Secretly I was hoping your extension would expose some 'unified' DS or something so that I could attach 1 'Custom Preferences' DS to my pages and access all entries for the static 'sub-sections'.

I haven't thought about it, this is a good suggestion! I'm not sure how feasible it is, as it needs to work for past, present and future fields. I'll ponder on it anyway. Thanks for the feedback :)

I have just implemented this extension and really like that it allows me to expose some 'Website Preferences' to authors.

Out of interest, do you think that "Website Preferences" better describes the extension? I ask you this because I'm still not sure about "custom".

@eKoeS thanks for your quick reply. I 'feared' CS would 'only' take care of the visual part :)

The option to expose a 'unified' DS would rock, but I would not know how difficult that would be…

Re: the name. I don't believe "Website Preferences" describes the functionality better, per se. As a matter of fact: I don't think 'Preferences' successfully describes the functionality.

Your extension could be used for a lot more than 'preferences'. Basically it is a way to visually combine static sections. Difficult to name for sure ;)

Maybe something like "Static Section Tabs"?

Uhm, it looks like people prefer the prefix "Static Section" and dislike the suffix "Preferences". Interesting... should perhaps this extension be merged with Static Sections?

The option to expose a 'unified' DS would rock, but I would not know how difficult that would be…

I never had the need to write a custom datasource so far, so I think it's a good occasion to do that now. ;)

Re: the name. I agree that static sections should get more emphasis than 'preferences'.

Re: a unified DS. The value in this extension, for me, lies in the fact that it allows me to expose multiple static sections _ as one_ through the Publish Tabs etc. When dealing with multiple static sections the use case to want to access that data through one DS seems logical.

If I'd merely needed one simple static sectin, for 'preferences', there would be less use for this extension imho. My assumption, therefore, was that most people use this with multiple static sections.

When dealing with multiple static sections the use case to want to access that data through one DS seems logical.

Good point. That could also have positive impacts on performance, since you have to load only one DS object in memory.

If I'd merely needed one simple static sectin, for 'preferences', there would be less use for this extension imho. My assumption, therefore, was that most people use this with multiple static sections.

Thanks David, your assumption makes sense to me.

Thank you Simone for your graceful reception of my feedback :)

In the end, this extension will work just like it does now, right?

In the end, this extension will work just like it does now, right?

Yup, with the addition of a custom DS which gathers all the data from the static sections.

@eKoeS have you've given this custom 'aggregate DS' some more thought?

If this is not yet available I might have a look at the 'Union Datasource' extension

Not currently available, but intended to be in the future. Sorry, time is an enemy in these days...

No problem. Union Datasource does exactly what I need. It might actually be worth linking to from the readme of your extension.

That's a good idea, thanks.

Simone, I just tried to add a Subsection Manager field and the result is simply a Selectbox. I noticed the SSM JS is not linked/loaded on that (System:Admin) page. Is this a known issue?

The screenshot on this extension's homepage indicates that a SSM is a possible field.

I've added the specific question to the SSM thread since it seems a SSM issue: SSM adds its assets (with an __appendAssets() callback) only to publish pages.

The SSM assets are not loading because the Custom Preferences section entries are not under /publish but under /symphony/extension/custompreferences/preferences/

Yep, it's a known issue but unfortunately I couldn't find any viable workaround. However, SSM is not the only field affected. From what I recall, the majority of field extensions only append assets where they are necessary. While this is by all means a good practice, Custom Preferences doesn't benefit from that.

There are two ideal ways to solve this problem.

1. Creating a new getAssets() method inside the Field class that is responsible for loading all the needed assets every time a field must be rendered.
2. Moving the addStylesheetToHead() and addScriptToHead() calls inside displayPublishPanel().

It would be great if developers could modify their field extensions to support Custom Preferences. While it seems to be the only extension now rendering fields outside publish, there could be more in the future facing this limitation.

Ok, so it's a 'known issue'… (might add that to the docs since I could not find it, even in GitHub Issues) :)

Your solution 1) seems most useful (generic) but means a rather big change for extension developers.

I might look for a quick workaround, maybe you could add some optional (config?) 'raw' addStylesheetToHead() and addScriptToHead() delegates to this extension so that we could, if need be, 'patch' and or 'extend' it?

I wonder, how did you workaround this yourself: the screenshot in this extension's homepage clearly shows a SSM :)

might add that to the docs since I could not find it, even in GitHub Issues

Right, the README needs some love :)

Your solution 1) seems most useful (generic) but means a rather big change for extension developers.

Yeah, definitely.

maybe you could add some optional (config?) 'raw' addStylesheetToHead() and addScriptToHead() delegates to this extension so that we could, if need be, 'patch' and or 'extend' it?

Sure, but in that case wouldn't it be better/easier to implement solution #2?

I wonder, how did you workaround this yourself: the screenshot in this extension's homepage clearly shows a SSM :)

Well, that's because SSM used to be less smart than now ;)

Hi Simone, I totally forgot about this issue but ran into it again today. Do you have any tips to quickly hack around this? Or should I ask Nils?