• die Klassen werden nicht geladen, autoload ist bei Typo3-v7 anders
• die Grafiken werden nicht geladen, der Pfad zu gfx hat sich geändert
• die Bezeichner in den Formularen (Klassen) haben sich geändert; javascript greift dadurch völlig daneben
• die Struktur des Config-arrays der Formularseite hat sich geändert; die Funktion getConfig muß total neu geschrieben werden;
• kleinere Änderungen

zunächst werden die Klassen nicht geladen. unser TYPO3 läuft im sogenannten composer Mode. Es gibt eine zentrale composer.json im Root der TYPO3-Installation. Wenn die Studip-Extension im Verzeichnis typo3conf/ext/ installiert ist, müssen diese Zeilen der composer.json hinzugefügt werden:

"autoload": {
          "psr-4": {
            "UniPassau\\Importstudip\\": "typo3conf/ext/importstudip/Classes/"
          },
          "classmap": [
                      "typo3conf/ext/importstudip/Resources/Private/PHP/restclient/"
                      ]
        }

Ich habe dann noch folgendes gemacht:

php composer.phar dumpautoload
rm -rf /var/www/htdocs/typo3temp/Cache/*

dieses „dumpautoload“ soll den compoeser veranlassen, alle Klassen neu zu laden. Ob das wirklich nötig ist weiß ich nicht. Zusätzlich habe ich den TYPO3-Cache gelöscht. Auch dieser Schritt ist vielleicht nicht nötig.

Es werden jetzt alle Klassen aus dem „Classes“-Verzeichnis geladen und zusätzlich eine Klasse RestClient.

Nach dem Studium des allwissenden Internet bin ich auf diese Lösung gestoßen:

You are calling your code statically, which is not the case with this function and that is the reason your call fails!

Please try this:

$flashMessageService = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\Messaging\FlashMessageService::class);
$messageQueue = $flashMessageService->getMessageQueueByIdentifier();
$messageQueue->addMessage($message);

Ich habe also in der Datei „StudipRESTHelper.php“ diese Zeile

\TYPO3\CMS\Core\Messaging\FlashMessageQueue::addMessage($message);

durch diese Zeilen ersetzt:

$flashMessageService = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\Messaging\FlashMessageService::class);
$messageQueue = $flashMessageService->getMessageQueueByIdentifier();
$messageQueue->addMessage($message);

dieser Fehler ist eine Folge dieses Datenbankfehlers oder umgekehrt:

ERROR => "Column 'data' cannot be null" (28 chars)
   lastBuiltQuery => "INSERT INTO tx_importstudip_config (route,data,mkdate,chdate) VALUES ('exter
      n/externalpagetypes',NULL,'1468565423','1468565423')" (128 chars)

hier wird „NULL“ als Daten übergeben, und das ist scheinbar nicht erlaubt.

Beim Gegner finde ich in der access.log:

GET /api.php/extern/externalpagetypes HTTP/1.1" 401 39 "-" "PHP RestClient/0.1.2"

und bei direktem Aufruf der api:

HTTP/1.1 403 Route not activated

das ist es aber nicht, die Anmeldedaten stimmen nicht

es gibt erstmal einen anderen Fehler:

array(4 items)
   caller => "TYPO3\CMS\Core\Database\DatabaseConnection::exec_UPDATEquery" (60 chars)
   ERROR => "Unknown column 'extern' in 'where clause'" (41 chars)
   lastBuiltQuery => "UPDATE tx_importstudip_config SET data='[\"0\",\"1\",\"5\",\"9\"]',chdate='1
      468823674' WHERE route=extern/externalpagetypes" (123 chars)

Hier wird kein String an den SQL-Updater übergeben. Ich habe folgendes geändert:

diff StudipConnector.php.org StudipConnector.php
337c337
<                         'route=' . $route,
---
>                         'route=' . "'" . $route . "'",

Dieser Fehler taucht vermutlich immer dann auf, wenn der Cache abgelaufen ist und die DB-Tabellen aktualisiert werden müssen.

hier hängt er fest:

00211:     public function chooseUserInstitute($parameters, $config) {
00212:         print_r($parameters['row']['pi_flexform']); 

00213:         $config = self::getConfig($parameters);

00214:         $html = '<div id="tx-importstudip-choose-user-institute" data-input-name="'.
00215:             $parameters['itemFormElName'].'" data-input-value="'.

und als Folgefehler

00597:         #$data=$data[0];
00598:         // Extract already configured flexform values.

00599:         $xml = simplexml_load_string($data['row']['pi_flexform']);

00600:         if ($xml) {
00601:             $json = json_encode($xml);

es wird ein String erwartet für simplexml_load_string, aber ein array übergeben

$data=$data[0];

die vollständige Funktion sieht jetzt so aus:

 public static function getConfig($data) {
        $result = array();
        // Extract already configured flexform values.   
        $data=$data[0];
        $xml = simplexml_load_string($data['row']['pi_flexform']);
        if ($xml) {
            $json = json_encode($xml);
            $fullConfig = json_decode($json, true);
            $fullConfig = $fullConfig['data']['sheet']['language']['field'];  
            foreach ($fullConfig as $c) {
                $result[$c['@attributes']['index']] = $c['value'];
            }
        }
        return $result;
    }

die Fehlermeldung mit dem simplexml_load_string ist jetzt weg!

der Fehler ist weg, die Funktion macht aber jetzt rein garnix mehr, es werden keine Konfigurationsdaten gespeichert. Mit python wäre das nicht passiert

neuer Versuch mit dieser komplett neuen Funktion, nachdem ich die Struktur des Arrays durchsucht habe:

public static function getConfig($data) {
        $result = array();
        // Extract already configured flexform values.
        $config = $data['row']['pi_flexform']['data']['dataSheet']['lDEF'];
        if (is_array($config)) {
            foreach ($config as $key => $value) {
                $result[$key] = $value['vDEF'];
            }
        }
        return $result;   
    }

sieht jetzt so aus:

PHP Runtime Deprecation Notice: Non-static method UniPassau\Importstudip\Utility\ConfigForm::getStatusgroupForm() should not be called statically, assuming $this from incompatible context in /var/www/hss.dmknet.de/htdocs/typo3conf/ext/importstudip/Classes/Utility/AjaxHandler.php

ich mußte die Klasse AjaxHandler vollständig ändern und alle Aufrufe dynamisch machen, hier ein Beispiel:

<         return ConfigForm::getSmallNewsForm($inputname, $value);
---
>         $configform = new ConfigForm();
>         return $configform->getSmallNewsForm($inputname, $value);

OK

eigentlich sollen die nach und nach je nach Anforderung aufgeklappt werden

verfluchte Schweinerei, in TYPO3-7 wurden scheinbar die Bezeichner geändert in den Templates für die Forms. Das Javascript greifr jetzt nicht mehr, weil es die Bezeichner nicht mehr findet. Ich mußte die js-datei anpassen nach folgendem Muster:

26c26
<             closest('.t3-form-field-container');
---
>             closest('.form-section');

jetzt sieht es so aus:

es erfolgt eine Abfrage von Statusgruppen für ein Institute, obwohl beim Konfigurieren noch kein Institute ausgewählt wurde. Dies erzeugt einen internen AJAX-Fehler.

Ich habe die JS-Datei geändert:

136c136,137
<                     Tx_ImportStudip.enableInput('tx-importstudip-statusgroups',
---
>                     if (TYPO3.jQuery('#tx-importstudip-institutes').find('input[type="radio"]:checked').length != 0) {
>                       Tx_ImportStudip.enableInput('tx-importstudip-statusgroups',
143c144,145
<                     );
---
>                       );
>                     }  

also eine if-abfrage ergänzt. Das Statusgruppenform wird erst aufgerufen, wenn ein radio-Button checked ist.