Calc element not using correct placeholder

[cheesegrits]

Yes, the calc gets eval'ed multiple times on submission. That's not a surprise, as it gets run a a result of the element's getValue() method (which calls _getV(), which does the actual eval), which is called in multiple places - the preProcess phase, validation, final database store formatting, then potentially in things like getEmailValue() during onAfterProcess hooks (like email plugin).

I could experiment with putting caching in there, in _getV(), although if I recall correctly we used to do that, and it caused problems. But I can't offhand remember what the problem was. But probably worth trying again, as this was quite some time ago, and we may have resolved whatever wrinkle it was that was that caching was clashing with.

However, in all of my testing, the raw and non-raw values for a read-only join placeholder are what I would expect at each run through _getV().

-- hugh

 

[troester]

From your 1st post: "and the calc element is set to only calc on save."
You could use a form php plugin in this case setting a non-editable field element.

 

[Bauer]

I guess that's my only solution. I've been at it all day and got nowhere.

I know that a 'swapValuesForLabels' function call is what causes the raw value to get set to the label initially. I have no idea what that's all about. I thought that maybe something works differently in PHP7 where synchronous tasks are being run and stepping on the other plugins? I also have another calc element in that same form. But I unpubished it and the problem still exists.

What made me finally give up was turning on Joomla debug, which triggered the fabrik debugger, and slowed things to a snail's pace until I finally ran out of memory on the server. Then the next time I tried, the Chrome browser froze and I had to use the task manager to kill it.

Just some FYI on what was in the fabrik.log.php - over 5000 lines of warnings - just from logging in and using 2 menu pages - mostly repeats of these...

WARNING deprecated Accessing JVersion data through class member variables is deprecated, use the corresponding constant instead.
WARNING deprecated JDispatcher is deprecated. Use JEventDispatcher instead.
WARNING deprecated JFile::read is deprecated. Use native file_get_contents() syntax.
WARNING deprecated JLayoutFile::setLayout() is deprecated, use JLayoutFile::setLayoutId() instead.
WARNING deprecated JLayoutFile::refreshIncludePaths() is deprecated, use JLayoutFile::clearIncludePaths() instead.
WARNING deprecated Accessing JVersion data through class member variables is deprecated, use the corresponding constant instead.
WARNING deprecated JHtml::getJSObject is deprecated. Use json_encode instead.

I don't know, but I'm now sorry I ever 'upgraded' to PHP7 - even though it is noticeably faster.

Things like this just drive me crazy because I stubbornly think I can figure it out. But I've been looking at that calc code on and off for what, 3 years now, and have yet to get 'the big picture' on how it works. I think that part of the problem, from what I gather anyhow, is the way it works with the entire group data array rather than just worrying about each calc element one at a time. Why is it that for all the other fabrik element plugins (I have dabbled with), $data is just the data for the element being processed - but here the $data array works with the entire list (most of the time). There just seems to be a lot of 'extra work' in that code, looping through all the elements, that you wouldn't think necessary.

I need a vacation.

 

[cheesegrits]

I've never seen swapValuesForLabels() modify the raw. No clue what's going on there.

Don't feel bad about not having the "big picture". I've been working on this for close to 10 years, and I don't either.

Just use a form plugin.

-- hugh

 

[Bauer]

Do you think it has anything to do with the use of functions in that 'Deprecated' list of warnings that show in the fabrik.log.php file (that I included above)?

 

[troester]

"Deprecated" shouldn't hurt, it's only a notice (although any notice may break expected JSON strings etc...)

News:
I've installed a PHP7 server - and now I can see the "label" in the first log entry (1st of 3 logs/runs during form Save)
But the "calc run" used for returning and storing the calculation is correct.

So the problem is that the result of the 1st run isn't really "used" but the calc is breaking because of the wrong MySQL query.
I think in your case you could work around by quoting the id.
But in principle:
Why is it getting the label "on the 1st run" in PHP7?
Are there other situations where a calc may create different results?

I think a calc element can't be used for "doing" anything (beside returning a string) because it can be run on load, on list load, ajax... additionally to those multiple "onSave" runs (imagine an INSERT instead of the log)

 

[rob]

btw the log is from the entire system not necessarily from fabrik code

 

[cheesegrits]

I think a calc element can't be used for "doing" anything (beside returning a string) because it can be run on load, on list load, ajax... additionally to those multiple "onSave" runs (imagine an INSERT instead of the log)

Correct. We should maybe make this clearer, explicitly say that in the wiki. But the calc was only ever designed for returning a value, not for "side effects" ("doing" anything).

For "doing things", submission plugins should be used.

I'll install PHP7 as some point, figure out why it has that effect. Rob is starting a develop branch in github which will become Fabrik 4.0, which will be our first "official" PHP7 compatible version, along with a lot of name space improvements, getting rid of deprecated J! calls, removing all our old J! 2.5 legacy code, etc.

-- hugh

 

[cheesegrits]

I've added this to the wiki for the calc ...

IMPORTANT NOTE(top)

The calc element should only be used to return a value. It should not be used to "do things", like update database tables. If you need to do "stuff" other than just return a value for the element, you should use a PHP form submission plugin.

 

[Bauer]

btw the log is from the entire system not necessarily from fabrik code

That explains the length. It almost seems like overkill that the Joomla debugger has to be running b4 the Fabrik debugger will. (Slows things to a snail-pace.) But I guess I understand.

...and, Welcome back! Hope you had a nice refreshing vacation with the family!

 

[Bauer]

I've added this to the wiki for the calc ...

IMPORTANT NOTE(top)

The calc element should only be used to return a value. It should not be used to "do things", like update database tables. If you need to do "stuff" other than just return a value for the element, you should use a PHP form submission plugin.

So I'm finding that out the hard way.
But IMO, maybe a 'phpEval' element plugin would be a good idea? So long as the eval() code only gets run once when the element is 'prerendered' - and then stored to both the value and the raw value at that time - what would it hurt?

 

[cheesegrits]

If you wanna write it, I'm all for it.

-- hugh

 

[Bauer]

"Deprecated" shouldn't hurt, it's only a notice (although any notice may break expected JSON strings etc...)
[...]

Thanks for all that, troester.
It seems like php7 is more sensitive to those types of errors - and more things will break because of them than used to under v5.6.
The post I just made regarding the Yes/No plugin is an example. I used to get that error - but I'm pretty sure the code still continued. Now, (w/php7 ?) it's freezing the ajax.

 

[cheesegrits]

To be honest, you'd be better off dropping back to 5.6 and waiting for the 4.0 Fabrik release to use PHP 7. We're actually putting in significant effort to make 4.0 full 7 compliant. Until then it's "some effort".

Sent from my HTC One using Tapatalk

 

[Bauer]

Well I wasted an entire day trying to use the php plugins to do what the calc elements were doing. But it's not as easy as it sounds. The calc plugin already takes care of WHEN to do the calculation. If you use php plugins, you have to create multiple instances of the same code (in both the list and the form) to "cover the bases" that the calc element covers.

With a fresh mind this morning, it looks like I have it working again using the calc elements.
The key seemed to be to just use the $data array (which is already set when the calc is eval'd) - and forget about using placeholders.
For some reason, the data array never has the label and raw data mixed up.

However, what was happening - and I discovered this 3 years ago - is that sometimes the '$data' value for the element referenced is an array, and sometimes it is a string.
So for any instances where I was referencing an element with a placeholder, I changed it to use $data instead - and also check whether it was an array or not.
e.g. When initializing the variable I wanted to use in the calc code, I changed...

$ftid = '{fb_member_facilities___facilitytype_id_raw||0}';

to

$ftid = is_array($data['fb_member_facilities___facilitytype_id_raw'] ) ? $data['fb_member_facilities___facilitytype_id_raw'][0] : $data['fb_member_facilities___facilitytype_id_raw'];

And remarkably, all is well!

I'm not going back to php5 unless I really come across something I can't overcome.
I'm just a stubborn old mule and am accustomed to trying new code and staying 'on the cutting edge' of developments. That's just who I am. While it would be nice to get this project into production once and for all, there are numerous other things that the client needs to do on her end of the deal. So I probably have a month or so where I can experiment with php7 and help you out, by identifying the issues you might not be aware of, at the same time. I don't mind helping you guys find the problems with php7 - no matter how grumpy or ornery I get about it. I'll put up with the Fabrik imperfections so long as you folks can put up with mine.

 

[cheesegrits]

Yes, things like join elements will typically be arrays on submission, and strings on display, iirc.

I just use that is_array() test by reflex when dealing with anything which uses the elementlist model (dropdowns, joins, etc).

Up to you on the PHP7 thing, but I haven't even installed it yet. Need to get our current github back to a solid state, after the Great Modal Merge of Ought Sixteen, before I introduce any more variables. When Rob gets back, I'll be setting up a PHP7 test setup, with the new 'develop' branch where we'll be working on that. It's up on github if you are interested. Large commit to it yesterday, changing all our helpers and plugins to use namespacing.

-- hugh

 

[Bauer]

Just when I get one thing settled - I have to deal with another 'new' thing. I realize this is all just 'the nature of the beast' - and I just expressed my pride in always being 'on the cutting edge' - but that still doesn't stop me from b*ing about it!

I'm just 'cleaning up' the project and installing all the updates for other extensions. Then I'll do a backup and install from github.