Automatisches Einlesen, Umschreiben & Vorbereiten von RSS-Artikeln zur Veröffentlichung
Oliver G
682755c6a0
_resolve_wp_tag_ids created a WordPress tag for every keyword the rewriter invented, up to 12 per post. That is where the 3.055 tags for 955 posts came from - 1.683 of them used exactly once, 473 attached to no post at all. The categories are stable now, but the tags would simply grow back. Three changes, all on the write path: A proposed tag has to appear for wordpress_new_tag_min_proposals (3) different articles before it is created. Proposals are counted in the new tag_proposals table, keyed on (name, article), so re-publishing an article does not inflate its own count. Tags that already exist in WordPress are assigned as before - the gate only guards creation. Only the first wordpress_max_tags_per_post (5) tags reach WordPress. The full list still feeds the category rules, which were validated against it. The lookup fallback of reusing the first search hit is gone. It filed "Camping" under the unrelated existing tag "Campingplatz" whenever the exact tag was missing, which quietly produced wrong tags rather than none. If the proposal bookkeeping fails, nothing is creatable that run: existing tags still get assigned and the taxonomy stays put, rather than falling back to creating everything. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .dedupe | ||
| .github | ||
| backend | ||
| data | ||
| docs | ||
| internal | ||
| logs | ||
| pages | ||
| scripts | ||
| static | ||
| tools | ||
| utils | ||
| .env.example | ||
| .gitignore | ||
| __version__.py | ||
| AGENTS.md | ||
| app.py | ||
| CHANGELOG.md | ||
| LICENCE | ||
| main.py | ||
| pytest.ini | ||
| README.md | ||
| requirements.txt | ||
| test_checklist.md | ||
| versioning.py | ||
rss-news (Rebuild)
rss-news wird als bestehendes Repository weitergefuehrt und schrittweise zu einer robusten, rechtssicheren News-Pipeline neu aufgebaut.
Aktueller Stand:
- Alte Streamlit-App wird nicht produktiv genutzt.
news.vanityontour.dewird bis zum Go-Live der neuen App aufhttps://vanityontour.deumgeleitet.- Planung, Doku und Wiki werden als Grundlage fuer den Neuaufbau gepflegt.
Ziele
- RSS-gestuetzte Artikelverarbeitung mit klaren Quellregeln
- Rechtssichere Nutzung (Quellen, Attribution, Lizenzinformationen)
- Zuverlaessige Automatisierung auf Hetzner
- Publikation nach WordPress (IONOS aktuell, spaeter offen)
- Zugriff nur nach Login (zunaechst User/Password)
Architektur-Richtung (MVP)
- Backend:
Python + FastAPI - Jobs: Queue-Worker (z. B. Redis + RQ/Celery)
- Daten: SQLite fuer MVP, spaeter optional PostgreSQL
- Auth: Session-Login mit einem Admin-User
- Publishing: WordPress REST API (Status zunaechst
pending)
Details: docs/PROJECT_PLAN.md
Projektsteuerung
- GitHub Project:
https://github.com/users/OliverGiertz/projects/3/views/1 - Dieses Board ist die zentrale Steuerung fuer ToDos, Bugs, Verbesserungen.
- Wiki-Struktur liegt unter
docs/wiki/.
Dokumentation
- Projektplan:
docs/PROJECT_PLAN.md - ToDo-Liste:
docs/TODO.md - Quell- und Lizenzpolicy:
docs/SOURCE_POLICY.md - Wiki Home:
docs/wiki/Home.md
Lokale Entwicklung (Legacy-Code)
Der vorhandene Legacy-Stand kann weiterhin lokal gestartet werden:
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
streamlit run app.py
Hinweis: Diese App ist funktional historisch und wird durch die neue Architektur ersetzt.
Deployment-Zielbild
- Betrieb auf Hetzner
- Reverse Proxy via CloudPanel/Nginx
- Produktive Domain:
news.vanityontour.de - Bis zur Fertigstellung: Redirect auf
https://vanityontour.de
Sicherheit
- Keine Secrets im Repository
.envlokal/auf Server, nie committen- Auth-Pflicht fuer die neue WebApp
- spaeter optional: Passkeys/WebAuthn
Rechtlicher Hinweis
Dieses Projekt verarbeitet nur Quellen mit dokumentierter Nutzungsgrundlage. Vor produktiver Nutzung ist eine finale rechtliche Pruefung der ausgewaehlten Feeds notwendig.