In den *.tpl sollte das eigentlich auch nicht nötig sein, die werden doch in 2.10 gar nicht verwendet?
Ich hab eben meine Seite auf 2.10.3 gebracht, da klappts weiterhin einwandfrei. Keine Ahung, woran das noch liegen könnte. :(
Druckbare Version
In den *.tpl sollte das eigentlich auch nicht nötig sein, die werden doch in 2.10 gar nicht verwendet?
Ich hab eben meine Seite auf 2.10.3 gebracht, da klappts weiterhin einwandfrei. Keine Ahung, woran das noch liegen könnte. :(
Hey,
Danke fürs Feedback! Ich werde heute nochmal sauber machen und die Erweiterung neu aufsetzen, strikt nach Anleitung. Hoffe ich finde meinen Fehler dann :)
Hey,
hab den Fehler gefunden. Wenn du im Modul des Editors den Haken von "Veröffentlichung erlauben" wegmachst, erscheint logischerweise die checkbox für published nicht mehr. Wenn man dann aber anonym ein unveröffentlichtes Event einträgt, wird anstatt published = 0, published = NULL.
Wär cool wenn dus dir mal anschaust :)
MFG
Ah, super. Da könnte was dran sein. :)
Ich schau mir das die Tage an und mach dann ein Update im ER.
So, hier hab ich es mir einfach gemacht und vor dem Einfügen in die Datenbank ein
eingefügt. Version 1.3.2 ist im ER - danke nochmal für die Fehlermeldung und Suche nach der Ursache. :)PHP-Code:
if (is_null($NewEventData['published'])){
$NewEventData['published'] = '';
}
Servus,
Merci dir! Er meckert jetzt aber wieder beim TOKEN... Du lieferst nur .tpl und .xhtml mit. Aber ist xhtml nicht nur eine Verlinkung auf das vom Browser jeweils unterstüzte? Somit fehlt .html5 ...
Hab mir ein eigenes Template aus .xhtml und entsprechend gleichem .html5 gebaut und es funktioniert...
Hey!
Erstmal danke für diese tolle Erweiterung!
Wie weiter oben schoneinmal angemerkt wurde, wäre ein Datepicker ne feine Sache... vielleicht kannst du deine Erweiterung ja mit calendarfield kombinieren. Das wär echt mega-gut :)
Und dann habe ich da noch ein Problem:
Wenn ich einen neuen oder alten Eintrag speichern will, erscheint folgende Meldung:
Liegt das Problem bei mir, oder bei der Erweiterung?Zitat:
Invalid request token!
The request token could not be verified. Please go back and try again.
This error occurres if there is a POST request without a valid authentication token. In Contao 2.10, the referer check has been replaced with a request token system. If the problem persists, you are maybe using an incompatible third-party extension or have not correctly updated your Contao installation.
For more information, visit the Contao FAQ page or search the Contao forum.
LG,
Till
EDIT: Ich verwende contao 2.10.4 und calendar_editor 1.3.2 stable. Außerdem habe ich mod_rewrite in der .htaccess aktiviert... vielleicht hat das ja damit was zu tun (wäre nicht da erste mal)
OK,
Problem gelöst!
Ich hatte die tpl-Datei als Template genommen. Die enthielt aber einen Fehler. Dieser lässt sich wie folgt beseitigen:
Im templates-Ordner des Plugins muss in der Datei eventEdit_default.tpl nach der Zeile 40 folgende Zeile eingefügt werden:
Damit ist das Template wieder lauffähig.PHP-Code:
<input type="hidden" name="REQUEST_TOKEN" value="{{request_token}}" />
Vielleicht wäre es aber eh sinnvoller auf HTML5-Templates umzusteigen :) Das wäre mir eine große Freude!
LG,
Till
EDIT: Ich hab die modifizierte (!) Datei mal angehängt ;)
Hallo,
zunächst mal Vielen Dank für diese tolle Erweiterung!
Ist es möglich Felder im Standard Template mit Defaultwerten zu belegen.
Gibt es eine Möglichkeit den neuen Kalendereintrag defaultmäßig auf veröffentlicht zu setzen.
Danke
Gruß
madie
Hallo,
hat niemand eine Idee, wie ich zumindest die neuen Kalendereinträge defaultmäßig auf veröffentlicht setzen kann?
Vielen Dank und LG Grüße
Madie
Ich habe aktuell leider recht wenig Zeit hierfür. Die HTML-Templates werde ich mir mal anschauen und der nächsten Version hinzufügen.
Das mit den Default-Werten sollte über die Hooks gehen, die ich hier beschrieben habe. In der Hook-Funktion müsste man dann, wenn kein vorhandenes Event bearbeitet wird, und kein Submit stattfindet, die Checkbox setzen, also in etwa.PHP-Code:
$result['fields']['published']['value'] = '1';
Eventuell bau ich für die Veröffentlichung auch eine Option in das Modul ein.
Hallo zusammen,
ich bin im Programmieren keine besonders große Leuchte, daher vermute ich mal, dass hinter meinem Problem mal wieder nur meine Unkenntnis steckt:
Ich habe wie in der Anleitung geschrieben, das Frontend über den zusätzlichen Hook mit Feldern aus der Erweiterung Calender_Plus erweitert.
Alles funktioniert so weit prima. Jedoch werden die Werte aus dem Frontend nur in die Details geschrieben.
Weder beim Editieren noch beim Anlegen werden die Werte aus cep_location in das entsprechende Datenbank-Feld ge- bzw. überschrieben.
Habe ich irgendetwas übersehen?
Vielen Dank für Eure Hilfe.
In der Anleitung steckt wahrscheinlich zuviel des Guten. ;)
Da werden ja zwei Hooks erläutert - einmal der zum Einfügen weiterer Felder, und danach der zum Ändern der Post-Daten vor dem Eintrag in die DB. In diesem zweiten Hook werden in dem Beispiel die cep_*-Werte wieder gelöscht und mit ins Detail-feld geschrieben. Du müsstes dann einfach diesen Teil löschen, also inder config den Hookentfernen und in der EventEditHookPlus.php die FunktionPHP-Code:
$GLOBALS['TL_HOOKS']['prepareCalendarEditData']['EditPlus'] = array('EventEditHookPlus', 'prepareData');
löschen.PHP-Code:
public function prepareData($eventData)
Hallo Gausi,
vielen Dank für den Hinweis. Jetzt klappts...
Super Erweiterung, super Support.
Hallo Gausi,
super Erweiterung, soweit ich das gelesen habe.
Damit ich sie einsetzen kann, wäre aber folgende optionale Funktion nötig.
Ein Zeitraum darf in einem Kalender nur einmal belegt werden, also eine Doppelbuchung muss mit einer Fehlermeldung verhindert werden. Dann könnte man die Erweiterung z.B. für Flugzeugreservierungen verwenden und pro Flugzeug einen Kalender anlegen.
Hier muss dann natürlich verhindert werden, dass ein Flugzeug mehrfach gechartert wird.
Könnte man so etwas einbauen und wenn ja, hast Du eine Idee ?
Gruß
Olli
Hallo olli1770,
die Einträge im Kalender heißen im Backend zu Recht 'Event' und nicht 'Ressource'.
Ich verstehe deinen Gedanken, aber es gibt eben zwischen Events und Ressourcen genau den von dir angesprochenen Unterschied: Eine Ressource kann zu einem Zeitpunkt nur einmal verwendet werden. Aber natürlich kann es im Kalender mehrere Veranstaltungen zur gleichen Zeit geben.
Beide Objekte können Daten und Uhrzeiten / Zeiträumen zugeordnet werden.
Bedenke aber, dass Gausis Erweiterung nur die Frontend-Eingabe für die Contao-Events ermöglicht. Für eine korrekte Verwaltung von Ressourcen müsste eine Doppelbelegung auch im Backend verhindert werden.
Deine Anregung richtet sich also eher an den Contao-Core und die darin enthaltene Kalender/Event-Funktionalität.
Ich stimme dir aber natürlich zu, dass es viele denkbare Einsatzmöglichkeiten für einen Ressourcen-Planer gäbe...
Gruß, folkfreund
Hallo zusammen,
ich würde gern den Eventtitel im Betreff der Benachrichtigung ausgeben lassen.
Die betreffenden Stellen in der ModuleEventEditor.php habe ich schon gefunden. Mir fehlt jedoch das Wissen, das ordentlich umzusetzen.
Könnt Ihr mir bitte dabei helfen?
Falls es sogar updatesicher über die langconfig ginge, wäre das noch besser!PHP-Code:
protected function SendNotificationMail($NewEventData, $editID, $User)
{
$Notification = new Email();
$Notification->from = $GLOBALS['TL_ADMIN_EMAIL'];
$host = $this->Environment->host;
if ($editID) {
if ($editID == -1) {
$Notification->subject = sprintf($GLOBALS['TL_LANG']['MSC']['caledit_MailSubjectDelete'], $host);
} else {
$Notification->subject = sprintf($GLOBALS['TL_LANG']['MSC']['caledit_MailSubjectEdit'], $host);
}
} else {
$Notification->subject = sprintf($GLOBALS['TL_LANG']['MSC']['caledit_MailSubjectNew'], $host);
}
$arrRecipients = trimsplit(',', $this->caledit_mailRecipient);
$mText = $GLOBALS['TL_LANG']['MSC']['caledit_MailEventdata']." \n\n";
if (!FE_USER_LOGGED_IN) {
$mText .= $GLOBALS['TL_LANG']['MSC']['caledit_MailUnregisteredUser']." \n";
} else {
$mText .= sprintf($GLOBALS['TL_LANG']['MSC']['caledit_MailUser'], $User)." \n";
}
$mText .= $GLOBALS['TL_LANG']['MSC']['caledit_startdate'].': '.$NewEventData['startDate']." \n";
$mText .= $GLOBALS['TL_LANG']['MSC']['caledit_enddate'].': '.$NewEventData['endDate']."\n";
$mText .= $GLOBALS['TL_LANG']['MSC']['caledit_starttime'].': '.$NewEventData['startTime']."\n";
$mText .= $GLOBALS['TL_LANG']['MSC']['caledit_endtime'].': '.$NewEventData['endTime']."\n";
$mText .= $GLOBALS['TL_LANG']['MSC']['caledit_title'].': '.$NewEventData['title']."\n";
if ($NewEventData['published']) {
$mText .= $GLOBALS['TL_LANG']['MSC']['caledit_publishedEvent'];
} else {
$mText .= $GLOBALS['TL_LANG']['MSC']['caledit_unpublishedEvent'];
}
if (!$this->caledit_allowPublish) {
$mText .= "\n\n".$GLOBALS['TL_LANG']['MSC']['caledit_BEUserHint'];
}
$Notification->text = $mText;
Vielen Dank.
Hallo pandroid,
nur per langconfig geht wahrscheinlich nicht, da du auf jeden Fall an dem bereits von dir gefundenen Code was ändern musst.
Hier ein Beispiel, wie man das machen könnte:
1. die Vorgaben der Betreffs anpassen - die %s werden im folgenden durch die übergebenen Parameter ersetzt.
2. die Parameterübergabe in der von dir genannten Funktion SendNotificationMail bearbeitenPHP-Code:
$GLOBALS['TL_LANG']['MSC']['caledit_MailSubjectNew'] = "Neues Event '%s' auf %s";
$GLOBALS['TL_LANG']['MSC']['caledit_MailSubjectEdit'] = "Event '%s' wurde bearbeitet auf %s";
$GLOBALS['TL_LANG']['MSC']['caledit_MailSubjectDelete'] = "Event '%s' wurde gelöscht auf %s";
Gruß, folkfreundPHP-Code:
if ($editID)
{
if ($editID == -1)
{
$Notification->subject = sprintf($GLOBALS['TL_LANG']['MSC']['caledit_MailSubjectDelete'],
$NewEventData['title'], $host);
}
else
{
$Notification->subject = sprintf($GLOBALS['TL_LANG']['MSC']['caledit_MailSubjectEdit'],
$NewEventData['title'], $host);
}
}
else
{
$Notification->subject = sprintf($GLOBALS['TL_LANG']['MSC']['caledit_MailSubjectNew'],
$NewEventData['title'], $host);
}
Hallo Folkfreund,
vielen Dank für Deine Hilfe.
Das hat prima funktioniert.
Nochmal hallo an alle,
ich würde gern den Namen des Frontend-Users im Template event_full ausgeben.
Mit "showTemplateVars" ist zu erkennen, dass die Ausgabe auf die ID des FE_User beschränkt ist.
Habt Ihr eine Lösung wie ich aus der ID den Mitgliedernamen machen kann?
Vielen Dank für Eure Hilfe.
Versuch es mal mit einem Inserttag: {{user::username}}
Hallo Thomas,
danke für den Tipp.
Ich möchte aber NICHT den derzeit angemeldeten User ausgeben, sondern den User, der über calendar_editor als Frontend User und "Besitzer/Ersteller" des Kalendereintrags hinterlegt ist.
Hallo zusammen,
ich möchte gerne die Frontendeingabe eines Termins für unsere Mitglieder vereinfachen.
Wie kann ich die:
a) die css-Klasse über dca ansprechen und diese mit einem bestimmten Wert belegen? Danach würde ich das Feld im Frontend mit display:none unsichtbar machen, und
b) die Anweisung "Termin veröffentlichen" von vorneherein mit Häkchen laden und dann ebenfalls über css ausblenden.
Habe schon etliche dca-Anweisungen ausprobiert, aber leider nicht die richtige gefunden. Wäre dankbar für Tipps oder auch andere bessere Lösungsvorschläge.
Viele Grüße
Für den Ersteller des Events in den Anzeige-Templates müsste man wohl diese Information in das Template einbringen. Das wäre eine kleine SQL-Abfrage, die in die Methode addEventInformation in der Datei EventEditor.php eingefügt werden müsste, um dann den Namen in ein passendes Templatefeld einzufügen. Ich schau mal, dass ich das beim nächsten Update mit einbaue.
Updatesicher könnte man fürs erste afaik diese SQL-Abfrage auch in das Template event_full übernehmen. Wie die Abfrage aber genau aussehen muss, kann ich jetzt nicht sagen. ;)
Werte vorbelegen könnte so gehen. Aber dann darf das zugehörige Feld nicht einfach über css ausgeblendet werden, sondern darf gar nicht im Formular auftauchen (Template anpassen). Das Formular wird nämlich angezeigt, bevor in der DB ein Eintrag erstellt wird, und da greift DCA dann nicht, wenn ich das richtig sehe. Published ist aber auch ein Feld in den Events selber, d.h. diese Änderung würde sich dann vermutlich auch auf das Backend auswirken.
Ansonsten sollte das Vorbelegen der Felder im Formular über den Hook buildCalendarEditForm funktionieren, den ich be den Erweiterungen beschrieben habe.
Hallo Gausi,
danke für die Hinweise und Tipps. Werde mich weiter durchwuseln - mal sehen, was draus wird. ;-)
Gruß
Hallo, Gausi!
Ich habe mir für eine Frontendbearbeitung das Template folgender maßen angepasst:
Die Textausgaben wandern bei Zeiten noch in die langconfig. ;)Code:<div class="<?php echo $this->class; ?> ce_text block"<?php echo $this->cssID; ?><?php if ($this->style): ?> style="<?php echo $this->style; ?>"<?php endif; ?>>
<?php if ($this->headline): ?>
<<?php echo $this->hl; ?>><?php echo $this->headline; ?></<?php echo $this->hl; ?>>
<?php endif; ?>
<h3><?php echo $GLOBALS['TL_LANG']['MSC']['caledit_currentActionHint']; ?></h3>
<p class="caledit_info">
<?php if ($this->CurrentEventLink): ?>
<?php if ($this->CurrentPublished): ?>
<span class="date"><?php echo $this->CurrentDate; ?>: </span><a href="<?php echo $this->CurrentEventLink; ?>" title="<?php echo $this->CurrentTitle; ?>"> <?php echo $this->CurrentTitle; ?> </a>
<?php else: ?>
<span class="date"><?php echo $this->CurrentDate; ?>: </span><span class="title"><?php echo $this->CurrentTitle; ?></span>
<?php endif; ?>
<span class= "caledit_publishinfo"><?php echo $this->CurrentPublishedInfo; ?></span>
<?php if ($this->DeleteEventLink): ?>
<span class="deletelink">
<a href="<?php echo $this->DeleteEventLink; ?>" title="<?php echo $this->DeleteEventTitle; ?>"> <?php echo $this->DeleteEventTitle; ?> </a>
</span>
<?php endif; ?>
<?php else: ?>
<span class= "caledit_publishinfo"><?php echo $this->CurrentPublishedInfo; ?></span>
<?php endif; ?>
</p>
<h3><?php echo $this->EditHeadline ?></h3>
<?php if (!$this->fields): ?>
<p class="error"><?php echo $this->FatalError; ?></p>
<?php else: ?>
<div class="event<?php echo $this->classList; ?>">
<?php if ($this->deleteHint): ?>
<p class="caledit_delete"><?php echo $this->deleteHint; ?></p>
<?php endif; ?>
<div class="form">
<form action="<?php echo $this->action; ?>" method="post">
<input type="hidden" name="FORM_SUBMIT" value="caledit_submit" /><?php echo $this->messages; ?>
<input type="hidden" name="REQUEST_TOKEN" value="{{request_token}}">
<input type="hidden" value="{{user::username}}" name="gast_nr">
<input type="hidden" value="{{user::id}}" name="FE_User">
<input type="hidden" value="event" name="cssClass">
<div class="info">Um eine Zuordnung zu gewährleisten wird Deine Gaststättennummer <strong>{{user::username}}</strong> automatisch gespeichert!</div>
<div class="form_calendar_edit">
<?php if ($this->fields['title']): ?>
<?php $objWidget = $this->fields['title']; ?>
<div class="calender_edit_field title_field">
<div class="label w10"><?php echo $objWidget->generateLabel(); ?></div>
<div class="value w70"><?php echo $objWidget->generateWithError(); ?></div>
</div>
<?php endif; ?>
<?php if ($this->fields['tour']): ?>
<?php $objWidget = $this->fields['tour']; ?>
<div class="calender_edit_field tour">
<div class="label w10"><?php echo $objWidget->generateLabel(); ?></div>
<div class="value w30"><?php echo $objWidget->generateWithError(); ?></div>
</div>
<?php endif; ?>
<?php if ($this->fields['just_dart']): ?>
<?php $objWidget = $this->fields['just_dart']; ?>
<div class="calender_edit_field just_dart">
<div class="label w10"><?php echo $objWidget->generateLabel(); ?></div>
<div class="value w30"><?php echo $objWidget->generateWithError(); ?></div>
</div>
<?php endif; ?>
<?php if ($this->fields['startDate']): ?>
<?php $objWidget = $this->fields['startDate']; ?>
<div class="calender_edit_field date_time">
<div class="label w10"><?php echo $objWidget->generateLabel(); ?></div>
<div class="value w30"><?php echo $objWidget->generateWithError(); ?></div>
<?php endif; ?>
<?php if ($this->fields['startTime']): ?>
<?php $objWidget = $this->fields['startTime']; ?>
<div class="label w10"><?php echo $objWidget->generateLabel(); ?></div>
<div class="value w30"><?php echo $objWidget->generateWithError(); ?></div>
<div class="clearing"></div>
</div>
<?php endif; ?>
<?php if ($this->fields['disz1']): ?>
<?php $objWidget = $this->fields['disz1']; ?>
<div class="calender_edit_field disziplin">
<div class="label w10"><?php echo $objWidget->generateLabel(); ?></div>
<div class="value w20"><?php echo $objWidget->generateWithError(); ?></div>
<?php endif; ?>
<?php if ($this->fields['disz2']): ?>
<?php $objWidget = $this->fields['disz2']; ?>
<div class="value w20"><?php echo $objWidget->generateWithError(); ?></div>
<?php endif; ?>
<?php if ($this->fields['disz3']): ?>
<?php $objWidget = $this->fields['disz3']; ?>
<div class="value w40"><?php echo $objWidget->generateWithError(); ?></div>
<div class="clearing"></div>
</div>
<?php endif; ?>
<?php if ($this->fields['details']): ?>
<?php $objWidget = $this->fields['details']; ?>
<div class="calender_edit_field textarea">
<div class="label w10"><?php echo $objWidget->generateLabel(); ?></div>
<div class="value w70"><?php echo $objWidget->generateWithError(); ?></div>
</div>
<?php endif; ?>
<?php if ($this->fields['published']): ?>
<?php $objWidget = $this->fields['published']; ?>
<div class="calender_edit_field">
<div class="info"><strong>Du bist Dir noch nicht sicher, das Turnier öffentlich zu machen?</strong><br />Macht nichts, einfach den Haken hier nicht setzen. Später kannst Du Dir im Gaststättenbereich, die unveröffentlichten Tunriere anzeigen lassen und den Haken nachträglich setzen oder weitere Informationen bearbeiten!</div>
<div class="value w70"><?php echo $objWidget->generateWithError(); ?></div>
</div>
<?php endif; ?>
<div class="calender_edit_field">
<div class="value w100"><input type="submit" class="submit" value="Turnier eintragen" /></div>
</div>
</div>
</form>
</div>
</div>
<?php endif; ?>
</div>
Leider speichert Deine Erweiterung, nach einem Serverumzug, die Start- & Endzeit zwar als Timestamp, aber nur noch mit der Zeit 00:00.
Ich habe festgestellt, dass in allen Variablen (startTime, endTime, startDate & tstamp) der Timestamp vom Startdatum eingetragen wird, endDate bleibt dagegen leer (sollte ja auch so sein).
Ein Eintrag aus dem Backend funktioniert dagegen einwandfrei und wird auch korrekt in die DB geschrieben.
An Deinem Script habe ich nichts geändert oder angepasst.
Bevor ich es noch vergesse!
Ich habe den Kalender um diverse Felder erweitert, damit es meinen Anforderungen gerecht wird. Hier werden aber nur Texte oder Selectwerte eingetragen, die sich darauf nicht auswirken dürften.
EDIT:
Ich habe mir die aktuelle Version nochmal aus dem Rep. geholt und per FTP hoch geladen. Es hätte ja sein können, dass ein Übertragungsfehler vorliegt, aber keine Besserung.
Wenn trotz Angabe einer Start- oder Endzeit der Timestamp vom Datum mit 0:00 Uhr gespeichert wird, dann werden die Strings vermutlich irgendwie falsch in ein Datum konvertiert.
Wenn eine Startzeit angegeben wird, dann wird das so verarbeitet:
Evtl. läuft da bei $GLOBALS['TL_CONFIG']['datimFormat'] etwas schief. Ansonsten habe ich da auf die Schnelle auch keine Idee. :(PHP-Code:
$s = $eventData['startDate'] . ' ' . $eventData['startTime'];
$startTime = new Date($s, $GLOBALS['TL_CONFIG']['datimFormat']);
$eventData['startTime'] = $startTime->tstamp;
Danke erst mal für den Ansatz.
Im gesamten System funktioniert es ja, demnach müsste da was am event_editor verbogen sein, warum auch immer.
Ich versuche gleich nochmal in den Code zu schauen, ob ich da auf die Schnelle was finde.
Wie gesagt, ich habe nur das Template angepasst und benötige dort nur startTime als Variable.
Ich habe gerade mal die INPUT-Feld (startTime) für des BE mit dem FE verglichen.
Dort sehe ich nur einen Unterschied in der class - BE -> tl_text und FE -> text, ein mandatory bekommt es auch noch dazu.
Könnte das schon entscheidend sein?
Ich kann mir das nicht denken.
Wenn es nötig ist, gebe ich dem endTime eine dummy-Zeit (23:59) mit, als dirty-Lösung.
Braucht es vielleicht besondere Servereinstellungen?
Ich habe die Seite auf einen neuen Server umgezogen.
Allerdings kann ich mir das nicht vorstellen, dann würde das gesamte Contao betroffen sein.
Wie sieht es mit Unverträglichkeiten zu anderen Modulen aus?
Gibt es da vielleicht einen Ansatz?
Bei mir ist zusätzlich calenderfield installiert.
EDIT:
Auffällig ist, dass der automatische Timestamp (tstamp), in der DB, mit dem Wert von startTime überschrieben wird. Obendrein wird dem, scheinbar die falsche Zeit angehängt. Das Datum ist immer korrekt, nur die Zeit stimmt nicht.
Hallo zusammen,
auch ich habe leider das Problem, dass die Erweiterung, nach einem Serverumzug, die Start- & Endzeit nur noch mit 00:00 speichert.
Ich habe die Erweiterung calendarfield mal deaktiviert und auch das Standard-Template anstelle meines angepassten Templates eingesetzt - leider beides ohne Erfolg.
Ich erinnere mich, dass bei der Erweiterung calendar_extended mal Probleme wegen der PHP-Version auf dem Server gab. Vielleicht könnte das hier auch der Fall sein?
@Thomas: Könntest Du das bitte bei Dir auch mal prüfen?
Hat jemand noch eine Idee, woran es liegen könnte?
Ich habe php5 5.3.3-7+squeeze6 laufen!
Diese Version habe ich gerade aktualisiert, in der Hoffnung es würde sich etwas ändern.
Ob das nun an der Version liegt, kann ich nicht sagen.
Ich mache bei einem laufenden Server sicherlich kein Downgrade mehr. ;)
Aber gut, dass es nicht nur ein Phänomen bei mir ist, ich war schon am verzweifeln. :(
Wie gesagt, Neuinstallation, Deinstallation von anderen Modulen oder Default-Templates ändern nichts an der Tatsache.
Ich habe den Code von calenderfield schon rauf und runter, aber die Erweiterung hält sich an den Vorgaben von Contao.
Für das Problem habe ich nochmal eigens einen Thread eröffnet, sonst wird das hier unübersichtlich:
https://www.contao-community.de/show...des-Timestamps
Vielleicht kann das ja ein Moderator kurz dahin verschieben, danke.
Ich habe nun mal alles durchgetestet:
- Contao 2.9.5 (MusicAcademy) und Calendar_Editor frisch auf Contao2Go aufgesetzt - alles funktioniert prächtig
- Contao 2.10.3 (MusicAcademy) und Calendar_Editor frisch auf Contao2Go aufgesetzt - alles funktioniert prächtig
- Contao 2.10.3 und Calendar_Editor Live-Version vom Server auf Contao2Go importiert - gleicher Fehler
- Alle Erweiterungen deaktiviert, alle zusätzlichen Felder über Calendar_Editor_Plus entfernt, Calendar_Editor deinstalliert und neu installiert, Standard-Templates eingestellt - gleicher Fehler
Ich bin jetzt ehrlich am verzweifeln, woran es liegen kann!
In der frischen 2.10.3 (MusicAcademy) wird im Template ein Captcha angezeigt, in meiner importierten Serverversion mit neuer Installation und Standard-Template wird es jedoch nicht angezeigt.
Ich verstehe es vor allem nicht, dass es aus dem BE heraus funktioniert.
Meine Schlussfolgerung ist eben, dass es da ein Problem zwischen der Erweiterung und Contao geben muss.
Interessant ist es, dass es nicht funktioniert, wenn Du eine identische Contoa-Version aus einem Live-System importierst und es dort dann nicht mehr funktioniert.
Es ist jetzt die Frage, ob es ein Ticket wert ist!?
Für einige ist die Funktion ja elementar wichtig und ich gerate langsam unter Zeitdruck, bis Sonntag müsste schon zumindest ein Workarround erarbeitet sein. Mir fehlen dafür aber leider die Mittel.
Was mich daran ärgert, dass es vorher einwandfrei funktionierte.
Ich habe jetzt nochmal über Contao2Go eine blanke 2.10.4 und die Erweiterung installiert - das funktionierte auch wie es soll.
Anschließend habe ich alle Erweiterungen, die ich live einsetze dort ebenfalls installiert - auch dann lief die Erweiterung ohne den Fehler.
Dann habe ich alles wieder blank gesetzt, meine Datenbank aus dem Live-System (2.10.3) importiert, den Ordner tl_files, templates und module aus dem Live-System kopiert und natürlich das Install-Tool aufgerufen. Mit dem Ergebnis, dass das Problem wieder auftrat, obwohl ich für Calendar_editor das Standard-Template benutzte. Da alles andere frisch aus der 2.10.4 kam, kann der Fehler also nur in der Datenbank (was auch immer) oder in den angepassten Templates für die anderen Module liefen, oder???
Vielleicht ist es genau das selbe Phänomen, wie es im Catalog auftritt und tatsächlich der MYSQL-Version geschuldet.
Ich habe keine Ahnung.
Das Catalog-Problem kenne ich noch gar nicht.
Aber scheinbar liegt es hier doch auch an der Datenbank.
Ich habe jetzt mal in eine blanke 2.10.4 mit C2G nur die Live-Datenbank (ohne Templates, ohne Erweiterungen etc.) importiert und dann noch Calendar_Editor installiert. Ergebnis: Wieder der alte Fehler.
Wenn ich jedoch Calendar_Editor in einer blanken (also leeren Datenbank) mit 2.10.4 auf C2G installiere, funktioniert die Erweiterung!
@Thomas
Konnte das Problem beim Catalog gelöst werden? Unter welchem Stichwort kann ich denn danach am besten Suchen?
Bis jetzt gibt es auch da noch keine Lösung!
Da geht es nur darum, ein Feld vom Typ Zahlenwert in der DB zu speichern.
https://www.contao-community.de/show...vom-Typ-Nummer
Ich habe derzeit das lustige Problem, dass das Captcha mal geht und mal nicht. Jetzt liefs wieder 10 Tage und aktuell kommt wieder sowas
PHP-Code:
Fatal error: Call to a member function generateQuestion() on a non-object in /..../templates/eventEdit_....xhtml on line 194
Taucht bei Euch im Quelltext auch das alte typolight Javascript auf?
Das habe ich nur beim Editor mit drin, vielleicht stört genau das den Editor.Code:<script type="text/javascript" src="typolight/typolight.js"></script>
Die Funktion new date() ist eine von Javascript genutzte Funktion und genau da vermute ich das Problem.
Ich werde erst mal sehen wo das Script her kommt. Da das Script unter Contao nicht mehr vorhanden ist, könnte es da schon das Problem geben.
Folgende Änderung, um zumindest die Anpassung für Contao zu gewährleisten:
modules/calendar_editor/ModuleEventEditor.php - Zeile 65
mit Folgendem ersetzen:Code:$GLOBALS['TL_JAVASCRIPT']['rte'] = 'typolight/typolight.js';
Damit wird zumindest das richtige Script für den Tiny geladen.Code:$GLOBALS['TL_JAVASCRIPT']['rte'] = 'contao/contao.js';
Ändert aber nichts an der falschen Speicherung.
Nur zur Info: Ich lese hier eifrig mit. Aber da ich das Problem nicht nachstellen kann, und ich nicht so tief in PHP und/oder SQL drinstecke, kann ich aktiv zur Lösung nichts beitragen. Das scheint ja ein recht merkwürdiger, aber hartnäckiger Fehler zu sein. :(
Ja, Gausi, das ist es!
Ich bin aber gerade schon eifrig dabei, Deinen Code etwas zu editieren.
Vielleicht übernimmst Du das dann in eine spätere Version.
Den Fehler selbst werde ich aber wahrscheinlich nicht finden.
Mir ist es einfach unerklärlich, warum Contao das startDate als tstamp übernimmt und die Zeit nicht richtig speichert, bzw. daraus ein 00:00 macht.
Ich habe schon mit der Serverzeit gespielt, aber alles steht auf Europe/Berlin, auch die Server interne Zeit.
Ich habe hier gleich die nächste Verbesserung:
modules/calendar_editor/ModuleEventEditor.php - Zeile 701
ändern in:Code:'eval' => array('rgxp' => 'date', 'mandatory' => true)
maxlength ist hier zwar nicht so wichtig, aber ich finde es wichtig die Entities zu decodieren (Sicherheit).Code:'eval' => array('rgxp' => 'date', 'mandatory' => true, 'maxlength' => 128, 'decodeEntities' => true)
In allen weiteren Feldern hast Du es drin, aber hier fehlt es. ;)
Ab welcher Stelle ist der Timstamp eigentlich falsch? D.h. wie sieht $eventData unmittelbar vor dem Eintrag in die DB aus (Zeile 364 in ModuleEventEditor, "$objInsert = $this->Database->prepare ..."). Könntest du da mal für Testzwecke eine Ausgabe in eine andere Datei oder so reinbauen?
Dann wäre der Fehler zumindest schonmal eingegrenzt auf die Verarbeitung der Strings aus dem Formular, oder auf die Speicherung der Timestamps in der DB durch das Contao Framework. Womit ich den schwarzen Peter nicht weitergeben möchte - evtl. sind ja die Daten, die ich da liefere, ja nicht zu 100% in dem Format, das Contao da erwartet.
Wenn Du mir auch sagst wie ich so etwas am Besten machen kann?
Ich habe keinen Plan, wie man dort eine Ausgabe generiert.
Am Besten wäre ja, wenn die Ausgabe vor dem Eintrag in die DB erfolgt und vorerst auch keinen Eintrag vornimmt, sondern dort ein break macht.
Oder eine Übergabe an die Bestätigungsseite!
Damit könnte man auch gleich eine Ausgabe erzeugen, welche Daten gespeichert wurden. :)
Dazu fehlen mir die Mittel.
Mist, ich dachte, du wüsstest das. Wie man sowas am besten macht, ist mir nämlich auch noch etwas schleierhaft. :p
Ist zwar nicht schön formatiert, aber das
vor dem Block mitPHP-Code:
file_put_contents('caleditDEBUG.txt', serialize($arrEvent));
sollte im Rootdir die Datei caleditDEBUG.txt anlegen und die Daten, die an die DB übergeben werden, in halbwegs lesbarer Form speichern.PHP-Code:
$this->Database->prepare ...
Hmmm, da kommt nicht viel bei rum:
Sowohl als Ausgabe für einen Neueintrag, als auch für das Bearbeiten eines Events.Code:N;
Ich habe das jetzt hier eingesetzt (Zeile 366-375):
Fehlermeldung keine, er legt nur die Dateien an.Code:if (empty($OldId)) {
// create new entry
file_put_contents('caleditDEBUG_new_cal.txt', serialize($arrEvent));
$objInsert = $this->Database->prepare('INSERT INTO tl_calendar_events %s')->set($eventData)->execute();
}
else {
// update existing entry
file_put_contents('caleditDEBUG_old_cal.txt', serialize($arrEvent));
$objUpdate = $this->Database->prepare("UPDATE tl_calendar_events %s WHERE id=?")->set($eventData)->execute($OldId);
}
Kann euch das System-Log bei der Suche helfen?
http://de.contaowiki.org/System-Log
Gruß, folkfreund
Ups, da hatte ich wohl eine alte Version zum rauskopieren des Codes genommen. :o Da hab ih wohl zwischendurch was umbenannt.
In die Datei soll das Objekt, was auch in die DB kommen soll, also
PHP-Code:
file_put_contents('caleditDEBUG_new_cal.txt', serialize($eventData));
$objInsert = $this->Database->prepare('INSERT INTO tl_calendar_events %s')->set($eventData)->execute();
Ja, da folgt jetzt auch eine Ausgabe: ;)
1. Ausgabe:
29.02.2012 - 12:00 Uhr
2. Ausgabe:Code:a:19:{s:9:"startDate";i:1330470000;s:7:"endDate";N;s:9:"startTime";i:1330470000;s:7:"endTime";i:1330470000;s:5:"title";s:15:"CD Tour Turnier";s:6:"teaser";N;s:7:"details";s:23:"<p>testen mit debug</p>";s:8:"cssClass";s:5:"event";s:3:"pid";s:1:"2";s:9:"published";s:0:"";s:7:"gast_nr";s:7:"gast120";s:4:"tour";s:12:"CD Tour 2012";s:5:"disz1";s:7:"Offenes";s:5:"disz2";s:6:"Einzel";s:5:"disz3";s:8:"301 M.O.";s:7:"FE_User";s:1:"3";s:5:"alias";s:18:"cd-tour-turnier-67";s:6:"tstamp";i:1330470000;s:7:"addTime";s:1:"1";}
28.02.2012 - 13:00 Uhr
Wie man sieht, werden die tstamps augenscheinlich hier schon verkehrt umgerechnet, bzw. falsch gefüllt.Code:a:19:{s:9:"startDate";i:1330383600;s:7:"endDate";N;s:9:"startTime";i:1330383600;s:7:"endTime";i:1330383600;s:5:"title";s:15:"CD Tour Turnier";s:6:"teaser";N;s:7:"details";s:23:"<p>testen mit debug</p>";s:8:"cssClass";s:5:"event";s:3:"pid";s:1:"2";s:9:"published";s:0:"";s:7:"gast_nr";s:7:"gast120";s:4:"tour";s:12:"CD Tour 2012";s:5:"disz1";s:7:"Offenes";s:5:"disz2";s:6:"Einzel";s:5:"disz3";s:8:"301 M.O.";s:7:"FE_User";s:1:"3";s:5:"alias";s:18:"cd-tour-turnier-68";s:6:"tstamp";i:1330383600;s:7:"addTime";s:1:"1";}
Also liegt der Fehler nicht in Contao oder der Datenbank, sondern in meinem Code. Da dürften dann diese Zeilen verantwortlich sein
Da wird der startTime-String aus dem Formular durch den Timestamp ersetzt. Da ich nicht genau verstehe, was da passiert, bzw. wie die Erzeugung des Date-Objektes abläuft (den Teil habe ich aus diesem Posting), kann ich da nicht soviel zu sagen. Evtl. findest du per Google eine andere Möglichkeit, einen String in einen Timestamp umzuwandeln, der zuverlässiger funktioniert.PHP-Code:
$s = $eventData['startDate'] . ' ' . $eventData['startTime'];
$startTime = new Date($s, $GLOBALS['TL_CONFIG']['datimFormat']);
$eventData['startTime'] = $startTime->tstamp;
(Evtl reicht einfach DateTime anstelle von Date? Oder ist $GLOBALS['TL_CONFIG']['datimFormat'] bei dir verkehrt gesetzt?)
Ich verstehe nicht ganz, warum Du hier new Date() verwendest.
Wird die Uhrzeit denn mit Ajax (Javascript) geparsed?
In PHP gibt es die Funktion new Date() ja nicht, aber für Javascript schon.
PHP: time - Manual
PHP: microtime - Manual
PHP: date - Manual
Interessant wäre vielleicht folgendes:
Keine Ahnung ob das Funktioniert.Code:$startTime = date($eventData['startTime'], "H:i:s"); <-- Contao hat dafür eine Funktion, leider habe ich keinen Plan wo die gespeichert wird, in den Einstellungen kann man es angeben, aber in der localconfig.php wird sie nicht gespeichert, im Gegensatz zu dateFormat und datimFormat (vermutlich timeFormat)
$eventData['startTime'] = $startTime->tstamp;
Ich habe da nicht wirklich den Plan und für mich sind die meisten Dinge böhmische Dörfer, vielleicht hilft es Dir aber weiter.
@folkfreund
Nein, das bringt uns nicht weiter.
Hab da grade mal nachgeschaut, weil ich wie gesagt diese zeilen von jemand anderem übernommen habe.
Die Klasse Date ist Teil von Contao (system/libraries/Date.php). Mit new Date(...) wird also ein neues Date-Objekt erzeugt, mit Javascript hat das nichts zu tun. Wenn der erste Parameter kein Integer ist, wird der entsprechend des zweiten geparsed. Dieser ist hier fix der Wert, der in den Einstellungen von Contao unter "Datums- und Zeitformat" angegeben ist. Der sollte in etwa sein "d.m.Y H:i".
Ok, das würde sich dann aber mit der Javascript-Geschichte beißen, sollte Jemand ein entsprechendes Script laden. Aber das steht erst mal auf einem anderen Blatt.
new date() also abgehakt! :)
Könnte es vielleicht daran liegen, das Du startTime sowohl als Input, als auch als Variable verwendest?
Könnte sich das beißen?
Ich würde das so schreiben:
So würde es zumindest mal keine Kollision zwischen den gleichnamigen Variablen geben.Code:$s = $eventData['startDate'] . ' ' . $eventData['startTime'];
$datetimeFormat = new Date($s, $GLOBALS['TL_CONFIG']['datimFormat']);
$eventData['startTime'] = $datetimeFormat->tstamp;
Respektive anwendbar auf alle anderen Felder.
Hi, Gausi!
Bist Du da dran?
Oder gerade ausgelastet?
Hört sich vielleicht blöd an, aber da kann ich nichts dran machen, da ich den Fehler bei mir nicht reproduzieren kann. Weder auf zwei Echtsystemen, noch lokal mit Xampp. :(
Zur Fehlersuche fallen mir da nur einige Debug-Ausgaben ein, die an den unterschiedlichen Stellen die Variablen z.B. in eine Textdatei schreiben.
An den Variablennamen sollte es eigetlich nicht liegen, das $eventData['startTime'] ist ja völlig unabhängig von $startTime.
Ansonsten probier einfach, die Datums-Umwandlung wieder mit strtotime durchzuführen, also
Da das aber nicht unbedingt mit allen Formaten klarkommt, habe ich das vor einiger Zeit durch die (hier wohl nicht funktionierende) Methode ersetzt.PHP-Code:
$s = $eventData['startDate'] . ' ' . $eventData['startTime'];
$eventData['startTime'] = strtotime($s);
Danke, das habe ich jetzt in allen relevanten Funktionen angepasst und funktioniert auch.
Mir ist noch eingefallen und vielleicht hilft das weiter.
Ich stelle dem Benutzer ein Formular zur Verfügung, indem nur das Anfangsdatum und die Anfangszeit eingetragen werden darf. Demnach bleiben Enddatum und Endzeit immer leer.
Jetzt habe ich das so gestrickt, das Dein Script generell für diesen Zweck immer Anfangsdatum und Anfangszeit in die Enddaten einträgt.
Augenscheinlich, funktioniert das nicht richtig mit Hilfe der Funktion new date().
Die Option, relevante Daten mit dem Hook, vor dem Eintragen noch zu verändern, habe ich gar nicht ausprobiert.
Ich könnte mir aber denken, dass man vorher das Startdatum und die Startzeit nochmals abfängt und für Enddatum und Endzeit vorbereitet und dann erst speichert.
Mit der jetzigen Anpassung kann ich aber sehr gut leben, muss ich halt Deine Erweiterungen von Aktualisierungen ausnehmen. ;)
Das ist aber nicht nötig, da das automatisch passiert. ;)
Wenn kein Enddatum gesetzt wird, wird NULL dafür in die DB eingetragen (es sei denn, es wird eine Endzeit eingegeben).
Wenn eine Startzeit, aber keine Endzeit eingetragen wird, dann wird die Startzeit auch als Endzeit benutzt, um ein "Event mit offenem Ende" zu erzeugen, wie es im Backend beschrieben ist. Das etwas umständliche ausfüllen mit gleichen zeitwerten dafür wie im Backend ist hier nicht erforderlich.
Deshalb habe ich ja geschrieben, dass das in meinem Fall scheinbar nicht funktioniert.
Daher befüll ich einfach die Spalten mit den selben Werten und umgehe damit *dirty* diesen Umstand. ;)
Moin, moin!
Wäre es nicht besser, wenn man die Parameter (?edit=xxx), in der URL-Adresse, per Session weiter gegeben werden?
Ich habe das Template z.B. so umgeschrieben, das die Bearbeitung nur an bestimmten Tagen durchgeführt werden darf.
Hierzu kann der Seitenbetreiber sowohl einen bestimmten Tag im Monat, z.B. immer den 25., oder aber ab einem bestimmten Datum die Bearbeitung, über das Backend, sperren.
Damit ist aber nicht das Modul selber gesperrt und man kann die Einträge mit der Angabe von URL?edit=xxx dennoch aufrufen und bearbeiten.
Damit eben keiner auf diese glorreiche Idee kommt, würde ich gerne die Parameter verstecken.
Gerne auch per htaccess, hierzu habe ich leider nicht viel gefunden.
folderurl -> uninteressant, es müssen keine Ordner versteckt werden
redirect4ward -> ebenso, es sei denn ich habe da eine Möglichkeit übersehen
urlcleaner -> bringt auch nicht die Funktion mit, auch da könnte ich aber etwas übersehen
Hm, ich würde diese Funktion dann eher irgendwie in die Logik des Moduls einbauen. Bei den Events gibt es ja jetzt schon die Möglichkeit, übers Backend einzelne Events von der Frontend-Bearbeitung auszusperren. Das ließe sich ggf. erweitern. Mehr als eine Form "Bearbeitung nur erlauben von ... bis" würde ich da aber nicht reinbringen wollen. Das wäre dann vermutlich zu speziell.
Wie sieht denn bei dir der Anwendungsfall aus, dass so etwas benötigt wird?
Ich versuche das mal an einem Beispiel näher zu bringen!
In einem Magazin werden Veranstaltungen veröffentlicht, die immer im nächsten Monat liegen müssen.
Einträge = aktueller Monat + 1 Monat (letzter Tag des Monats)
Das heißt, im März dürfen nur Einträge für den April oder später gemacht werden, usw.!
Diese werden dann auch im Magazin publiziert, welches monatlich, um den 1. rum, erscheint.
Redaktionsschluss z.B. der 25. jeden Monats.
Zusammengefasst:
1. der Benutzer darf nur Events bis zum Redaktionsschluss eintragen -> wird von der Redaktion festgelegt, es reicht der Tag, z.B. jedes mal der 25. des aktuellen Monats
2. vom Redaktionsschluss bis zum Sperrdatum dürfen keine Einträge getätigt werden -> Sperrdatum wird wieder von der Redaktion festgelegt, man könnte auch hier nur den Tag heranziehen
3. immer nur ab dem nächsten Monat eintragbar
Mit dem Tag lässt sich am besten der Vergleich im Modul realisieren ohne ständig die Timestamps wieder umwandeln zu müssen, Beispielcode folgt gleich. ;)
Ich habe das jetzt als Rohentwurf so gelöst:
Mit EFG ein Formular erstellt in dem der Redakteur die Tage eintragen kann.
event_upcoming-Template mit folgendem Code ergänzt: (funktioniert auch)
Respektive findet dieser Weg auch im eventEdit_default-Template statt, um das Sperrdatum auszulesen und einen Hinweis darauf zu geben, dass bis zum Sperrdatum keine Einträge möglich sind.Code:<?php
// Tag für Redaktionsschluss auslesen
$this->import('Database');
$result = $this->Database->prepare("SELECT * FROM tl_formdata_details")
->limit(1,1)
->execute();
if ($result->numRows) {
$lastdayRedaktions = $result->fetchAllAssoc();
foreach ($lastdayRedaktions as $lastdayRedaktion)
{
$redaktionDeadline = $lastdayRedaktion['value'];
}
} ?>
...
<?php if(date("j", time()) <= $redaktionDeadline): ?>
<?php if ($this->editref): ?>
<div class="editlink"><a href="<?php echo $this->editref; ?>" title="<?php echo $this->editTitle; ?>"> <?php echo $this->editLabel; ?> </a></div>
<?php endif; ?>
<?php elseif(date("j", time()) > $$redaktionDeadline): ?>
<div class="redaktion_deadline">Redaktionsschluss</div>
<?php endif; ?>
Natürlich wäre es schön, wenn der Editor diese Möglichkeit als Option mitbringt.
Besser noch, eine optionale Erweiterung des Editors, diese Option benötigt ja nicht jeder.
Dadurch, dass der Bearbeiten-Link die ID des Eintrages mit bekommt, ist diese ja auch im Browser sichtbar.
Demnach könnte der Benutzer einfach eine ID mit anhängen und diese dann bearbeiten.
Und das wäre nicht gut.
Wichtig wäre auch eine Kontrolle, ob der Benutzer auch der Besitzer ist.
Nochmal meinen Wunsch im Einzelnen:
1. eine Auswahlmöglichkeit - nur Einträge in einer bestimmten Zukunft tätigen zu können, z.B. aktueller Monat +1 Woche, +1 Monat, +2 Monate usw.
2. Redaktionsschluss oder Eintragsstop
3. Sperrdatum -> Dauer vom Eintragsstop bis zum Sperrdatum, danach wieder Freigabe
2.1. + 3.1. ein Formular für die Bearbeitung, nur im BE über Gruppenrechte
4. wenn möglich gecleante URL (SESSION)
Letzteres würde sicherlich ein wenig die Sicherheit erhöhen.
Denkbar wäre auch eine Kontrolle, ob es sich nur um einen Zahlenwert handelt. Dann können auf dem Wege auch keine bösen Codes geladen werden.
Soweit habe ich jetzt nicht in Deinen Code geschaut, um zu sehen, ob das nicht schon passiert. Ich weiß eben nur, dass man die ID beeinflussen kann.
Ich hoffe, das kam einigermaßen verständlich rüber. :)
Nachtrag:
Mir ist gerade eingefallen:
Ich benutze dasselbe Formular für Bearbeitung und Eintragung.
Demnach müsste es auch gesperrt sein, wenn die ID beeinflusst wird.
Das teste ich nachher nochmal, gerade sitze ich aber an einer anderen Geschichte.
Ah, ok. Einsatzzweck verstanden, glaube ich. :)
Wenn ich das richtig sehe, sollte das eine Ergänzung zu den Einstellungen sein, die im Kalender vorgenommen werden. Da gibt es ja bisher die Optionen "FE Bearbeitung erlauben" und "Nur zukünftige Events".
Diese Optionen müssten dann erweitert werden um ein "von...bis". Die FE-Bearbeitung wäre dann z.B. generell erlaubt "von 1. April bis 25. April", und bei zukünftige Events "von 1.Mai bis Ende der Welt". Das müsste man dann einmal im Monat im BE aktualisieren. Das automatisiert zu verlängern, oder das über den X.ten im Monat zu machen, wäre imho zu sehr an diesen speziellen Fall gebunden. Evtl. ließe sich sowas aber über einen Cronjob erledigen.
Dass die ID per Parameter übergeben wird, sollte dann eigentlich kein Problem sein. Wenn eine ungültige ID probiert wird, kommt ja auch jetzt schon eine Fehlermeldung. Und da ich beim Einlesen der Parameter das Contao-Framework nutze, sollte darüber auch kein Schweinkram mit der DB möglich sein.
Ich schreib das mal auf die Todo-Liste hierfür. Aber ich habe aktuell noch ein paar andere Listen, die höhere Priorität haben. Könnte also was dauern. ;)
Danke, ich komme mit der Lösung auch erst mal zurecht! ;)
Wenn Du das umsetzen kannst ist das schon mal super und nutzt bestimmt dem Ein oder Anderen bei späteren Umsetzungen.
Bei mir ist jetzt allerdings ein völlig obskurer Umsetzungswunsch dazu gekommen, der meinem ersten Wunsch nicht mal mehr im Entferntesten entspricht.
Ich fange einmal klein an. :)
1. Festlegung eines Sperrdatums
1.1. dieses Sperrdatum sorgt dafür, dass man Termine nur bearbeiten oder eintragen kann, wenn das aktuelle Datum vor der Sperrzeit liegt, das Datum kann auch vor dem Letzten des Monats liegen
1.2. der gesamte Folgemonat wird auch gleich gesperrt, da es Ziel ist, das der Benutzer die Termine, nach Redaktionsschluss des Magazins nicht mehr ändern kann, der Folgemonat fließt mit in die Ausgabe
1.3. Termine nach dem Folgemonat sollen weiterhin zu bearbeiten sein
1.4. gleichzeitig wird die Möglichkeit Termine einzutragen gesperrt, solange bis das Sperrdatum in die Zukunft verlegt wird, das ist auch gut so, denn ich weiß im Moment nicht, wie ich der calenderfield-Erweiterung beibringen kann, dass ab jetzt nur noch Termine ab dem 1. des übernächsten Monats eintragbar sein sollen. Dafür müsste ich nur den Kalender vor dem übernächsten Monat sperren können. Lauter ?????
2. Erscheinungstermin, das ist die leichteste Übung daran. :D
Schwierigkeiten die dabei auftraten?
1. Welche Datumwerte nimmt man als Vergleichswerte?
2. Wie gleiche ich die Schaltjahre aus?
3. Welche Vergleichsoperatoren für die unterschiedlichen Behandlungsmethoden, um die Anzeige der Bearbeitungslinks zu steuern?
4. Welche Reihenfolge muss ich dabei einhalten?
Das Ganze habe ich jetzt erst mal Hardcoded, in Templates implementiert und wandert bei Zeiten vermutlich in ein Modul.
Die erste Umsetzung ist doch sehr umfangreich, da werde ich nochmal bei müssen und den Code etwas überarbeiten.
Ich bin jedenfalls froh, das erst mal ans Laufen gebracht und die nicht gerade Nervenschonenden Vergleichsoperatoren geknackt zu haben. :)
Hallo Gausi,
hallo Thomas,
ich habe ja das gleiche Problem bei den Uhrzeiten gehabt. Egal ob ich Start- und Endzeit oder nur die Startzeit eingetragen habe, wurde immer 00:00 eingetragen.
Habt Ihr das Problem lösen können? So ganz habe ich Eure Antworten dazu nicht verstanden. Wo müsste ich denn was anpassen?
Vielen Dank für Eure Hilfe.
Moin pandroid!
Das musst Du im Quelltext der Erweiterung ändern und dann gegen Updates schützen.
Ich komme gerade nicht dazu, aber wenn ich Morgen dran denke lade ich Dir die angepasste Version hoch.
Oder Du findest die Stelle in der Zeit selber, dann gib kurz Bescheid. ;)
Hallo!
Hier ein kleiner Lösungsansatz mit dem wir das Problem mit den Zeitstempeln in den Griff bekommen haben, ohne die Erweiterung anzupassen.
Problem:
Die Erweiterung benutzt zum parsen des Datums/der Uhrzeit die Date-Klasse von Contao zusammen mit den Konfigurationswerten "dateFormat" und "datimFormat". Wenn eine Uhrzeit eingetragen wurde, werden Datum und Uhrzeit jedoch einfach mit einem Leerzeichen aneinandergehängt. Falls der Konfigurationswert "datimFormat" nun aber nicht genau "Datumsformat" + Leerzeichen + "Zeitformat" lautet, klappt das nicht!
Lösung:
Im Backend unter "Eintellungen/Datum und Zeit" das "Datums- und Zeitformat" so einstellen, dass es genau "Datumsformat" + Leerzeichen + "Zeitformat" entspricht.
Mit diesen Einstellungen hat es bei uns dann geklappt.
Ich hoffe das hilft Euch weiter :-)
Ah, das hört sich sehr schlüssig an!
Ist das bei den anderen, die dieses Problem hatten, auch der Fall? Über eine Rückmeldung (hier im Thread oder per PN/Mail) wäre ich sehr dankbar. Denn dann wäre zumindest die Ursache dafür endlich gefunden, und ich könnte mich mal daran setzen, das anders zu lösen. :)
Das Problem daran ist, dass ich im gesamten System ein anderes Format verwende.
Welches über die Einstellungen deklariert ist.
Das habe ich aber auch irgendwie im Modul selber angepasst, auch der Wunsch nach einem Sperrdatum für die Datumsauswahl habe ich dirty im Modul angepasst.
Da ich für diese Seite definitiv bei der 2.10.4 bleiben werde, macht das nicht weiter was aus, sperre ich halt das Modul vor Updates. ;)
Die Anpassungen kann ich leider nicht bereit stellen, da sie speziell an die Anforderungen des Kunden angepasst sind.
Der Kunde kann an anderer Stelle (nicht Events) eintragen, ab wann der Benutzer erst wieder Termine eintragen darf.
Danach reagiert calender_events und vergleicht das Sperrdatum mit dem eingetragenen Datum und gibt eine Fehlermeldung aus, sollte der Termin vor diesem Sperrdatum liegen.
Ganz nützlich, wenn man z.B. Redaktionszeiten vorgeben möchte.
Hier wird z.B. eine Zeitung mit Terminen für den nächsten Monat gedruckt. Damit die Zeitung und die Seite auf gleichem Stand sind und Niemand weitere Termine eintragen kann, ohne dass sie den Weg in die Zeitung gefunden haben, wurde das Sperrdatum nötig.
Der Benutzer kann aber weiterhin Termine eintragen, halt erst für Zeiten nach diesem Datum.
Ok, aber dann ist bei dir auch ein Datum-Zeit-Format, welches nicht so aussieht, wie es der Editor hier erwartet, die Ursache für das Problem? Ich will ja auch nicht fordern, dass jetzt jeder das Format so einstellt, nur damit diese Erweiterung funktioniert ;).
Das ist ganz klar ein Bug, wenn nicht gar ein Designfehler, den ich jetzt hoffentlich schnell ausbügeln kann. Ich muss dann halt mal schauen, wie ich anderweitig aus den beiden Eingaben einen Timestamp bekomme. :)
Ja gut, die Daten kamen Anfangs per CSV aus einem anderen System, vielleicht ist genau das der Punkt.
Es war ja sogar so, dass das Fremdsystem scheinbar nicht mit CMT gearbeitet hat und obendrein eine andere Systemzeit hatte.
Da musste ich schon Anpassungen vornehmen.
Man hätte hingehen können und die Daten nochmals aufbereiten können, aber so war das etwas einfacher für mich.
Obendrein habe ich das Modul etwas besser kennenlernen dürfen, sodass ich es eben so anpassen konnte, wie vom Kunden gewünscht. :)
Hier habe ich eine Abfrage eingebaut, die sich ein Datum aus einer Tabelle der Formular-Daten holt und als Sperrdatum fungiert.
So konnte ich dem Kunden ein Formular zur Verfügung stellen, indem er dieses Datum immer wieder neu anpassen kann.
Unter Beachtung der Einstellung *Events nur in der Zukunft* kann der Kunde nun die Eingabe von Terminen bis zu dem Zeitpunkt sperren, ohne dabei dem Mitglied generell die Eingabe zu untersagen.