TYPO3

Wieder einmal ein leidiges RealUrl Problem: Eine Multidomain-Seite funktionierte prinzipiell prächtig, nur bei fehlerhaften Einloggen oder beim Ausloggen der Fe-User trat das lästige „Segment 1 was not a keyword for a postVarSet as expected“ auf. Felogin ohne RealUrl funktionierte jedoch anstandslos.

Lösung:

In der RealUrl-Config fehlte in der Sektion init der Wert

1
'postVarSet_failureMode' => ' '

Nachdem Einfügen dieses Wertes funktioniert nun alles wie gewünscht.

Wird beim Indexieren von Seiten die Fehlermeldung The path to pdftools is not correctly set in the extension manager configuration. You can get the path with „which pdfinfo“ or „which pdftotext“ generiert obwohl der Pfad in der Extension-Konfiguration richtigangegeben ist, kann es am open_basedir liegen. Hier muss /usr/bin freigegeben sein, da mit is_file nach der jeweiligen Tool (catdoc usw.) gesucht wird.

Gefunden in den Kommentaren auf der Extensionseite.

Da ich immer wieder danach suche, hier als kleine Gedankenstütze: variable Empfänger und Betreff mit einem Powermail-Formular 2.x.

Die Auswahl des Betreffs erfolgt in meinem Fall über ein Select-Feld mit der ID 13. Das Select-Feld hat folgende Optionen:

  • **** bitte wählen ****|
  • Betreff Nummer 1|1
  • Alternativer Betreff|2

Anmerkung: Die Pipe trennt den angezeigten Wert von der tatsächlichen Value des Option-Tags. 

Auf der Seite des Formulares wird ein Ext-Template erstellt in dessen Setup folgende TS-Condition geschrieben wird:

1
2
3
4
5
6
7
8
9
10
[globalString = GP:tx_powermail_pi1|field|13 = 1]
  plugin.tx_powermail.settings.setup.receiver.subject = Betreff Nummer 1
  plugin.tx_powermail.settings.setup.receiver.email = empfaenger1@email.de
  plugin.tx_powermail.settings.setup.sender.subject = Ihre Nachricht: Betreff Nummer 1 
[global]
[globalString = GP:tx_powermail_pi1|field|13 = 2]
  plugin.tx_powermail.settings.setup.receiver.subject = Alternativer Betreff
  plugin.tx_powermail.settings.setup.receiver.email = empfaenger2@email.de
  plugin.tx_powermail.settings.setup.sender.subject = Ihre Nachricht:Alternativer Betreff
[global]

1
2
3
# Get the subtitle of
10 = TEXT
10.data = levelfield : -1 , subtitle , slide

Wichtig: Im localconf muss das entsprechende Feld zum Slide freigeben werden:

1
$TYPO3_CONF_VARS['FE']['addRootLineFields'] = ',subtitle,nav_title';

gefunden im TSRef (natürlich :-)

typoscrip0t beispiel um den titel der neuen news-extension von georgringer als seitentitel einzubinden für typo3 4.7 (GP statt GPvar !)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#default
page.headerData.5 = TEXT
page.headerData.5.field = subtitle
page.headerData.5.ifEmpty.field = title
page.headerData.5.wrap =|  -  {$pageTitle}
 
# auf der News Detailseite wird der Newstitel als Browsertitel ausgegeben
# id ändern!!
#[globalVar = TSFE:id=999999]
[PIDinRootline = 1,2,3]
### tt_news: prepare single title
#    temp.newsTitle = RECORDS
#    temp.newsTitle {
#        source = {GP:tx_ttnews|tt_news}
#        source.insertData = 1
#        tables = tt_news
#        conf.tt_news >
#        conf.tt_news = TEXT
#        conf.tt_news.field = title
#    }
 
### tx_news: prepare single title
temp.newsTitle = RECORDS
temp.newsTitle {
source = {GP:tx_news_pi1|news}
source.insertData = 1
tables = tx_news_domain_model_news
conf.tx_news_domain_model_news >
conf.tx_news_domain_model_news = TEXT
conf.tx_news_domain_model_news.field = title
}
 
page.headerData.5 >
page.headerData.5 = COA
page.headerData.5 < temp.newsTitle
page.headerData.5.wrap =|  -  {$pageTitle}
[global]

hatte das komische problem das bei der suche mit indexed_search gewisse, meist kurze wörter (3 zeichen oder kürzer) nicht gefunden wurden, andere aber schon…

env:

  • typo3 4.7.8
  • indexed_search 4.7.7
  • indexed_search_mysql 4.7.7
  • macina_searchbox 2.2.0
  • crawler 3.5.0

bin bei der suche auf die möglichkeit gestossen das für indexed_search sog.  „stopwords“ defininert werden können, d.h. wörter welche nicht gefunden werden sollen. dies soll scheinbar bei grossen seiten die suche erheblich beschleunigen. weitere infos dazu:
http://blog.martinholtz.de/blog-post/2009/10/03/indexed-search-performance-probleme/
http://www.lx-networking.de/news/indexed-search-beschleunigen/348

leider hatte das mein problem nicht gelöst, aber es ist mir beim prüfen dabei aufgefallen das unter „info“ > „indexed_search“ > „words and content“ bei mir nirgends „words“ gefunden wurden (count:0), nur bei content war der inhalt wie erwartet abgebildet.

daraufhin habe ich ein wenig mit der konfiguration rumgespielt, und festgestellt das die extension „indexed_search_mysql“ sowohl den crawler wie auch die indexirung über das frontend daran hinder ebendiese „words“ in die tabelle zu schreiben. nachdem ich also „indexed_search_mysql“ desinstalliert habe, werden nun alle wörter indexiert und gefunden :)

die erweiterung „indexed_search_mysql“ (zur performance-verbesserung von „indexed_search“ gedacht) war also das übel und sollte m.e. nicht verwendet werden. stattdessen eine optimierung per kontrollierten „stopwords“ ins auge fassen (wie in unter obigen links beschrieben).