Thread

I have a Create record SAEF with a basic textinput field:

<span>*</span> <strong>URL to Downloadable File:</strong>

<strong>http://</strong><input type='text' name='field_id_69' value='' maxlength='512' size='128' />

and Edit SAEF

<span>*</span> <strong>URL to Downloadable File:</strong>

<strong>http://</strong><input type="text" name="{exp:form_helper:field_grabber field_name='blogentry_url'}">

The custom field_id_69 is set to Text Input, 512Max, Formatting: none, fieldname: blogentry_url.  If I create the record and set it to ‘open’, no problem.  If I create set to ‘closed’, when I display the field with:

<a href="http://{blogentry_url}">{blogentry_body}</a>

the blogentry_url is surrounded by tags, thus a mouse-over displays in status:

%cp%3efilename.pdf%c/p%3E

and source code of page shows

<a href=‘http://<p>filename.pdf
</p>’><p>Test32
</p></a>

If I use the Edit SAEF and set to Open, the added <p> tags do not get displayed, if I set back to closed, they reappear.

The Create SAEF allows the user to set the status with:

<select name='status'>
   <option value='open' selected='selected'>Open</option>
   <option value='closed'>Closed</option>
</select>

The Edit SAEF changes the status with:

<select name='status'>
  {exp:form_helper:statuses entry_id="{entry_id}"}
    <option value='{entry_status}' {selected}>{entry_status}</option>
  {/exp:form_helper:statuses}
</select>

If I open the entry within the control panel Edit screen, touch nothing and click update.  The tags disappear. From then on, using the Edit SAEF to change it back-n-forth to open/closed, the problem doesn’t re-occur for those entries OR anymore further entries created with the Create SAEF.

Updated In double-checking source of displayed page, it seems that all fields (3 total) get the added <p> tags around them when set to status ‘closed’, all dissapear when setting to ‘open’.  All fields are set to formatting: none.

Updated Also found the following two threads 63162 and 99103 which deal with similar but not quite the same.  Indeed if I go into Custom Field properties for the above listed field (just the one mind you), switch it to formating of xHTML with update all and then switch it back to none with update all, the entries display correctly (i.e. p tags are gone), but when I go to create a new one (again only with status at ‘closed’) the p tags return.  Doesn’t seem like the exact cause of the problem was identified in either article.

Now for the even bizzare aspect, if I have created 3 entries with the Create SAEF and set all 3 to closed, they all display with the error.  If I open the 1st of those in the CP and update without changing anything, ALL 3 entries are now without the tags.  I deleted all and retried this, but this time ‘touched’ the 2nd one rather than the first… only the 2nd entry displayed correctly.

I tried creating 2 entries via CP first, they display fine, then created 2 with SAEF, they do not.  Now opened one created by CP in the CP and updated it, no change to the two from SAEF, but opened the 2nd created with SAEF in the CP, ‘touched’ it, only it was corrected.  Deleted all and did the exact same thing, but this time I opened the 1st one created with SAEF in the CP and ‘touched’ it, both of the ones miss-displaying were corrected.  I repeated 3x’s in a row thinking I had to be doing something manually, but this is consistent.

I would understand that if the tags appeared regardless if I set to open/closed with the create SAEF, but what throws me off, is it displays fine when set to open using either SAEF.

I’ve stripped it down to just the bare minium, no styles, no formatting and it doesn’t seem to make a diff.  Built a new create SAEF template from scratch and no change.

Its obvious the CP is scrubing the field and/or repairing the custom field formatting to ‘none’ even though that’s what the properties say, and it would make more sense if I had to ‘touch’ each entry in the CP. Also, why are all fields affected by just updating one?

The only thing I haven’t done is delete and recreate the field in the field set (which would mean creating a new field, doing a sql call to replicate existing data to the new field, then delete the old and being sure to scrub the content before replcating); i.e. a lot of work.

Again I always dread I’m missing something simple or failing to do something I missed in the docs, so I’m prep’ing my can of V8.

EE 1.6.8

Do you have a link to where we can see what’s going on?

-greg

I just stumbled across a Nov. 2008 comment on the SAEF User Guide:

As of 1.6.5 you must include the formatting type for any custom fields that you are populating with a SAEF. For example:

<input type="hidden" name="field_ft_12" value="textile" />

  which is the meat of the problem.  If I add the above for each field and set to none, the tags go away.

I just recently updated from 1.6.4 to 1.6.8.  I’m not using the custom_fields tag for a specific reason (Once working I want to use JS validation code that differs per fields of the same type) and to be honest, most of my other pages like this do use that tag for the create record page.

The odd thing is that the unwanted tags show up only when the status is set to ‘closed’.  I’m guessing with the exp:weblog:entries pulls the listing, the plug-in that ‘formats’ the output grabs field_ft_# value for the first entry of a given status type and either runs with that for all remaining records OR some other method that doesn’t include checking this value for each record displayed.  As a test I removed the hidden inputs mentioned above on SAEF, set all entries to closed after touching in CP so they do not show unwanted tags, then created a new entry set to ‘open’, low and behold the behavior is reversed.  Now Open entries have the unwanted tags.

Thus not a bug per say, but undocumented behavior as I’m guessing it is expected that all Create SAEF’s utilize the custom_field tags.

Other questions raised in my head…
  • Should I be doing this on the edit pages as well?
      ...I’m guessing not as once the field is set, regardless of how I edit the data (PHP, FormHelper Plug, etc) shouldn’t alter this field?

  • Is there another field that I need to update in a hidden input as well since I’m not using the custom_fields tag?
      ... I guess I could create a record in the CP and then the same in an SAEF then compare the database records.

... off to update all my non-Custom_Fields tag using Create SAEF’s past and present!

Are you using any extensions?

As per the docs, if you are using the {custom_fields} tag pair, this should be done for you.

-greg

Using a few, but to test disabled both extensions and plug-ins, no change in behavior, but as stated, manually setting the value or use the custom_fields tag resolves it.

So if you use {custom_fields} all is well then?  Sorry, I’m not following what the issue is then.

-greg

I was just responding to your query about the behavior potentially being related to an ext or plug, which it doesn’t seem to be.

Problem is resolved, for those not using custom fields, you must set the field_ft_xx value in a hidden input for each field (see post before last).

Glad you were able to figure out what the problem was. Don’t hesitate to post again as needed.