PHP errors after using ee('Variables/Parser')->extractVariables()
Developer Preview
For one of my add-ons (low_reorder:entries), I allow the variables to be prefixed. In EE3, I used ee()->functions->assign_variables() to re-assign variables, with success. With the EE4 method, I’m getting errors. For reference, this is the code I’m now using:
$vars = ee4()
? ee('Variables/Parser')->extractVariables(ee()->TMPL->tagdata)
: ee()->functions->assign_variables(ee()->TMPL->tagdata);
ee()->TMPL->var_single = $vars['var_single'];
ee()->TMPL->var_pair = $vars['var_pair'];
This code works OK for EE3, but generates a bunch of these errors in EE4:
Notice
Undefined property: Text_ft::$row
ee/legacy/fieldtypes/EE_Fieldtype.php, line 177
Severity: E_NOTICE
Warning
array_key_exists() expects parameter 2 to be array, null given
ee/legacy/fieldtypes/EE_Fieldtype.php, line 177
Severity: E_WARNING
Thanks Low, do you have a sample of tagdata that’s generating those errors for you?
Something like this:
<li>
{entry_id}: <a href="{url_title_path=">{foo_title}</a> ({status})
{foo_categories backspace="1"}{foo_category_name}, {/foo_categories}
</li>
Where foo_ is the prefix I’m stripping out, then reassigning the vars. The var pair seems to be the culprit here.
Ok I’m not getting those errors, having a hard time seeing where it would come in. I’m testing _remove_var_prefix() from Low Reorder 2.2.1 (my copy is way out of date), on a simple plugin and it seems to be working fine. Can you share a var_dump($vars); that you get from that operation before replacing the Template lib’s vars?
Here’s a print_r:
Array
(
[var_single] => Array
(
[entry_id] => entry_id
[url_title_path="services/people-management"] => url_title_path="services/people-management"
[title] => title
[status] => status
[category_name] => category_name
)
[var_pair] => Array
(
[categories backspace="1"] => Array
(
[backspace] => 1
)
)
)
Ok, your array looks fine. I was able to replicate though, had to pass things off to the Channel module like Low Reorder does, but I’ve got a replicable case now, thanks Low!
Looks like the issue was with unmodified category metadata fields, extractVariables() was a red herring. Modified metadata fields (`{category_name:url_encode}’) are treated like a Text fieldtype so they can be parsed. Unmodified shouldn’t have been sent through there, but were, resulting in the fieldtype class looking for properties that aren’t to be found. Should have this patched up in the next build, thanks Low!