The member_is_author function needs to know the author id of the current entry being edited. For it to know this, make sure its tag pair is wrapped by some version of an {exp:weblog:entries} tag. Leave author_id=”{author_id}” as is. The {author_id} will be replaced with the actual author id of the entry. It always happens dynamically at the time the template is parsed.

mk

Wow!...
Finally got a chance to play around with this. As Tony used to say, “iiiiiiiitttttt’s great”.
Solspace…this and the stand alone entry form are going to make life so much easier for a lot of people I actually don’t have a need for it at the moment but I know I will.
—————
What I did and a couple of observations…
I started with one of my stand-alone entry forms and modified it to bring in all the current data from an entry. Worked like a champ.
Then I decided, I didn’t want the user to be able to edit all the fields, only some, so I eliminated all the fields I didn’t want edited. This works just fine for the most part, any fields that aren’t touched are left as is, except…
——-
Anything that can be set to defaults in your weblog preferences will revert to those defaults. So, if you’ve change the category to something else, it reverts that back to the default. (status, comments, trackbacks, all the options the same)
The way around this is to bring those values in as hidden fields. They get resubmitted as is and the user can’t touch them.
——-
Make sure you bring in the URL-Title, it’s required. In fact bring in any of your fields that are required. You can still make them hidden so the user can’t touch them.

Have fun!

Options?...Hit a stumbling block.
There is an example in the sample code for bringing in categories but don’t see one for the “options” (comments/trackbacks/etc). Is there a way?

PXLated,

Right on the required fields. We always need to call in the url_title and categories, even if just to hide them.

I haven’t built anything for the options, but I bet they come in using the standard tag provided in the entry_form function. Let me know if I need to add that.

mk

I’ve gone through the template and replaced “edit_entry” with the name of my template. When I try to access the template, via:

http://bigpicweblog.com/exp/index.php/weblog/my_template_name/800/

...I get a blank screen. What am I missing? Thanks in advance for the info.

Solspace,

Form_Helper (and your approach in general) is indeed most helpful. And just in time, too… I’m meeting with a client tomorrow, and now I can actually SHOW her the stand alone edit form that, until now, has been so elusive. Phew!

A quick question: the field_grabber function is nifty, but I’m wondering if there’s any performance difference (or other considerations) between this

and this

Is all that field grabbin slowin things down?

Tip for anyone using the former method: use {custom_fields} to quickly generate the form, then view source and copy the custom field code (with all the appropriate field_ids) in order to really customize…

Again, big fat thanks, Solspace. You’re a real paypal.

ismschism,

Right you are. Most certainly the DB is being hit to find the name of the fields. It’s a lean and mean plugin, so the hit is modest, but it does happen for every call of the plugin. Your method is better by far, except that it’s a pain and more novice users probably like the convenience.

Thanks for chipping in.

For some reason when I use the sample code from sample_edit_form.php for pi.form_helper.php, I get a blank screen. Does anyone here have a template based on sample_edit_form working? If so, could you post it in its entirety here, or email it to me? I can examine it to figure out how to get mine to work. Thanks in advance.

I just emailed you

I’ve been trying, without success, to use checkboxes in the stand alone edit form. I tried this

with field_id_39 a <select> given multiple “checkbox” options, but of course EE doesn’t support custom multiple select fields. So this didn’t work. (I didn’t think it would, but had to be sure

I then reduced the select to just one option, thinking maybe a group of single-option select fields might work together like a bunch checkboxes. But no. What I get are two(?) checkboxes, one with the {value} label, and one without. By checking one and unchecking the other, I can toggle between the two using the edit form, but I can’t uncheck both and get nothing—if that makes sense. There is no null value for the select option, I guess. I’m not too clear how checkboxes do boolean in any case, and this whole input -> select thing is sorta nind mumbing.

Hmm. Before form_helper, I was trying Robin’s approach to hacking the edit form, and I guess my answer might still lie there, but form_helper’s {checked} variable seems so close. I’m no programmer, but might one turn a textfield boolean using something like {checkbox} to test for a field value… no value = no “checked” input… ?

Okay I got the checkbox to work, sort of. Here’s an example of a custom text field turned checkbox, named phd:

The field starts out empty, thus appearing as an unchecked checkbox in the stand-alone entry form. When the checkbox is checked, “Ph.D.” appears in the control panel and in the stand-alone edit form, the checkbox is checked. All good stuff. The only problem is, unchecking the checkbox doesn’t remove the “Ph.D.” value—I can store checked values, but not take them away.

Robin, did you really get this to work? I can’t find what I’m missing in your EEwiki examples… the PHP is just for the preview, right? or do I need it to finagle the checkbox?

Heh- no, you’re right- the checkbox was persistent when editing, but you couldn’t ‘uncheck’ it and make it stick.  Which makes sense when you think about it, as an unchecked checkbox or radio button isn’t sent, so the ‘blank’ never overwrites the existing data.

Urgh- how annoying is that.  Anyway, did a quick search, found this.

Simple (yet annoying) way to do it is to add a hidden field with the same name and a null value just before your checkbox.  Since the checkbox will take the last value for the name, the null gets overwritten if checked, but the blank overwrites if not.

So basically:

<label for=“phd”>
<input type=“hidden” name=“field_id_55” value=”“>
<input type=“checkbox” name=“field_id_55” id=“phd” value=“Ph.D.” {if phd != ”“}checked{/if} />
Ph.D.
</label>

Which I did a quick check on, and it does allow you to check/uncheck via edit form. 

Sorry about that- I just hadn’t ‘unchecked’ anything I edited.

Good trick rob1. I’ll have to put that to use. One of the annoyances is that you can’t send post arrays to EE. The only post array you can send is the category values. A core feature request would be post array handling. With this we could create custom fields in the CP that handled multi-select fields and such. Major power there. But a major system change too.
mk

Robin, you rock. Finally, my stand-alone edit is complete! Thanks to all who made it possible… what a great support community

Just wondering how you guys are going about stripping out the

tags that ee brings back into the edit form?

I’ve tried the filter_html plug-in, and it sorta works but not very good. It leaves a space at the beginning of each field and doesn’t leave the text formatting quite right. Any ideas?

- Jesse BC

Oh, and I think someone asked about making status’s selectable. Here’s the code I used that seems to work just fine.

<div class=‘itemTitle’>Entry Status</div>
<select name=‘status’ class=‘select’>
<option value=‘open’ {if status == “open”}selected=‘selected’{/if}>Open</option>
<option value=‘Display on Front Page’ {if status == “Display on Front Page”}selected=‘selected’{/if}>Display on Front Page</option>
<option value=‘closed’ {if status == “closed”}selected=‘selected’{/if}>Closed</option>
</select>

Thanks Jesse BC,

Both of the things you mention are built in to the next version of the plugin.

mk

Here’s a classified ad system built using the form_helper plugin. Just launched it yesterday.

http://www.newwest.net/index.php/classifieds

mk