Query debuggen mit Extbase

Eine Abfrage ans Repository bleibt leer? Aber warum? Welcher Parameter in der Abfrage führte zum leeren Ergebnis?

Leider erhält man nicht so rasch die SQL-Query, die hier abgefeuert wurde. Aber mit einem kleinen Eingriff wird man doch schlauer: folgenden Schnipsel vor dem $query->execute(); einfügen:

/** @var Typo3DbQueryParser $queryParser */
$queryParser = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Extbase\\Persistence\\Generic\\Storage\\Typo3DbQueryParser');
\TYPO3\CMS\Extbase\Utility\DebuggerUtility::var_dump($queryParser->parseQuery($query));

Update 2017-12-06

In TYPO3 8.x ist durch die Integration von Doctrine der Aufruf etwas anders

$queryParser = $this->objectManager->get(\TYPO3\CMS\Extbase\Persistence\Generic\Storage\Typo3DbQueryParser::class);
\TYPO3\CMS\Extbase\Utility\DebuggerUtility::var_dump($queryParser->convertQueryToDoctrineQueryBuilder($query)->getSQL());

 

Quellen:

„Nächster Montag“ via TypoScript

Im TYPO3.net-Forum ist die Frage aufgetaucht, wie man denn „nächster Montag“ via TypoScript errechnen könne? Mich hat die Fragestellung gereizt…


Die eigentliche Schwierigkeit fand ich eher darin, eine Berechnungsformel zu finden. Nach etwas Nachdenken und Nachlesen, welche Werte die Datumsfunktionen date()/strftime() liefern können, stand die Berechnung fest:

Man nehme den aktuellen UNIX-Zeitstempel und addiere hierzu: acht minus den aktuellen Wochentag als Zahl, multipliziert mit den Sekunden eines Tages.

page.555 = COA
page.555 {
  stdWrap.prioriCalc = 1
  stdWrap.strftime = %A, %d.%m.%Y
  10 = TEXT
  10 {
    data = date: U
  }
  20 = TEXT
  20 {
    data = date: U
    strftime = %u
    wrap3 = +(8-|)*(24*60*60)
  }
}

Quellen

TYPO3_cliMode – Breaking Change in TYPO3 8.0

Mit TYPO3 8.0 hat sich bei CLI Skripten eine Kleinigkeit geändert. Die Konstante TYPO3_cliMode ist fortan undefiniert. Mich hatte es eine Weile gekostet, bis ich drauf kam, warum mein CLI-Aufruf stets mit einem „Access denied“ starb. Mit der richtigen Suche findet sich in der Changelog-Doku dann aber des Rätsels Lösung:

==========================================
Breaking: #72368 - TYPO3 Constants removed
==========================================

Description
===========

The PHP constants ``TYPO3_enterInstallScript`` and ``TYPO3_cliMode`` and the global variable ``$GLOBALS['TYPO3_AJAX']`` which were used when a TYPO3 Request was initialized have been removed. They have been replaced by an alternative to use the ``TYPO3_REQUESTTYPE`` constant at the very beginning of each TYPO3 request.


Impact
======

Checking for the mentioned constants and global variable have no effect anymore and may lead to unexpected behaviour.

If not checked if the constant even was defined, the application will stop immediately.


Affected Installations
======================

Any installation which uses a third-party extension using these constants.


Migration
=========

Use ``TYPO3_REQUESTTYPE & TYPO3_REQUESTTYPE_CLI`` or ``TYPO3_REQUESTTYPE & TYPO3_REQUESTTYPE_INSTALL`` instead.

.. index:: php

Translate-ViewHelper und Fluid-Inline-Notation in Attributen

Eigentlich ganz simpler Fall: in ein Sprachlabel soll eine Variable eingesetzt werden, die wiederum per ViewHelper zuvor verändert werden soll. Ein typisches Beispiel ist eine Anzeige der letzten Aktualisierung.

Die einfache Variante des ViewHelpers ohne eine ViewHelper-Anwendung auf das Argument:

<f:translate key="last_updated" arguments="{0: update_timestamp}" />

Möchte man ViewHelper in Inline Notation innerhalb des arguments-Attributs anwenden, so sind die Array-Werte innerhalb des Arrays in Singlequotes zu fassen (und darin befindliche Singlequotes ggf. zu escapen):

<f:translate key="last_updated" extensionName="{extensionName}" arguments="{0: '{update_timestamp->f:format.date(format:\'d.m.Y H:i\')}'}" />

Http-Header aus TYPO3 heraus

Schon öfters standen wir vor dem Problem, dass TYPO3 irgendwelche HTTP-Header liefert, nur nicht die, die wir erwarteten. Heute bin ich auf die Spur gestoßen: bei einem Kunden blieben gelöschte Seiten im Index der Suchengine. Ursache war, dass bei gelöschten Seiten eine Defaultseite mit aktuellem Inhalt gezeigt wurde – nur wurde dabei kein 404 odgl. gesendet, sondern ein „302 Found“, wodurch die veraltete URL dem indexer als in Ordnung suggeriert wurde. Das brachte aber die indizierten Inhalte durcheinandern.
Weiterlesen

„Clear cache“-Buttons – Welcher tut eigentlich was?

Immer wieder taucht die Frage auf, welchen der Cache-Buttons man nun eigentlich leeren müsse, um eine bestimmte fest-gecachte Einstellung aufzufrischen, oder welche für die Holzhammer-Methode (alles löschen) eigentlich nützlich ist. Im Zweifelfall drückt mal einfach alle Buttons – ohne zu wissen, warum eigentlich oder was man da eigentlich tut.

Markus hat in einem Blogbeitrag einmal zusammengefasst, welcher Button welche Caches leert, und welcher Cache für was zuständig ist. Danke!

TYPO3 CMS „clear cache“ buttons explained
(als PDF-Backup)