Trigger Manager - "expects parameter 1 to be string, array given"

Squiz Matrix Support
1

Dear Reader,


On our version 3.28.0, with the Trigger Manager, attempting to create a new child, or to aquire a lock on an existing trigger generates 18 "PHP Warnings":

[quote]PHP Warning

File: [SYSTEM_ROOT]_3.28.0/core/lib/html_form/html_form.inc Line: 433

Message: htmlspecialchars() expects parameter 1 to be string, array given

Backtrace: Show[/quote]

and on the Trigger | Details screen, under "Events", instead of displaying 27 checkboxes each with an event name, it diplays the 27 checkboxes each with the word "Array"



Do you know, or can you suggest what might have gone wrong?



Any help you can give will be greatly appreciated.



regards

Polonius

2

Hi,
Were there any errors while running installation steps?? what version are you on?

I am pretty sure running step_02.php, compile_local.php, step_03.php, compile_local.php scripts will fix this.



Regards,



Ash

3

Thank you Ash.
We'll try those scripts and let you know how we go.

regards

Polonius

4

Just outta curiosity, is it a FRESH install or was there any new code added ?
You are welcome.



Cheers,



Ash

5

We have tried those steps, but the problem remains.


We upgraded from V3.26.0 progressively to V3.26.1 through V3.26.2 to V3.26.3 and to V3.26.4, following the steps per the upgrade instructions, then from V3.26.4. to V3.28.0.

There were no errors during the upgrades.

Instead of overwriting the existing code we put the new source code in a new directory, and renamed the directories.



But we have discoverd the the problem is not only with the Trigger Manager, it also applies to the Paint Layout.



On Paint Layout, acquiring a lock fails to populate the combo box “Add Custom Asset Type” on the Paint Layout Details Screen.



Here are the first few lines of the backtrace:

    0 => array (

“function” => “sq_error_handler”,

“args” => array (

0 => 2,

1 => “htmlspecialchars() expects parameter 1 to be string, array given”,

2 => “[SYSTEM_ROOT]_3.28.0/core/lib/html_form/html_form.inc”,

3 => 433,

4 => array (

[Max Depth Reached]

)

)

),

1 => array (

“file” => “[SYSTEM_ROOT]_3.28.0/core/lib/html_form/html_form.inc”,

“line” => 433,

“function” => “htmlspecialchars”,

“args” => array (

0 => array (

[Max Depth Reached]

)

)

),

2 => array (

“file” => “[SYSTEM_ROOT]_3.28.0/core/assets/paint_layout/paint_layout_page/paint_layout_page_edit_fns.inc”,

“line” => 191,

“function” => “combo_box”,

“args” => array (

0 => “paint_layout_page_449_new_type”,

1 => array (

[Max Depth Reached]

),

2 => ,

3 => “”

)

),

3 => array (

“file” => “[SYSTEM_ROOT]_3.28.0/core/include/asset_edit_interface.inc”,

“line” => 1110,

“function” => “paintAddAssetType”,

“class” => “Paint_Layout_Page_Edit_Fns”,

“object” => new Paint_Layout_Page_Edit_Fns Object (

“static_screens” => array (

[Max Depth Reached]

),

“_tmp” => array (

[Max Depth Reached]

)

),

“type” => “->”,

“args” => array (

0 => new Paint_Layout_Page Object (

[Max Depth Reached]

),

1 => new Backend_Outputter Object (

[Max Depth Reached]

),

2 => “paint_layout_page_449”

)

),




Any help you can give will be greatly appreciated.



Thanks

Polonius
6

Hi,
I had a look and this really surprises me. The end class it is complaining about seems to be working fine. Was it working fine on any of the 3.26.X version ? Or rather what was the version you had previously that it was working fine on ?



cheers

7

Hi,
Yes, it was working on V3.26.0

Polonius

8

[quote]
Hi,

Yes, it was working on V3.26.0

Polonius

[/quote]



To be honest i cannot possibly see a reason for these error messages. If you are Squiz Client, I would suggest that you file a support ticket for it.



Regards,



Ash

9

Resolved.


We didn't find ot what was wrong, but the problem was solved by installing V3.28.1. Then we migrated the old database to the new installation, following the upgrade instructions.



Thanks for your help

Polonius.

10

I've seen this before, and actually ran into it again today. I didn't get a chance to fully debug it, but I discovered that this probably occurs when step_03.php does not finish correctly.


More specifically, step_03.php calls uninstall_asset_types() at the very beginning. It then loops over all the files and installs all the types again. In between the point where it removes them and then installs them all again, anything in the system thats getting a list of installed types seems to just return "Array".



I bumped into this on a system that was taking a long time to run step_03.php, and reproduced it by putting in a pause just after the uninstall_asset_types() call.



So anyone else who comes across this again, make sure your step_03.php finishes normally (meaning it should finish with "ASSET TYPES CACHED").