Wunsch zur Tag Verwaltung

[robert]

Ich nutze Tags neuerdings mehr und zu unterschiedlichsten Zwecken. Dies bedingt aber auch, dass ich immer wieder ältere Artikel mit neuen Tags versehen möchte um sie mit neueren Artikeln besser zu verknüpfen.

Dazu würde ich mir wünschen - ohne wieder mal zu wissen wie schwierig das umsetzen ist:

Auflistung aller Artikel mit Datum. Neben jedem aufgelisteten Artikel werden die Tags in einem editierbaren Textfeld dargestellt. Hier kann man dann recht schnell ein, zwei, zig Artikel bzw. eigentlich nur deren Tags editieren.

Denn bisher muss ich jeden Artikel einzeln aufrufen und neu speichern. Gerade zweiteres möchte ich ebenfalls verhindern, da die Artikeln sonst in Feedreadern wieder auftauchen.

D.h. es sollte eben nur das Datenfeld mit den Tags verändert werden (oder sind es mehrere?)

Hoffe mein Wunsch ist verständlich ansonsten erläutere ich gerne nochmals. Ob umsetzbar kann ich leider mangels Kenntnissen nicht sagen.

[blog.brockha.us]

Exakt das selbe habe ich mir letzte Nacht aus exakt dem selben Grund auch gewünscht. Ich habe auch meine Tags ein wenig umstrukturiert und kam nicht darum herum, Artikel neu zu speichern. So ein Artikel <-> Tag Editor wäre also nicht schlecht.

Worum es ja eigentlich geht: Wenn man den Artikel als solchen nicht geändert hat, dann will man auch nicht das Änderungsdatum des Artikels angepasst haben. Dazu fallen mir 2 Lösungen ein:

1.) Gespeichert wird ein Artikel nur, wenn sich wirklich etwas geändert hat. Dazu müsste man die Alte Version wohl vorrätig halten und mit der neuen vergleichen. Das hätte dann zur Folge, dass -wenn nur Tags geändert werden- auch nur die Tags gespeichert werden und nicht noch mal der Artikel.

2.) Man baut ein weiteres Häckchen: "Änderungsdatum nicht anpassen". Dann wird gespeichert, aber ohne das Änderungsdatum zu ändern und somit nicht den RSS Feed durcheinander zu bringen.

Letzteres wäre wohl am einfachsten zu bauen, würde ich denken, ohne in den Code geschaut zu haben. Vielleicht sogar einfach über ein Plugin.

Was meinst Du dazu, Garvin?

[robert]

Für das ändern von etlichen Artikel ist das aufrufen jedes einzeln aber trotzdem mühselig. Da wäre eben so eine Liste mit einem frei editierbaren Tag Feld halt praktischer.
Aber ich bin für jede Verbesserung/Unterstützung dankbar.

[blog.brockha.us]

Wie gesagt: So ein Artikel <-> Tag Editor wäre schon cool.

Meine Lösungsvorschläge sind eher für das allgemeine Problem, dass Artikel beim Speichern neu im RSS Feed auftauchen, selbst wenn sie gar nicht verändert wurden. Das betrifft ja nicht nur das Ändern der Tags, es kann ja auch beliebige andere Einstellungen betreffen. Aber mir fällt gerade auf, dass das gar nicht so trivial ist, automatisch zu erkennen. Bei dem Podcast Plugin kann man z.B. einfach ein Filmchen in einem erweiterten Attribut speichern. Das ändert auf jeden Fall den Artikel, ohne dass sich der Artikel im Editor geändert hätte.

Da hilft also wohl nur die 2. Idee, in der der Blogger selbst entscheiden kann, wie mit dem Artikel umgegangen werden soll.

[garvinhicking]

Hi!

Die Überprüfung ob sich ein Artikel geändert hat, müsste es eigentlich schon geben: include/functions_entries, updertEntry methode holt sich den alten Eintrag in $_entry bevor er aktualisiert wird.

Theoretisch müsste man folgende Abfrage:

Code: Select all

        if (!serendipity_db_bool($entry['isdraft']) && !serendipity_db_bool($_entry['isdraft'])) {
            $entry['last_modified'] = time();
        }

nur erweitern um:

Code: Select all

        if (!serendipity_db_bool($entry['isdraft']) && !serendipity_db_bool($_entry['isdraft']) && $entry['body'] != $_entry{'body']) {
            $entry['last_modified'] = time();
        }

Aber das könnte auch unnachvollziehbare Folgen haben. In manchen Fällen ist es nämlich wichtig, dass last_modified gebumpt wird auch wenn man was anders als nur den body/extended ändert.

Eine neue Checkbox in die Eintragsmaske dafür einzubauen halte ich persönlich vor Overkill, das würde die Maske unnötig verkomplizieren.

Vernünftige RSS-Reader können ja einen ARtikel anhand der GUID herausfinden und würden eine Änderung dann garnicht anzeigen, daher finde ich das Problem auch eher als akademisches.

Roberts Grundwunsch nach der Tag-Sache ist daher sicher der interessantere. Aber auch mit viel Arbeit verbunden, ich persönlich werde mir das erst nach der Buchveröffentlichung ansehen können. Wer zwischenzeitlich dran will, kann das natürlich gerne tun. Eine derartige Maske dürfte aber sehr komplex werden, da man ja auch damit rechnen muss dass es mehrere tausend blogartikel mit vielen tags geben könnte, und ein browser auch nur begrenzt viele input-felder anzeigen kann.

Grüße,
Garvin

[robert]

Die Liste dürfe über mehrere Seiten verteilt sein
Aber danke mal fürs Nachdenken. Vielleicht findet sich jemand InteressierteR.

Das Buchprojekt hat natürlich Vorrang, davon haben wir ja alle etwas!!!

[blog.brockha.us]

Aber das könnte auch unnachvollziehbare Folgen haben. In manchen Fällen ist es nämlich wichtig, dass last_modified gebumpt wird auch wenn man was anders als nur den body/extended ändert.

Konfigurierbar machen in der generellen S9Y Konfiguration, "Einträge nur speichern bei Text-Änderung", default: ausgeschaltet? Ich persönlich fände diese Feature echt cool und wenn das so einfach zu implementieren ist..

Alle erweiterten Attribute würden dann trotzdem gespeichert, da das das Plugin selbst macht, oder?

[garvinhicking]

Hi!

Ich würde ungerne die globale s9y konfiguration mit einer so doch recht ungebräuchlichen option 'swampen'.

Ich würde mich mit einer versteckten $serendipity['updateTimestampOnlyWhenChanged'] Option in der serendipity_config gerade noch anfreunden können...?

Alle erweiterten Attribute würden dann trotzdem gespeichert, da das das Plugin selbst macht, oder?

Gespeichert wird das sowieso, aber dann würde halt der timestamp nicht aktualisiert, was dann dazu führen könnte das plugins möglicherweise irgendwas nicht ausführen, was auf einem neuen last_modified basiert...

Grüße,
Garvin

[blog.brockha.us]

Ich würde mich mit einer versteckten $serendipity['updateTimestampOnlyWhenChanged'] Option in der serendipity_config gerade noch anfreunden können...?

Ich auch.

Gibt es eigentlich irgendwo eine Dokumentation zu allen Konfigurationen, die man mittels des lokalen Konfigurationsfiles setzen kann? Da könnte man das dann für Nerds wie mich auch mit erwähnen.

[garvinhicking]

Hi!

Gibt es eigentlich irgendwo eine Dokumentation zu allen Konfigurationen, die man mittels des lokalen Konfigurationsfiles setzen kann? Da könnte man das dann für Nerds wie mich auch mit erwähnen.

Demnächst gibt es ein Buch, in dem so etwas haar klein zerfasert ist.

Grüße,
Garvin

[yellowled]

Da könnte man das dann für Nerds wie mich auch mit erwähnen.

Demnächst gibt es ein Buch, in dem so etwas haar klein zerfasert ist.

Ha, da hat jemand den Vertrag für "s9y for Dummies" schon in der Tasche, wie?

YL

[falk]

Da könnte man das dann für Nerds wie mich auch mit erwähnen.

Demnächst gibt es ein Buch, in dem so etwas haar klein zerfasert ist.

Ha, da hat jemand den Vertrag für "s9y for Dummies" schon in der Tasche, wie?

YL

Will ich schreiben! Will ich schreiben! *amdaumennutschend*