Answers.Body: <p>What you could try is to use the Preparse plugin and add a field to your entry type that automatically generates a secret key for each submitted entry.</p>
  
  <p>Show the user this key on the page they are redirected to upon form submission, tell them to write it down.</p>
  
  <p>You now set up a new guest entry form to submit matches. So instead of deleting entries, the user enters his personal secret key into a field to submit a new entry (I'd suggest to post to the same channel but different entry type).</p>
  
  <p>On the front-end you can now list only those requests/offers entries that do not have a matching "delete" entry yet. Another advantage over your delete approach is that you have a nice record and overview in the CP of what was offered and when.</p>
  
  <p><strong>Code example:</strong></p>
  
  <p>There's no template function to generate a random string, but you could apply Craft's <code>shuffle</code> function on an array of characters.</p>
  
  <pre><code>{%- set chars = '012345678901234567890123456789'|split('') %}
  {%- set key = shuffle(chars)|join %}
  
  {{- key|slice(0, 6) }}
  </code></pre>
  
  <p>That's how you could generate the secret keys within the Preparse field. And to loop through your "requests" and only show them if there's no matching "response" entry yet, do something like this.</p>
  
  <pre><code>{% set requests = craft.entries({
      section: 'lifts',
      type: 'requests',
      limit: null,
  }) %}
  
  {# 
   # Loop through all "requests". Check for each of them if there's a
   # matching "response" before outputting.
   #}
  {% for request in requests %}
  
      {#
       # Try to get an entry of entry type "responses" where the "secretKey"
       # field value matches the "secretKey" of the "request" in the current
       # itteration of this "requests" loop (returns an EntryModel or NULL).
       #}
      {% set hasResponse = craft.entries({
          section: 'lifts',
          type: 'responses',
          secretKey: request.secretKey,
      }).first() %}
  
      {#
       # Only output if "hasResponse" is not NULL
       #}
      {% if not hasResponse %}
          {{ request.message }}
      {% endif %}
  {% endfor %}
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-27T17:22:03.743Z
Answers.Text: That sounds like a plan. I've been thinking about letting them create a second entry and having a field that holds some common string, but I can't work out how to compare 2 separate entries for a matching string and then not show either if there is a match. Any pointers to a code example?
Answers.UserDisplayName: Paul Frost
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-27T18:58:15.717Z
Answers.Text: Thanks carlcs, any reason why the user couldn't input their own password (instead of using Preparse) when they post their first entry and then use that when they submit the second one to remove it?
  
  Any chance of adding some comments to the code to explain what's happening so I can try and learn for the future.
  If the first set only gets all entries with the type: 'requests' how does the second set hasResponse get type: 'responses' find any 'responses' if the original set only included 'requests'?
Answers.UserDisplayName: Paul Frost
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-27T20:02:24.693Z
Answers.Text: Well, you could also allow the user to set a password instead of generating one. But what happens when more than one "request" is stored with a password "1111"? This (most likely) won't happen with the generated ones. What you could do is to let them input a password, show them the request's ID and require them to input both, ID and password to submit a "response".
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-28T11:59:54.113Z
Answers.Text: I've got this working now. I'm using the original entryId as the secretKey in a hidden input and also asking for their email address as a second test. I suspect many people will forget any sort of password that they set or remember a generated random string. Security isn't that big an issue in this case.
Answers.UserDisplayName: Paul Frost
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-27T01:38:00.673Z
Answers.LastActivityDate: 2016-02-27T20:19:35.767Z
Answers.LastEditDate: 2016-02-27T20:19:35.767Z
Answers.UserDisplayName: carlcs
Answers.Body: <blockquote>
    <p>Using the Guest Entries plugin, how can I allow people to edit/delete?</p>
  </blockquote>
  
  <p>As it currently stands, you can't. The Guest Entries plugin was written to accept new entries only.  That's largely because, as you've touched on, they are "anonymous" submissions and there's no secure/easy way to authenticate that the user has permissions to edit/delete the entry they are trying to edit/delete.</p>
  
  <p>So you'd need to fork the plugin and add your own custom logic to achieve what you're looking for.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-25T22:41:31.863Z
Answers.Text: Plugin development is out of my league. I'm not a PHP developer and this is my first Craft site after years of using ExpressionEngine, so I'm on a steep learning curve.
  Any other suggestions as to how I could achieve my goal?
  Would the standard front end entry form be easier to adapt to my need?
Answers.UserDisplayName: Paul Frost
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-25T22:48:02.437Z
Answers.Text: No, the standard entry save form requires an authenticated session, which you don't want. I can't think of any way to do what you're looking for without some custom PHP/plugin work. Maybe someone else can.
Answers.UserDisplayName: Brad Bell
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-28T05:20:34.653Z
Answers.Text: @PaulFrost Late to the party, but I forked the GuestEntries plugin to allow editing & deleting of guest entries... https://github.com/ChaseGiunta/GuestEntries
Answers.UserDisplayName: Chase Giunta
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-25T22:09:44.600Z
Answers.LastActivityDate: 2016-02-25T22:09:44.600Z
Answers.UserDisplayName: Brad Bell
Body: <p>I have a form for people offering or requesting to share-a-lift to an event.
  I'm using the <a href="https://github.com/pixelandtonic/GuestEntries" rel="nofollow">Guest Entries plugin</a>. </p>
  
  <p>But I need them to be able to edit and delete those entries, as once a pair are matched up they need removing from the list of offers/requests to avoid multiple offers.</p>
  
  <p>I have a page with the list of the lifts on offer or requested and have a link from each of the entries to the form page but with the entryId as segment 2.</p>
  
  <p><strong>How do I code the Delete button?</strong> (turns out you can't)</p>
  
  <p>I appreciate that this is not the most secure way of doing things, but the client has been using a similar form/method on their old site and have not had any fraudulent or malicious issues in many years.
  If anyone can suggest a more secure method without any logins or registration I'm open to ideas.</p>
  
  <p><strong>The final solution</strong></p>
  
  <p>As you can't delete or edit Guest Entries @carlcs came up with the idea of allowing a second entry (in another entry type) with a common field to the first.</p>
  
  <p>In the template listing all the offers and requests you look for entries from both entry types with a matching field, and if a match is found don't show either. See the code in his answer for the details.</p>
  
Tags: <plugin-guestentries>
Title: Using the Guest Entries plugin, how can I allow people to edit/delete?
ThreadText: # Using the Guest Entries plugin, how can I allow people to edit/delete?
  
  (Asked by: username_0 on 2016-02-25)
  
  I have a form for people offering or requesting to share-a-lift to an event.
  I'm using the [Guest Entries plugin](https://github.com/pixelandtonic/GuestEntries).
  
  But I need them to be able to edit and delete those entries, as once a pair are matched up they need removing from the list of offers/requests to avoid multiple offers.
  
  I have a page with the list of the lifts on offer or requested and have a link from each of the entries to the form page but with the entryId as segment 2.
  
  **How do I code the Delete button?** (turns out you can't)
  
  I appreciate that this is not the most secure way of doing things, but the client has been using a similar form/method on their old site and have not had any fraudulent or malicious issues in many years.
  If anyone can suggest a more secure method without any logins or registration I'm open to ideas.
  
  **The final solution**
  
  As you can't delete or edit Guest Entries @username_1 came up with the idea of allowing a second entry (in another entry type) with a common field to the first.
  
  In the template listing all the offers and requests you look for entries from both entry types with a matching field, and if a match is found don't show either. See the code in his answer for the details.
  
  **Tags:** plugin-guestentries
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2016-02-27. Score: 4 | Accepted answer
  
  What you could try is to use the Preparse plugin and add a field to your entry type that automatically generates a secret key for each submitted entry.
  
  Show the user this key on the page they are redirected to upon form submission, tell them to write it down.
  
  You now set up a new guest entry form to submit matches. So instead of deleting entries, the user enters his personal secret key into a field to submit a new entry (I'd suggest to post to the same channel but different entry type).
  
  On the front-end you can now list only those requests/offers entries that do not have a matching "delete" entry yet. Another advantage over your delete approach is that you have a nice record and overview in the CP of what was offered and when.
  
  **Code example:**
  
  There's no template function to generate a random string, but you could apply Craft's `shuffle` function on an array of characters.
  
  ```
  {%- set chars = '012345678901234567890123456789'|split('') %}
  {%- set key = shuffle(chars)|join %}
  
  {{- key|slice(0, 6) }}
  
  ```
  
  That's how you could generate the secret keys within the Preparse field. And to loop through your "requests" and only show them if there's no matching "response" entry yet, do something like this.
  
  ```
  {% set requests = craft.entries({
      section: 'lifts',
      type: 'requests',
      limit: null,
  }) %}
  
  {# 
   # Loop through all "requests". Check for each of them if there's a
   # matching "response" before outputting.
   #}
  {% for request in requests %}
  
      {#
       # Try to get an entry of entry type "responses" where the "secretKey"
       # field value matches the "secretKey" of the "request" in the current
       # itteration of this "requests" loop (returns an EntryModel or NULL).
       #}
      {% set hasResponse = craft.entries({
          section: 'lifts',
          type: 'responses',
          secretKey: request.secretKey,
      }).first() %}
  
      {#
       # Only output if "hasResponse" is not NULL
       #}
      {% if not hasResponse %}
          {{ request.message }}
      {% endif %}
  {% endfor %}
  
  ```
  
  > **Comments:**
  > **username_0**: That sounds like a plan. I've been thinking about letting them create a second entry and having a field that holds some common string, but I can't work out how to compare 2 separate entries for a matching string and then not show either if there is a match. Any pointers to a code example?  
  > **username_0**: Thanks username_1, any reason why the user couldn't input their own password (instead of using Preparse) when they post their first entry and then use that when they submit the second one to remove it?  Any chance of adding some comments to the code to explain what's happening so I can try and learn for the future. If the first set only gets all entries with the type: 'requests' how does the second set hasResponse get type: 'responses' find any 'responses' if the original set only included 'requests'?  
  > **username_1**: Well, you could also allow the user to set a password instead of generating one. But what happens when more than one "request" is stored with a password "1111"? This (most likely) won't happen with the generated ones. What you could do is to let them input a password, show them the request's ID and require them to input both, ID and password to submit a "response".  
  > **username_0**: I've got this working now. I'm using the original entryId as the secretKey in a hidden input and also asking for their email address as a second test. I suspect many people will forget any sort of password that they set or remember a generated random string. Security isn't that big an issue in this case.  
  
  ---
  
  ### Answer by username_2 on 2016-02-25. Score: 1
  
  > Using the Guest Entries plugin, how can I allow people to edit/delete?
  
  As it currently stands, you can't. The Guest Entries plugin was written to accept new entries only. That's largely because, as you've touched on, they are "anonymous" submissions and there's no secure/easy way to authenticate that the user has permissions to edit/delete the entry they are trying to edit/delete.
  
  So you'd need to fork the plugin and add your own custom logic to achieve what you're looking for.
  
  > **Comments:**
  > **username_0**: Plugin development is out of my league. I'm not a PHP developer and this is my first Craft site after years of using ExpressionEngine, so I'm on a steep learning curve. Any other suggestions as to how I could achieve my goal? Would the standard front end entry form be easier to adapt to my need?  
  > **username_2**: No, the standard entry save form requires an authenticated session, which you don't want. I can't think of any way to do what you're looking for without some custom PHP/plugin work. Maybe someone else can.  
  > **username_3**: @username_0 Late to the party, but I forked the GuestEntries plugin to allow editing & deleting of guest entries... https://github.com/username_3/GuestEntries  
  
  ---
  
  