Danny van Kooten
Forum Replies Created
-
Thanks for the update @dryheat3. Glad that seems to have improved it. Definitely keep an eye of things and don’t hesitate to let me know in case you suspect numbers are drifting off again.
Forum: Plugins
In reply to: [Albert - The AI Butler] Read page returns truncated page output?Relevant information:
< What is causing the output by the read-page ability to be truncated?
> The truncation is not coming from your MCP server.
What's happening is:
Your MCP server returns the page content successfully.
The connector framework passes that content to ChatGPT.
ChatGPT has a tool-response size budget. When a tool returns a very large payload (such as a full Gutenberg page with lots of block comments, image markup, and HTML), the response is shortened before it reaches me.
The tool output is then marked as "(truncated)", which is exactly what I saw for the larger page responses.
Evidence:
view-page for Products returned the full page because it was small enough.
view-page for Privacy Policy returned the full page.
view-page for The people behind ibericode was cut off midway through the fourth profile section.
The initial find-pages response was also truncated because it contained multiple full page bodies in a single payload.
So the bottleneck is almost certainly the ChatGPT MCP connector/tool transport layer, not WordPress or Albert.
How to make MCP editing work better
I would recommend adding one or more of these abilities to Albert:
get-page-summary
Returns only ID, title, slug, excerpt, modified date.
Avoids huge payloads.
replace-text-in-page
Inputs: page ID, search string, replacement string.
Ideal for typo fixes.
patch-page
Inputs: page ID + list of text replacements.
Safer than replacing entire content.
get-page-blocks
Returns Gutenberg blocks individually.
Lets me edit only a specific block.
find-text
Search across pages/posts for a phrase.
Great for content audits.
For AI-driven site maintenance, replace-text-in-page is by far the most useful. It would have allowed me to fix all issues you found without needing the entire page content.Thanks Pete. Today’s release (version 2.4) contains some tracking related changes which should, in theory, prevent even more non-human traffic from being recorded in the statistics.
- The User-Agent check has been expanded to also check for “prerender”, which some prerendering engines add.
- The browser’s visibility API is used to only capture a pageview if the document is actually visible.
I’m curious if it has any effect on your numbers.
Hi Pete,
I just wanted to let you know that I’ve read this and am following along. Can you elaborate on the “pageviews” reported by Google Search Console though? As far as I know, GCS only tracks the number of times your site appeared in Google search results and how many times a search result linking to your site was clicked.
Hi @kriskorn,
I just wanted to let you know that I’ve read this and will be looking into it!
Hi @nathalie75,
Can you please try updating to version 2.3.6 to see if that fixes your issue?
Happy to hear it @isaxby! Was the issue that you did not set an API key or choose a Mailchimp audience in the form settings?
Hi Betty,
I regret to say that this is due to a database migration on the table backing the post counts attempting to run multiple times on your site, but never finishing because of the size of your dataset combined with your hosting’s resource limits. So something that should have only run once, ran dozens of times on your site.
I am afraid that there is no easy way to fix this except for re-installing a back-up of the Koko Analytics database tables.
Alternatively, if you don’t care much about historical numbers, you can go into Koko Analytics > Settings > Data and use the Reset Statistics button there to start from a clean slate. Going forward, everything will count correctly again.
We had to do quite an intensive database migration in a recent version so this issue should not re-occur again, but a way to prevent it in the long run is by limiting your dataset to only include the last 1 or 2 years of data. This will help any database migrations finish in time and also improve general performance of your Koko Analytics dashboard.I hope that clarifies a bit. Best, Danny
Hi Betty,
I just emailed your other email address and also tried from my Gmail address instead of my own domain. Hopefully some of these do arrive.
Let me know what importing the file I sent you does please.
Danny
For example, this subpage is frequently visited by foreign-language visitors: https://ludwigsapo.de/rezept-einloesen/rezepte-aus-dem-ausland/, but it doesn’t appear at all in Koko.
That is really strange. I just visited the page and checked the Network tab in my browser’s developer tools. There is an HTTP request to the data collection endpoint which returns a 200 OK response, which means it was processed correctly.
> Am I correct in understanding that visitors to the foreign-language pages weren’t counted at all (= that they aren’t included in the visitor count for the original language)?Yes. The data collection endpoint returns a 400 Bad Request error for the requests initiated from the foreign-language pages, so they are rejected by Koko Analytics (because of the empty path value) and not counted at all.
I’ll do some digging to see what we can do about this, but it may take me a couple of days as I am really quite busy right now and this is quite a time intensive thing to check (as I need to get my hands on WPML and set it up etc.).Hi Betty,
Yes, to your email. Maybe it was marked as spam? I’ll send it again but with a download link instead of an attachment this time.
Hi @nathalie75,
Do you have a link to a page on your site in one of the other (non-main) languages that is not the homepage?
I notice that visiting the German version of your site correctly produces a request to the Koko Analytics collection endpoint with a pa (this is the “path” value) of “/”.
However, when on any other language, it will send a pa value of “”, which is rejected by the endpoint. I will have to run some tests locally trying to replicate your WPML set-up to see how we can properly fix this, as I think it is due WPML somehow stripping off the language part.
So in short: looks like a bug due to the combination of Koko Analytics + WPML, but I have to dig into it to see what would be the best fix.Hi Betty,
Your database was somehow stuck at migration version 12, while the latest version is 20. I ran the database migrations locally and sent you an updated export file that you can import via Koko Analytics > Settings > Data.
Let me know what importing that file does please.
Best,
DannyThank you Betty. I received the export file. I am carving out time in my day tomorrow to look at this in detail and will keep you posted with my findings.
Hi Betty,
You can send it to me by email at [email protected].