Thread

i also back use of CI field validation.
I would also like to raise the topic of somehow limiting what can be edited by limiting it to editing only their own entries - i.e. some kind of clearance level lock in the initial tag. I am not sure how best to describe it though - or whether this is better handled with template logic.

@nevsie Good point. At a very minimum you need the Member Group ID to allow/restrict access to the SAEF. If a user is logged in, matching the author ID is fairly easy too. However if you want more granular control like allow user X from Member Group Y to only edit Channel Z entries, or only specicif entries: that would require a permission system. That’s a project on its own I think.

Some thoughts in rough personal priority order:

1) Fixing the display bugs with the file upload/manager (see bug: https://support.ellislab.com/bugs/detail/13716/). I’ll admit this is self-serving as I need that fixing for a current site (so should possibly :zip: !)

With my non-self-serving hat on, I’d suggest fixing the existing, known bugs should take priority over a complete re-write or additional functionality. However, I appreciate that the development reality may be that some - or all - of these can’t be fixed without a total re-write.

2) Native support for editing entries. Essential really.
On access permissions, I’d personally be OK if access permissions followed the CP settings in terms of ability to edit entries authored by others, and which channels users are permitted to post to, but guess others may need something more flexible.

3) I’m with bluedreamer especially on (3) an “upload only” file option which doesn’t give full file manager access, as well as (4) edit only certain fields but leave all others unchanged.

4) I’m with Natham Pitman on “Redirect with appended entry ID in URL please”

5) To answer one of your specific queries on how I style forms using CSS. Over the years I have developed my own standard markup and related CSS to handle form layouts from short and simple (labels above inputs) to long, complex forms with nested fieldsets and custom formatting.  The markup relies almost exclusively on standard field tags (<fieldset>, <label> etc…) plus a few select container tags (<div>, <ul> for checkboxes etc…). I haven’t had any particular trouble getting a simple SAEF to conform to my prefered markup, but it would be an issue with longer forms without the ability to lay-up custom fields independently of one another as in…

5) Like others, I want to be able to manually lay-up the form using specific field shortnames rather than the {custom_fields} loop.

e.g. if I have a custom field {body} I’d like to be able to use tags along the lines of:

{body:field_name}
{body:field_data}
{body:field_instructions}

(that syntax may be bogus, but you get the idea)

The goal would be field-level control over formatting and markup. Some example use cases:

- varying the field type on text inputs to use new HTML5 attributes like type=“email”.

- providing different, custom field labels or instructions on a public-facing form vs the CP version.

The {custom_field} loop could remain as an alternative for simpler forms.

(As a short ps: I think there may be ways to ‘hack’ this with the current SAEF but I haven’t had cause to try them.)

6) Support for {categories} within the entry preview. Or more generically: support for all tags available in a standard channel:entries tag (including, I’m guessing, related entries display?).

Seems like buying Safecracker outright & rolling it into the next EE release would be the easiest path.  EllisLab gets battle-tested code with the features everyone wants without having to compete with 3rd Party developers.  Easy peasy.

perhaps a bit dated now, but the feature request thread pertaining to this is here: http://ellislab.com/forums/viewthread/157958/

Having worked extensively with SAEFs on a previous project, I’d echo the requests for:

* Less predefined markup, more tags
* Redirect URLs for new entries
* Ability to use forms for editing

In the work I did, I had to do a bunch of quick and dirty database work following a new entry, and the redirect URL let me go to my own PHP template with the new ID, get that done, and then redirect out.

It’s vital that custom fieldtypes work fully in the SAEFs. This was all on 1.6.8 with a client that was stuck in IE6, and we relied heavily on Pixel & Tonic add-ons. Fortunately Brandon was available to build in compatibility, but the CP & SAEFs need to match out of the box. Whatever browsers the Control Panel supports (IE7 in EE2), that support needs to be there for the SAEF.

Thanks for requesting our input!

Mark

yes i agree, best way if posiblle is to buy SafeCracker and focus on other important priorities..

I definitely want as much code control as possible, and would prefer not to have to use a plugin for non-members to post.

Awesome feedback so far everyone!  Keep it comin’!  :D

-greg

Right, I almost forgot my most important request. And that’s because of how awesome SafeCracker is. Having the modal file browser in the SAEF isn’t good. They should be regular file upload fields.

I’ve been using Safecracker for a few projects and have been really happy with it, so I’d agree with the others - work with them to roll Safecracker into EE. One thing I’d like to see developed is a basic date field to be used with SAEF’s - without the time automatically being included.

This an encouraging development. Forgive me if I repeat some of the comments already posted. I think the following are the most important:

Simple Field Names:
When looking to have a really finely controlled front-end form, I really hate using the database names such as field_id_1 to save to the correct field. Using the short name would be so much simpler.

CSS & Java-script:
CSS & Javascript should NOT be inline or embedded automatically, if it has to be embedded it should be abstracted to a file and have data passed to it via html and then appended inside the head tags or to before the closing body tag.

Save form with Login
The ability to create forms without needing to log in first would make EE very, very powerful, no more need for third party form modules 😊

Inline Errors:
The current method of showing errors is about 4 or 5 years out of date, taking users away from the page is terribly annoying. Providing tags to markup how errors should be shown inline in the template would be much better. Something like:

{if errors}
  <ul>
    {errors wrap="li"}
  </ul>
{/if}

OR inline

<label for="name">Name:</label><span class="error">{exp:saef:error field="name"}</span>
<input type="text" name="name" id="name" />

I would find creating multi-page forms to be helpful. 

It would also be great if there was some template logic that could alter the fields on other pages based on the results from previous pages.  So for example if a user selected something from a dropdown on page1, only certain categories are available on page2.

I’ve also needed in the past for users to be able to select files they have previously uploaded (album covers for a music site where they would upload each track individually).  But I expect that this is a rather niche use case.

I’ve not had a problem hard coding the form fields in the past.

I can see multipage SAEF’s being handy, but surely that can be handle by template / url logic? So i think it should be considered, but maybe not a set feature as such - just my opinion.

Error handling is very important too. I guessed this would be handle by the typical EE flash message screen with a back link, but inline errors would be very nice and clean too. I believe CI offers both methods from memory.

1. Session-based form validation that won’t drop form field data in a browser with javascript disabled.

There are these tortured souls who work in our government offices and public institutions in the US that can’t yet dump IE6 or IE7, and their well-meaning network geeks have disabled javascript on them to make life on the web even more challenging.

Right now what happens to these folks when they fill out an SAEF and a field doesn’t validate, is the page reloads and EE’s default user message template lists the problem field(s), then the user clicks the back button and arrives at a totally empty form, that they get to fill out from scratch, and hope every field validates….. or they can start over again.

2. My “dream” is an inline error tag that could be placed along-side/above/below the form field it pertains to:

{exp:saef:validation field="field_short_name" required="yes" error="Please enter your email address"}
<input type="text" dir="ltr" id="field_id_20" name="field_id_20" value="{session_content}" maxlength="128" size="50" />

Then instead of the default error page, we could reload the form at the same URL, with content intact.

For those of us who choose to, we could then combine the inline, session-based form validation with, something like this, and cover just about every users needs.

3. The auto-response email template system used in FreeForm.

4. Secure entry deletion link that’s built in. We built a lost and found pet listing. About half the time the pets find their way back home and the person the listed them needs a way to clear out the listing without bugging the site owner to do it.

Thanks for asking.