Using Joomla table prefix in placeholders

[DeeEmm]

Hi,

I am using the Joomla prefix for all of my fabrik database tables as I have multiple identical Joomla instances in a single database.

My issue is this:

I am trying to reference a value using the calc plugin, If I use the full prefix within the placeholder the value is retrieved. However, if I try to replace the prefix with the standard Joomla prefix '#__' the value is not retrieved.

Here is my code - this works:

return "<img src='/media/calc/{iugb3_crm_deals___stage}.jpg'>";

This does not work:

return "<img src='/media/calc/{#__crm_deals___stage}.jpg'>";

How can I reference the Joomla table prefix dynamically?

TIA

/DM

 

[cheesegrits]

Hmmm. At the moment, you can't. We would have to modify our placeholder code to understand the #__ concept.

Which sounds like a reasonable thing to do, so I'll have a look at doing that right now.

-- hugh

 

[cheesegrits]

OK, that should be in github now.

-- hugh

 

[DeeEmm]

Bloody awesome.

Only issue is that it does not appear to be working for me

I also have a funny issue. Tried to capture the value of $match being returned by writing to the error_log but it doesn't write anything. Weird!!

Therefore, not sure if it's not working or if I have some other issue preventing it from working.

Any suggestions?

 

[cheesegrits]

Well, I have to confess I didn't actually try it, which may reduce the awesomeness.

Testing now.

-- hugh

 

[cheesegrits]

Seems to work for me.

What does your calc actually return? Is the placeholder replaced with blank space, or with the placeholder unchanged?

-- hugh

 

[DeeEmm]

The placeholder is replaced with a null value (nothing).

The calculation I am using is:

return"<img src='/media/calc/{#__crm_deals___stage}.jpg'>";

and it is retuning

<img src="/media/calc/.jpg">

Could the extra underscore in my table names be causing this issue?

 

[cheesegrits]

Nope, as you can see from the code around line 755 in the parent.php helper, I'm doing:

		$config = JFactory::getConfig();
		$prefix = $config->get('dbprefix');
		$match = str_replace('#__', $prefix, $match);

Which should just replace #__ with the dbprefix, regardless. I should really use a preg_replace() and pin the search pattern to the start of the string, but if someone puts #__ in the middle of a placeholder, well, it'll get replaced. And str_replace is a lot quicker than a preg_replace(), and this is code we execute a lot.

Can you try this. Right after those lines, put this:

if (strstr($orig, '#__')) {
   var_dump($orig, $match, $this->_searchData);exit;
}

... and either load or submit your form (depending whether you do 'Calc on Save Only' or not).

Your browser should then just show an otherwise blank page, with that output on it. Paste the output here.

-- hugh

 

[DeeEmm]

Sorry, posted a reply but it didn't submit. damn timeouts.

The code returns nothing - i.e. it just returns the normal page. I've also tested this on my local server with the same results. I've even tried adding an echo'foo';exit; statement - this also returns nothing.

It looks like replaceWithFormData is not getting called.

Any ideas?

/DM

 

[cheesegrits]

At all? Period? So you can just go about Fabrik business as usual, and it never breaks, even with an 'exit' NOT inside that test to see if the match has a #__ in it?

-- hugh

 

[DeeEmm]

Yes. it is very bizarre. This is what I was experiencing with the error_log statement - nothing was getting printed to the log. I wanted to also test it on my local server just to make sure it wasn't something weird going on with the wildcard subdomain setup that I have on the production server. And it's the same in both cases, it appears that the method is not getting called. The file is definitely being included as if I introduce a syntax error the page fault on refresh with a 500 error.

I'm at a loss to understand why / what is happening.

Happy to give you access if you want to have a poke around.

/DM

 

[cheesegrits]

That is indeed most bizarre.

Can you test it in some other context? Anything other than the calc element that uses placeholders. Take your pick. I dunno, maybe the 'email to' on a form email plugin.

-- hugh

 

[cheesegrits]

What is weird is, if that {#__foo} placeholder is getting replaced with an empty string, then that means the placeholder code ran, called by something which set the $keepPlaceHoders arg to false, in the call to parseMessageForPlaceholders().

And even if for some strange reason there was no posted form data being supplied, the preg_replace_callback(), line 603 in the parent.php, will still run if the $msg has {anything} in it (which doesn't contain spaces), and and your 'exit' should happen.

And as I said, it works for me.

BTW, one thing that just occured to me is that even if you have the calc set to "Calc on Save Only" set to No, so in theory we re-calc every time it is displayed, it probably won't get re-calc'ed if you have J! caching enabled, because then there is an odds on chance the page is just being served up out of J!'s cache, and never going through our list / form rendering.

Hmmmmmm.

-- hugh

 

[cheesegrits]

Although even then, the code should still run on form submit.

But you could test this theory, by setting "Disable caching" on your List's advanced settings, which should force us to ignore J!'s cache and render the page anew every time.

-- hugh

 

[cheesegrits]

BTW, just in case, I checked and all flavors of regex, including all possible flavors used by PHP, count # as a word character.

I checked on that, on the remote possibility that your flavor of PHP is using a regex which considers # to be a space character, which would mean that ...

		$msg = preg_replace_callback("/{[^}\s]+}/i", array($this, 'replaceWithFormData'), $msg);

... wouldn't fire for {#__foo}, if it considered # to be a space character, as per the \s shorthand.

-- hugh

 

[DeeEmm]

Okay so finally managed to get some time to take a quick look at this.

Caching is off for Joomla but I could not see where to check for Fabrik. However all changes made to other elements seem to instantly propagate so I will assume that it is also off.

One (unrelated) thing that I noticed is that if I check the 'add to page title' checkbox under the publishing tab it appends the un parsed calculation to the title.

If I set the calc field to use the actual database prefix I found that I could detect the placeholder within the following methods... replaceRequest & replaceWithUserData however, it did not appear in the replaceWithFormData or parseMessageForPlaceHolder methods as I would have expected.

Additionally if I add the code to replace the prefix within the replaceWithUserData method it works. It does not work however if I place the code within the replaceRequest method.

I'm pretty sure that whilst the placeholders are being passed to the replaceWithUserData method it is not the correct place to place the code. So whilst it is now possible to get this working on my site in this manner, I doubt that this is the preferred way to achieve it.

Not sure that this additional info is of any help, give me a shout if I can try anything else for you. Still keen to get this working properly on my site.

As far as testing with other placeholders, currently there are none setup. I will try to set some time aside to create a test using some other placeholders.

/DM