Re: [TYPO3-german] Erweiterungen migrieren nach 8.7

2017-07-27 Diskussionsfäden Michael Kasten
Hallo,

> Na wenn du es gefunden hast, wäre es schön wenn du uns sagen könntest wo der 
> Fehler lag. :)

mein Fehler, ich bin von was größerem ausgegangen allerdings bin ich lediglich 
am Caching
gescheitert, da ich vorher auf der 7.6er das Caching per default aus hatte.

Passiert mir auch nach Jahren alle paar Monate wieder mal, Asche auf mein Haupt 
:)

mit besten Grüßen

-- 
Michael Kasten | http://m-kasten.de
Im wirklichen Leben gibt es kein [Strg]+[Z]
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] ViewHelper-Rückgabe erneut in FLUID rendern?

2017-07-27 Diskussionsfäden Stephan Schuler
Hallo Manuel.

Schön dass Du eine Lösung gefunden hast.

Kannst Du den Versuch der eben nicht funktioniert hat auch noch kurz hier 
veröffentlichen?  Ich bin nämlich von deutlich anderen Voraussetzungen 
ausgegangen als ich Dir meine Erklärung geschrieben habe.

Insbesondere hast Du jetzt aber ja eine Variante gefunden, in der Du nicht „von 
Hand“ Fluid nochmal „nachrendern“ musst. Und das sollte eigentlich auch immer 
so sein. Bei verschachtelten ViewHelper-Aufrufen bekommt ein umschließender 
ViewHelper nicht den umschlossenen Fluid-Code sondern das Renderingergebnis des 
umschlossenen Codes. Wenn der umschlossene Code selbst ViewHelper enthält 
werden die zunächst evaluiert, und so wird (zumindest theoretisch) von innen 
nach außen gearbeitet.

Das war mit ziemlicher Sicherheit in Deinem vorherigen Versuch auch der Fall.

Du brauchst für die Verlinkung nicht zwangsläufig den ActionViewHelper. Du hast 
zwar vergleichbare Argumente $action, $arguments und $controller, mehr aber 
auch nicht. Wenn Du einfach vom AbstractTagBasedViewHelper ableitest hast Du 
ebenfalls den ControllerContext, das reicht. Um zu vermeiden, dass das Ergebnis 
HTML-Specialchar-Escaped wird musst Du dieses Defaut-On-Feature im ViewHelper 
deaktivieren. Das dürfte der aber der AbstractTagBasedViewHelper für Dich tun.

Auch unter PHP5 wäre ich nie auf die Idee gekommen, eine Funktion mit nur einem 
Teil der Argumente zu überschreiben. Das macht man nicht, schon weil die IDE 
dann mit ihrer Autovervollständigung durcheinanderkommen dürfte. Spätestens 
wenn die abgeleitete Klasse ein Argument bekommt das es in der Parent-Klasse 
nicht gibt, das dann aber die Position eines ganz anderen Arguments der 
Parent-Klasse einnimmt wird es haarig. Ich will mir eigentlich nicht ausmalen, 
wie die zugehörige Reflection-Meta-Data aussieht. Insbesondere nachdem die 
Parameterreihenfolge von Fluid ja ausgelesen und aufgerufen wird dürften das 
die Art von Bugs sein denen man ewig hinterher läuft.

Stell Dir die Methode in einem ViewHelper vor:
➢ public function render($a=null, $b=’’, $c=0)

Und dazu der Aufruf in Fluid:
➢ 

Was Fluid jetzt machen muss ist klar: Die eigentlich optionalen Argumente 
„$a=null“ und „$b=’’“ aktiv übergeben, um das letzte optionale Argument „$c=5“ 
abweichend vom Default übergeben zu können.

Wenn sich da jetzt in der Vererbungshierarchie die Parameterreihenfolge ändert 
geht die Welt unter.

Dein „GROUP BY“ kann ich allerdings nicht so stehen lassen. Es ist ja nicht so, 
dass Dir jemand das „GROUP BY“ verbietet. Nur gibt es in der Theorie des ORM 
eben kein „GROUP BY“, bzw. das Ergebnis ist kein Teil dieser Welt mehr. Stell 
Dir ein Objekt $sportler vor, sagen wir einen Langstreckenläufer. Der hat die 
Attribute $sportler->name, $sportler->höchstgeschwindigkeit, 
$sportler->besteRundenzeit und $sportler->alter. Jetzt nehmen wir „SELECT * 
FROM sportler GROUP BY alter“. Raus kommt natürlich ein Objekt vom Typ 
Langstreckenläufer, das ist unsere Domäne. Was ist jetzt die beste Rundenzeit, 
und was die Höchstgeschwinditkeit? Sind das die Werte des ersten Objekts der 
Altersgruppe, oder die Höchstwerte der Gruppe? Das hängt offensichtlich vom 
DBMS ab mit dem Du arbeitest, und in diversen Datenbanken sind bei solchen 
Abfragen schon im SELECT-Teil nur diejenigen Attribute erlaubt die im GROUP BY 
genannt sind, andere Queries erzeugen einen Fehler im Datenbankserver.

Wenn Du das „GROUP BY“ verwenden willst: Bitte gerne. Aber im Zusammenhang des 
ORM ist es eben nicht definiert, dann musst Du ohne ORM auskommen oder es 
ORM-kompatibel formulieren.
Man könnte hierfür ein paar SQL-Views bauen und die auf sinnvolle Objekte 
mappen. Wenn ich eine Tabelle „Höchstgeschwindigkeit nach Alter“ rendern möchte 
sind es keine Sportler mit denen ich hantiere sondern vielleicht 
„Rennstatistiken“ oder etwas in der Art. Ein solches Objekt hat dann aber 
keinen Namen mehr, und auch diverse andere Attribute die ein solcher Sportler 
hat, sondern nur noch ein Alter und eine Höchstgeschwindigkeit.

Beste Grüße,


Stephan Schuler
Web-Entwickler | netlogix Web Solutions

Telefon: +49 (911) 539909 - 0
E-Mail: stephan.schu...@netlogix.de
Web: websolutions.netlogix.de




Neu: Wir sind Amazon Web Services Partner. Mehr erfahren:
https://websolutions.netlogix.de/technologie/amazon-web-services-aws





netlogix GmbH & Co. KG
IT-Services | IT-Training | Web Solutions
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: i...@netlogix.de | Web: http://www.netlogix.de

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Matthias Schmidt



___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo

Re: [TYPO3-german] Erweiterungen migrieren nach 8.7

2017-07-27 Diskussionsfäden Christian Hackl

Na wenn du es gefunden hast, wäre es schön wenn du uns sagen könntest wo der 
Fehler lag. :)
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Re: RTE konfigurieren: TSConfig von altem Typo3 4.5 bewirkt nichts in Typo3 8.7.3

2017-07-27 Diskussionsfäden Christian Hackl

Soweit ich weiß funktioniert kein RTE TS mehr für den ck_editor.
Du kannst aber den alten RTE noch nach installieren für Typo3 8. Allerdings 
musst du früher oder später sowieso auf den ck_editor umsteigen, deshalb wäre 
es empfehlenswert sich damit gleich zu beschäftigen.

Für den Einstieg kannst du dir ja mal aus dem Ter (Extension Manager) die 
Extension hh_ckeditor_custom ansehen / herunterladen.
Mit der hast du nen etwas leichteren Einstieg - diese legt dir die benötige 
yaml an plus die rte.css und macht gleich die nötigen verlinkungen etc.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Bilder werden nicht mehr verlinkt

2017-07-27 Diskussionsfäden Denis Schischka
Hallo, ich habe das Problem, dass Bilder in neuen Inhaltselementen im Frontend nicht mehr verlinkt werden. Im Backend ist alles richtig eingestellt. 
Ich habe auch ein altes Element kopiert und dort das Bild neu verlinkt. Dort hatte ich dann den Link vom kopierten Element und nicht den neuen Link. Ebenso habe ich versucht ein neues Bild zu verlinken, das hat auch nicht funktioniert.


Typo3 Version: 6.2.27
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


[TYPO3-german] RTE konfigurieren: TSConfig von altem Typo3 4.5 bewirkt nichts in Typo3 8.7.3

2017-07-27 Diskussionsfäden Irgendwas mit E

Mit mäßigen, angestaubten Typo3 Kenntnissen portiere ich gerade ein altes Typo3 
4.5 nach Typo3 8.7.3. Beide nutzen css_styled_content.

Das TSConfig 1:1 übernommen zeigt im RTE des neuen Typo3 offenbar Null Auswirkungen. Im alten RTE 
werden z.B. zwei Select-Boxen "Blockstil:" und "Textstil:" angezeigt (ich 
vermute mal durch
RTE.default.showButtons = <...>, textstyle, <...> , blockstyle <...>
). Im neuen RTE sind die nicht zu sehen.

Hier bin ich totaler Anfänger. Haben sich die Objektnamen im TSConfig geändert? 
Werden die Formatierungen der alten rte.css nicht mehr ausgelesen weil jetzt 
.yaml Dateien verwendet werden?

Vielleicht könnt Ihr mir etwas auf die Sprünge helfen.


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Erweiterungen migrieren nach 8.7

2017-07-27 Diskussionsfäden Michael Kasten
Hallo Christian,

danke für die Antwort, ich suche da noch ein bisschen nach Hilfen denke aber 
mein Problem gefunden
zu haben

Dankeschön

-- 
Michael Kasten | http://m-kasten.de
Im wirklichen Leben gibt es kein [Strg]+[Z]
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Erweiterungen migrieren nach 8.7

2017-07-27 Diskussionsfäden Christian Hackl

Ich wüsste keine - du kannst aber mal das deprication log anschalten im 
Install-Tool

Dann kannst du da drin mal nachsehen, was alles veraltet ist. Bzw. was du 
ändern solltest.
Ansonsten helfen die anderen Logs fürs erste weiter. (Auch Server error_log)
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Re: .png Bilder werden nicht skaliert, .jpg schon

2017-07-27 Diskussionsfäden Christian Hackl

Test doch mal:
öffne die alte png in deinem Editor (photoshop - gimp - etc) und speicher sie 
dort einmal ab am besten unter einem anderen namen (nur mal zum test) und guck 
nochmal ob sie dann skalieren.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Erweiterungen migrieren nach 8.7

2017-07-27 Diskussionsfäden Michael Kasten
Hallo Liste,

in Ermangelung eines Extensionbuilders für 8.7 habe ich nun eine Erweiterung 
erstellt die zumindest
unter 7.6 genau alles das macht was ich möchte:

Listenansicht mit Filterformular

Wie gesagt läuft das unter 7.6 Einwandfrei, ich kann die Ergebnisliste Filtern 
und Sortieren

Unter 8.7 macht das nun aber so überhaupt nichts?

Wenn ich mir das DB Logfile ansehe dann stelle ich fest das beim Absenden des 
entsprechendem
Formulars wohl überhaupt keine Anfrage ausgeführt wird

Ich habe das Gefühl das die Abfrage also überhaupt nicht ausgeführt wird, wer 
sich die Repository
Classe einmal ansehen will: https://pastebin.com/wLSc1bQv

Gibt es denn irgendwo eine Migrationshilfe für Erweiterungen?

mit besten Grüßen

-- 
Michael Kasten | http://m-kasten.de
Im wirklichen Leben gibt es kein [Strg]+[Z]
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Re: ViewHelper-Rückgabe erneut in FLUID rendern?

2017-07-27 Diskussionsfäden Manuel Raaf

Sodale,

ich bin zwischenzeitlich auf eine Lösung gekommen (durch Mithilfe eines Kollegen, der wesentlich länger Extensions entwickelt, aber bisher auch noch nie den beschriebenen Bedarf hatte): 

Ich hole mir den Text via renderChildren(), verarbeite und prüfe ihn auf die Textmuster, die ich dann im ViewHelper durch gerenderte Tags ersetze und dann einfach wieder als Text zurückgebe. Letztlich ist mein Kernproblem in 4 Zeilen Code gelöst. 

Mein ViewHelper leitet von \TYPO3\CMS\Fluid\ViewHelpers\Link\ActionViewHelper ab, nicht vom AbstractViewHelper. 
In PHP 5.6 überschreibe ich render() wie folgt:


/**
* @param string $action
* @param array $arguments 
* @param string $controller

*/
public function render($action = null, array $arguments = [], $controller = 
null)
{
$sigel= $this->renderChildren();
#
# Text zum $sigel wird geholt, verarbeitet und mit preg_match_all() auf Muster 
geprüft, die dann im Anschluss in ActionLinks gesetzt werden sollen
#
#
# Die nächsten 4 Zeilen lösen das Kernproblem:
$uriBuilder = $this->controllerContext->getUriBuilder();
$uri = $uriBuilder->reset()->uriFor($action, $arguments, $controller);
$this->tag->setContent($match[0]);
$this->tag->forceClosingTag(true);
$str = str_replace($match[0], $this->tag->render(), $str);
#
# sonstiger Code; Schleifenende
#
return $str;
}

Diese Zeilen sind in einer Schleife, die die Treffer von preg_mach_all() durchläuft. 


Im Template habe ich den Aufruf via <...action="list" controller="Literatur" 
arguments="{searchSubmitted : 2, literaturKurztitel : ''}">{element.textSigel}


In PHP 7 muss man entweder warnings deaktivieren ODER aber die Funktion 
render() 1:1 überschreiben, d.h. dass die eigene render() exakt die gleichen 
Parameter benötigt, wie die der Originalklasse. Andernfalls kommt ein 
php:warning, dass die Strukur nicht identisch ist, und TYPO3 steigt aus. Der 
Vollständigkeit halber hier der 1:1-kopierte Code:

/**
* @param string $action Target action
* @param array $arguments Arguments
* @param string $controller Target controller. If NULL current 
controllerName is used
* @param string $extensionName Target Extension Name (without "tx_" prefix 
and no underscores). If NULL the current extension name is used
* @param string $pluginName Target plugin. If empty, the current plugin 
name is used
* @param int $pageUid target page. See TypoLink destination
* @param int $pageType type of the target page. See typolink.parameter
* @param bool $noCache set this to disable caching for the target page. You 
should not need this.
* @param bool $noCacheHash set this to suppress the cHash query parameter 
created by TypoLink. You should not need this.
* @param string $section the anchor to be added to the URI
* @param string $format The requested format, e.g. ".html
* @param bool $linkAccessRestrictedPages If set, links pointing to access 
restricted pages will still link to the page even though the page cannot be 
accessed.
* @param array $additionalParams additional query parameters that won't be 
prefixed like $arguments (overrule $arguments)
* @param bool $absolute If set, the URI of the rendered link is absolute
* @param bool $addQueryString If set, the current query parameters will be 
kept in the URI
* @param array $argumentsToBeExcludedFromQueryString arguments to be 
removed from the URI. Only active if $addQueryString = TRUE
* @param string $addQueryStringMethod Set which parameters will be kept. 
Only active if $addQueryString = TRUE
* @return string Rendered link
*/
   public function render($action = null, array $arguments = [], $controller = 
null, $extensionName = null, $pluginName = null, $pageUid = null, $pageType = 
0, $noCache = false, $noCacheHash = false, $section = '', $format = '', 
$linkAccessRestrictedPages = false, array $additionalParams = [], $absolute = 
false, $addQueryString = false, array $argumentsToBeExcludedFromQueryString = 
[], $addQueryStringMethod = null)
   { . }


Viele Grüße,
Manuel
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] ViewHelper-Rckgabe erneut in FLUID rendern?

2017-07-27 Diskussionsfäden Manuel Raaf
Hi Dieter, 

ich denke, du meinst es nur gut, aber ich finde es ehrlich gesagt nicht so fein, dem anderen Denk- oder Planungsfehler zu unterstellen bzw. es für möglich zu halten, dass diese gemacht wurden, wenn man nicht von "unterstellen" sprechen möchte. Stattdessen wäre es angebrachter zu sagen "ja, TYPO3 hat manche Eigenschaften, die man als Einschränkung sehen kann". 
Du musst mir hier schließlich nichts verkaufen ;)


Anderes Beispiel: bau dir eine SQL-Abfrage mit $this->createQuery() und sag mir dann, wenn du merkst, dass du GROUP BY nicht einbringen kannst, dass es an deinem Denkfehler liegt. Wirst du kaum machen - schließlich ist es nicht dein Fehler. Man könnte zwar sagen, dass man sich vorher ewig lang mit den Einschränkungen von TYPO3-Klassen beschäftigen soll, aber wer geht heutzutage schon davon aus, dass man keinen GROUP BY angeben kann?! Das ist so dermaßen banal und gehört in jeden QueryBuilder und Konsorten! 
Der Fehler liegt auch hier nicht in der Planung, sondern in TYPO3/Extbase. Und dann darf man den Mist eben anders lösen -.-

Kurz: Nicht alle Probleme lassen sich auf Denk-/Planungsfehler zurückführen.

Ja, mir ist am ersten Tag TYPO3 bereits aufgefallen, dass das System für jene gedacht ist, die Hilfe dabei brauchen, kein "dummes Zeug" zu machen in der Entwicklung. Ich habe es damals anders ausgedrückt, aber im Prinzip lief es inhaltlich genau darauf hinaus :D 
Ich weiß für gewöhnlich, was ich mache, und daher brauche ich diese Hilfe des Frameworks nicht so zwanghaft. Dass sie da ist, finde ich prima, da sie einen unterstützen kann, aber ich möchte sie eben bei Bedarf möglichst unkompliziert umgehen. 
Andere Templatesprachen sind flexibler; FLUID eben nicht. Also muss eine Lösung her - für eine einfache Anforderung eine einfache Lösung. 


Na, mit JS wäre es ja erst recht Flickschusterei :D

DataProcessing war zu umständlich und noch dazu in TypoScript. Aber danke 
trotzdem für den Hinweis.
Ich bin durch einen Kollegen auf eine andere, viel einfachere Lösung gekommen. 
Im Prinzip sogar unkompliziert. Siehe nächster Post.

Viele Grüße,
Manuel

ps.: Recherchen sind dann wirtschaftlich, wenn sie ein hilfreiches Ergebnis haben. Andernfalls freilich nicht, aber die Alternative ist es ebenso wenig, da man dadurch auch nicht weiter kommt. Lohnenswert ist eine Recherche daher allemal. 


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Re: .png Bilder werden nicht skaliert, .jpg schon

2017-07-27 Diskussionsfäden Irgendwas mit E

Problem gelöst (auch wenn ich die Lösung nicht verstehe):

Mit einer gerade eben (per Gimp) erstellten PNG-Grafik geht es. Die alte PNG-Grafik (von 
2011) wird hingegen weiterhin nicht skaliert. Falls jemand weiß wie man auch 
"alte" PNG Dateien skaliert bekommt, gerne schreiben.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] ViewHelper-Rckgabe erneut in FLUID rendern?

2017-07-27 Diskussionsfäden Manuel Raaf

Hi Stephan,

danke - ich bin gestern Abend noch auf eine Lösung gekommen (durch Mithilfe 
eines Kollegen; siehe nächter Post), die vllt (?) so in die Richtung geht, die 
du beschrieben hast.

Viele Grüße,
Manuel
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german