symphonycms
symphonycms copied to clipboard
Change Datasource Filters to work off Handles rather than IDs
The Datasource class currently uses a mix of handles and ID's when filtering, sorting, including elements and doing parameters.
For filtering, it might look something like this, where the keys are the Field ID's.
public $dsParamFILTERS = array(
'383' => '{$slug}',
'435' => '{$ds-language-by-code:english}',
);
But for included elements, or output parameters, the keys are actually the field handles:
public $dsParamINCLUDEDELEMENTS = array(
'fellowship-name',
'tagline: formatted',
'fellowship-description: formatted',
'alert-box: formatted',
'alert-url',
'summary',
'language',
'social-media'
);
public $dsParamPARAMOUTPUT = array(
'hero-image',
'related-content',
'related-resources',
'related-digital-projects'
);
I suggest that dsParamFILTERS
is updated to use handles as well. This would make developing across multiple environments more streamlined, as you no longer need to replicate the exact field ID's across both environments for the code to work.
I'm sure others have run into this in the past where you add a field locally, do all the datasource work, commit and push to the staging environment, replay the database changes and then find that the field ID's are out of sync and the datasource no longer works.
Aside from that, it simply makes datasources more consistent and easier to construct and read programmatically.
Thoughts?
+1 certainly agree. Along with Scaffolds this could be a massive time-saver. Currently scaffolds would only take care of sections; this would pretty much allow a copy/past of datasources across projects. I don't have the issue across environments as I usually sync-up with CDI so ID's tend to match.
On Fri, 26 Feb 2016 at 09:37 Brendan Abbott [email protected] wrote:
The Datasource class currently uses a mix of handles and ID's when filtering, sorting, including elements and doing parameters.
For filtering, it might look something like this, where the keys are the Field ID's.
public $dsParamFILTERS = array( '383' => '{$slug}', '435' => '{$ds-language-by-code:english}', );
But for included elements, or output parameters, the keys are actually the field handles:
public $dsParamINCLUDEDELEMENTS = array( 'fellowship-name', 'tagline: formatted', 'fellowship-description: formatted', 'alert-box: formatted', 'alert-url', 'summary', 'language', 'social-media' ); public $dsParamPARAMOUTPUT = array( 'hero-image', 'related-content', 'related-resources', 'related-digital-projects' );
I suggest that dsParamFILTERS is updated to use handles as well. This would make developing across multiple environments more streamlined, as you no longer need to replicate the exact field ID's across both environments for the code to work.
I'm sure others have run into this in the past where you add a field locally, do all the datasource work, commit and push to the staging environment, replay the database changes and then find that the field ID's are out of sync and the datasource no longer works.
Aside from that, it simply makes datasources more consistent and easier to construct and read programmatically.
Thoughts?
— Reply to this email directly or view it on GitHub https://github.com/symphonycms/symphony-2/issues/2566.
+1
+100 this would be awesome!
+1000 as @andrewminton already said +100
BTW @brendo I ran into this problem almost every week.
any workaround on filtering admin entries when using multilanguage fields ?
@cmnstmntmn I'll tackle this soon enough. See https://github.com/DeuxHuitHuit/multilingual_field/issues/70