Mark Jansen
Forum Replies Created
-
Hello Seb,
Assuming that your webserver runs Apache or a reverse proxy, you should really use (s)FTP or SSH to alter the
.htaccessfile. If.htaccesscan not be found, you might be running on an NGINX server, which doesn’t use.htaccessI am afraid there is not a lot of more I can do from my side. You’ll either have to wait for a response from OVH or maybe try your website on another host if you can.
Hi,
yes, the .htaccess line is safe to try. It only passes the Authorization header on to WordPress and changes nothing else. Add it above the “# BEGIN WordPress” line, then disconnect and reconnect Albert in Claude. If you get a 500 error, remove the line and the site will be back to normal straight away.
Thanks for testing and reporting this @businessbloomer .
The cause was in Albert, not your host. Because SiteGround answers everything under /.well-known/ itself, Claude Code falls back to a second address,
/wp-json/albert/v1/oauth/.well-known/openid-configuration, and that one did reach Albert. But Claude Code checks that response more strictly than the standard requires, and it expects two fields (subject_types_supportedandid_token_signing_alg_values_supported) that Albert didn’t include. Claude Code rejected the response and fell back to a /register address that doesn’t exist, hence the 404.I have sent you a snippet to temporary adds those two fields via an mu-plugin.
The proper fix will ship in the next Albert update, after which you can remove the snippet.
Hi Sébastien, thanks for the thorough test. Your logs point to the real cause, and I owe you a correction: this is not about /index.php/, and the beta doesn’t fix your problem (it fixes a different one). Sorry for the detour.
Your server removes the Authorization header before WordPress sees it. That header carries the sign-in token, so every request Claude makes after signing in arrives without it and is refused. That’s the log line you found (“OAuth Bearer token required”), and it’s why Site Health reports the header as missing. I confirmed it from outside: a request with a token reaches your site without one.
The cleanest fix is on OVH’s side. You could ask their support:
“Please pass the HTTP Authorization header through to PHP for my WordPress site (for example with CGIPassAuth On). WordPress Site Health reports that the Authorization header is missing.”
If you’d rather try it yourself first, you can add these lines to your
.htaccessfile, above the # BEGIN WordPress line:SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1Download a copy of the file first, and make sure you can edit it through SSH, FTP or OVH’s file manager. If your site shows an error 500 afterwards, remove the lines again: it means OVH doesn’t allow this rule, and support will need to do it.
Either way, Tools → Site Health should then show “The Authorization header is working as expected”. Once it does, remove the STELORA connector in Claude, add it again, and the tools should appear. You can stay on the beta or go back to
1.4.2, it makes no difference for thisI have found something. It comes down to the MCP adapter default server not registering the 3 tools when index.php is used.
I have created a fix for this in Albert, to circumvent this.
I would ask you to download the 1.4.3 beta release I created and test this please. If this works for you, I will release it to the repository. You can download the zip file here. Go to plugins > add plugins > upload plugin. Select the downloaded zip file there and it will replace the current version of Albert you have. If 1.4.3 is later released in the plugin repository, it will auto update.
Let me try to reproduce this. I’ll get back to you asap
- This reply was modified 1 week, 6 days ago by Mark Jansen.
Hello Seb,
thanks for the detailed report again. Good to see connecting itself did work now and it rules out OAuth, which helps.
First, a quick check. Albert doesn’t list each ability as its own tool. Your assistant gets three tools: discover-abilities, get-ability-info and execute-ability, and finds the abilities you’ve enabled (Find Pages, Update Page and so on) through those. This is how the WordPress MCP Adapter works.
Can you ask your assistant
“What abilities do I have available for this website?”
If none are listed or you still get the message no tools are available, please check if the three base tools are listed.
In Claude, go to Settings → Connectors and click your Albert connector. In ChatGPT, go to Settings → Apps & Connectors and click it. Either way, you should see a list of the tools it provides. Are discover-abilities, get-ability-info and execute-ability listed there?
1.4.2 is released, which should fix your issue. Would be great if you can let me know how it worked out.
Hello Seb,
Thanks for trying out Albert and bringing this issue to my attention
It appears this is a bug in Albert, not in your setup. Your site uses a permalink structure with /index.php/ in it, so the REST API only answers at
https://stelora.fr/index.php/wp-json/….Albert builds its OAuth discovery URLs with a plain/wp-json/path, without the/index.php/part. Those URLs return a 404 on your site. ChatGPT can’t find the sign-in configuration, so it falls back to guessing, and that’s where the 404s in your logs come from.I’ll push out a fix in Albert 1.4.2 later today, so Albert follows your permalink structure.
If you want to connect before then, you can do it without editing .htaccess yourself:
- Go to Settings → Permalinks, choose “Post name” and click Save. WordPress then writes the rewrite rules for you. If it can’t write to .htaccess, it will show you the rules to add.
- Check a few pages on your site. Your URLs will no longer contain /index.php/. WordPress normally redirects the old addresses, but check a page or two.
- In ChatGPT, remove the connector and add it again with https://stelora.fr/wp-json/albert/v1/mcp. If you’d rather keep your current permalinks, just wait for the update. You won’t need to change anything on your side. Let me know how it goes.
Post name is also the most common setting, and it gives you shorter, cleaner URLs. It’s still a change to every URL on your site though, so if you’d rather not, just wait for the update.
Let me know how it goes.
Forum: Reviews
In reply to: [Albert - Connect AI Assistants to WordPress] Fantastic plugin for developersThank you for this great review @primerpizza . I am very glad you like the plugin.
Hi @primerpizza
Good to see you have resolved it. It indeed requires an active and valid SSL certificate. I’ll make sure that will be clear in the documentation for future users.
Thanks for bringing it up.
Hi @dvankooten ,
Thaks for this topic and your kind words.
I am building enhanced block management for one of the upcoming versions. This should handle large posts like this better.
I’ll look into the option to find and replace just parts of a larger context.
Forum: Plugins
In reply to: [Simple CAPTCHA with Cloudflare Turnstile] Mobile performanceLooks like the issue is resolved indeed. Thanks!
Forum: Plugins
In reply to: [Simple CAPTCHA with Cloudflare Turnstile] Mobile performanceHi @elliotvs . Thanks and will do. We have disabled the plugin for now temporarily (so visitors can at least use the site again). I will revisit this in a day or 2 and let you know what comes up.