<p>It looks like EntryTypeModels have a fieldLayoutId attribute. By inspecting the route params, we can get the entry type ID, and then create a model from that. Other than this, I haven't been able to find anything passed to the FLD.</p>

<pre><code>    $params = craft()-&gt;urlManager-&gt;getRouteParams();
    $variables = $params['variables'];
    $matches = $variables['matches'];
    $entryTypeId = $matches['entryTypeId'];
    $entryType = EntryTypeRecord::model()-&gt;findById($entryTypeId);
    $fieldLayoutId = $entryType-&gt;fieldLayoutId;
</code></pre>

<p>Hopefully this helps!</p>

<p>Edit:</p>

<p>I also found that a fieldLayoutModel is passed to the <code>fieldlayoutdesigner.html</code> template when it is included. See the include in <code>templates/settings/section/_entrytypes/edit.html</code> as an example. Content from the <code>FieldLayoutModel</code> is then loaded. </p>

<p>I know you said you would rather not load with ajax, but it is definitely better than nothing. I don't see any hook or event that gives you access to this information.</p>

<p>You could do something like </p>

<pre><code>var fieldLayoutId = '{{ fieldLayout.id|e('js') }}';
</code></pre>

<p>from within your included js file and then go pull your metadata via ajax.</p>

CC BY-SA 3.0
2015-11-10T08:29:03.913Z
I think this is my best option so far. A couple of issues though – first, testing for route params on `BasePlugin::init` is too soon. I need to get to check for the `fieldLayoutId` on basically every GET request/standard pageload, not only on `fields.saveFieldLayout`. The only event I've found to listen to is `elements.populateElement`, although that fires once for every element on the page :/ The bigger problem is that just like with request path parsing, this would require me to hard code which attributes to look at (e.g. `entryTypeId`), making it difficult to support custom element types.
Mats Mikkel Rummelhoff
CC BY-SA 3.0
2015-11-10T08:29:30.890Z
Where did you add the above code? Inside an event listener? Which event did you listen for?
Mats Mikkel Rummelhoff
CC BY-SA 3.0
2015-11-10T15:29:47.093Z
I just threw this in a variable method and called it right from the FLD template to see if there was anything of use, since route parameters would always resolved at that point. Unfortunately I haven't gone any more in depth.
kcolls
CC BY-SA 3.0
2015-11-11T22:49:26.787Z
I added an edit finding a little more information that I found. I still can't find an elegant solution.
kcolls
CC BY-SA 3.0
2015-11-11T23:13:24.530Z
Thanks a lot for continuing to poke at this – I really appreciate it! Actually, your latest edit is really interesting. If I can somehow dump the `fieldLayout` variable from `fieldlayoutdesigner.html – JS or not – it's on :) I'm going to try out a couple of ideas. Thanks again!
Mats Mikkel Rummelhoff
CC BY-SA 3.0
2015-11-11T23:42:54.250Z
No problem! This is an intriguing problem. If you mean a literal dump of the variable, try {{ dump(fieldLayout) }}. Good luck!
kcolls
CC BY-SA 3.0
2015-11-09T23:52:34.877Z
2015-11-11T22:48:24.693Z
2015-11-11T22:48:24.693Z
kcolls
<p>Inside the CP, is it possible to pull the ID for the current field layout being rendered (both in the Field Layout Designer and in element editing forms)?</p>

<p><em>A bit of context:</em></p>

<p>I'm writing a plugin which adds functionality to the built-in Field Layout Designer. The extra functionality basically allow admins to add metadata when they are editing field layouts. This metadata is stored in a custom table, using the field layout's ID as FK. The idea is that whenever a field layout is rendered (either inside the FLD, or when an element is edited/created) the plugin should pull the metadata for the current field layout.</p>

<p>Modifying the FLD UI is easy – when the plugin loads, I basically check the DOM (with jQuery) for a FLD container. If a container is found, the plugin loads up a script.</p>

<p>Saving the metadata is also easy; the plugin hooks into <code>fields.saveFieldLayout</code> like this:</p>

<pre><code>craft()-&gt;on('fields.saveFieldLayout', function (Event $e) {
    $myPluginModel = new MyPlugin_MyPluginModel();
    $myPluginModel-&gt;fieldLayoutId = $e-&gt;params['fieldLayout']-&gt;id;
    $myPluginModel-&gt;metadata = craft()-&gt;request-&gt;getPost('myPlugin.metadata');
    craft()-&gt;myPlugin-&gt;saveStuff($myPluginModel);
});
</code></pre>

<p>The hard part is querying for the relevant metadata whenever a field layout is rendered, because <em>I can't find a way to pull the currently rendered field layout's ID</em>.</p>

<p>Here's ideas I've explored/solutions that doesn't work:</p>

<ol>
<li><p>Neither the FLD nor the element editing forms expose their field layout's ID to the the DOM.</p></li>
<li><p>I've looked at the HttpRequestService to see if the field layout ID (or any other data I could use to query for the field layout ID) could be pulled from the request.</p></li>
<li><p>I've tried accessing the current controller class via <code>craft()-&gt;controller</code> – thinking if I could get to the current element type I might be able to pull the field layout from its model, but <code>craft()-&gt;controller</code> is always <code>NULL</code>.</p></li>
<li><p>I've attempted to pull the global Twig context (via <code>craft()-&gt;templates-&gt;twig</code>) to look for the <code>fieldLayout</code> variable.</p></li>
<li><p>Ideally, I wouldn't want to pull the relevant metadata client side (i.e. with AJAX), but I did also look at the global Craft JS object to look for clues, but found nothing.</p></li>
<li><p>Parsing the request path and storing the ID of the entry type, asset source, category group etc. along with the field layout ID would work. I'd like to avoid this, because it makes it impossible to support custom element types without hard coding stuff.</p></li>
</ol>

<p>If it isn't possible – by any means – to pull the current field layout ID, the alternative approach is to somehow figure out which element type is being edited, then pull that element type's model and finally get the field layout model/ID from there. Ideally, I'd like to do this without having to hard code attribute names (i.e. <code>entryTypeId</code>, <code>categoryGroupId</code> etc), because I want this to work for any custom element type, too. Any suggestions in this regard is very welcome, as well.</p>

<plugin-development>
Pulling the currently rendered field layout inside the CP
# Pulling the currently rendered field layout inside the CP

(Asked by: username_0 on 2015-11-09)

Inside the CP, is it possible to pull the ID for the current field layout being rendered (both in the Field Layout Designer and in element editing forms)?
A bit of context:
I'm writing a plugin which adds functionality to the built-in Field Layout Designer. The extra functionality basically allow admins to add metadata when they are editing field layouts. This metadata is stored in a custom table, using the field layout's ID as FK. The idea is that whenever a field layout is rendered (either inside the FLD, or when an element is edited/created) the plugin should pull the metadata for the current field layout.
Modifying the FLD UI is easy – when the plugin loads, I basically check the DOM (with jQuery) for a FLD container. If a container is found, the plugin loads up a script.
Saving the metadata is also easy; the plugin hooks into fields.saveFieldLayout like this:
craft()->on('fields.saveFieldLayout', function (Event $e) {
    $myPluginModel = new MyPlugin_MyPluginModel();
    $myPluginModel->fieldLayoutId = $e->params['fieldLayout']->id;
    $myPluginModel->metadata = craft()->request->getPost('myPlugin.metadata');
    craft()->myPlugin->saveStuff($myPluginModel);
});

The hard part is querying for the relevant metadata whenever a field layout is rendered, because I can't find a way to pull the currently rendered field layout's ID.
Here's ideas I've explored/solutions that doesn't work:

Neither the FLD nor the element editing forms expose their field layout's ID to the the DOM.
I've looked at the HttpRequestService to see if the field layout ID (or any other data I could use to query for the field layout ID) could be pulled from the request.
I've tried accessing the current controller class via craft()->controller – thinking if I could get to the current element type I might be able to pull the field layout from its model, but craft()->controller is always NULL.
I've attempted to pull the global Twig context (via craft()->templates->twig) to look for the fieldLayout variable.
Ideally, I wouldn't want to pull the relevant metadata client side (i.e. with AJAX), but I did also look at the global Craft JS object to look for clues, but found nothing.
Parsing the request path and storing the ID of the entry type, asset source, category group etc. along with the field layout ID would work. I'd like to avoid this, because it makes it impossible to support custom element types without hard coding stuff.

If it isn't possible – by any means – to pull the current field layout ID, the alternative approach is to somehow figure out which element type is being edited, then pull that element type's model and finally get the field layout model/ID from there. Ideally, I'd like to do this without having to hard code attribute names (i.e. entryTypeId, categoryGroupId etc), because I want this to work for any custom element type, too. Any suggestions in this regard is very welcome, as well.

**Tags:** plugin-development


---

## 1 answers

### Answer by username_1 on 2015-11-09. Score: 3

It looks like EntryTypeModels have a fieldLayoutId attribute. By inspecting the route params, we can get the entry type ID, and then create a model from that. Other than this, I haven't been able to find anything passed to the FLD.
    $params = craft()->urlManager->getRouteParams();
    $variables = $params['variables'];
    $matches = $variables['matches'];
    $entryTypeId = $matches['entryTypeId'];
    $entryType = EntryTypeRecord::model()->findById($entryTypeId);
    $fieldLayoutId = $entryType->fieldLayoutId;

Hopefully this helps!
Edit:
I also found that a fieldLayoutModel is passed to the fieldlayoutdesigner.html template when it is included. See the include in templates/settings/section/_entrytypes/edit.html as an example. Content from the FieldLayoutModel is then loaded. 
I know you said you would rather not load with ajax, but it is definitely better than nothing. I don't see any hook or event that gives you access to this information.
You could do something like 
var fieldLayoutId = '{{ fieldLayout.id|e('js') }}';

from within your included js file and then go pull your metadata via ajax.

> **Comments:**
> **username_0**: I think this is my best option so far. A couple of issues though – first, testing for route params on `BasePlugin::init` is too soon. I need to get to check for the `fieldLayoutId` on basically every GET request/standard pageload, not only on `fields.saveFieldLayout`. The only event I've found to listen to is `elements.populateElement`, although that fires once for every element on the page :/ The bigger problem is that just like with request path parsing, this would require me to hard code which attributes to look at (e.g. `entryTypeId`), making it difficult to support custom element types.  
> **username_0**: Where did you add the above code? Inside an event listener? Which event did you listen for?  
> **username_1**: I just threw this in a variable method and called it right from the FLD template to see if there was anything of use, since route parameters would always resolved at that point. Unfortunately I haven't gone any more in depth.  
> **username_1**: I added an edit finding a little more information that I found. I still can't find an elegant solution.  
> **username_0**: Thanks a lot for continuing to poke at this – I really appreciate it! Actually, your latest edit is really interesting. If I can somehow dump the `fieldLayout` variable from `fieldlayoutdesigner.html – JS or not – it's on :) I'm going to try out a couple of ideas. Thanks again!  
> **username_1**: No problem! This is an intriguing problem. If you mean a literal dump of the variable, try {{ dump(fieldLayout) }}. Good luck!  

---

