2.20.1 - Server Error when using Checkboxes in Forms

Our Facilities office has a long form for event setup requests. Recently, users trying to use the form have run into “Whoops, server issues.” messages and cannot submit.

In the debug logs, I see the following in AJAX since July 10:

25-Jul-2025 9:36:19am CDT LiveWhale Notice: /livewhale/nocache.php?livewhale=ajax&function=handleFormsSubmission&id=13&smart_cache_disabled=1 AJAX error: The server returned the status error 500. (IP / Details / Page / mischlern)

After a process of elimination, I determined that the issue are the Checkboxes form fields. If a user has any value in a Checkboxes field, the server error appears. If the Checkboxes fields are left alone, or if there are none, there are no issues.

Since the real form is limited to login only, I’ve made an test form anyone can use to demonstrate the issue: Testing Form • Beloit Web Team • Beloit College

For example, if I try to submit the form without doing anything, I get error checking messages:

However, if I try to only answer the checkbox question, I get a server error:

To my knowledge, we don’t have any client code that affects the behavior of forms other than CSS, so I suspect this may be a CMS issue.

Any input or advice is welcome.

Thanks,
Nick

A quick follow-up: had the thought to try this testing form while not logged in. It appears the behavior when not logged-in is an endless spinning gear.

I don’t see any errors in the AJAX debug for anonymous submissions, but I finally noticed the following in our Errors debug. (Was too focused on the specific form to see “Form” errors.)

25-Jul-2025 10:18:55am CDT America/Chicago PHP Fatal error: Uncaught TypeError: strpos(): Argument #1 ($haystack) must be of type string, array given in /var/www/www.beloit.edu/livewhale/core/modules/forms/public.widget.forms.php:288

That appears to be the real issue: a data type mismatch?

Thanks,
Nick

Thanks Nick – this looks like it must be an edge-case PHP 8.1 bug we didn’t catch earlier, sorry about that! Thanks for the test case, we’ll get this queued up for a core diagnosis and fix pronto.

In the short-term, I wonder if temporarily making that checkbox field optional rather than required might work as a workaround?

I believe I discovered this too when testing 2.20.2 and LW fixed it. Maybe there is already a patch?

@karl: In the actual form, all of the Checkbox fields are optional, but they ask questions that most users are going to add a value for.

  • What kinds of tables to you need? (round, square, rectangle)
  • What podium setup do you need? (simple, branded)
  • What additional power needs do you have? (some, extreme)

My alternative was to try and avoid Checkboxes in the form, but I don’t think any other option will be quite as effective.

@jwilcox: Testing on dev (2.20.2), it does appear that this issue doesn’t occur. (Why do I always forget something, like this, when trying to troubleshoot.)


Guess I need to consider doing the upgrade to 2.20.2?

Ah, good memory, thanks Jon.

@mischlern The 2.20.2 upgrade would fix this, yes. Otherwise you can reach out to Request Help (so we have permission to SFTP in) and we can probably patch in a quick fix for you gratis. We aren’t able to back-patch every bug fix to prior versions, but I suspect this one is just a one-liner that would be easy enough to patch.

Cheers,
Karl

I’ll try to do both, given Facilities would like this fixed now, and the upgrade would take me some time to plan and communicate. Thanks, both of you.


@karl A slight aside: I’ve also seen a few other error messages that may be PHP 8.1 related, but aren’t causing obvious issues, like:

Trying to access array offset on value of type int in public.data.widgets.php on line 4772

Would you like for me to share what I’m seeing, or are do you feel like you’re already on top of these things?

A quick temporary fix might be to replace the checkboxes with a multi-select box.