Answers.Body: <p>When you create the form in civix using</p>
  
  <pre><code>civix generate:form MyForm civicrm/myform
  </code></pre>
  
  <p>I believe the last parameter determines the WordPress page to have the parameters &amp;page=CiviCRM&amp;q=civicrm/myform&amp;reset=1. If not then you likely need to implement a shortcode for it.</p>
  
  <p>Note that after adding or modifying a route in the XML file, you must reset CiviCRMs "menu cache". This can be done in a web browser by visiting "/civicrm/menu/rebuild?reset=1"</p>
  
  <p>Also beware: The form system is not well documented and may undergo significant revision after the CiviCRM 4.x series. In general, migrating basic pages will be easier than migrating basic forms, so you may want to consider to consider building your data-input UI using basic pages, the AJAX API, and/or the in-place editing API.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-02T21:15:19.900Z
Answers.LastActivityDate: 2015-04-02T21:15:19.900Z
Answers.UserDisplayName: Joe Murray
Answers.Body: <ol>
  <li><p>See also: <a href="http://wiki.civicrm.org/confluence/display/CRMDOC/Displaying+Public+Forms+in+WordPress+Frontend+Sites">http://wiki.civicrm.org/confluence/display/CRMDOC/Displaying+Public+Forms+in+WordPress+Frontend+Sites</a></p></li>
  <li><p>If you generate a link programmatically with <code>CRM_Utils_System::url()</code>, there is a boolean parameter ($frontend) which determines whether the URL will use WP's frontend system or backend system. Most forms are in the backend, so the the default is to use backend. See also: <a href="https://github.com/civicrm/civicrm-core/blob/4.6.beta5/CRM/Utils/System.php#L212">https://github.com/civicrm/civicrm-core/blob/4.6.beta5/CRM/Utils/System.php#L212</a></p></li>
  <li><p>It would be great to support clean URLs (<code>http://site.org/civicrm/foo</code>) on WordPress. I'm not a WordPress expert, and I've been told this is an esoteric area in WP (virtual pages?), but from Civi's perspective... we basically need some kind of rule in WP that maps all requests for "/civicrm/*" to CRM_Core_Invoke::invoke().</p></li>
  </ol>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-03T14:54:31.440Z
Answers.Text: Thanks Tim! Section 4 on that wiki page was pretty confusing, so I went ahead and clarified it while I was in there. As far as clean URLs, the whole virtual page thing is a bit weird. I found a good explanation of it here: https://wordpress.stackexchange.com/a/9959/70100
Answers.UserDisplayName: Nicholai
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-02T22:21:05.937Z
Answers.LastActivityDate: 2015-04-02T22:21:05.937Z
Answers.UserDisplayName: Tim Otten
Body: <p>I'm experimenting with the jQuery Repeater plugin to create multiple contacts via a single form. Using Civix, I've created an extension and a custom form. The form loads normally on the admin side, like:</p>
  
  <p><code>http://site.org/wp-admin/admin.php?page=CiviCRM&amp;q=civicrm/foo</code></p>
  
  <p>What is the proper way to expose the form to the public site? The goal is to send the visitor to:</p>
  
  <pre><code>http://site.org/civicrm/foo
  </code></pre>
  
  <p>Once there, user will fill and submit the form, and the extension's hook will deal with the result. Given the warnings all over the docs about custom forms potentially breaking in future updates, does it even make sense to approach things this way? Or is it better to put the form on a WP page, using REST API calls to populate dropdowns and checkboxes, and deal with the result?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-02T19:24:15.703Z
Comments.Text: When you say "custom form" you mean a php class that extends `CRM_Core_Form`?
Comments.UserDisplayName: Coleman
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-02T20:05:39.157Z
Comments.Text: That's correct; I haven't changed anything from the civix skeleton form yet (it still has the demo "Favorite Color" input field). I wanted to check if this is even the right approach before I build out an entire form here.
Comments.UserDisplayName: Nicholai
Tags: <wordpress><extension>
Title: How to display an extension's form as a public Wordpress page
ThreadText: # How to display an extension's form as a public Wordpress page
  
  (Asked by: username_0 on 2015-04-02)
  
  I'm experimenting with the jQuery Repeater plugin to create multiple contacts via a single form. Using Civix, I've created an extension and a custom form. The form loads normally on the admin side, like:
  
  `http://site.org/wp-admin/admin.php?page=CiviCRM&q=civicrm/foo`
  
  What is the proper way to expose the form to the public site? The goal is to send the visitor to:
  
  ```
  http://site.org/civicrm/foo
  
  ```
  
  Once there, user will fill and submit the form, and the extension's hook will deal with the result. Given the warnings all over the docs about custom forms potentially breaking in future updates, does it even make sense to approach things this way? Or is it better to put the form on a WP page, using REST API calls to populate dropdowns and checkboxes, and deal with the result?
  
  **Tags:** wordpress, extension
  
  > **Comments:**
  > **username_1**: When you say "custom form" you mean a php class that extends `CRM_Core_Form`?  
  > **username_0**: That's correct; I haven't changed anything from the civix skeleton form yet (it still has the demo "Favorite Color" input field). I wanted to check if this is even the right approach before I build out an entire form here.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2015-04-02. Score: 5 | Accepted answer
  
  1. See also: <http://wiki.civicrm.org/confluence/display/CRMDOC/Displaying+Public+Forms+in+WordPress+Frontend+Sites>
  2. If you generate a link programmatically with `CRM_Utils_System::url()`, there is a boolean parameter ($frontend) which determines whether the URL will use WP's frontend system or backend system. Most forms are in the backend, so the the default is to use backend. See also: <https://github.com/civicrm/civicrm-core/blob/4.6.beta5/CRM/Utils/System.php#L212>
  3. It would be great to support clean URLs (`http://site.org/civicrm/foo`) on WordPress. I'm not a WordPress expert, and I've been told this is an esoteric area in WP (virtual pages?), but from Civi's perspective... we basically need some kind of rule in WP that maps all requests for "/civicrm/\*" to CRM\_Core\_Invoke::invoke().
  
  > **Comments:**
  > **username_0**: Thanks Tim! Section 4 on that wiki page was pretty confusing, so I went ahead and clarified it while I was in there. As far as clean URLs, the whole virtual page thing is a bit weird. I found a good explanation of it here: https://wordpress.stackexchange.com/a/9959/70100  
  
  ---
  
  ### Answer by username_2 on 2015-04-02. Score: 1
  
  When you create the form in civix using
  
  ```
  civix generate:form MyForm civicrm/myform
  
  ```
  
  I believe the last parameter determines the WordPress page to have the parameters &page=CiviCRM&q=civicrm/myform&reset=1. If not then you likely need to implement a shortcode for it.
  
  Note that after adding or modifying a route in the XML file, you must reset CiviCRMs "menu cache". This can be done in a web browser by visiting "/civicrm/menu/rebuild?reset=1"
  
  Also beware: The form system is not well documented and may undergo significant revision after the CiviCRM 4.x series. In general, migrating basic pages will be easier than migrating basic forms, so you may want to consider to consider building your data-input UI using basic pages, the AJAX API, and/or the in-place editing API.
  
  
  ---
  
  