Extensions

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]

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).

diese blogs habe mir weitergeholfen:

http://www.typo3forum.net/forum/indexed-search/12556-such-problem-eingeloggtem-fe-user.html

http://www.typo3.net/forum/beitraege//60818/

kurz-fazit daraus:

  1. entweder extension installieren (hab ich nicht getestet):
    http://www.website-schmied.de/toolbox/typo3-extensions/
  2. oder per typoscript alle suchresultate für alle user anzeigen bspw. :
    ———

    1
    2
    3
    4
    
     # Show all records if user loged in
    [loginUser = *]
         plugin.tx_indexedsearch.show.forbiddenRecords = 1
    [global]

    ———

ausserdem:
dem crawler in der „crawler-configuration“ sagen dass er mit allen gruppen crawler soll

das ganze ist einigermassen undurchsichtig… habe nach stunden ausprobieren folgendes rausgefunden (auf typo3/felogin v. 4.7.7), vieleicht hilfts jemandem:
– ob TS oder flexform spielt m.e. keine rolle, ich mach nun alles per TS
– redirect auf pid 1 (bei mir „home“) geht irgendwie nicht, sobald ich irgeneine andere pid angebe gehts (sowohl bei redirectPageLogin wie auch bei redirectPageLogout)
– die reihenfolge bei redirectMode & redirectFirstMethod ist je nach dem entscheidend, etwas damit rumprobieren hat geholfen (bspw. muss „logout“, „vor „login“ stehen)

*cheers

siehe auch:
http://www.typo3forum.net/forum/typo3-4-x-fragen-probleme/50423-felogin-kein-redirect-2.html

 

Die Seminars-Extension versendet an den Benutzer eine Email mit folgendem Text:

1
2
3
4
5
Sehr geehrte/r *NAME*
 
Guten Tag *VERANSTALTUNG*,
 
vielen Dank für Ihre Anmeldung zu dieser Veranstaltung: am *DATUM* um *ZEIT* Uhr.

 

Der Fehler liegt in der locallang-Dateien, die in typo3conf/l10n/de/seminars/* liegen. Dort steht z.B.

1
2
3
Guten Tag %s
 
vielen Dank für deine Anmeldung für die Warteliste von dieser Veranstaltung:

Wobei das %s nach dem Doppelpunkt stehen sollte.

 

TYPO3 4.7.7
Powermail 2.04

Bei einem Powerrmailformular bleiben die Bubbles der jQuery-Validierung in deutsch leer.

Abhilfe schuf der Download des Files  jquery.validationEngine-de.js.

Eingebunden wird es im TS-Setup (der Pfad muss an die eigene Installation angepasst werden):

1
2
page.includeJSFooterlibs.powermailJQueryFormValidationLanguage >
page.includeJSFooterlibs.powermailJQueryFormValidationLanguage = fileadmin/templates/layout/js/jquery.validationEngine-de.js