Login

u/LowCommunication7675

r/zotero
Saving heise.de forum pages produces identical generic items — og:title "heise online" overrides the correct page title
▲ 1 r/zotero

Saving heise.de forum pages produces identical generic items — og:title "heise online" overrides the correct page title

Hi all,

I've hit what looks like a systematic problem in the Embedded Metadata translator with heise.de forum pages, and I'd be grateful if someone could confirm it. Full disclosure: I'm blocked from the official Zotero forums, so I can't report this there myself — if you can reproduce it, please consider posting it in the forums.

For transparency: I'm a practicing dentist, not a programmer — I couldn't have produced a report at this level of detail on my own. The tests were run on my machine, and this report was written with the help of an AI assistant (Qwen Code, GLM-5.3-Flash) based on those results. Everything above reflects what was actually observed.

What happens: Saving any heise.de forum page through the Zotero Connector (Chrome) produces an identical, portal-generic item every time — title "heise online", creator "heise online", and the abstract is the portal homepage's meta description ("News und Foren zu Computer, IT, Wissenschaft, Medien und Politik. Preisvergleich von Hardware und Software sowie Downloads bei Heise Medien."). No thread or post title, no date. In practice every heise forum discussion looks like a duplicate of every other one.

Why this hurts beyond cosmetics: In my library a duplicate-handling plugin merged snapshots of completely unrelated discussions into a single old "heise online" item — the generic metadata genuinely breaks duplicate-detection workflows.

Why it happens: The pages themselves are fine — the HTML <title> is correct (e.g. "Lokales Gedächtnis statt Speichern beim Anbieter | Forum - heise online"), but heise serves portal-level OpenGraph metadata on forum pages:

<meta property="og:title" content="heise online">

The Embedded Metadata translator apparently prefers og:title over the document title, so the generic portal name wins.

To reproduce: Save any forum page, e.g.

https://www.heise.de/forum/heise-online/Kommentare/Sogar-Chatverlaeufe-KI-Anbieter-geben-Daten-ihrer-Nutzer-weiter/Lokales-Gedaechtnis-statt-Speichern-beim-Anbieter/posting-46668303/show/

The same happens for thread pages (for example .../Kompressor-ist-nicht-im-Aussengeraet/thread-7612630/).

Environment: Zotero 10.0.5 on Windows 10, current Chrome + Zotero Connector. I verified the saved snapshots' HTML directly, so this is not a temporary server hiccup.

Suggested fix: When og:title is identical to the site's root/portal title (or, more generally, when og:title does not match the page's document title), fall back to the document <title> for the item title. For forum pages that would yield the thread or post name as expected.

Question: Can anyone else confirm this on other sites that serve portal-level og:metadata on deep pages? If it reproduces, please post it in the official Zotero forums.

u/LowCommunication7675 — 8 days ago
▲ 1 r/zotero

Local API writes broken in 10.0.5: POST/PATCH drop the connection without a response (was: 400 "primaryData" not loaded in 10.0.3)

Hi all,

I believe I've hit a reproducible bug in the local API (the HTTP server on port 23119) and would appreciate independent confirmation. A heads-up: I'm blocked from posting in the official Zotero forums, so I can't report it there myself — if you can reproduce it, please consider posting it in the forums.

For transparency: I'm a practicing dentist, not a programmer — I couldn't have produced a report at this level of detail on my own. The tests were run on my machine, and this report was written with the help of an AI assistant (Qwen Code, GLM-5.3-Flash) based on those results. Everything above reflects what was actually observed.

Environment: Zotero 10.0.5 on Windows 11, local API enabled, in-app local API key granted.

Zotero 10.0.3 (reported to the Zotero team by email on Sep 20, no reply): Creating an item via POST /api/users/0/items (cloud Web-API semantics, no client-generated key) failed deterministically with a per-item 400 response:

{"0": {"code": 400, "message": "'primaryData' not loaded for item (null/1/<key>)"}}

Zotero 10.0.5 (retested today): The bug is still there, but the failure mode changed — it got quieter:

  • POST /api/users/0/items with a valid webpage item closes the TCP connection without any response — no status code, no body. The library version stays unchanged and no partial item is left behind.
  • PATCH /api/users/0/items/<key> with a JSON body like {"parentItem": "<otherkey>"} plus If-Unmodified-Since-Version behaves the same: connection closed abruptly. (I hit this while moving an existing attachment to a different parent item.)
  • Reads (GET) still work, and the connector endpoints still work (/connector/saveItems returns 201 as before).
  • Identical behavior with and without the Expect: 100-continue header, so it's not header-related.

Quick repro:

curl -v -X POST "http://localhost:23119/api/users/0/items" \
  -H "Content-Type: application/json" \
  -H "Zotero-API-Key: <YOUR-LOCAL-API-KEY>" \
  --data '[{"itemType":"webpage","title":"Example Domain","url":"https://example.com/"}]'

On 10.0.5 the connection is closed before any HTTP response arrives (curl: empty reply); on 10.0.3 the same request returned the 400 JSON above. For the PATCH variant, pick any item key and set parentItem to another item's key.

Workaround: Writes through the cloud Web API work fine (create and patch) and reach the local library after the next sync — that's what I'm using for automation now.

Question: Can anyone else reproduce this on 10.0.5 (or 10.0.4)? If yes, please post it in the official Zotero forums — happy to provide more details (debug output, etc.).

reddit.com
u/LowCommunication7675 — 8 days ago
▲ 81 r/zotero

18 years of Zotero, 10,000+ items, and an AI agent that remembers: my fully local setup (guide)

I've been using Zotero since 2008 and now have ~10,000 items. Over the last months I put together a setup where an AI agent works with my library — and I wrote the whole thing up as a step-by-step guide, originally for my daughter (medical student), now public: it takes you from an empty Chromebook to a complete AI workstation, and the Zotero part works on any machine.

https://www.logies.de/ai-workstation-linux-vm.html

What the setup does:

  • Zotero stays the single source of truth. Zoteus (an MCP server, MIT-licensed) connects it to an AI agent through the Local API — no cloud API key, no library upload.
  • Semantic search over your own PDFs, fully local (multilingual e5-small, ~129 MB, works fine on DE+EN mixed libraries), so the agent can find things by meaning, not just keywords — then read the actual attached full texts, not abstracts.
  • The agent has a memory of its own. This is the heart of the setup: a local memory server (also self-built, open source) that gives the agent a durable, searchable memory — full-text and semantic — of tested workflows, rules and experiences. It stores what worked, retrieves it in later sessions, and gets better month by month. For me this was the difference between a chatbot that forgets everything and a genuine assistant.
  • Flashcards via Anki are covered too.

A word on what this feels like in practice: after 35 years of DOS and Windows, I now use Linux effortlessly because the agent handles it, and I have it write small programs for me. The AI becomes a tool that lets the user grow, rather than one that replaces them — that idea is what the guide is really about.

Everything is free, ad-free, no registration: https://www.logies.de/ai-workstation-linux-vm.html

Happy to answer questions about the setup, the indexing performance (11k+ items indexed overnight on modest hardware), or how the memory side interacts with the Zotero side. Feedback on the guide is very welcome too.

u/LowCommunication7675 — 22 days ago