Hi @taohi,
Thanks for this, and glad 3.6.5 went in cleanly. Your list of what you depend on was the useful part, so here is a straight answer to it.
Those classes are not internals. mwai_functions_list is the documented filter, and the array it expects back is an array of Meow_MWAI_Query_Function. That is the API, I just never said so clearly. For what it is worth, its constructor has had no breaking change since June 2025 and everything added since has been additive. One tip: build your tools with Meow_MWAI_Query_Function::fromJson(), which takes a plain array, so a newly added argument can never shift your call.
One distinction worth making: the global $mwai is Meow_MWAI_API, the public facade, and it is safe to build on. $mwai_core is internal and carries no promise. If something is only reachable through it today, tell me which method and I will expose an equivalent.
You also found a real bug. mwai_mcp_callback was fired with five arguments over MCP but only four from the Workspace, so a handler registered for that fifth argument died with an ArgumentCountError as soon as the same tool ran in the Workspace. Fixed in 3.6.6, both paths now pass five. Thank you, that would not have surfaced without your list.
On your four requests, yes to all of them. I will state the supported surface explicitly, keep a working compatibility path for at least twelve months on anything in it, and flag developer-facing changes in the changelog rather than folding them into a general line.
The developer docs are at https://ai.thehiddendocs.com/ and the filters page is getting the missing MCP filters plus one correction: the second argument of mwai_chatbot_reply is the Reply object, not the query. Worth checking your handler if you wrote it from that page.
Cheers,
Jordy.
Thread Starter
taohi
(@taohi)
Re: AI Engine Pro — dependency list / 3.6.6
Hi Jordy,
3.6.6 is on production, clean install, no issues. PHP was already 8.3 so the new minimum was a non-event.
The one thing you asked for. There is exactly one method we can only reach through $mwai_core:
$mwai_core->discussions->get_discussion( $botId, $chatId )
We use it to read a stored discussion's messages by chatId. The case: our chatbot suppresses a repeated greeting, but when the widget re-initialises the request arrives with an empty in-memory history, so the handler would wrongly conclude "new chat" and greet a second time. Reading the stored discussion is what closes that gap. We only need the messages array — a read, never a write.
Worth noting that the facade already holds the module: Meow_MWAI_API has private $discussions_module and calls the exact same get_discussion( $botId, $params['chatId'] ) internally at classes/api.php:809. So what's missing is only the public accessor, not the capability. A getDiscussion( $botId, $chatId ) on the facade would cover us completely and we would drop the $mwai_core reference the same day.
On the MCP callback. Glad it was useful. For the record, we were never hit by it ourselves — we register with accepted_args = 4 and our handler takes four, so WordPress only ever passed four. I found it by diffing the two apply_filters() call sites while checking whether 3.6.6 was safe for us. I verified the fix in the 3.6.6 zip: both paths now pass five and the fifth argument is appended, so positions 1–4 are untouched. Nothing to change on our side.
On mwai_chatbot_reply. Thanks for flagging the doc error. We checked — our handler already treats the second argument as the Reply object and goes through $reply->query, so we were fine by luck rather than by the docs. The correction is still worth making; someone writing a new handler from that page would get it wrong silently, since a wrong assumption there degrades behaviour rather than throwing.
On fromJson(). Noted, though it doesn't apply to us yet — we don't go through mwai_functions_list at all, our tools are attached to the query directly via a mwai_chatbot_query handler. If that ever changes we'll build them with fromJson().
The commitments on the supported surface, the twelve-month compatibility path and the separate changelog lines are exactly what we needed. That turns "will this update break our 290 KB integration" from a research project into a changelog read. Thank you.
Cheers,
Klaus
I am adding getDiscussion( $botId, $chatId ) to the Meow_MWAI_API for the next release. It returns the stored discussion with the messages array decoded, or null if the chatId has no history yet, so your greeting/suppression case is covered. The documentation will also be fixed
The mwai_chatbot_reply documentation is being corrected. You are right that it is the worst kind of doc error, since a wrong assumption there quietly degrades behaviour instead of throwing. Thanks for your feedback, always!
