Been trialling this new plugin which is really useful, but it does seem to be causing some saving issues on resources. The saving is looping and just hanging. The changes are saved if you refresh the page but not ideal.
If I disable the plugin saving works as expected.
This is on MODX 3.0.2 and 3.1.2 with PHP 8.3.
I really love the idea of having AI to assist so would be good to get this resolved.
Hi Helen,
I haven’t had the pleasure to play with it, yet.
But I can try to assist you with debugging/hunting the issue.
Normally when such issues happen, you get some information in the developer-tools.
Go edit a page in your setup. Before you press save, open the dev-tools (F12, or CTRL+SHIFT+I). Now press save.
You either can see a Javascript-Error in the tab “Console”, or you see a red line request in the network-tab. If there is a red request, click on it (a side panel opens), and now press on the sub-tab “answer” (or response), and copy the body of the response.
Copy your findings here. Good luck!
I’ve done as suggested and these are the errors I have received:
typRequest URL:
https://www.website.com/connectors/index.php
Request Method:
POST
Status Code:
500 Internal Server Error
Remote Address:
213.129.84.97:443
Referrer Policy:
strict-origin-when-cross-origine or paste code here
And also:
{message: 'JsonReader.read: Json object not found'}
message
:
"JsonReader.read: Json object not found"
[[Prototype]]
:
Object
read @ ext-all.js:21
handleResponse @ utilities.js?mv=312pl:409
processResponse @ ext-all.js:21
success @ ext-all.js:21
n @ ext-all.js:21
t @ ext-all.js:21
A @ ext-all.js:21
It could be a conflict with another plugin / extra too. Does the above help?
Hi again,
so the first message is from the network-tab, and the second from the console-tab. We are getting closer. And yes, I’m assuming from the beginning, that it has to do with another extra, or something else.
Now do that process again, and then after saving, click on the red request (/connectors/index.php) again. You have shown me the information from the first sub-tab (“Headers”):
But we want to know, what the system is nagging about, and that is in the sub-tab “Preview” (and/or “Response”):
It should say “success: false” and have an error-message. Or it shows a long error-message directly. Copy everything there and paste it here again.
OK here you go - Response Headers
HTTP/2 500
x-powered-by: PHP/8.3.19
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
content-encoding: gzip
vary: Accept-Encoding,User-Agent
set-cookie: PHPSESSID=sfhs91bp330jeuuom7p47o3219; path=/; HttpOnly
cache-control: max-age=1, private, must-revalidate
content-type: text/html; charset=UTF-8
date: Wed, 23 Apr 2025 14:06:34 GMT
server: Apache
X-Firefox-Spdy: h2
I have tried different browsers to see if that makes a difference, but no joy.
Hi Helen, you misunderstood 
We don’t care about the Headers (also not the Response Headers).
We want to know, what the script is responding.
Please do the process again, press on the red request,
and then press on the response-tab:
The side-panel that opens, when you click on a request, has its own tabs (“sub-tabs”).
Indeed looking at the response there might give us a helpful error message.
The only thing that AIKit currently does on save is index resources into the Pinecone vector database if that’s configured, so I’m guessing it’s going to be tied in with that. Are you using that?
(If you’re not, it’s totally possible that not having it set up causes it to break… this is a very early proof of concept project.)
aikit.vector_database and aikit.pinecone_ system settings would be relevant as well.
I have checked the Response and actually there is nothing returned.
And I haven’t configured a Pinecone vector database. This would be a new step for me to do.
This was in the timings
Okay, now I would try to activate the debug-mode, and do the same things again, hoping that the system gives us some more info.
To activate the debug-mode, go to the system-settings, press the “reset filter/search” button (just in case), and then search for “debug” (yellow line in screenshot):
Set that value to “1” (without the quotes).
After that, the cache should clear itself. You can do the test-saving again, and hopefully this time, the system tells us where it hurts.
Also, after doing that and checking the response, look into the error-log (located at wwwebsite.com/manager/?a=system/event ), does it have additional errors?
Be aware here, that after activating the debug-mode, the error-log could fill up with a lot of “notices” and/or “warnings” - these are most of the time totally ignorable. We really are just interested in anything in the log that says “ERROR”.
Hi @sebastian-marinescu I followed your instructions and put the debug mode to 1 and then did a save, but sadly no other error messages.
Hmmmmmmmmm, okay - no problem, we’ll find the problem eventually
Next I would force the “/connectors/index.php” to display errors. That means, in your preferred way (ssh / ftp), go and edit the file “/connectors/index.php”. At the top, before any other code runs, add the following:
$errorType = 'connectors';
$errorPath = dirname($_SERVER["DOCUMENT_ROOT"], 1) . 'php-error-' . $errorType . '.log';
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
ini_set('log_errors', 1);
ini_set('error_log', $errorPath);
error_reporting(E_ALL ^ (E_NOTICE | E_WARNING | E_DEPRECATED));
So it should look something like this:
Save the file, and do the saving-test again with checking the request’s response in the developer-tools, and checking MODX’s error-log.
Be aware: If you are testing all that on a production-site, then I’d recommend removing or commenting out the new code you added, and also disabling the debug-mode again, after you finished your save-test.
Side-Notes:
php-error-connectors.log