9

See here for example front-end HTML code for all of Craft's default field types: https://straightupcraft.com/articles/craft-cms-field-guide-twig?view=input Matrix: {# You need to include the 'type' input to identify the matrix block type you are submitting #} <input type="hidden" name="fields[fieldHandle][new1][type]" value="contacts"> {# All of ...


4

The way you've set it up now, it won't be possible without doing 2 requests: one to create the wish, and one to alter the project (add the wish relation). If you'd turn it around, and give the wish section a field 'belongsToProject' (or whatever else you'd like to call it), you'd be able to create this hidden input field in your wish form: <input type="...


4

This has been solved via a support ticket, which I'm posting here for others etc. The first time you load the template, the URI is mapping to your "Get A Quote" entry, which gets assigned to the entry variable when your template is loaded. When you submit the form, the same URL is requested again, once again matching your "Get A Quote" entry, ...


4

If the fields are marked as required in your field layout, then they should fail validation even on the front-end, so it sounds like a bug to me. Can you send a database backup as well as the template code you're using for the form over to support@buildwithcraft.com? Update The issue was that if your entries were set to be disabled by default, then Craft ...


4

TL;DR: Turns out this was an issue with my apache config on the Craft instance. Explanation: I did a little digging around the GuestEntriesController.php file and noticed that Craft was not picking up that my POST was coming from an ajax request. After looking into that more I manually added the ajax header to my post request: $.ajax({ url: config....


3

I was going out of my mind trying to work this out. William Isted spotted that Craft is using col1 as the fieldname in the table on the edit entry page. (You can see this in the inspector). This is from /admin/entries/rsvps/92-test <textarea name="fields[guests][0][col1]" rows="1" style="min-height: 46px;">Ian</textarea> If I switch my forms ...


3

Edited based on comment below No sorry I see what you mean now. But I think with entry drafts you need to have first published an entry, then you create a draft from that entry, essentially creating two versions of the same one. I think for approving entries as comments this is going to lead to a lot of complexity and you might struggle to get the results ...


3

Ok found the solution to this. All input fields must have the following format fields[handle] - i was just using the handle! Example: <input name="fields[firstName]" id="firstName" type="text" placeholder="First name *">


3

You can add a hidden field for your postDate to your GuestEntry form, e.g. <input type="hidden" name="postDate" value="{{ now|date("Y-m-j H:i:s") }}" /> This adds the postDate using Craft's YYYY-MM-DD HH:MM:SS format.


3

if you're using an Entry Form - [entries/saveEntry] you'll need to pass them in as fields. For example if you had a text field called "Links" you would need an input like this <input type="text" name="fields[links]" value="{{ entry.links }}"> Passing in inputs with the name fields[your_field_name] allow it to be picked up and populated correctly.


3

Problem solved! (head slap) The <form> requires the following parameters: enctype="multipart/form-data" An odd error that gets thrown if omitted.


3

Be sure that you're testing as a logged-out user on the front-end of the site. If you have an active Craft session, you could be getting a false positive error message.


3

I got it to work by adding the below at line 182 of GuestEntriesController.php $entry->id = craft()->request->getPost('entryId'); Then I added a hidden field with the current entries id in the template. <input type="hidden" name="entryId" value="{{ entry.id }}"> I don't know if this is the best way to do it but it seems to be ...


2

I ran into this issue too, but there is another cause to this error. Go into Settings > Users > Settings in the Control Panel and ensure "Allow public registration?" is checked, it's unchecked by default. Then it's also worth adding a conditional to the registration page to test if they are logged in or not, to ensure the error can never be triggered for a ...


2

Hope that its not too late. I would not use paypal. Use stripe instead. You can then redirect the user to the Charge plugin by Squarebit.co.uk after the entry has posted. Once payment is made, change the status of your entry to enabled. Much cleaner and stripe is easier to work with.


2

You should be able to edit that entry using craft()->entries->saveEntry($entry) with $entry->authorId set to a registered user with the necessary permissions. To get the ID of the user that created the entry, access the Guest Entries plugin settings in your plugin: $settings = craft()->plugins->getPlugin('guestentries')->getSettings(); $...


2

RichText fields make use of the Redactor plugin library, which if I understand correctly, essentially parses line-breaks and wraps lines in properly formatted html <p> tags via javascript. However, when you save from the front-end, it doesn't have a chance yet to parse the data. Only when you view the data on the back-end and re-save does redactor get ...


2

This has been fixed in Guest Entries 1.5.1.


2

You could append a query string on your redirect url that you can then query for in your template. I've used this to display different messages for a new post or an edited post. <input type="hidden" name="redirect" value="my-photos?message=photo-added"> {% set message = craft.request.getQuery( 'message' ) %} {% if message|length and message == '...


2

According to the README, the Guest Entries plugin accepts an AJAX request, and returns an object containing the entry ID, title, and so forth. As such, if you're using jQuery, you should be able to do something like this (not tested): $.ajax({ data: $('#theform').serialize(), method: 'POST', done: function (data) { // The entry title. ...


2

So, I found the answer after much digging. Thanks to this answer https://craftcms.stackexchange.com/a/9831/7962 I see that the entries field type has to be referenced with an additional set of brackets. My form now works after changing my input to: <input type="hidden" name="fields[event][]" value="{{ eventId }}">


2

The Guest Entries plugin checks for a parentId value in POST and passes that on to saveElement, so that should be all you need to do: https://github.com/craftcms/guest-entries/blob/v2/src/controllers/SaveController.php#L216


2

You can use this {% if entry.hasErrors() %} Render a message here {% endif %}


1

The site is running through CodeKit compiler connected to MAMP server. This was odd because it has never happened before with same configurations but When I run the site directly from MAMP server the problem disappeared. But I have no idea why compiler was causing that.


1

Paul, when I change the Locale setting to British English (en_gb) within the database, the Post Date field's date-format changes to dd/mm/yyyy. In DB: databaseName > craft_locales > Change "en" to "en_gb" Let us know how you get on :)


1

You could add a field "IP Address" to your Entry Type and make the form submit the guest's IP (→ getIpAddress() method) via a hidden field. <input type="hidden" name="fields[ipAddress]" value="{{ craft.request.getIpAddress() }}"> For further improvements you could make your own field type for "IP Address" with a plugin, that adds custom validation (→ ...


1

Not sure if this is of use to you, and if you use it I would recommend ensuring that you use is with security in mind. But someone has forked the GuestEntries plugin to allow editing and deleting of entries. https://github.com/ChaseGiunta/GuestEntries


1

Correct. It currently only allows for creating new entries, not editing existing ones.


1

Digging into a past solution for checkboxes thanks to @bradbell, here's the answer! <select name="fields[honorific]"> {% for honortitle in entry.honorific.options %} {% set chosen = false %} {% if honortitle.selected %} {% set chosen = true %} {% endif %} <option value="{{ honortitle.value }}"...


1

What's probably happening on both of your cases is a PHP fatal error, which are notoriously difficult to recover from. The upcoming Craft 3 (thanks to some clever tricks in Yii 2), however does handle fatal PHP error much better and in situations like yours, you would be receiving the actually underlying fatal error message.


Only top voted, non community-wiki answers of a minimum length are eligible