Problem using php variables in form eval

DickTracy

New Member
Hi
I'm creating a 'contact the owner' form for a page and trying to use eval to set the contact email address and property name (its a property listings site).

The values already exist in the page as php variables eg $thispropertyname (created through sourceror) so I can echo $thispropertyname just before the form with no problem.

But when in eval (type field) I enter:
$thisrental = $thispropertyname;
return $thisrental;

It returns a blank space.

Is it possible to use a php variable like this in eval?

Thanks
 
I think you have to set $thispropertyname as a global variable in your sourcerer code so it'll get picked up in Fabrik.
 
I tried that earlier but it didn't work.

I think recent versions of joomla treat global variables differently - I used to pass variables from articles to modules using global variables but that also doesn't work any more.
 
I use fabrik to add and edit items in a database table, then sourceror to 'include' php files using that data to present the information in articles.

These 'include' files run queries on the database table and create many variables including $thispropertyname.

So each article starts with something like {source}<?php include 'includes/information.php'; ?>{/source}, which sets up the variables for the article.
 
It's possible that the fabrik plugin is being loaded by J! before your sourcerer code is being run, although I'd have to install sourcerer and test that to know for sure.

One way to tell is just put a ...

echo "I am here";exit;

... in both your sourcerer included file, and the element default. Obviously modify the "I am here" message so you know which is which. See which one you get.

-- hugh
 
jfquestiaux, I don't know how to do that because even to run a query in eval will require a variable of some sort and I can't pass variables to a fabrik form (as far as I know)

(The form is on a holiday rentals listing site, and I want to include a 'contact the owner' form on each property that includes the property name when the form gets emailed to the property owner)

cheesegrits, I guess you are right, but even when I include the {fabrik view=form id=4} IN the sourceror code, which I would have thought forces the sourceror code to be run first, the variable is still not found.

Thanks
 
Did you actually try the "I am here" thing?

Remember that even if you put the {fabrik ...} string inside the Sourcerer code, J! is still processing that article content and running it through the content prep. So it may well still be doing the {} plugin text replacement before Sourcerer evals your code.

I may be wrong (I quite often am), but definitely worth testing before we attempt further diagnosis. First rule of debugging, eliminate the obvious first.

-- hugh
 
Cheesgrits, sorry on first reading I had misunderstood what you are asking.

I have just tried s you suggested and it exits on the sourceror code when both echo "I am here";exit; statements are present

So yes, it seems definite that it is carying out the sourceror code first.

If they were both the same type of plugin I imagine I could change the order they are carried out, but think this is not possible when fabrik is a 'content' type and sourcerer is a 'system' type ?

Cheers
 
Well, if sourcerer is definitely running first (and yes, I think system plugins are always going to run before content plugins, assuming they use a hook that runs before content is prepared), we don't need to worry about execution order.

One thing you might try instead of globals is to set session variables. So in your Sourcerer code, do something like ...

PHP:
$foo = 'whatever you do to create foo';
$session = JFactory::getSession();
$session->set('something.unique.foo', $foo);

... and then in your eval'ed code inside Fabrik, do ...

PHP:
$foo = '';
$session = JFactory::getSession();
if ($session->has('something.unique.foo')) {
    $foo = $session->get('something.unique.foo');
    $session->clear('something.unique.foo');
}
return $foo;

-- hugh
 
Oh, and obviously replace something.unique with whatever makes sense for you. Like, within Fabrik, we use things like fabrik.form.<form_id>, etc. Some unique context you can generate both when setting and getting.

-- hugh
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top