RSS: Einheitliche PageIDs

[evaki]

Anscheinend gibt es bei Anwendern das Problem, daß beim Löschen einer News-Page in der Folge mit dem Neuanlegen der RSS-Feed nicht mehr stimmt, da eine neue PageID vergeben wird. Die Folgen sind mehr als ärgerlich. Man kam hier bei uns auf die Idee PageIDs zu reservieren, für News z.B. 1000-1010 01-10, Banner xx-xx usw.

Was ist nötig (Script) um im laufenden Betrieb (News vorhanden) die PageIDs entsprechend zu ändern, also ohne daß die Nachrichten verloren gehen und die Funktion gestört wird?

MfG. Evaki

Nachdem ich selbst ein wenig gespielt habe, stellt sich mir eine weitere Frage. Wo ist die zuletzt generierte PageID (und wie) gespeichert, also auch wenn die Seite längst geloscht ist?

[BlackBird]

Die Vergabe der IDs erfolgt über Mechanismen der Datenbank. Da hat WB nichts mit zu tun. Dementsprechend wird die zuletzt vergebene ID auch nicht irgendwo vermerkt.

Das Problem mit dem Feed verstehe ich nicht, der wird doch auf Basis der aktuellen Daten erzeugt?

[evaki]

Hallo
>die zuletzt vergebene ID auch nicht irgendwo vermerkt.
Was ich nicht verstehe wo die Infornation der zuletzt erzeugten PiD herkommt (deren Seite schon gelöscht ist), wenn eine neue Seite angelegt wird, also Seite 55 angelegt, gelöscht und neue Seite erhält 56.
Bei meiner Spielerei hatte ich einer Seite per phpmyadmin eine höhere PiD gegeben (die Seite dann gelöscht), ab der dann beim Anlegen einer neuen Seite folgerichtig hochgezählt wurde.
>Problem mit dem Feed verstehe ich nicht
Wenn der Fee abonniert ist, passiert beim Wechsel nichts mehr. So zumindest wurde es mir erklärt. Das erschien mir einleuchtend. Habe ich etwas verwechselt oder nicht bzw. falsch verstanden?
MfG. Evaki

[BlackBird]

Was ich nicht verstehe wo die Infornation der zuletzt erzeugten PiD herkommt

Das macht die Datenbank. Dort ist definiert, daß es sich um ein sogenanntes auto_increment Feld handelt. Die Datenbank vergibt dann automatisch eine fortlaufende ID. Die zuletzt vergebene - bzw. nächste freie - ID ist ebenfalls in der Datenbank selbst hinterlegt. WB hat damit nichts zu tun, das macht mySQL selbst.

[BlackBird]

Hier mal beispielhaft der CREATE TABLE aus meiner lokalen WB 2.8.3 Testinstallation. Wie Du siehst, ist page_id als AUTO_INCREMENT Feld deklariert. Unten steht die aktuelle - das heißt nächste zu vergebende - AUTO_INCREMENT ID.

Code: [Select]

CREATE TABLE `wb_pages` (
`page_id` INT(11) NOT NULL AUTO_INCREMENT,
`parent` INT(11) NOT NULL DEFAULT '0',
`root_parent` INT(11) NOT NULL DEFAULT '0',
`level` INT(11) NOT NULL DEFAULT '0',
`link` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
`target` VARCHAR(7) NOT NULL DEFAULT '' COLLATE 'utf8_unicode_ci',
`page_title` VARCHAR(255) NOT NULL DEFAULT '' COLLATE 'utf8_unicode_ci',
`menu_title` VARCHAR(255) NOT NULL DEFAULT '' COLLATE 'utf8_unicode_ci',
`description` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
`keywords` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
`page_trail` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
`template` VARCHAR(255) NOT NULL DEFAULT '' COLLATE 'utf8_unicode_ci',
`visibility` VARCHAR(255) NOT NULL DEFAULT '' COLLATE 'utf8_unicode_ci',
`position` INT(11) NOT NULL DEFAULT '0',
`menu` INT(11) NOT NULL DEFAULT '0',
`language` VARCHAR(5) NOT NULL DEFAULT '' COLLATE 'utf8_unicode_ci',
`searching` INT(11) NOT NULL DEFAULT '0',
`admin_groups` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
`admin_users` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
`viewing_groups` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
`viewing_users` TEXT NOT NULL COLLATE 'utf8_unicode_ci',
`modified_when` INT(11) NOT NULL DEFAULT '0',
`modified_by` INT(11) NOT NULL DEFAULT '0',
`page_code` INT(11) NOT NULL,
PRIMARY KEY (`page_id`)
)
COLLATE='utf8_unicode_ci'
ENGINE=MyISAM
AUTO_INCREMENT=15;

Wichtig ist auch, zu verstehen, daß sich die ID nicht dadurch ändert, daß zwischendrin IDs rausgenommen werden. mySQL vergibt immer die nächsthöhere ID, egal ob davor welche frei sind oder nicht. Das heißt, wenn ich mit obigem Statement eine leere Tabelle erzeuge, wird die allererste Seite, die ich mit WB anlege, die ID 15 bekommen - obwohl die 14 IDs davor gar nicht belegt sind.

Wenn Du mySQL durch manuelle Vergabe einer nächsthöheren ID - z.B. 25 - zwingst, die nächste AUTO_INCREMENT ID zu ändern, wirst Du ab diesem Zeitpunkt entsprechend höhere IDs bekommen. Du könntest z. B. erzwingen, daß Deine Seiten-IDs mit 1001 statt 1 anfangen.

[BlackBird]

Wenn der Fee abonniert ist, passiert beim Wechsel nichts mehr.

Das kommt darauf an. Man kann einen Feed genauso cachen wie eine HTML-Seite. Wenn der Benutzer den Feed nach dem initialen herunterladen lokal zwischenspeichert, kann das Problem natürlich auftreten. Ob und wie man das verhindern kann, müßte ich erst recherchieren.

[DarkViper]

WebsiteBaker hat grundsätzlich keinerlei Einfluss auf die Vergabe der IDs. Diese werden ausschließlich von der Datenbank selbst verwaltet.

Bei meiner Spielerei hatte ich einer Seite per phpmyadmin eine höhere PiD gegeben (die Seite dann gelöscht), ab der dann beim Anlegen einer neuen Seite folgerichtig hochgezählt wurde.

Eine manuelle Änderung einer ID in der Datenbank zerstört die Abhängigkeiten zwischen den Tabellen. Wenn Du z.B. in der Tabelle 'pages' eine SeitenId änderst und diese Seite dann im Backend löschst, bleiben die zugehörigen Einträge in der Tabelle 'sections' sowie in allen betroffenen Modultabellen etc. als verlorene Einträge übrig, da sie durch die verfälschte ID nicht mehr gefunden und gelöscht werden können.

Wesentlich sinnvoller als WB 'mit roher Gewalt irgendwie' an irgendwas anzupassen ist es, einfach die längst vorhandenen Möglichkeiten von WB zu nutzen.

In Deinem Fall [wenn ich das jetzt richtig verstanden habe, willst Du eine komplette News-Seite gegen eine neue austauschen] ist das ganz simpel zu bewerkstelligen.

• Lege auf der 'alten' News-Seite eine einen neuen Abschnitt vom Typ 'news' an, weise ihn der selben Gruppe zu wie den bisherigen und setze das Veröffentlichungsda tum auf irgendwann in ferner Zukunft
• Baue jetzt den 'neuen' News-Bereich auf (Einträge anlegen)
• Nach Abschluss der Arbeiten setze das Veröffentlichungs-Ende-Datum des 'alten' News-Abschnittes auf ein Datum in der Vergangenheit und das Veröffentlichungs-Beginn-Datum des neuen Abschnitts ebenfalls.

fertig...
(sollte der 'alte' News-Abschnitt nicht mehr benötigt werden, kann er selbstverständlich auch in der Abschnittsverwaltun g direkt gelöscht werden.)

Resultat: Du hast eine Seite mit lauter neuen News-Einträgen und sämtliche RSS-Abo-Links sind weiterhin unverändert gültig.

[BlackBird]

Ich denke, das Problem liegt in der Refresh-Rate des Feeds. Die Feedreader gehen damit ganz unterschiedlich um. Halt in lokaler Cache. Daran wird der Vorschlag von DV vermutlich nichts ändern. Ich bin aber kein RSS-Guru.

Eventuell hilft es, dem Channel eine "time to live" zu geben und diese niedrig anzusetzen.

http://www.rssboard.org/rss-specification#ltttlgtSubelementOfLtchannelgt

[BlackBird]

Versuch mal das hier:

modules/news/rss.php Zeile 53 ff sieht so aus:

Code: [Select]

<rss version="2.0">
<channel>
<title><?php echo PAGE_TITLE; ?></title>
<link>http://<?php echo $_SERVER['SERVER_NAME']; ?></link>
<description> <?php echo PAGE_DESCRIPTION; ?></description>

Da fügst Du das ttl ein, etwa so:

Code: [Select]

<rss version="2.0">
<channel>
                <ttl>60</ttl>
<title><?php echo PAGE_TITLE; ?></title>
<link>http://<?php echo $_SERVER['SERVER_NAME']; ?></link>
<description> <?php echo PAGE_DESCRIPTION; ?></description>

Die 60 steht für 60 Minuten.

[evaki]

Danke für Deine auführlichen Erläuterungen zur PiD-Vergabe. Die sind einleuchtend und nachvollziehbar. Ich bekomme hier meist die Informationen zugerufen, für deren Hintergrund ich oft erst recherchieren muß. Fehlt dann irgend etwas fundamentales für das Verständnis, geht die Recherche schon mal ins Nirgendwo  

Lege auf der 'alten' News-Seite eine einen neuen Abschnitt vom Typ 'news' an, weise ihn der selben Gruppe zu wie den bisherigen und setze das Veröffentlichungsda tum auf irgendwann in ferner Zukunft

Das klappt natürlich nur wenn die Seite inkl. PiD nicht gelöscht wurde, nicht nur die News-Section.

Beim Feed-Problematik ging es um rss.php mit der angeängten PiD, die bei Löschung der Seite dann eine andere ist. Der Abonnent bekommt dann keine Nachricht mehr. So zumindest habe ich das verstanden.

Mal schauen ob meine Mittagszeit noch für das Thema ausreicht, ansonsten schaue ich mir Eure Mitteilungen heute Abend in Ruhe an.

Erstmal vielen Dank für Eure Aufmerksamkeit und die Bemühungen.
Mir ist es wichtig, die Dinge zumindest halbwegs zu verstehen bzw. nachvollziehen zu können.
Auch erwartet mein Arbeitsumfeld, daß ich mich darum bemühe  

MfG. Evaki

[BlackBird]

Hm, nach nochmaligem Lesen glaube ich, daß DV recht hat und ich das Problem falsch verstanden habe. Ich dachte, die Links im RSS-Feed seien falsch, weil die News darin nicht mehr vorhanden sind. Offenbar geht es aber tatsächlich um die News-Seite selbst. Sorry. Ich laß meine Antworten oben trotzdem stehen, falls mal jemand das von mir gedachte Problem hat.

[marmot]

Hi,

Was ist nötig (Script) um im laufenden Betrieb (News vorhanden) die PageIDs entsprechend zu ändern, also ohne daß die Nachrichten verloren gehen und die Funktion gestört wird?

du könntest in der rss.php auch die page_id "umleiten". Z.B. Zeile 22 einfügen:

Code: [Select]

if ($page_id == <old_pid>) $page_id = <new_pid>; Dann sollten die User mit altem und mit neuem Aufruf glücklich sein. Wie ja ausführlich erläutert wurde, sollte die alte pid automatisch frei bleiben. Wenn du das natürlich all zu oft machst, dann wird es irgendwann unübersichtlich . (Man kann ja einen Kommentar in den Code einfügen, zb wird in 6 Monaten gelöscht. Bis dahin sollten alle User Zeit haben umzustellen und in den News schreibt man als aktuelle Meldung, dass auf den neuen Aufruf umgestellt werden soll)

Gruß

[evaki]

Ich weiß nicht was die Kollegen mittlerweile gebastelt haben, aber Deine Lösung in Kombination mit der Vorgehensweise von D.V.  scheint mir für diesen Zweck optimal zu sein, zumal schon eine gepatchte rss.php vorliegt. Da ich gestern, noch am Abend, auch den Weg gefunden habe, um in der Datenbank eine alte bzw. "verlorene" PiD wiederherzustellen (Dank nochmal für die Infos zur Datenbank, der Rest ergab sich durch Lesen von dev.mysql.com/doc/), sollte das die Lösung sein.
MfG. Evaki

Neu: Die Kollegen danken. Da immer auch zwei BAK der letzten 48Std. vorliegen, ist das Problem also beherrschbar.

[Luisehahne]

Hallo,

nur mal aus Neugierde, was ist an der Lösung von DarkViper verkehrt? Warum passt das nicht?


Dietmar

[evaki]

Daran ist nichts verkehrt.
Es gab in der Hitze des hektischen gestrigen Nachmittags nur nicht immer das sofortige Verstehen.
Erst im Laufe des Abends hatte ich die Möglicheit alles nochmals durchzuschauen
Der Stand ist, soweit ich weiß "sowohl als auch" je nach Situation.

Gestern funktionierte auch das Patchen in der Datenbank bei Verlust einer Newsseite. Das ist durch den einfachen Trick von "marmot" jedoch überflüssig geworden.

MfG. Evaki

[marmot]

Hi,

nur mal aus Neugierde, was ist an der Lösung von DarkViper verkehrt? Warum passt das nicht?

falls die Frage auch an mich gerichtet war, da ich ja der Quertreiber war, der trotz vorhandener Optimallösung noch was hinzugefügt hat:

1.) Ich habe nie beahautpet, dass was nicht passt.

2.) Wenn du den von mir zitierten Teil der Frage liest, stellt du fest, dass dort explizit nach Code gefragt war. Was DarkViper gerschrieben hatte war eine Verfahrensweise, was ich geschrieben hatte war eine Zeile Code. Insofern scheint mir das Aufzeigen dieser Alternative nicht nur nicht verwerflich sondern sogar angezeigt.

3.) Weil es gerade so schön passt. Es ist hier im Forum durchaus nicht unüblich einen bereits vorhandenen und funktionierenden Lösungsvorschlag noch weiter zu kommentieren, Alternativen anzubieten oder gar zu verbessern: https://forum.WebsiteBaker.org/index.php/topic,24686.msg168325.html#msg168325. Dabei erkenne ich durchaus neidvoll an, dass perfekte Problemlösungen einem kleinen Kreis hochbegabter Spezialisten vorbehalten bleiben.

Gruß

[Luisehahne]

Hallo Marmot,

Nein die Frage war nicht an dich gerichtet. Es war einfach nur Neugierde. Ich bin immer offen für Lösungen, wenn sinnvoll und ohne Querschläger (globale Wechselwirkungen), zu übernehmen. So ist z.B. der Wunsch der Community umgesetzt div Container mit class="modulename" um die Sections zu setzen. Zusätzlich die ID des Anchor. Damit fällt das <a name=""... Tag weg, welches teilweise das Layout zerschossen hat.

Wir sind kräftig an der WB 2.8.4 dran. Ich mag deinen Support und denke wenns passt die Ein oder Andere Lösung zu übernehmen.

Dietmar