Moin André, alle,
ich möchte diese Erweiterung [edit_date] gern einsetzen, deshalb habe ich sie mal in 2.10.4 getestet ... und dafür angepasst (siehe Anhang).
Obwohl die Erweiterung (1.0.0 stable) auf Anhieb ohne Fehlermeldungen zu laufen schien, erforderte eine genaue Besichtigung dann doch einige Patches:
- Die aktive Änderung des Felds "tstamp" ist höchst problematisch/unmöglich, vermutlich systemweit, aber jedenfalls im DCA von tl_article!
- An diesem Feld sollte man in keiner Weise drehen, weder im Backend, noch in der DB!!! Unter anderem hängt die korrekte Versionierung von diesem Feld ab. Es gibt reichlich Hinweise in DC_Table.php darauf.
- Sobald man im DCA von "tl_article" das Feld "tstamp" aufnimmt, verhält sich Contao nicht mehr so, wie geplant
- Jede aktive Änderung einer "tstamp" wird sowieso NACH Speicherung des Datensatzes neu gesetzt (siehe DC_Table.php und diverse andere Stellen im Core, etwa für das un/sichtbar machen von Datensätzen)
Zu 3.: ohne das Feld "tstamp" im DCA von "tl_article" wird im Artikel-Kopf als Änderungsdatum das MAX Datum des Artikel-Kopfes und aller zugeörigen Inhalts-Elemente angezeigt. Das ist sehr hilfreich / richtig, weil der Artikel ja nur ein Container / Behälter für den eigentlichen Inhalt ist.
Wird aber versucht, die "tstamp" anzuzeigen (selbst wenn 'readonly' oder 'disabled'), funktioniert das nicht mehr. Es wird stattdessen nur noch das Änderungsdatum des Artikelkopfes gezeigt. Mag sein, dass das ein Bug im Contao Core DC_Table.php ist. Es zeigt aber jedenfalls, dass das Bearbeiten der "tstamp" nicht vorgesehen ist.
Deshalb habe ich "tstamp" im Backend von [edit_date] komplett entfernt. Dort bleibt also nur das "createdate".
Die beiden Inserttags {{article_create}} und {{article_update}} (auch mit Parametern id=X und/oder format=Y) bleiben erhalten ... allerdings erheblich verbessert:
- wurde keine Artikel ID angegeben, dann hat die Original-Version die ID der SEITE herangezogen ($objPage->id). Das ist natürlich komplett falsch und erklärt auch eine frühere Nachricht "woher auch immer diese Daten stammen". Seite.Id ist typisch <> Artikel.Id. Meine Version versucht, den ersten Artikel in der Hauptspalte der aktuellen Seite zu ermitteln. Gibt es keinen (veröffentlichten, in der Hauptspalte), oder wurde ausdrücklich eine nicht existierende Artikel-ID angegeben, dann wird das Inserttag unverändert angezeigt (ohne die {{}} Klammern).
- direkt nach Installation von [edit_date] mit bereits existierenden Artikeln ist das "Erstellungsdatum" für alle diese Artikel auf 0 (== 01.01.1970) gesetzt. Deshalb gibt meine Modifikation dann das Datum der letzten Änderung aus. Ihr müsst also das Erstellungsdatum explizit setzen, falls Ihr das Inserttag {{article_create}} wirklich sinnvoll einsetzen wollt.
- Wie oben erwähnt berücksichtigt Contao im Kopf des Artikels auch die Änderungs-Daten sämtlicher Inhalts-Elemente zum Artikel. Auch das habe ich in das Inserttag {{article_update}} eingebaut. Das ist die Antwort auf mehrere frühere Nachrichten in diesem Zweig, die dies Feature vermisst haben. Ich finde das Standard-Verhalten zwar auch gut, aber ich habe es optional gemacht: siehe die Kommentare in den Quelltexten unten
Die Änderungen sind so umfangreich, dass ein diff länger wäre, als die neuen Quellen zu zeigen (siehe auch Anhang für eine manuell installierbare Version). Hier im Forum habe ich auch die länglichen, nicht hilfreichen, Kommentare am Anfang der Dateien entfernt.
system/modules/edit_date/config/config.php:
PHP-Code:
<?php if (!defined('TL_ROOT')) die('You can not access this file directly!');
$GLOBALS['TL_HOOKS']['replaceInsertTags'][] = array('EditDate', 'InsertTags');
// Set to false in your system/config/localconfig.php AFTER the comment line
// ### INSTALL SCRIPT STOP ###
// only if you really want to have the insert tag article_update to show only the
// tstamp of the article header record. Even then you can't edit that tstamp.
// The only way to change it is to edit the article header in some way and then
// it will just be newer than before. Also note: don't fiddle with the tstamp
// in your database ... that might break your Contao system (e.g. the versioning)!
$GLOBALS['TL_CONFIG']['edit_date_update_respects_ce_dates'] = true;
class EditDate extends Backend
{
/**
* Hook function for replaceInsertTags()
*/
public function InsertTags($strTag)
{
if ((strpos($strTag, 'article_create') !== false) || (strpos($strTag, 'article_update') !== false))
{
global $objPage;
$parts = (strpos($strTag, '::') !== false) ? explode('::', $strTag) : $strTag;
$tag = (is_array($parts)) ? $parts[0] : $strTag;
$options = explode('&', str_replace(array('[', ']'), '', $parts[1]));
foreach ($options AS $param)
{
$value = explode('=', $param);
$option[$value[0]] = $value[1];
}
$id = trim($option['id']);
if ($id !== '' && is_numeric($id))
{
$objArticle = $this->Database->prepare("SELECT id, createdate, tstamp FROM tl_article WHERE id=?" . (!BE_USER_LOGGED_IN ? " AND (start='' OR start<?) AND (stop='' OR stop>?) AND published=1" : ""))
->limit(1)
->execute($id, time(), time());
}
else
{
// Get ID of first arcticle in main column
$objArticle = $this->Database->prepare("SELECT id, createdate, tstamp FROM tl_article WHERE pid=? AND inColumn=?" . (!BE_USER_LOGGED_IN ? " AND (start='' OR start<?) AND (stop='' OR stop>?) AND published=1" : "") . " ORDER BY sorting")
->limit(1)
->execute($objPage->id, 'main', time(), time());
}
if ($objArticle->numRows < 1)
{
// no article with given ID or in main column of current page: return the unmodified tag
return $strTag;
}
$tstamp = 0;
switch($tag)
{
case 'article_create':
$tstamp = $objArticle->createdate;
if ($tstamp > 0)
{
break;
}
// createdate was not set, a common case after installing [edit_date] with existing articles.
// Silently fall back/through to using the update date / tstamp
case 'article_update':
$tstamp = $objArticle->tstamp;
if ($GLOBALS['TL_CONFIG']['edit_date_update_respects_ce_dates'])
{
// Look for max date of content elements, as Contao 2.10.x does in DC_Table.php around line 3385 ff.
// The date shown then is identical to what Contao shows in the article header
$objMaxTstamp = $this->Database->prepare("SELECT MAX(tstamp) AS tstamp FROM tl_content WHERE pid=?")
->execute($objArticle->id);
if ($objMaxTstamp->tstamp)
{
$tstamp = max($tstamp, $objMaxTstamp->tstamp);
}
}
break;
}
return $this->parseDate((strlen($option['format']) ? $option['format'] : $GLOBALS['TL_CONFIG']['datimFormat']), $tstamp);
}
return false;
}
}
?>
system/modules/edit_date/dca/tl_article.php:
PHP-Code:
<?php if (!defined('TL_ROOT')) die('You can not access this file directly!');
/**
* Palettes
*/
$GLOBALS['TL_DCA']['tl_article']['palettes']['default'] = str_replace(
';{publish_legend}',
';{edit_date_legend},createdate;{publish_legend}',
$GLOBALS['TL_DCA']['tl_article']['palettes']['default']);
/**
* Fields
*/
$GLOBALS['TL_DCA']['tl_article']['fields']['createdate'] = array
(
'label' => &$GLOBALS['TL_LANG']['tl_article']['create_date'],
'exclude' => true,
'default' => time(),
'inputType' => 'text',
'eval' => array('rgxp' => 'datim', 'datepicker' => $this->getDatePickerString(), 'tl_class' => 'w50 wizard')
);
?>
Das sind die wesentlichen Änderungen. Im ZIP habe ich natürlich auch noch die Sprach-Dateien angepasst.
Das ZIP im Anhang ist gepackt mit dem Pfad system/modules/edit_date /... sämtliche Ordner und Dateien darin genau dorthin auf den Server laden und die neue Version sollte funktionieren. Kein Install oder DB-Update erforderlich.
Aber macht vorher ein Backup und wundert Euch nicht, dass die Modifikation nicht in der "Erweiterungsverwaltung" auftaucht (bzw. nicht als aktualisiert). Das ist halt leider so, wenn man manuell installiert.
Ich erhoffe Testberichte ... und dann ein Update von [edit_date] so bald als möglich durch André (aka Leuchte).
Liebe Grüße, Georg
[edit_date] Erstellungs- und Änderungsdatum eines Artikels anzeigen lassen
Zitieren
Lesezeichen