Wie kann ich die veraltete Extension "metatags" mit TYPO3 6.2 verwenden?

1. Extension-Dateien/-Inhalte auslagern:

- metatags/ext_typoscript_setup.ts ins eigene TypoScript (Setup) kopieren

- metatags/ext_typoscript_constants.ts ins eigene TypoScript (Constants) kopieren

- metatags/meta.php z.b. nach fileadmin/php/meta.php kopieren


2. Anpassungen TypoScript-Setup:

- PHP_SCRIPT durch USER ersetzen, und "includeLibs" und "userFunc" statt "file" verwenden:

plugin.meta = USER
plugin.meta {
  #file = EXT:metatags/meta.php
  includeLibs = fileadmin/php/meta.php
  userFunc = user_metatags
  ...

- ggf. page.headerData (in plugin.meta) auskommentieren und im eigenen PAGE-Objekt neu einfuegen


3. Anpassungen PHP:

- den Inhalt von meta.php in eine Funktion gemaess "userFunc" (siehe oben) verpacken, und Referenzen auf "$this" entfernen/ersetzen:

function user_metatags($content, $conf) {
    //if (!is_object($this))    die('Not called from cObj!');

    ...

    //$localDescription = trim($this->stdWrap($local['description'],$local['description.']));
    //$localKeywords = trim($this->stdWrap($local['keywords'],$local['keywords.']));

    $obj = $GLOBALS['TSFE']->cObj;
    $localDescription = trim($obj->stdWrap($local['description'],$local['description.']));
    $localKeywords = trim($obj->stdWrap($local['keywords'],$local['keywords.']));


Das Extension-Verzeichnis "metatags" kann abschliessend geloescht werden.

Optionsplit verwenden

#
# BEISPIELCODE FUER OPTIONSPLIT
#

# die optionsplit-logik steht nur in wenigen properties zur verfuegung.
# beispielsweise verwendet ein CONTENT cObject diese logik nicht.
# anders aber ein TMENU oder GMENU, hier kann optionsplit verwendet werden.
# ebenso steht optionsplit bei den properties "cObj" und "wrap" der split-
# funktion zur verfuegung.

# zur ausfuehrung des untenstehenden beispielcodes sollten mind. drei pages
# vorhanden sein (zur erzeugung des HMENU), sowie auf der aktuellen seite
# mind. drei content-elemente.


temp.separator = TEXT
temp.separator.value = <hr>


page = PAGE


# optionsplit steht bei allen properties eines menuitems (NO, ACT, ...)
# zur verfuegung. via optionsplit wird der erste menu-eintrag ohne komma,
# und alle weiteren mit komma-symbol vorangestellt ausgegeben.

page.10 = HMENU
page.10 {
    1 = TMENU
    1 {
        NO = 1
        NO.allWrap = | |*| ,|
    }
}
page.11 < temp.separator



# ein menu greift zunaechst nur auf daten der tabelle "pages" zu - bei anderen
# objekten / tabellen muss man anders vorgehen:
#
# via HMENU.special = userfunction und einer entspr. PHP-funktion koennen
# auch andere daten/tabellen abgefragt werden.
#
# wenn keine PHP-funktion benoetigt werden soll, dann koennen andere cObjects
# verwendet werden (bei denen stdWrap zur verfuegung steht), wie im folgenden
# demonstriert:


# 1. ein renderObj (bzw. je nach kontext) fuer die ausgabe,
#    mit einem trennsymbol angehaengt

page_content_renderObj = TEXT
page_content_renderObj {
    field = uid
    wrap = |SPLIT_HERE
}

# (man beachte dass das trennsymbol "SPLIT_HERE" in diesem beispiel immer
# hinten angehaengt wird, auch beim letzten erzeugten renderObjs)

# 2. ein cObject - z.b. CONTENT - erzeugt den auszugebenden code,
#    unter verwendung des obigen renderObj.
#    via stdWrap.split wird der auszugebende code wieder aufgetrennt,
#    und dabei via wrap (mit optionsplit) mit neuen individuellen
#    trennsymbolen versehen:
#    (hierbei werden auch leere werte gewrapped und ausgegeben - vgl. 3., unten)

page.20 = CONTENT
page.20 {
    table = tt_content
    select {
        pidInList = this
    }
    renderObj = < page_content_renderObj
    stdWrap {
        split {
            token = SPLIT_HERE
            wrap = | |*| ,|
        }
    }
}
page.21 < temp.separator


# 3. "split" liefert auch leere werte zurueck, falls sich das trennsymbol
#    am anfang oder am ende des jew. strings befindet, oder wenn zwei
#    trennsymbole direkt aufeinanderfolgen.
#    falls dieses verhalten nicht erwuenscht ist, kann split.wrap nicht
#    direkt verwendet werden. anstelle dessen wird cObjNum (mit optionsplit)
#    verwendet, und die jew. cObj's mit einer entsprechenden bedingung
#    (if.isTrue) versehen.

page.30 < page.20
page.30 {
    stdWrap {
        split >
        split {
            token = SPLIT_HERE
            cObjNum = 1 |*| 2
            1.current = 1
            1.if.isTrue.data = current
            2 < .1
            2.wrap = ,|
        }
    }
}



Ergebnis/Ausgabe:

Wie erhalte ich eine FAL Datei Referenz z.b. zur Verwendung mit TypoScript IMAGE cObject?

        $relationHandler = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\Database\\RelationHandler');
        $configuration = $GLOBALS['TCA']['tt_content']['columns']['image']['config'];
        $relationHandler->start($imagedata['image'], $configuration['foreign_table'], $configuration['MM'], $imagedata['uid'], 'tt_content', $configuration);
        $relationHandler->processDeletePlaceholder();
        $referenceUids = $relationHandler->tableArray[$configuration['foreign_table']];
        foreach ($referenceUids as $referenceUid) {
            try {
                $fileReference = \TYPO3\CMS\Core\Resource\ResourceFactory::getInstance()->getFileReferenceObject($referenceUid, array(), ($wsid === 0));
                //$origFile = $fileReference->getOriginalFile();
                $filename = $fileReference->getName();
                // write back to our $imagedata element... (for compatibility)
                $imagedata['image'] = $filename;
                // ...and store fileReference identifier for later use:
                $imagedata['fileref_uid'] = $fileReference->getUid();
            } catch (\TYPO3\CMS\Core\Resource\Exception\FileDoesNotExistException $e) {
                /* just catch exception, because we can't do anything about it here */
            }
        }


       $confIMG = array(
            'file' => isset($imagedata['fileref_uid']) ? $imagedata['fileref_uid'] : 'uploads/pics/'.$imagedata['image'],
            'file.' => array (
                'width' => $width,
                'treatIdAsReference' => isset($imagedata['fileref_uid']) ? 1 : 0,
            ),
            'params' => 'align="left" style="margin:0 10px 5px 0;"',
            'titleText' => trim($imagedata['tx_team_position'].' '.$imagedata['header']),
        );

Zeichensatz-Konvertierung / TYPO3-Datenbank Zeichensatz / ...

echo "ALTER DATABASE mydb CHARACTER SET utf8 COLLATE utf8_general_ci;" | mysql

mysqldump --default-character-set=latin1 --databases mydb > a.sql

cp a.sql b.sql

sed -i 's/DEFAULT CHARSET=latin1/DEFAULT CHARSET=utf8/g' b.sql

sed -i 's/CHARACTER SET latin1/CHARACTER SET utf8/g' b.sql

grep -v character_set_client <b.sql > c.sql

sed -i 's/SET NAMES latin1/SET NAMES utf8/g' c.sql

mysql --default-character-set=utf8 < c.sql

http://wiki.typo3.org/UTF-8_support#Convert_an_already_existing_database_to_UTF-8

http://www.i18nqa.com/debug/utf8-debug.html

http://www.utf8-chartable.de/unicode-utf8-table.pl

http://stackoverflow.com/questions/14980200/converting-special-charactes-such-as-%C3%83%C2%BC-and-%C3%83%C6%92-back-to-their-original-latin-alp

https://docs.typo3.org/typo3cms/InstallationGuide/UpgradeLTS/Index.html

http://php.net/manual/en/function.utf8-encode.php

http://php.net/manual/de/function.mb-convert-encoding.php

Wie kann ich TYPO3 unter Windows mit cygwin nutzen?

(getestet mit TYPO3 6.2.12)

Grobgesagt muss man Cygwin mit apache, PHP und MySql-Server installieren, und - beim aktuellen Entwicklungsstand von TYPO3 - ein paar kl. Anpassungen im TYPO3-Core vornehmen. (Es existieren diverse Bugreports bzgl. TYPO3-Cygwin-Support, siehe unten "Quellen".)

Zur Installation von Cygwin mit apache, PHP und MySql-Server findet sich hier eine ziemlich vollstaendige Anleitung:

http://umusebo.com/installing-and-configuring-apache-php-mysql-on-cygwin/


Anpassungen im TYPO3-Core:

1.) Mit folgender Aenderung erkennt TYPO3 das Cygwin-System:

in /typo3_src/typo3/sysext/core/Classes/Core/SystemEnvironmentBuilder.php

/**
* Determine the operating system TYPO3 is running on.
*
* @return string Either 'WIN' if running on Windows, else empty string
*/
static protected function getTypo3Os() {
    $typoOs = '';
       //if (!stristr(PHP_OS, 'darwin') && stristr(PHP_OS, 'win')) {
       if (!stristr(PHP_OS, 'darwin') && !stristr(PHP_OS, 'cygwin') && stristr(PHP_OS, 'win')) {
          $typoOs = 'WIN';
       }
   return $typoOs;
}



2.) Da sich die PHP-Funktion uniqid() unter Windows anders verhaelt als auf anderen Plattformen - ein Punkt wird in die generierte ID eingefuegt - muss eine kl. Anpassung bzgl. Cache-Identifiers vorgenommen werden:

in /typo3_src/typo3/sysext/core/Classes/Cache/Frontend/FrontendInterface.php

//const PATTERN_ENTRYIDENTIFIER = '/^[a-zA-Z0-9_%\\-&]{1,250}$/';
const PATTERN_ENTRYIDENTIFIER = '/^[a-zA-Z0-9_%\\-&\.]{1,250}$/';



Quellen:
http://umusebo.com/installing-and-configuring-apache-php-mysql-on-cygwin/
https://forge.typo3.org/issues/65744
https://forge.typo3.org/issues/14523
http://php.net/uniqid

(Frage: wie startet man mysqld automatisch als Service?)

Wie kann ich die Extension Quixplorer mit TYPO3 6.2 nutzen?

In der aktuellen Version 1.7.2 laeuft der Quixplorer nicht unter TYPO3 6.2, sondern zeigt eine Fehlermeldung:

Die Extension laesst sich aber leicht patchen:

in t3quixplorer/mod1/index.php
die zwei require()-Zeilen auskommentieren:

//require ($BACK_PATH.'template.php');
$LANG->includeLLFile('EXT:t3quixplorer/mod1/locallang.xml');
//require_once (PATH_t3lib.'class.t3lib_scbase.php');



Es gibt auch eine angepasste ExtBase-Version des Quixplorers, diese ist aber zum jetzigen Zeitpunkt noch nicht lauffaehig:
https://github.com/madsbrunn/t3quixplorer/tree/extbaseVersion



Quellen:
http://www.typo3forum.net/forum/typo3-extensions/74337-quixplorer-fuer-typo3-6-2-alternativen.html

https://github.com/madsbrunn/t3quixplorer/tree/extbaseVersion

Wie kann ich die Extension mm_forum unter TYPO3 6.2 nutzen/updaten?

Zwei Versionen der Extension mm_forum, angepasst fuer TYPO3 6.2:


1. version 1.11-dev (12.11.2014 ?)

gefunden auf:
http://die-netzmacher.de/titel/mm-forum-fuer-typo3-62/


2. version 1.10-dev (letzte aenderung: 2015-03-06)

(UPDATE 2015-06-08: seit dem 2015-03-06 sind weitere Aenderungen vorgenommen worden, evtl. untenstehende Bugs gefixed worde. Noch nicht ueberprueft.)

gefunden auf:
https://github.com/TYPO3-extensions/mm_forum

...sieht etwas besser aus: namespaces eingefuehrt, offenbar Abhaengigkeiten zu lib/div entfernt.

Ansonsten haben beide Versionen der Extension offenbar etwa den gleichen Entwicklungsstand.

Es finden sich aber in beiden Versionen auch diverse Fehler:



Fehler nur in 1.10-dev:

Forum-Suche:
PHP-Fehler: Fatal error: Call to a member function exec_SELECTquery() on a non-object in .../typo3conf/ext/mm_forum/pi1/class.tx_mmforum_pi1.php on line 5133

...Loesung: in pi1/class.... (?) get_topic_id() $this->databaseHandle ergaenzen:
if (!$this->databaseHandle) {
    $this->databaseHandle = $GLOBALS['TYPO3_DB'];
}

Gemeldete Beitraege bearbeiten:
funktioniert nicht, Status wird nicht gespeichert, keine Fehlermeldung

...Loesung: im Programmcode wird "fullQuoteString" (?) verwendet, muss ersetzt werden durch intval() o.Ae., damit die SQL-Query korrekt ist (kein string, sondern integer).


Umfragen:
Umfrageergebnis wird nicht gespeichert

...Loesung: (noch unbekannt)


Fehler in beiden Versionen:

Frontend:

Icons tw. veraendert/skaliert, Icon Positionen stimmen nicht

Offenbar ein TYPO3 (6.2?) Fehler, hier wird ein GIFBUILDER-Objekt mit einem IMAGE verwendet. Ueberschreibt man das GIFBUILDER-Objekt, und verwendet nur ein IMAGE, dann wird korrekt skaliert.
(buttons < .buttons_text und buttons.small und buttons.large beachten :-) siehe im TypoScript der Extension)

Backend:

In beiden Versionen sind im Backend neue Felder/Eintraege zu sehen:
Private Nachrichten: User search fields, User search order by (in der Vorversion hier nicht vorhanden)


Ein Thread zum Thema, mit evtl. weiteren Informationen:

http://www.typo3.net/forum/thematik/zeige/thema/118297



Nach dem TYPO3 6.2 Update:

Falls Benutzer-Eingabefelder via Backend-Modul definiert sind, kann es sein dass diese nach dem Update im Frontend bei „Benutzerdaten bearbeiten“ fehlen. Hintergrund ist, dass diese Felder als TypoScript-Setup-Schnipsel in der Datenbank gespeichert werden, und das teilweise als Content-Objekt vom Typ „HTML“ – das gibt’s bekanntlich nicht mehr unter TYPO3 6.2.

So kann man das fixen:

schauen was da ist:

mysql> select config from tx_mmforum_userfields;

testlauf, so kann man’s noch rueckgaengig machen:

mysql> update tx_mmforum_userfields set config = replace(config, 'HTML', 'THIS_SHOULD_BE_TEXT');

hat’s die richtigen erwischt?

mysql> select config from tx_mmforum_userfields;

dann diese durch TEXT ersetzen:

mysql> update tx_mmforum_userfields set config = replace(config, 'THIS_SHOULD_BE_TEXT', 'TEXT');