Extension: MD Simple Relation. Creates a "simple" relationship field, storing only the entry_id.

Doh! Maybe I can have a look-see at it this weekend. Question: are you using this in the default SAEF, between the {custom_field} tag pairs, or are you hard coding your custom fields?

Yes, using the default between the {custom_field} tags - the label shows up, but no input field at all.
I have not tried hard coding it, you think that could work?

I think that’s all or nothing - you can’t just do one custom field manually. You do them all, or you let the {custom_field} tags do their thing.

Wow, I just tried monkeying with this on a SAEF and got nowhere. SAEFs are tough, with custom field types. The problem with Simple Relation is that the field type is “simplerel”, so the SAEF doesn’t know what to do with it.

The closest I did get was trying to hack /system/modules/mod.weblog_standalone.php. I was attmpting to replicate the ‘rel’ field type. That was not pretty.

The next thing to try - and this may not work for you - it to manually do the custom fields. That may not be cool, because that might require a bunch of PHP on the template, with a custom query, to get the contents of the pulldown, etc etc.

To be honest, I don’t worry about SAEFs much because I don’t use them, myself.

I did just put this extension in a public repo on GitHub tonight: MD Simple Relation at GitHub. So, if anyone wants to take a stab at maybe using another extension hook to get this thing to work in a SAEF, then go ahead and fork it, and best of luck to you in doing so. If you get it to work, send me a Pull Request and we’ll fix this thing up right.

Thanks for giving it some effort Ryan. I generally don’t use SAEFs either, but in this case I need it because what I’m doing is creating a business directory where companies can login publicly and request inclusion. The businesses are stored in a weblog, and then related to a location (another weblog) as well as categorized by service/product type, hence the need for your extension.

I would not know enough PHP to pull off anything custom, but do you think this might work: manually coding the custom_fields in the SAEF and doing a call to the weblog entries for ‘location’ with the value for each option being entry_id?

On the very rare occasions that I’ve used a SAEF, I’ve always manually done the fields. It’s a little more work, but much more flexible that way.

You could do all your fields manually, and for the Simple Relation field do a custom query, just as you suggested. This may be the way to go. You could lift the query right out of the extension, and hardcode the values in there for the field you’re on (to replicate what your settings for the custom field in the CP).

That shouldn’t be too terrible to do.

Your extension solved a major problem for me, so thanks for that.

It initially worked perfectly, but now something weird is happening.

Entries that were already working are still fine, but new entries don’t bring back the related gallery. After looking into it, I’ve found that the field is returned with line breaks, rather than just as an integer.

Doing this in the template:
'{rel_image}'
Yields:
'

2
' 
instead of:
'2'

The edit form looks ok:

<option value='4'>Stepping Down</option>
<option value='1'>Spring 2009</option>

Any thoughts on what would cause that to happen?

Thanks again, because aside from this new issue, this extension has made me very happy!

Update: it’s actually outputting

'2 '

So, now at least I can strip that part out with php, but it’s still weird.

Can you confirm my suspicion that you probably recently upgraded from a pre 1.6.5 version of EE to 1.6.5+?

Hi, I’m on 1.6.7, but I only installed your extension two days ago, so the system hasn’t changed since then…

My latest attempt was to strip out the html and trim the field, then plug that into the gallery tag:

{assign_variable:images="{exp:html_strip}{rel_image}{/exp:html_strip}"}
Check what I've got: '{images}'
{if rel_image}
{exp:gallery:entries gallery="my_gallery" category="{images}"}

I expected that to work, but it’s still a no go.

Thanks, Matt

Well, it’s probably a problem with the extension. I’m fairly certain I developed this before 1.6.5 or am not explicitly setting the field formatting.

The issue is outlined in this devot:ee article on field formatting, and what you can do in the meantime to most likely fix this is:

1) Right around line 390 you’ll see: $r .= $DSP->input_select_footer();. Add the following line (per the article) directly after that:

$r .= $DSP->input_hidden('field_ft_' . $row['field_id'], $row['field_fmt']);

If you had existing entries where this became a problem, you may need to pay special attention to the “One More Thing” section of that article to “reset” those entries. Let me know if that helps.

I just updated the extension at GitHub with this line as well.

That did the trick!

Thanks so much. Matt

If you had existing entries where this became a problem, you may need to pay special attention to the “One More Thing” section of that article to “reset” those entries. Let me know if that helps.

Thanks so much, Ryan. I’m working on my first EE site, and I’ve been using your MD Simple Relation extension. I was taking the value from my Simple Relation field and doing a query to find the original entry it was related to. I’ll just say that it’s hard to find an entry_id with a value of something like this:

7

😉 If I couldn’t get the problem fixed, I was going to have to go back to trying to do embedded related_entries and reverse_related_entries with multiple embedded templates. Nasty. You can imagine my excitement when I saw the posts on this thread today.

Also, while pulling out my hair the past couple of weeks with this issue, I figured out the “One More Thing” step before seeing your link to the devot:ee article. I was doing this every time I would post a new entry in order to remove the [p][/p] tags.

Here are the steps I used to fix the existing entries each time I posted a new one: 1) While editing the custom field, change the Field Type from MD Simple Relation to something like Text Input (otherwise you’ll see “Text formatting is not available for your chosen field type.”) 2) You probably ultimately want to set the formatting to be None. In order to force the update of existing entries, set it to XHTML for now.
3) You should now see the checkbox at the bottom of the page to “Update all existing weblog entries with your new formatting choice?” Check this box. 4) Warning: When you click Update in the next step, you will lose your relationship settings. So I would recommend you note down all of the settings so you can change them back later. (You might be able to actually change the type back to MD Simple Relation before clicking Update so you don’t lose your settings. It didn’t seem to actually set it to XHTML when I did this though.) 5) Click Update to change all the entries to XHTML format. 6) Now go back to edit the field again. This time set the Text Formatting to None. Change the Field Type back to MD Simple Relation. Re-enter the relationship settings (weblog, display order, etc.) 7) Check the “Update all existing weblog entries” checkbox again to remove the tags from all your existing entries. 8) Click Update.

I’m not sure if any of that made sense… it’s kind of hard to describe. Hopefully this will be useful to someone.

Thanks! Josh

Wow. Hopefully we saved you some serious time by just fixing the extension!