Answers.Body: <p>I'm not sure if this is the 'best' approach, but you can definitely accomplish this without creating your own tables, unless you have some other specific need. In your plugin <code>defineSettings</code> method you could either define individual fields (if the entry fields are predetermined) or a table field (if both the post data and entry fields should be configurable) to store field mappings. In your public controller method you can then map the post data to your entry's fields via the settings that you defined, perform other security/data checks, etc. and save the entry.</p>
  
  <p>In the plugin's controller:</p>
  
  <pre><code>public function actionSaveJob()
  {    
      // get 'post to field' mappings from plugin settings
      $pluginSettings = craft()-&gt;plugins-&gt;getPlugin('JobPostPlugin')-&gt;getSettings();
      $titlePostVar   = $pluginSettings-&gt;titlePostVar;
      $bodyPostVar    = $pluginSettings-&gt;bodyPostVar;
      $summaryPostVar = $pluginSettings-&gt;summaryPostVar;
  
      // retrieve post data
      $title   = craft()-&gt;request-&gt;getPost($titlePostVar);
      $body     = craft()-&gt;request-&gt;getPost($bodyPostVar);
      $summary = craft()-&gt;request-&gt;getPost($summaryPostVar);
  
      // create a new entry
      $entry = new EntryModel(); 
      $entry-&gt;sectionId  = 2; 
      $entry-&gt;typeId     = 2; 
      $entry-&gt;authorId   = 1; 
      $entry-&gt;enabled    = true;
  
      // set entry content
      $entry-&gt;getContent()-&gt;setAttributes(array(     
          'title'     =&gt; $title,     
          'body'      =&gt; $body,
          'summary'   =&gt; $summary, 
      ));
  
      // save the entry
      $success = craft()-&gt;entries-&gt;saveEntry($entry);
  }
  </code></pre>
  
  <p>Completely untested, but should be more or less correct. If anyone sees an error please comment or feel free to edit.</p>
  
  <p>You would also want to add conditions to ensure that the post data exists and that it is formatted correctly, and that whatever security conditions you've established are met, and perhaps record/return success and or errors.</p>
  
  <p>For simplicity I have shown this all happening in a controller action, however, I think the recommended approach would be to separate this between a controller and a corresponding service, so that the controller is never actually modifying the DB.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-10-31T20:53:11.477Z
Answers.Text: Thanks. How can I grab a list of fields in a select menu so the user can map each field in the settings?
Answers.UserDisplayName: Russ Back
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-01T00:25:29.520Z
Answers.Text: I was thinking that you would have them enter them manually, but you're right — a drop-down would be nicer. You can access the fields through the fieldLayoutModel. Although I'm not sure how to get that from a section id directly. I do know how to do this from an entry `{{ entry.getFieldLayout().getFields() }}`. Maybe that will get you started. I'll play around later, when I have time to check out the class reference. You might check out a plugin called 'inspecter'. Its great for wandering around the object tree, and printing out available variables, methods, properties, etc.
Answers.UserDisplayName: Douglas McDonald
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-01T19:18:32.617Z
Answers.Text: Thanks - I've found a way of doing it here http://craftcms.stackexchange.com/questions/4491/displaying-a-list-of-fields-in-a-form-select. Not sure if that's the best way though. Seems straightforward enough
Answers.UserDisplayName: Russ Back
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-01T23:35:23.377Z
Answers.Text: That will definitely work. I was just trying to narrow the field choices down to the entry type in question. All fields might be a big drop-down, with possibly duplicate field names, etc (unless you display field handles).
Answers.UserDisplayName: Douglas McDonald
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-01T23:52:50.243Z
Answers.Text: May not be the most direct, but this seems to work: `{% for field in craft.entries.type('jobs').first().getFieldLayout().getFields() %}{{ field.getField().name }}{% endfor %}`
Answers.UserDisplayName: Douglas McDonald
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-02T00:18:02.987Z
Answers.Text: This also works through the section: `{% for field in craft.sections.getSectionByHandle('jobs').getEntryTypes()[0].getFieldLayout().getFields() %}{{ field.getField().name }}{% endfor %}`
Answers.UserDisplayName: Douglas McDonald
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-02T11:34:17.873Z
Answers.Text: Thanks. I ended up taking a similar route but in a way that enabled choosing a section from a list first, then  displaying the list of fields for that section. That way the plugin has no dependency on any kind of pre-existing handle or ID.
Answers.UserDisplayName: Russ Back
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-04T21:06:34.450Z
Answers.Text: In your example above you have $entry->typeId. What would that be - I'm assuming the type id of the section, such as Entry. I'm struggling to find anything on that though.
Answers.UserDisplayName: Russ Back
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-04T21:11:44.337Z
Answers.Text: Actually I think I have answered my own question there by looking at the foreign keys in the DB - looks like we need to grab the ID of the relevant Craft\EntryTypeModel that we are posting to.
Answers.UserDisplayName: Russ Back
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-04T21:48:38.857Z
Answers.Text: Yes. Type ID is the entry type that you want to assign to the entry. You may be able to omit this if there is only one type, but I don't know for sure. Or at least it may default the next time you view and save that entry in the CP.
Answers.UserDisplayName: Douglas McDonald
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-10-24T18:45:23.547Z
Answers.LastActivityDate: 2014-10-24T18:51:20.693Z
Answers.LastEditDate: 2014-10-24T18:51:20.693Z
Answers.UserDisplayName: Douglas McDonald
Body: <p>Been looking at porting a site from EE to Craft. </p>
  
  <p>We have a custom module that accepts a POST and then stores that data in fields in a particular channel. The mappings are stored in extension settings so there are no hardcoded field IDs in the module code.</p>
  
  <p>In Craft, how would we go about that? I can see that we'd need to have a controller method that would be publicly accessibly but am unsure if we can easily use Entries or if we need a custom table with fields, field layout etc.</p>
  
  <p>The use case is a job board. Jobs are just entries in that they have a job title, body, summary, salary range, blah blah blah, and CMS users should be able to create jobs in Craft, so just a channel looks fine. The only addition is that a third party needs to post data to the channel to create jobs too, hence the need for the plugin.</p>
  
  <p>Can you please advise the best approach here? The bit I'm stuck on is either creating mappings in the plugin settings that link the posted data with fields created in the channel, or on showing a template where the CMS user can create and edit jobs using the standard Craft field layout UI.</p>
  
  <p>Hope that all makes sense!</p>
  
  <p>Thanks </p>
  
Tags: <plugin-development><entries>
Title: Posting remotely - to fields in a channel or a plugin's fields?
ThreadText: # Posting remotely - to fields in a channel or a plugin's fields?
  
  (Asked by: username_0 on 2014-10-24)
  
  Been looking at porting a site from EE to Craft.
  
  We have a custom module that accepts a POST and then stores that data in fields in a particular channel. The mappings are stored in extension settings so there are no hardcoded field IDs in the module code.
  
  In Craft, how would we go about that? I can see that we'd need to have a controller method that would be publicly accessibly but am unsure if we can easily use Entries or if we need a custom table with fields, field layout etc.
  
  The use case is a job board. Jobs are just entries in that they have a job title, body, summary, salary range, blah blah blah, and CMS users should be able to create jobs in Craft, so just a channel looks fine. The only addition is that a third party needs to post data to the channel to create jobs too, hence the need for the plugin.
  
  Can you please advise the best approach here? The bit I'm stuck on is either creating mappings in the plugin settings that link the posted data with fields created in the channel, or on showing a template where the CMS user can create and edit jobs using the standard Craft field layout UI.
  
  Hope that all makes sense!
  
  Thanks
  
  **Tags:** plugin-development, entries
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2014-10-24. Score: 2 | Accepted answer
  
  I'm not sure if this is the 'best' approach, but you can definitely accomplish this without creating your own tables, unless you have some other specific need. In your plugin `defineSettings` method you could either define individual fields (if the entry fields are predetermined) or a table field (if both the post data and entry fields should be configurable) to store field mappings. In your public controller method you can then map the post data to your entry's fields via the settings that you defined, perform other security/data checks, etc. and save the entry.
  
  In the plugin's controller:
  
  ```
  public function actionSaveJob()
  {    
      // get 'post to field' mappings from plugin settings
      $pluginSettings = craft()->plugins->getPlugin('JobPostPlugin')->getSettings();
      $titlePostVar   = $pluginSettings->titlePostVar;
      $bodyPostVar    = $pluginSettings->bodyPostVar;
      $summaryPostVar = $pluginSettings->summaryPostVar;
  
      // retrieve post data
      $title   = craft()->request->getPost($titlePostVar);
      $body     = craft()->request->getPost($bodyPostVar);
      $summary = craft()->request->getPost($summaryPostVar);
  
      // create a new entry
      $entry = new EntryModel(); 
      $entry->sectionId  = 2; 
      $entry->typeId     = 2; 
      $entry->authorId   = 1; 
      $entry->enabled    = true;
  
      // set entry content
      $entry->getContent()->setAttributes(array(     
          'title'     => $title,     
          'body'      => $body,
          'summary'   => $summary, 
      ));
  
      // save the entry
      $success = craft()->entries->saveEntry($entry);
  }
  
  ```
  
  Completely untested, but should be more or less correct. If anyone sees an error please comment or feel free to edit.
  
  You would also want to add conditions to ensure that the post data exists and that it is formatted correctly, and that whatever security conditions you've established are met, and perhaps record/return success and or errors.
  
  For simplicity I have shown this all happening in a controller action, however, I think the recommended approach would be to separate this between a controller and a corresponding service, so that the controller is never actually modifying the DB.
  
  > **Comments:**
  > **username_0**: Thanks. How can I grab a list of fields in a select menu so the user can map each field in the settings?  
  > **username_1**: I was thinking that you would have them enter them manually, but you're right — a drop-down would be nicer. You can access the fields through the fieldLayoutModel. Although I'm not sure how to get that from a section id directly. I do know how to do this from an entry `{{ entry.getFieldLayout().getFields() }}`. Maybe that will get you started. I'll play around later, when I have time to check out the class reference. You might check out a plugin called 'inspecter'. Its great for wandering around the object tree, and printing out available variables, methods, properties, etc.  
  > **username_0**: Thanks - I've found a way of doing it here http://craftcms.stackexchange.com/questions/4491/displaying-a-list-of-fields-in-a-form-select. Not sure if that's the best way though. Seems straightforward enough  
  > **username_1**: That will definitely work. I was just trying to narrow the field choices down to the entry type in question. All fields might be a big drop-down, with possibly duplicate field names, etc (unless you display field handles).  
  > **username_1**: May not be the most direct, but this seems to work: `{% for field in craft.entries.type('jobs').first().getFieldLayout().getFields() %}{{ field.getField().name }}{% endfor %}`  
  > **username_1**: This also works through the section: `{% for field in craft.sections.getSectionByHandle('jobs').getEntryTypes()[0].getFieldLayout().getFields() %}{{ field.getField().name }}{% endfor %}`  
  > **username_0**: Thanks. I ended up taking a similar route but in a way that enabled choosing a section from a list first, then  displaying the list of fields for that section. That way the plugin has no dependency on any kind of pre-existing handle or ID.  
  > **username_0**: In your example above you have $entry->typeId. What would that be - I'm assuming the type id of the section, such as Entry. I'm struggling to find anything on that though.  
  > **username_0**: Actually I think I have answered my own question there by looking at the foreign keys in the DB - looks like we need to grab the ID of the relevant Craft\EntryTypeModel that we are posting to.  
  > **username_1**: Yes. Type ID is the entry type that you want to assign to the entry. You may be able to omit this if there is only one type, but I don't know for sure. Or at least it may default the next time you view and save that entry in the CP.  
  
  ---
  
  