Simple Content Plugin Issue - not able to get placeholders to work

[nrsmoll]

I have two lists, "Main" which is a contact form, and "Visits" (list id 66) which is a related table (one to many relationship).

In the list view of "Visits" I have put a content plugin so that I can have the patient details (from the contact form) at the head of the Visits lists, to remind the user of who's record they are working on. In otherwords, I am putting the details of the parent row above the child list.

The following code works perfectly (except that it is always choosing the same contact/record).

{fabrik view=details id=91 rowid=66}

I have tried sooo many combinations to try and get this to work. (The rowid and table ID are the same coincidentally). I've made sure the joins are present (Main -> visit).

{fabrik view=details id=91 rowid={rowid}}
{fabrik view=details id=91 rowid=[rowid]}
{fabrik view=details id=91 rowid='{rowid}'}
{fabrik view=details id=91 rowid=visit___fk_visit_main}
{fabrik view=details id=91 rowid=visit___fk_visit_main_raw}
{fabrik view=details id=91 rowid={visit___fk_visit_main_raw}}
{fabrik view=details id=91 rowid=[param1]}
{fabrik view=details id=91 rowid=main___id

I'm sure this is a really easy fix, and most of those bits of code are wrong.

 

[cheesegrits]

OK, the problem is that the content plugin code is entirely self contained, it's a J! content plugin, which knows nothing about where it's being inserted - which could be an a J! article, or a Fabrik form intro, or a J! html module, or anything.

Are you using the related data feature to bring up the list?

-- hugh

 

[nrsmoll]

Yep, so I use the related data link on the right hand side of the screen. I click that, and it goes to a list of my ?visits? relating to my ?main? record. In that visits list, I placed the content plugin in the introduction section.

 

[cheesegrits]

OK, try ...

{fabrik view=details id=91 rowid=[visit___fk_visit_main_raw]}

The visit___fk_visit_main_raw should be on the query string of the URL from the related data link. And in {fabrik... } content plugin strings, if you want to use a placeholder, you have to use [] rather than {}. because of the way J! content plugin handling works ... if you use {} ...

{fabrik view=details id=91 rowid={visit___fk_visit_main_raw}}

... the J! code that parses out the plugin strings will get confused, and think that the first occurence of } terminates the plugin string, and chop the actual string short. So use {} instead, then our plugin code will automagically replace those, and should pick up the query string value in our normal placeholder replacement code.

-- hugh

 

[nrsmoll]

The code you gave worked...mostly

{fabrik view=details id=91 rowid=[visit___fk_visit_main_raw]}

It worked on one patient only for some reason (on record 66). Its weird, because the URLs seem to be accurate, and the ID's seem right. In fact, record 66 is the only one it worked on, and record 69, which is a test record that I created this morning. Effectively, I suspect that it doesn't work for old records. Is this the way it is supposed to be?

 

[cheesegrits]

OK, that's because you are using formid=91, which belongs to the "Header" list (ID 84), not the list with the related data link I presume you are arriving from (Main, ID 77). And 84 has a pre-filter on it on the user ID.

So if you try and view the details of a row that doesn't match your ID, the pre-filter is going to prevent it loading, because list pre-filters apply to ALL access to the data, not just list display, including form/details views - a list-prefilters prevents you seeing a row in the list, it prevents you see the form/details as well.

If you pointed back to the form belonging to Main, it would work, or if you used the Header list to arrive at the related data page it would work (because you wouldn't be able to see the filtered out rows in list to hit the related data link on in the first place).

So basically, it's because you are Crossing The Streams (never cross the streams!) and reflecting back to a form belonging to a different list than the one you came form, that has different pre-filters.

I tested by turning the filter off on 84 temporarily. But I turned it back on again, as I don't know if you are already exposing that list to live users.

-- hugh

 

[nrsmoll]

Geez, well done. I didn't think to look at the prefilters!

I didn't know that prefilters work on all views (forms/details/etc)

The prefilters were leftover from a function I was working on/troubleshooting in the past. I had copied list 84, and in the old list it had that prefilter in it. And since I am new to this, I have a bit of a scorched earth / try everything approach, leaving lots of debris in my path, and didn't think to check for prefilters!

 

[cheesegrits]

Yup, list filters are intended to enforce security, as well as just simply filtering the display. So with a few exceptions, all access to a lists data adds the WHERE clauses generated by the pre-filters. As you've discovered, that applies to loading form/details views. It also applies to, say, the related data counts - so if the related list has prefilters, we apply those when counting the records to show in the related data link.

One exception to this is database joins. If you join to a list, we don't apply list filters to the options the join displays in form view. This is because we're actually joining to tables, not Fabrik "Lists" (you'll note that the dropdown when setting up a join element shows you all the table names in your database, it's not showing you "Lists"), and we don't know which "List" that table belongs to (well, we can if you only have one copy of the List, but ...). So if you want to enforce the same filtering on a the join options, you have to apply them by hand in the join's WHERE filter.

One other thing to note is that pre-filters applied in a list menu item will only be applied to form/details views if the view URL has the relevant Itemid in the link. Pre-filters in menus are NOT secure in the way that native list pre-filters are, as they can be avoided by just removing the Itemid.

-- hugh

 

[nrsmoll]

Actually, I have been trying to apply a prefilter to database joins. I have given it a serious go on two occasions failed to get it to work (using the WHERE filter), so I have sat back on cascading dropdowns, which seem to work. I have not exhausted all my debugging efforts, so this is a work in progress.

 

[nrsmoll]

So it seems like to get the plugin to work on lists, the following worked:

{fabrik view=details id=91 rowid=[visit___fk_visit_main_raw]}

But to get the same plugin to work on the top of forms, the following worked:

{fabrik view=details id=91 rowid={visit___fk_visit_main_raw}}

The sole difference is that curly braces were required to work atop the forms, where square braces were required to work above lists.

 

[cheesegrits]

I can't replicate this. The square brackets work in all locations for me.

-- hugh