from:"Thomas Skierlo"


in ext_tables.php

// Re-activate Subheader for all CE
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addFieldsToPalette('tt_content','header','--linebreak--,subheader;LLL:EXT:cms/locallang_ttc.xml:subheader_formlabel','after:header');

(in eine Zeile, der Linebreak ist forumsbedingt)

Grüße,

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

Re: [TYPO3-german] utf8_unicode_ci / TYPO3 6.2.0


Hallo Oli,

installiere Dir den aktuellen Master (von HEUTE), gehe ins Install Tool. Unter "All 
configuration" -> [SYS][setDBinit] trägst Du ein:

SET NAMES utf8 COLLATE utf8_unicode_ci;

Mir ist zwar nicht ganz klar, wieso dies ohne single-tics um die Parameter 
funktioniert. Tatsache ist aber, dass danach die Probleme weg waren.

Unklar bleibt am Ende, warum diese Setting überhaupt erforderlich ist, 
speziell, wenn serverseitig alles auf utf8_unicode_ci gezwungen war. Ich 
vermute, auch bei Dir wird die DB ansonsten anstandslos funktioniert haben.

Grüße,

Thomas





Quote: Oliver Klee wrote on Wed, 15 January 2014 18:35


Hi,

Am 15.01.2014 13:38, schrieb Thomas Skierlo:
> klar geht das - die komplette Geschichte steht in der englischen Liste:
> 
> exec_SELECTquery

> ERROR: Illegal mix of collations (utf8_general_ci,IMPLICIT) and
> (utf8_unicode_ci,IMPLICIT) for operation '<>'
> lastBuiltQuery : SELECT COUNT(uid) FROM tt_content WHERE media <> '' AND
> CAST(CAST(media AS DECIMAL) AS CHAR) <> media OR (CType = 'uploads' AND
> select_key != '')

Das selbe Problem habe ich auch:

<http://forge.typo3.org/issues/36754>


Oli
--
Certified TYPO3 Integrator | Former TYPO3 Security Team Member




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

Re: [TYPO3-german] utf8_unicode_ci / TYPO3 6.2.0


STOP - alles auf Anfang

Habe gerade auf Forge gesehen, dass vor 4 Stunden wohl genau an dieser Stelle 
Hand angelegt wurde. Neuesten HEAD installiert, Collation eingetragen, Cache 
gelöscht und: siehe da, es klappt. Kein Absturz mehr beim Update Wizard.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] utf8_unicode_ci / TYPO3 6.2.0


Hallo Renzo,

vielen, vielen Dank für Deine Antwort. Ich hatte zwischenzeitig einer der unter 
#41596 gelisteten anderen Issues gefunden, der auch in einem Patch mündete.

Mir gefällt nicht, hier mit einem Patch zu arbeiten. Den habe ich zwei Tage 
später vergessen und lande irgendwann in noch größerem Chaos. Zumal es, 
abgesehen von diesem elenden query im Update Wizard, überhaupt keine Probleme 
mit utf8_unicode_ci gibt. Mein erster Versuch war schließlich, eine 6.1.6 Site 
zu migrieren - und die lief/läuft komplett und ohne db-Probleme, bis zum Klick 
auf den Wizard.

Mir ist auch vollkommen unklar, warum an dieser Stelle überhaupt ein solch 
kritischer Query gebildet wird. Hier ist nichts zeitkritisch, und mit php gäbe 
es hier wohl keine Probleme.

Wenn dieses Problem nur durch einen Patch behebbar ist, dann frage ich mich, 
warum der nicht in den Core wandert. Das Resümee kann also nur sein:

TYPO3 6.2.0 ist nicht kompatibel mit utf8_unicode_ci

Ich habe in meinem kurzen Entwicklerleben bereits "weichere" 
Ausschlusskriterien für eine S/W erlebt. Das ist für mich ein ziemlich hartes Manko.

Ich werde - mit knirschenden Zähnen - erneut auf unicode_general_ci wechseln, 
und damit meinen 4. Anlauf für 6.2.0 einläuten.

Nochmals vielen Dank für Deine Hilfe,

Grüße,

Thomas

Quote: Renzo Bauen wrote on Wed, 15 January 2014 14:59


Hallo Thomas

setDBinit ist standardmässig für nichts zu gebrauchen. Es gibt aber
einen Patch, inzwischen eigentlich für alle TYPO3 Versionen. Leider hat
es der Patch nie bis in die fertige Version geschafft.
Ich brauche das weil mein SQL-Server im Strict-Mode läuft!

Es geht grundsätzlich so:
Du brauchst einen Patch für den Bootstrap.php. Siehe dazu
http://forge.typo3.org/issues/41596
Das letzte 6.1.xer Patchset ist die Nummer 11! 
Dannach ist es für die 6.2.


Neben der LocalConfiguration.php, welche grundsätzlich nicht editiert
werden sol, musst Du eine AdditionalConfiguration.php anlegen.
Darin kannst Du dann alles setzen, was m an mit setDBinit so machen
kann. Ich habe z.B. diesen Eintrag wegen dem strict-mode:



Ich hoffe, dass dies dich auf den richtigen Weg bringt...

Beste Grüsse
Renzo

--




Renzo Bauen
conPassione gmbh
T +41 33 345 00 92
M +41 79 330 10 11
http://www.conpassione.ch
TYPO3 Bronce Associate 


Am Mittwoch, den 15.01.2014, 13:38 +0100 schrieb Thomas Skierlo:

> Quote: Georg Ringer wrote on Wed, 15 January 2014 13:18
> 
> > Am 15.01.2014 13:11, schrieb Thomas Skierlo:
> > > Dieser endet bei mir
> > > grundsätzlich in einem SQL Error.
> > 
> > den man hier auch nennen könnte, oder?

> 
> 
> Hallo Georg,
> 
> klar geht das - die komplette Geschichte steht in der englischen Liste:
> 
> exec_SELECTquery

> ERROR: Illegal mix of collations (utf8_general_ci,IMPLICIT) and 
(utf8_unicode_ci,IMPLICIT) for operation '<>'
> lastBuiltQuery : SELECT COUNT(uid) FROM tt_content WHERE media <> '' AND 
CAST(CAST(media AS DECIMAL) AS CHAR) <> media OR (CType = 'uploads' AND select_key != '')
> 
> Es knallt wegen /typo3/sysext/install/Classes/Updates/TtContentUploadsUpdateWizard.php (checkForUpdate()). Der Bug scheint seit 16 Monaten bekannt.
> 
> Parallel dazu scheint es auch nicht möglich, die Collation per setDbInit/Install Tool zu erzwingen. Egal was ich dort eingebe, die Eingabe wird bestätigt, aber ignoriert (LocalConfiguration.php bekommt nur einen neuen Timestamp)
> 
> 
> 
> 
> ___

> TYPO3-german mailing list
> TYPO3-german (at) lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german




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

Re: [TYPO3-german] utf8_unicode_ci / TYPO3 6.2.0


Quote: Georg Ringer wrote on Wed, 15 January 2014 13:18


Am 15.01.2014 13:11, schrieb Thomas Skierlo:
> Dieser endet bei mir
> grundsätzlich in einem SQL Error.

den man hier auch nennen könnte, oder?



Hallo Georg,

klar geht das - die komplette Geschichte steht in der englischen Liste:

exec_SELECTquery
ERROR: Illegal mix of collations (utf8_general_ci,IMPLICIT) and 
(utf8_unicode_ci,IMPLICIT) for operation '<>'
lastBuiltQuery : SELECT COUNT(uid) FROM tt_content WHERE media <> '' AND 
CAST(CAST(media AS DECIMAL) AS CHAR) <> media OR (CType = 'uploads' AND select_key != 
'')

Es knallt wegen 
/typo3/sysext/install/Classes/Updates/TtContentUploadsUpdateWizard.php 
(checkForUpdate()). Der Bug scheint seit 16 Monaten bekannt.

Parallel dazu scheint es auch nicht möglich, die Collation per 
setDbInit/Install Tool zu erzwingen. Egal was ich dort eingebe, die Eingabe 
wird bestätigt, aber ignoriert (LocalConfiguration.php bekommt nur einen neuen 
Timestamp)




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

[TYPO3-german] utf8_unicode_ci / TYPO3 6.2.0


Hallo,

sorry, wenn ich diese Frage zeitgleich auch im englischen Forum stelle - aber 
ich stecke fest, und bekomme keine Antworten.

Die Frage ist ganz einfach:

Hat irgend jemand TYPO3 6.2.0 zusammen mit utf8_unicode_ci (anstatt utf8_general_ci) im Betrieb. 
Falls ja, bitte Hand heben. Ganz besonders entzückend wäre es, wenn der oder die zusätzlich einen 
Klick auf "Update Wizard" im "Install Tool" tätigen könnte. Dieser endet bei 
mir grundsätzlich in einem SQL Error.

Danke im Voraus,

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

Re: [TYPO3-german] Bilder per CONTENT-Objekt auslesen und verlinken (T3 6.1)


Hallo Lars,

schau Dir mal FILES an. Durch FAL hat sich vieles geändert. 


20 = FILES
20 {
references {
table = tt_content
uid.field = uid
uid.override.field = 
_LOCALIZED_UID
fieldName = image
}

renderObj = COA
renderObj {
10 = IMAGE
10 {
file.import.data = 
file:current:publicUrl
   }
   

Du findest das, was Du suchst unter:

altText.data = file:current:alternative
typolink.parameter.data = file:current:link
usw.

Viel Erfolg,

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

[TYPO3-german] addTCAcolumns

2014-01-13 Diskussionsfäden Thomas Skierlo


Hat sich zwischen 6.1.x und 6.2.0 hier irgend etwas geändert?

\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addTCAcolumns('pages', 
$tempColumns, 1);

z.B. Wegfall des 3. Parameters? Falls ja, wo kann man eine solche Information 
finden?

Mein Depreciation Log wird derzeit geflutet mit:

13-01-14 11:00: Usage of feInterface is no longer part of the TYPO3 CMS Core. 
Please check EXT:statictemplates.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] indexed_search unter 6.2.0

2014-01-13 Diskussionsfäden Thomas Skierlo

Hallo Philipp,

danke für den Hinweis - die Erklärung würde zu den Symptomen passen. Ich habe jetzt Indexer.php 
gepatcht und den Index neu aufgebaut. Hinsichtlich des "Erscheinens" des Plugins bringt 
dies jedoch keine Veränderung. Header wird ausgegeben, der Rest nicht. Die Template Datei wird 
komplett ignoriert - und auch eine Umstellung auf die "Experimentelle" Variante ändert 
daran nichts. Die Ursachensuche wird noch etwas erschwert durch einen stochastisch 
dazwischenfunkenden Fatal vom Logger.

Grüße,

Thomas

Quote: Philipp Gampe (pgampe) wrote on Sun, 12 January 2014 20:47
----

Hi Thomas,

Thomas Skierlo wrote:

> Funktioniert auch stabiler als mein erster Anlauf mit dem Upgrade.
> Abgesehen von der einen oder anderen Exception (die sich selten
> wiederholt). Der einzige Unterschied: Auf der migrierten Site funktioniert
> indexed_search, auf der neu angelegten nicht. Konfiguration ist identisch,
> und auch im Typoscript Object Browser ist zwischen alter und neuer Version
> keinerlei Unterschied zu finden. Abgesehen vom Header  wenn man ihn denn
> setzt  gibt das Plugin gar nichts aus. In beiden Fällen ist das
> herkömmliche Plugin, also nicht die experimentelle Version, gewählt. Die
> eigene Template-Datei wird auch im TSOB angezeigt, aber ansonsten komplett
> ignoriert. Ein Index wird erstellt. Ansonsten: Schweigen im Walde

Vermutlich werden keine Index Einträge angelegt:
http://forge.typo3.org/issues/54917

Die alten Einträge existieren vermutlich.

Grüße
--
Philipp Gampe  PGP-Key 0AD96065  TYPO3 UG Bonn/Köln
Documentation  Active contributor TYPO3 CMS
TYPO3  inspiring people to share!

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

[TYPO3-german] indexed_search unter 6.2.0

2014-01-12 Diskussionsfäden Thomas Skierlo

Hallo in die Runde,

ich habe in den letzten Tagen zwei Anläufe unternommen, auf 6.2.x umzusteigen. Der erste
Versuch bestand in einer Migration einer 6.1.6 Version zur "offiziellen"
6.2.0beta3. Es gab viele (lösbare) Probleme, aber die upgegradete Site lief schließlich.
Inklusive aller Dinge, die auch unter 6.1.6 funktionierten. Da beim Upgrade meine bereits
auf FAL migrierten Assets zerschossen wurden, habe ich mich dazu entschlossen, einen
weiteren Anlauf zu wegen. Mit einer Neuinstallation.

Diesmal mit dem Master von vor ca. 1 Woche. Neue DB, aber ansonsten exakt
gleicher Bestückung an Extensions/Sys_Extensions.

Funktioniert auch stabiler als mein erster Anlauf mit dem Upgrade. Abgesehen
von der einen oder anderen Exception (die sich selten wiederholt). Der einzige
Unterschied: Auf der migrierten Site funktioniert indexed_search, auf der neu
angelegten nicht. Konfiguration ist identisch, und auch im Typoscript Object
Browser ist zwischen alter und neuer Version keinerlei Unterschied zu finden.
Abgesehen vom Header wenn man ihn denn setzt gibt das Plugin gar nichts aus.
In beiden Fällen ist das herkömmliche Plugin, also nicht die experimentelle
Version, gewählt. Die eigene Template-Datei wird auch im TSOB angezeigt, aber
ansonsten komplett ignoriert. Ein Index wird erstellt. Ansonsten: Schweigen im
Walde.

Irgendwelche Ideen?

Grüße,

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

[TYPO3-german] Re: BE-Layouts unter 6.2.0

2014-01-11 Diskussionsfäden Thomas Skierlo


Quote: Thomas Skierlo (tsknl) wrote on Sat, 11 January 2014 11:16


Hallo Matthias,

danke für den Tipp - genau, was ich gesucht habe.

Grüße,

Thomas

Quote: Matthias Eberlein  (skydivematy) wrote on Sat, 11 January 2014 11:06

> Hallo Thomas,
> 
> schau dir dazu bitte die kleine Ext. von Gerog Ringer an.
> 
> https://github.com/georgringer/belayout_fileprovider
> 
> Funktioniert perfect.
> 
> gruss

> maty



Ich würde das Thema gerne noch mal aufgreifen. M.E. gehört dieser File Provider 
in den Core, zumindest als sys_extension. Ein wesentlicher Grund für BE_Layouts 
aus dem Filesystem sind eigene Extensions, die ein BE-Layout mitbringen sollen. 
Ich z.B. installiere alle meine Domains/Subdomains auf genau diese Weise. Durch 
die Notwendigkeit zur vorherigen Installation einer Community Extension 
entsteht eine weitere Abhängigkeit, die eine so kritische Funktion nicht haben 
sollte.


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

[TYPO3-german] Re: BE-Layouts unter 6.2.0

2014-01-11 Diskussionsfäden Thomas Skierlo


Hallo Matthias,

danke für den Tipp - genau, was ich gesucht habe.

Grüße,

Thomas

Quote: Matthias Eberlein  (skydivematy) wrote on Sat, 11 January 2014 11:06


Hallo Thomas,

schau dir dazu bitte die kleine Ext. von Gerog Ringer an.

https://github.com/georgringer/belayout_fileprovider

Funktioniert perfect.

gruss
maty




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

[TYPO3-german] BE-Layouts unter 6.2.0

2014-01-11 Diskussionsfäden Thomas Skierlo


Moin,

es gab vor geraumer Zeit abendfüllende Diskussionen, ob und wie BE-Layouts, ähnlich wie bereits 
BE-Layouts für Gridelements, "installierbar" gemacht werden könnten. Die Lösung war wohl 
ein "Data-Provider". Ich würde diese Funktion jetzt, wie auch bereits vor Jahren, gerne 
nutzen, finde aber keine Beispiele. Ist das noch Ghostware, oder gibts das bereits?

Grüße,

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

Re: [TYPO3-german] TYPO3 6.2 Wann Upgrade wagen?

Resümee des bisherigen Upgradverlaufs:

1) Mehrere kleine Probleme, die zwar unschön, aber schnell kurierbar waren.
Keine davon wäre ein Grund, den Upgrade nicht zu wagen. Soweit bon!

2) Jetzt die unschöne Seite. Nach dem Upgrade und nach Bestätigung mehrerer
Wizzards, waren die unter 6.1.6 anstandslos arbeitenden FAL-Assets unbrauchbar.

Soll heissen: Die Originalmaße sind futsch, gleiches gilt für Title,
description und alternative. Neuindizierung brachte keine Abhilfe. Nur NULL und
0 Einträge unter sys_file_metadata, und dies gilt für alle Files. Mein Image
Rendering Hook bekommt nur noch Bullshit (sorry) geliefert und macht die
Blutgrätsche - was bleibt ihm auch anderes?

Unter Reports plötzlich: Files flagged as missing: 298 files

Bei manchen stimmt das. Die sind tatsächlich weg, im Sinne von "gewesen". Andere sind
noch physisch anwesend, werden aber nicht als vorhanden erkannt. Unter den "missing"
Files finden sich auch welche, die zu längst gelöschten CE gehöre, welche durch den Recycler
gelöscht wurden.
Erwähnen sollte ich vielleicht noch, dass ich eine Multi-Domain/Subdomain Umgebung
umgezogen habe. 292 der "verschwundenen" 298 Files entstammen einer Subdomain,
deren Daten ich lange nicht mehr angerührt hatte (obschon bereits auf FAL migriert).

Das dies tatsächlich am Upgrade liegen muss, sieht man dann an

3) Neuen File hochgeladen, versehen mit Metadaten und per Text w. Image
verwurstet. Und siehe da. Alles klappt, inklusive meinem Hook und BS-3
Rendering. Einige wenige RTE Klassen für BS sind auf der Strecke geblieben,
aber das lässt sich sicher fixen.
Dieser neu hochgeladene File verfügt tatsächlich über Höhe und Breite, und die
Metadaten stehen in der DB.

4) Die Typolink-Erzeugung über "typolink.parameter.data = file:current:link"
ist irgendwie auf der Strecke geblieben. Kann aber nix Gravierendes sein.

Ich vermute fast, dass meine FAL Migration schief gegangen ist, weil ich
bereits komplett auf FAL umgestiegen war. Möglicherweise sind die
Migrationspfade derzeit etwas 4.5-lastig (wofür ich Verständnis hätte). Eine
gute Idee wäre es sicherlich, vor der beta4 auch einen Migrationstest von einer
bis dato bestens gepflegten 6.1.x zu wagen.

Zu klären bliebe, warum bei der Migration die GE-spezifischen Spalten
"tx_gridelements_backend_layout" und "tx_gridelements_children"
zurückgesetzt/gelöscht wurden. Ist aber einfach behebbar.

Wahrscheinlich hilft es den Entwicklern eher, wenn viele ebenfalls den Upgrade
Weg beschreiten. Ich denke, meine Probleme wären mit einer frischen 6.2.0 nicht
aufgetreten. Wenn man also tatsächlich etwas zu verlieren hätte, so wäre ein
Neueinstieg mit frischer 6.2.0 dem Upgrade sicher vorzuziehen.

Zumindest ist die heutige Nacht weit weniger dunkel als die letzte...

Hasta mañana.

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

Re: [TYPO3-german] Nochmal gridelements 1.4.1 / TYPO3 4.7.17


Quote: JCL - Johannes C. Lax wrote on Tue, 07 January 2014 15:59


Hallo Thomas,

> Schau doch mal nach, was beim betroffenen GE in tt_content in 
> der Spalte "tx_gridelements_backend_layout" steht.

>

danke fur die Antwort. Da steht "1" drin, und das entspricht der ID fur das
Backend-Layout.



so weit, so gut


Ich hatte vergessen zu erwahnen, dass zusatzlich im Feld "Spalte" noch

[WERT IST NICHT ERLAUBT ("11"]

steht. Hier kann ich aber die richtige Spalte auswahlen. Der Wert "11"
entspricht in diesem Fall der ID des Inhaltselements. Zufall?

Johannes.



Du meinst das Feld colPos? Da sollte i.d.R. die Benennung Deiner Inhaltsspalte 
stehen (die, in welche Du das GE eingefügt hast). Wenn da besagte Meldung 
kommt, dann passt beim BE Layout irgend etwas nicht.

Ich würde übrigens auch mal in Richtung DB-Update gucken. Wenn ich mich recht 
erinnere, gab es in der Frühzeit von GE mehrere Änderungen in der DB.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Assets unsichtbar nach Upgrade auf 6.2.0beta3


Quote: Cedric Ziel (virtualmachine) wrote on Tue, 07 January 2014 14:42


Jep, hört sich gut an :)

Zitat von Thomas Skierlo :

> Oh Mist, hab's gerade gefunden. Scheduler? Zwei Tasks zur Wahl: FAL
> Update Storage Index, FAL Extract Metadata in Storage?
> ___
> TYPO3-german mailing list
>
TYPO3-german (at) 
lists.typo3.orghttp://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german



Schade, hat leider nicht die Dimensions zurück gebracht. Hat augenscheinlich gar nichts bewirkt. Was mir in 
der DB auffällt. In "sys_file" haben alle Records eine 0 in der Spalte "metadata". Ist 
doch sicher ein Flag, welches darauf verweist, dass es separate Metadaten gibt. Ich habe auch zu jedem File 
einen Eintrag in "sys_file_metadata" - leider nur mit unsinnigem Inhalt.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Assets unsichtbar nach Upgrade auf 6.2.0beta3


Oh Mist, hab's gerade gefunden. Scheduler? Zwei Tasks zur Wahl: FAL Update 
Storage Index, FAL Extract Metadata in Storage?
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Assets unsichtbar nach Upgrade auf 6.2.0beta3


Quote: Cedric Ziel (virtualmachine) wrote on Tue, 07 January 2014 14:11


Hi Thomas,

Ein ähnliches Problem hatte ich auch mit FAL Bildern-das gehört zu den
Dingen, die aktuell noch gefixt werden [müssen]. Bei mir trat dies im
Zusammenhang mit impexp auf.

Mein Workaround war eigentlich ziemlich simpel:
Ich habe die Indexierung bei den Files (image extensions) komplett
entfernt, welche wie von dir beschrieben wurde.
Danach habe ich den Index neu aufgebaut und alles war schick.



Hallo Cedric,

das klingt gut, auch wenn ich zugegebenermaßen nur Bahnhof verstanden habe. Wo 
kann ich die Indexierung der Files beeinflussen, und wie kann ich danach den 
Index neu aufbauen? Und dies kann doch auch bestenfalls die Maße wiederbringen, 
denn alle Text-Zutaten (Title, Description, Alt) sind futsch.


Im Übrigen würde ich empfehlen, vom Beta Tag auf den aktuellen Master zu
wechseln; dort ist einiges los.

Viele Grüße,
Cedric



Ich hatte gestern tatsächlich vor, nicht die beta3, sondern den Master zu 
nehmen. Habe per Git geklont, aber abgebrochen, als der Download 100 MB. 
überschritten hatte. Ich habe allerdings auch noch nie vorher eine TYPO3 
Release per Git geholt, bei Extensions hingegen andauernd. Vielleicht mache ich 
was falsch.


Viele Grüße,

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

[TYPO3-german] Assets unsichtbar nach Upgrade auf 6.2.0beta3

Nach dem gestrigen Umzug meines Entwicklungssystems von 6.1.6 auf 6.2.0beta3
gab es mannigfaltige Probleme - glücklicherweise viele davon leicht behebbar.

Was bleibt sind die nicht mehr vorhandenen Images. Ich sehe nur noch die,
welche ich per Gridelements selber rendere. Da mir das bisherige Rendering von
CSC (inkl. dem aktuellen für 6.2.0) für wirkliche responsive Images ungeeignet
erschien, habe ich mich per eigenem Hook für's Image Rendering dazwischen
geklemmt (basierend auf dem Code bzw. Setup von CSC 6.2.0 vor ca. 2 Monaten).
Dies lief auf 6.1.6 wunderbar, und ich vermutete zuerst mal hier den aktuellen
Bildverlust.

Da ich meine Redakteure komplett vom Ungemach irgend welcher Pixelangaben frei
machen will, führe ich komplexe Bildberechnungen durch, um das Bild in ein
responsives Grid zu wickeln. Dazu lese ich zuerst einmal aus, welche Maße es
denn im Originalzustand hat:

$resFactory =
GeneralUtility::makeInstance('TYPO3\CMS\Core\Resource\ResourceFactory');
$fileProps = $resFactory->getFileObject($totalImagePath)->getProperties();

Bis gestern kam auch in $fileProps was Seriöses an, u.a. width und height.
Heute, unter 6.2.0beta3, stehen beide Werte auf 0. Demzufolge gibts auch nix zu
berechnen oder gar auszugeben.

Also in die DB geschaut, denn da war doch etwas mit "Migration von Metadata":
Und tatsächlich. sys_file scheint um einige Felder bereinigt zu sein, und diese, zusammen
mit weiteren neuen, stehen unter sys_file_metadata. Zumindest theoretisch. Title,
description and alternative stehen auf NULL, und width und height auf 0. Gilt für alle
Files. Deshalb kommt auch vorne nix mehr raus.

Irgendwelche Ideen?

Grüße,

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

Re: [TYPO3-german] Nochmal gridelements 1.4.1 / TYPO3 4.7.17


Schau doch mal nach, was beim betroffenen GE in tt_content in der Spalte 
"tx_gridelements_backend_layout" steht.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] TYPO3 6.2 Wann Upgrade wagen?

So, die mutmaßlich Gridelements zugesprochene SQL Fehlermeldung ist weg. Was
war geschehen?

Irgend etwas (ich bleibe hier bewusst diffuse) hat dafür gesorgt, dass die tt_content Spalte
"tx_gridelements_backend_layout" geleert, und die "tx_gridelements_children"
auf 0 gesetzt wurde. Dadurch bekam das Query ein Bäuerchen und finito. GE war es mit Sicherheit
nicht, denn das war zu diesem Zeitpunkt deaktiviert, da als inkompatibel gebrandmarkt.

Geht man im BE in den Record, und setzt das BE-Layout manuell wieder richtig, und
sortiert die Kind-Elemente manuell wieder unter das Elternelement, so klappt alles.
Trotzdem kann man den Datenbestand nach der Migration als "unbrauchbar"
betrachten.

Hinsichtlich der Ursache habe ich folgende Mutmaßung:

1. Der Migrationsassistent trifft auf eine inkompatible Extension
2. Diese wird deaktiviert
3. Danach empfindet der Migrationsassistent die DB-Felder dieser Extension als
überflüssig, denn sie ist ja nicht da
4. Und er entsorgt diese in den Orkus der Geschichte

Jetzt gilt es die nächste Nuss zu knacken. Obwohl ich bereits auf 6.1.6 alles
auf FAL migriert hatte, sehe ich kein einziges Asset mehr. Weder mit den 6.2
CSC Definitionen, noch mit dem 6.1-Kompatibility Mode. Life stinks.

Ich bin wirklich auf den Tag gespannt, an dem die ersten, bis heute auf 4.5
klebenden Agenturen, den Upgrade wagen (müssen :-)

Dann noch zwei Dinge, die den Upgrade Prozess extrem vereinfachen würden.

1) Viele Extension Entwickler, und so auch ich, haben eine Version für alles
Alte, und eine für 6.2. In der alten steht als Dependancy:
TYPO3 4.5.0-6.1.99

In der neuen steht: TYPO3 6.2.0-6.2.99. Dies führt dazu, dass man die neue
Extension niemals VOR dem Release Upgrade einspielen kann. Also wird sie
deaktiviert und die DB wird prophylaktisch mal schnell verwüstet.

Abhilfe schafft nur ein Konstrukt wie TYPO3 6.1.0-6.2.99 bei der neuen Version der
Extension. Selbst wenn dies "gelogen" ist, so sind die Konsequenzen immer noch
harmloser als das DB Chaos.

2.) Viele Extension Entwickler, und so auch ich, haben in ihrer neuen Version
TYPO3 6.2.0-6.2.99 stehen. Dies führt dazu, dass die derzeitige 6.2.0beta3 als
inkompatibel bezeichnet wird. Keine Ahnung, ob ein Punkt (.) hinter 6.2.0 hier
Abhilfe schaffen würde (6.2.0.beta3)
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] TYPO3 6.2 Wann Upgrade wagen?


Quote: Jo Hasenau (cybercraft) wrote on Mon, 06 January 2014 14:57


> Zweiter Versuch scheitert: Meine php Version (5.3.10) sei zu alt. GE
> benötigt 5.4.4. Ich denke, das muss ein Spaß sein, und patche auch das
> weg.

Moin moin.

Sorry - PHP 5.4.4 ging auf meine Kappe, weil das ursprünglich mal 
geplant war, dass TYPO3 6.2 das als Requirement hat. Aktuell steht dort 
allerdings nur ein PHP 5.3.7, weswegen ich das soeben auch für GE 
geändert und gepushed habe.


3.0 dev ist aber dennoch mit der ein oder anderen Baustelle versehen, 
weil sich in 6.2 insbesondere beim BE-Interface doch einiges geändert 
hat, was GE behindert. Von daher wäre ich dankbar für Feedback 
http://forge.typo3.org/projects/extension-gridelements2/issues




Ich bin mir momentan gar nicht so sicher, ob das überhaupt an GE liegt. Vergleiche ich 
die bisherige 2.x mit der 3.0.0-dev, so finde ich keine markanten Unterschiede. Ganz 
sicher keine im mutmaßlichen SQL-Debug-Verursacher "Gridelements.php", denn der 
ist absolut baugleich mit dem Vorgänger.


Wir haben unsere Weihnachtsferien beendet und sind ab heute wieder zu 
100% am Start, von daher sollte sich in den nächsten Wochen bei 1.5 dev, 
2.1 dev und 3.0 dev einiges tun.


Frohes Schaffen :-)


dito

Trotzdem noch die Frage: Was mach ich jetzt? Rollback auf 6.1.6 mit kommod 
schnurrendem GE, oder ausharren und Fehler suchen?




Joey

--
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your gob sometimes!)
Dieter Nuhr, German comedian
Xing: http://contact.cybercraft.de
Twitter: http://twitter.com/bunnyfield
TYPO3 cookbook (2nd edition): http://www.typo3experts.com




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

Re: [TYPO3-german] TYPO3 6.2 Wann Upgrade wagen?

Quote: Helmut Hummel wrote on Mon, 06 January 2014 15:18

Hi!

On 06.01.14 13:03, Thomas Skierlo wrote:

> Ich bin wie folgt vorgegangen:
>
> Im alten System:
> Gridelements und News temporär deinstalliert und umbenannt (.old)

Das umbenennen ist keine gute Idee mehr mit TYPO3 6.2 und sollte 
vermieden werden. Lieber in ein anderes Verzeichnis verschieben.

Ich habe - trotz intensiver Suche und Nachfrage, u.a. hier - nichts zu den 
Update-Procedures auf TYPO3 6.2 finden können. Ausser den Hinweis, vorher für 
aktuellste Versionen installierter Extensions zu sorgen. Dieses muss natürlich 
scheitern, wenn die installierte Version einer Extension bis 6.1.99 gilt, und 
die neue erst ab 6.2.0. Deshalb habe ich die alten Extensions deaktiviert, und 
nach dem Deaktivieren umbenannt. Die für 6.2 vorgesehene Extension dann per Git 
eingespielt, und wieder aktiviert. Was kann denn an dieser Vorgehensweise 
falsch sein, bzw. welche Alternativen hätte es gegeben? Wobei noch 
erwähnenswert ist, dass die zwei betroffenen Extensions wohl zu den derzeit 
bestgepflegtesten überhaupt gehören.

> Beim Aufruf des BE redirect ins Install Tool.

Das ist so weit korrekt, bzw. erwünschtes Verhalten.

> (alter Extension Manager musste deinstalliert werden).

Kannst Du das konkretisieren und in einen Bugreport auf forge packen? 
Das sollte eigentlich nicht nötig sein.

Das war im Endeffekt auch kein Problem, denn auch nach Klick auf den Button 
"Extension Manager entfernen" funktionierte alles weiter. Zeigt auch als 
Version 6.2.0 an, und funktioniert auch.

> Diverse Aktionen wurden wohl erfolgreich ausgeführt, mündeten aber dennoch in 
eine Fehlermeldung. Leider nicht notiert.

Schade ;)

> Nicht kompatible Extensions (in diesem Fall eine von meinen) über Wizzard im Install 
Tool deinstalliert (waren danach dennoch im Extension Manager auf Status 
"installiert".

Kannst Du das konkretisieren und in einen Bugreport auf forge packen?
Das dürfte nicht passieren.

> GE benötigt 5.4.4.
> Dies ist für mich der erste TYPO3 Upgrade, der dermaßen in die Hose ging,
> dass ich jetzt wirklich nicht weiß, ob ich mich durch diesen Berg an 
Problemen quälen, oder besser eine Rolle rückwärts machen soll.

Damit wir bis zum Release die Upgrade Erfahrung besser machen können, 
ist solches Feedback extrem wichtig! Dafür schon mal danke.

Jetzt wäre noch zu klären welche Probleme durch TYPO3 und welche durch 
Extensions verursacht werden, bzw. was konkret bei Extensions mit 6.2 
kaputt geht. Da würde mich insbesondere GE interessieren. Welche Version 
läuft denn auf dem selben Host unter 6.1.x problemlos und fällt unter 
6.2 auf die Klappe?

Hmm... das ist ziemlich merkwürdig. Der SQL Fehler stammt wohl aus der 
getChildren Routine vom GE Plugin. Genau an der hat sich aber zwischen 6.1.6 
(alles war grün und schön) zu 6.2.0beta3 (nix geht mehr) nichts geändert - . 
Nach meinen bisherigen Untersuchungen ist die GE 3.0.0-dev, abgesehen von den 
Dependancies im Wesentlichen identisch mit der unter 6.1.6 genutzten GE 2.x. 
Die SQL where clause ist die exakt Gleiche.

Warum das so ist rauszufinden würde auch noch weiterhelfen...

> Leute: php 5.4.4 ist total weltfremd. Ubuntu 12.04 ist derzeit der Volkswagen 
der Hoster. Auf 12.04 läuft 5.3.10, und das noch 3 Jahre lang.

Der Support für PHP 5.3.x läuft 2014 aus. Gleichzeitig kommt ein neues 
Ubuntu LTS 14.04 welches mindestens PHP 5.4, evtl. sogar PHP 5.5 
mitbtingt. Die großen Hoster werden sicherlich in diesem Zeitrahmen auch 
umschwenken auf neuere PHP Versionen, zumal diese bessere Performance 
bieten und damit verbunden evtl. sogar geringere Kosten verursachen.

So weltfremd ist die PHP 5.4.4 Voraussetzung also nicht, finde ich.

Ich möchte dabei zu bedenken geben, dass die zu erwartende Qual für Nutzer 
alter TYPO3 Versionen (auf aktuell gültigen LTS OS Versionen) beim Upgrade 
doppelt so groß wird, wenn sie neben TYPO3 Nickeligkeiten auch noch den Server 
aktualisieren müssen. Host Europe beispielsweise bietet Ubuntu 12.04 erst seit 
Ende 2013 an, da sie Probleme mit der Virtualisierungssoftware hatten. Ein 
Produkt kann sich auch durch Überspezifikation aus dem Markt katapultieren.

Irgend welche Ideen, wie ich mich jetzt in die richtige Richtung debuggen kann?

*zerknirschtestens*

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

Re: [TYPO3-german] TYPO3 6.2 Wann Upgrade wagen?

Quote: Johannes C. Schulz (enzephalon) wrote on Mon, 06 January 2014 13:15

Hallo Thomas

Meiner bescheidenen Meinung nach ist Ubuntu kein ServerOS. Debian Squeeze oder
gar Wheezy sollten hier die Wahl sein. Aber das nur am Rande.
Bitte würfele die Probleme die dir gerade GE mit der php-Version macht, nicht
mity typo3 durcheinander. Das sind zwei paar Schuhe!
Hast Du vor dem Upgrade mal ein nacktes 6.2 mit Deinen Extensions aufgesetzt?
Funktioniert das?

Viele Grüße
Johannes C. Schulz - EnzephaloN IT-Solutions
(von unterwegs gesendet)

Hallo Johannes,

ich nutze auf meinem Entwicklungs-Server bewusst eine Umgebung, die ich bei meinem Hoster
(hier: Host-Europe) in identischer Weise vorfinde. Mag sein, dass es bessere
Distributionen gibt, aber ich bin zu alt und träge, jetzt noch einen neuen
Nebenkampfschauplatz "Server OS" aufzumachen. Ich komme mit Ubuntu bestens
klar, und nutze dort eine recht komplexe php/fcgid Konfiguration. Ein php Upgrade
innerhalb der Server Lifetime wäre für mich die allerletzte Lösung, weil man sich i.d.R.
damit bloß Scherereien einkauft.

Und nein, ich habe kein neues 6.2 aufgesetzt, sondern versucht, mein
(minimales) 6.1.6 upzugraden. Zwei der Probleme sind auch schon weg. Sichtbar
zickt momentan nur noch GE rum. Aber das bekomm ich auch noch hin.

Bei News war die Lösung übrigens, es 2-3 mal zu deaktivieren/aktivieren,
jeweils zusammen mit Cache löschen. Plötzlich war der Fatal weg.

Grüße,

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

Re: [TYPO3-german] TYPO3 6.2 Wann Upgrade wagen?


Quote: Thomas Skierlo (tsknl) wrote on Mon, 06 January 2014 13:03



Fatal error: Interface 'Psr\Log\LoggerInterface' not found in 
/usr/local/share/typo3/typo3_src-6.2.0beta3/typo3/sysext/core/Classes/Log/Logger.php
 on line 36



Der Fehler ist behoben.
clean typo3temp/Cache directory
use "Clear all caches" in the backend.

Ich Depp, ich. Die restlichen Probleme bestehen leider weiter


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

Re: [TYPO3-german] TYPO3 6.2 Wann Upgrade wagen?


Quote: Jan Bartels wrote on Thu, 02 January 2014 23:23


Am 02.01.2014 17:49, schrieb Thomas Skierlo:
> Quote: Georg Ringer wrote on Thu, 02 January 2014 17:25
> 
>> Hallo,
>>
>> du kannst das sicherlich jetzt wagen! Und gerade wenn du wenig
>> Extensions hast die bei 6.2 brechen, sollte das von 6.1 sehr smooth sein.
>>
>> lg Georg
> 
>
> Hallo Georg,
>
> danke für Deine Antwort. Ich werd's dann morgen mal wagen

Berichte hier bitte anschließend über Deine Erfahrungen.

Meine sind nach wie vor nicht so positiv, denn ich komme noch nicht mal 
bis zum Install-Tool. Ich muss in den nächsten Tagen mein Testsystem 
noch mal komplett neu aufsetzen und vor dem Update mehrere Extensions 
sauber herausoperieren (also löschen), die ich im Verdacht habe, obwohl 
sie für 4.5 bis 6.1 freigegeben sind. Deaktivieren vor dem Update 
scheint nicht zu reichen.


Gruß,

Jan



Sodelle...etwas feedback

Bisher leider kein angenehmes Erlebnis. BE läuft noch halbwegs, jedoch mit 
unten eingeblendetem Fatal:

Fatal error: Interface 'Psr\Log\LoggerInterface' not found in 
/usr/local/share/typo3/typo3_src-6.2.0beta3/typo3/sysext/core/Classes/Log/Logger.php
 on line 36

Das FE zeigt durchaus noch etwas an, wenn man die 3 Seiten SQL-Debug davor 
wegrollt. Es erinnert leider nicht an das, was vor dem Upgrade da war.

SELECT * FROM tt_content WHERE tx_gridelements_container = 320 AND 
tt_content.deleted=0 AND tt_content.t3ver_state<=0 .

Um überhaupt soweit zu kommen, musste ich "News" vorerst (durch den Wizzard im 
Install Tool) wieder deinstallieren, denn ansonsten löste jeder Klick im BE einen Fatal 
aus.

Meine Ausgangssituation war mutmaßlich unkritisch:
TYPO3 6.1.6, php 5.3.10 Ubuntu 12.04

Extension: Gridelements, News, Static Info Tables, sowie 3 Ext. von mir.

Ich bin wie folgt vorgegangen:

Im alten System:
Gridelements und News temporär deinstalliert und umbenannt (.old)
Neueste Versionen von GE und News per Git
TYPO3 Upgrade auf 6.2.0beta3 auf dem Server

Beim Aufruf des BE redirect ins Install Tool. Alle Wizzards durchlaufen (alter Extension 
Manager musste deinstalliert werden). Diverse Aktionen wurden wohl erfolgreich 
ausgeführt, mündeten aber dennoch in eine Fehlermeldung. Leider nicht notiert. Nicht 
kompatible Extensions (in diesem Fall eine von meinen) über Wizzard im Install Tool 
deinstalliert (waren danach dennoch im Extension Manager auf Status 
"installiert".

News und GE waren ja noch deaktiviert. Beim Aktivieren von GE: "Your TYPO3 Version 
is lower than neccessary. You need at least TYPO3 v. 6.2.0."

Bon. Er mag die 6.2.0beta3 nicht. Also GE gepatcht, damit da Ruhe eintritt.

Zweiter Versuch scheitert: Meine php Version (5.3.10) sei zu alt. GE benötigt 5.4.4. Ich 
denke, das muss ein Spaß sein, und patche auch das weg. War aber wohl kein Spaß, denn das 
FE zeigt nur "rot".

Dies ist für mich der erste TYPO3 Upgrade, der dermaßen in die Hose ging, dass 
ich jetzt wirklich nicht weiß, ob ich mich durch diesen Berg an Problemen 
quälen, oder besser eine Rolle rückwärts machen soll.

Leute: php 5.4.4 ist total weltfremd. Ubuntu 12.04 ist derzeit der Volkswagen 
der Hoster. Auf 12.04 läuft 5.3.10, und das noch 3 Jahre lang. Kommt TYPO3 6.2 
tatsächlich mit php 5.3.7 klar, oder habe ich da was übersehen? Bin momentan 
echt ratlos.

Grüße,

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

Re: [TYPO3-german] Hausputz nach FAL-Migration

2014-01-03 Diskussionsfäden Thomas Skierlo


Quote: Philipp Gampe (pgampe) wrote on Fri, 03 January 2014 14:30


Hi Thomas,

Thomas Skierlo wrote:

> nur im Terminal sichtbar (also nicht im BE):
> fileadmin > _processed_ (mit Preview Files aus Haupt- und Subdomain)
> 
> Ist das so expected behavior? Ich könnte mir pro Domain/Subdomain einen

> _processed_ Ordner erklären, der dann nicht leer wäre. ODER ich könnte mir
> einen zentralen _processed_ Ordner vorstellen (wie bei mir), der dann aber
> den gleichnamigen unter der Hauptdomain überflüssig machen würde.
> 
> Ist der leere Ordner unter der Hauptdomain überflüssig? Können weitere

> alte Ordner ggf. entfernt werden?

Es sollte pro Storage nur ein __processed__ Verzeichnis geben. Die Anderen 
solltest du ohne Probleme entfernen können.


Grüße
--
Philipp Gampe  PGP-Key 0AD96065  TYPO3 UG Bonn/Köln
Documentation  Active contributor TYPO3 CMS
TYPO3  inspiring people to share!



Hallo Philipp,

danke für die Bestätigung. Das war auch meine Vermutung. Vielleicht ein Relikt 
einer anfangs nicht ganz sauberen Konvertierung.

Grüße,

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

Re: [TYPO3-german] TYPO3 6.2 Wann Upgrade wagen?

2014-01-02 Diskussionsfäden Thomas Skierlo


Quote: Georg Ringer wrote on Thu, 02 January 2014 17:25


Hallo,

du kannst das sicherlich jetzt wagen! Und gerade wenn du wenig 
Extensions hast die bei 6.2 brechen, sollte das von 6.1 sehr smooth sein.


lg Georg



Hallo Georg,

danke für Deine Antwort. Ich werd's dann morgen mal wagen,

Grüße,

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

[TYPO3-german] Hausputz nach FAL-Migration

2014-01-02 Diskussionsfäden Thomas Skierlo


Moin,

ich schleppe mein Entwicklungssystem seit 4.5 von Release zu Release, hatte 
also Altlasten, als es irgendwann an die FAL-Migration ging. Sie verlief dann 
aber erfreulich unauffällig. Die automatisch migrierten Assets habe ich per 
TYPO3 BE umsortiert (in Domain/Subdomain-spezifische File Mounts), und alles 
war gut. Jetzt versuche ich, die ganzen Altlasten etwas aufzuräumen, und dabei 
fällt mir Folgendes auf. Meine aktuelle Directory Struktur:

fileadmin > Hauptdomain > Images (mit Verzeichnissen und Originalbildern)
fileadmin > Hauptdomain > _processed_ (VZ ist leer)

fileadmin > Subdomain1 > Images (mit Verzeichnissen und Originalbildern)

nur im Terminal sichtbar (also nicht im BE):
fileadmin > _processed_ (mit Preview Files aus Haupt- und Subdomain)

Ist das so expected behavior? Ich könnte mir pro Domain/Subdomain einen 
_processed_ Ordner erklären, der dann nicht leer wäre. ODER ich könnte mir 
einen zentralen _processed_ Ordner vorstellen (wie bei mir), der dann aber den 
gleichnamigen unter der Hauptdomain überflüssig machen würde.

Ist der leere Ordner unter der Hauptdomain überflüssig? Können weitere alte 
Ordner ggf. entfernt werden?

Grüße,

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

[TYPO3-german] TYPO3 6.2 Wann Upgrade wagen?

2014-01-02 Diskussionsfäden Thomas Skierlo

Hallo zusammen,

ich arbeite seit längerem an meiner Extension "Bootstrapper", die TYPO3 (ein
weiteres mal) den Segen von BS3 bescheren soll. Mich interessiert im Endausbau
ausschließlich TYPO3 >= 6.2, ich hänge mit meinem Entwicklungssystem aber noch auf 6.1.6
fest, da mich derzeit noch einige heftige Issues zu 6.2 auf Forge abschrecken.

Ich benötige erfreulich wenige Extensions. Diese sind:

Gridelements
News
Static Info Tables (könnte derzeit auch ohne leben)

plus 2 eigene Extensions, die mir an dieser Stelle aber weniger Sorgen machen.
Dies alles natürlich multi-domain, und multilingual.

Für GE und News gibt es bereits 6.2-taugliche Dev.-Versionen. Soweit Bon.

Jetzt zur Frage: Ich bin seit Jahren daran gewöhnt, mit jeder neuen Release seit 4.5
mehrere Tage damit zu verbringen, das Depreciation Log wieder zu beruhigen. Ich weiß
also, wie das geht, aber ich bin es auch irgendwie leid - bzw. positiver ausgedrückt, ich
möchte mich derzeit um meine Extension kümmern, und weniger um den Core. Zumal ich
zeitgleich daran arbeite, neue Doku-Standards (ReST, SPHINX) und Versionierung (Git) zu
begreifen und anzuwenden. Lernkapazitätsmässig bin ich also gerade im
"Tilt-Mode".

Ist es unter diesen Prämissen sinnvoll, den Upgrade auf die 6.2.0beta3 zu wagen, oder sollte ich
besser noch damit warten? Irgendwo habe ich einen Satz gelesen, aus dem Gedächtnis in etwa so:
"Es kann sogar sein, dass die 4.5 User weniger Driss mit dem Upgrade haben werden, als die 6.1
Nutzer". Ist da was dran? Was mir auch fehlt ist ein Minimalwiki zum Upgrade: "Was muss
anders". Gibt's da irgendwas?

Es geht NICHT um ein Produktivsystem. Trotzdem würde mich im Moment ein weißes
BE über Gebühr nerven.

Danke für allen Input,

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

Re: [TYPO3-german] Doku Problem reST

2013-12-31 Diskussionsfäden Thomas Skierlo


Quote: Jost Baron (jost_baron) wrote on Tue, 31 December 2013 12:22


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Thomas,

mir haben die RestTools bei dem Problem geholfen. Näheres hier:

https://git.typo3.org/Documentation/RestTools.git/tree

Für Sphinx liegt unter

https://git.typo3.org/Documentation/RestTools.git/blob_plain/HEAD:/ExtendingSphinxForTYPO3/README.txt

die Anleitung.

Gruß Jost



Hallo Jost,

danke für den Tipp, aber die RestTools hatte ich bereits gemäß dem Wiki 
installiert. Was dort jedoch nicht stand, war den Hinweis, den TYPO3 Codeblock 
in die conf.py zu kopieren. Das habe ich jetzt gemacht. Immerhin, diesmal mit 
anderem Fatal :-)

 File "/usr/lib/python2.7/codecs.py", line 881, in open
   file = __builtin__.open(filename, mode, buffering)
IOError: [Errno 2] No such file or directory: 
u'/home/thomas/Documentation/bsc/source/_not_versioned/10_conf_py.yml'

Und, wo er recht hat, hat er recht. Bei mir gibt es weder '_not_versioned' noch 
'10_conf_py.yml'. Ich glaub, ich geb's auf, und trink mir lieber einen.

Salut

Thomas

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

[TYPO3-german] Doku Problem reST

2013-12-31 Diskussionsfäden Thomas Skierlo


Hallo,

nachdem ich mich jetzt doch entschlossen habe, mir das mutmaßliche Ungemach von Dokumentation per reStructuredText anzutun, klappte anfangs alles bestens. Sphinx funktioniert,  und auch die TYPO3 spezifischen Styles funktionieren  fast. Alles ist orange, es gibt ein TYPO3 Logo, das reST-Gedöhns klappt. Knallen tut's dann erst, wenn man 


. t3-field-list-table::

benutzt. Dann erscheint dieses:

/home/thomas/Documentation/bsc/source/UserManual.rst:34: ERROR: Unknown directive type 
"t3-field-list-table".

. t3-field-list-table::

* :a: Cell A

Irgendwelche Ideen, trotz baldigem Korkenknallen?

Grüße,

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

Re: [TYPO3-german] RTE icon-fonts statt images (Bootstrap3)

2013-12-31 Diskussionsfäden Thomas Skierlo


Quote: Robert Wildling wrote on Mon, 30 December 2013 14:13


Hi,

weiß jemand, wie man im RTE TYPO3 4.5 die link-types, die derzeit images 
zugeteilt bekommen (mail, download, external-link, etc) so umdefinieren 
kann, dass icon-fonts in dieser Art:


LINKNAME

erzeugt werden können? Steh seit Tagen komplett an und könnte wirklich 
jede Hilfe gebrauchen.


Danke!

Vilee Grüße, Robert



Hallo Robert,

ich denke, Du suchst an der falschen Stelle. TYPO3-seitig schaltest Du die 
Images einfach ab. Der Rest ist CSS, bzw. LESS.

z.B. für FontAwesome Icons:

mail:before { 
	content: @fa-var-envelope-o; 
}
external-link-new-window:before, .external-link:before, .internal-link:before, 
internal-link-new-window:before, .download:before, .mail:before {

   display: inline-block;
   font-family: FontAwesome;
   font-style: normal;
   font-weight: normal;
   line-height: 1;
   text-decoration: inherit;
   padding-right: 0.3em;
}

Grüße,

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

Re: [TYPO3-german] TYPO3 4.5 Bootstrap Carousel -> href-marker mit #

2013-12-22 Diskussionsfäden Thomas Skierlo


Quote: Robert Wildling wrote on Sat, 21 December 2013 14:37


Tatsächlich passiert das auch bei solchen Scripts:

lib.menu_screenreader {
   10 = TEXT
   10.dataWrap = class="sr-only">{$jump_to_content}

}

Im Quelltext wird der Seitepfad vor die # eingefügt. Warum passiert das? 
Wo kann man das abstellen?




Das ist durchaus "expected behavior" und beeinflusst die Funktion des Next/Prev Buttons des Carousel in keinster Weise. 
___

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

Re: [TYPO3-german] rtehtmlarea - eigene Klasse, die 'leer" sein darf

2013-12-20 Diskussionsfäden Thomas Skierlo

So, ich habe jetzt einen erneuten Anlauf mit Inline Klassen für den a-Tag gestartet.
Ergebnis: Es klappt - grundsätzlich. Man muss jedoch einige Kröten schlucken, zumindest
wenn man tatsächlich mit den Original BS Styles vom FE arbeiten möchte (und dies möchte
ich unbedingt, weil es danach visuell keinerlei Unterschied mehr zwischen FE und
BE-Darstellung gibt). Das Problem hierbei ist, dass der Link direkt nach Applizieren der
Button-Klasse die Funktion eines Buttons einnimmt - und nicht mehr per Modify-Link
editierbar ist. Weiterhin problematisch ist, dass man die offiziellen Link-Klassen
zusätzlich als "normale" Klassen für den Inline-Style zulassen muss. Danach
tauchen dann neben den gewünschten Button-Klassen auch Link Klassen im Text-Stil Selektor
auf - und man kann sie entfernen, und damit den gesamten Link unbrauchbar machen. Ein
Admin mit fundiertem HTML5/CSS Wissen mag damit klar kommen, ein domestizierter
Durchschnittsredakteur sicher nicht.

Vorausgesetzt, ich habe nichts übersehen, bleibt nur mein Resümee: Besser nicht
tun :-)

Ich denke, der seriösere Ansatz wäre ein tatsächlicher "Button"-Tag, mit
eigenem PHP zur Aufbereitung. Oder Link-Klassen, die man additiv/subtraktiv
hinzufügen/entfernen kann, wie bei den Standard Klassen auch. Sollte ich mal irgendwann
Langeweile bekommen.

p.s. Sorry für den "Tag" im letzten Post. Ich nutze das Forum, und war mir
nicht bewusst, dass dieses Tags ungewandelt durchlässt. Hoffentlich findet das sonst
niemand raus *g*.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] rtehtmlarea - eigene Klasse, die 'leer" sein darf

2013-12-20 Diskussionsfäden Thomas Skierlo


>
> Das tut dem CSS nicht weh, und der RTE ist ausgetrickst. Bislang läuft
> alles einwandfrei. Bootstrap 3 im FE und BE. Erhebend!

Glückwunsch! Passend zu Weihnachten. :-)

> Das Tüpfelchen auf dem i wären jetzt noch Buttons. Befürchte aber, dass
> das mit dem derzeitigen Klassen-Handling vom RTE nicht geht, da ein
> Bootstrap Button bis zu 3 Klassen erfordert, plus die Anchor-Klasse vom
> Link.

Das geht schon. Es müssen alle Klassen für den RTE definiert werden. 
Dann kann man bei Markierung des Textes/Links sukzessive die benötigten 
hinzufügen. Neu ausgewählte werden immer hinzufügt und ersetzen die 
vorhandene(n) nicht. Bei FTM/TYAML hat man sich das für die YAML-Buttons 
auch zunutze gemacht. Für Redakteure sicher etwas gewöhnungsbedürftig, 
aber es funktioniert.




Meinst Du damit Link-Klassen, also zusätzlich zu "external-link, external-link-new-window, internal-link..."  die Klassen btn, btn-small, btn-lg, btn-primary, btn-warning als Link Klassen anlegen? 


Zum Test habe ich die erforderlichen Klassen mal als Textstile angelegt, also als 
zulässige (non-Link) Klassen für den  Tag. Das klappt sogar 
erstaunlicherweise, zeigt aber ein merkwürdiges Verhalten, wenn man den tatsächlichen 
Link entfernt. Dazu kommt, dass der Link (Button) danach nicht mehr zu editieren war.

Werde es mal mit zusätzlichen Link-Klassen versuchen.

Danke für den Hinweis.

Grüße,

Thomas


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

Re: [TYPO3-german] rtehtmlarea - eigene Klasse, die 'leer" sein darf

2013-12-16 Diskussionsfäden Thomas Skierlo



Sodelle. Habe zwar noch keinen Krieg gewonnen, aber zumindest eine Schlacht. 
Die verschwundenen Tabellenklassen sind wieder aufgetaucht. Da der RTE wohl 
ausschließlich auf Klassen triggert, die auch tatsächlich im Stylesheet 
enthalten sind, habe ich leere Klassen für die beiden fehlenden Tabellenklassen 
im Less-File angelegt. Möglicherweise mag der RTE mit leeren Styles zufrieden 
sein, LESS hingegen ist es nicht - und schmeisst sie schnöde raus. Als Bugfix 
habe ich jetzt Styles hinterlegt, die unschädlich sind. Und jetzt gehts.

Falls jemand weiss, wie man leere Klassen in LESS erhalten kann, bitte melden.



So, auch die letzte Hürde genommen. Einen leeren CSS-Selektor kann man mit Less 
doch erreichen:

clearfix { /**/ }

Das tut dem CSS nicht weh, und der RTE ist ausgetrickst. Bislang läuft alles 
einwandfrei. Bootstrap 3 im FE und BE. Erhebend!

Das Tüpfelchen auf dem i wären jetzt noch Buttons. Befürchte aber, dass das mit 
dem derzeitigen Klassen-Handling vom RTE nicht geht, da ein Bootstrap Button 
bis zu 3 Klassen erfordert, plus die Anchor-Klasse vom Link.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] rtehtmlarea - eigene Klasse, die 'leer" sein darf

2013-12-15 Diskussionsfäden Thomas Skierlo


> Also, bisher hat in der CSS-Datei für den RTE immer folgendes funktioniert:
> 
> ..custom_class {}
> 
> Gruß

> Christian


Hallo Christian,

unterstellt, dass es keine zwei Punkte vor der custom_class {} sein sollen, so 
bringt dies im Falle von .clearfix nichts. Eine leere Definition scheint nicht 
zu reichen.

Habe mittlerweile ähnliche Probleme mit table-Klassen. Bootstrap bietet 5 
vordefinierte Tabellenklassen (table, table-striped, table-bordered, 
table-hover, table-condensed). Nach entsprechender Parametrierung des RTE 
bekomme ich 3 meiner Tabellenklassen zu Gesicht (table, table-bordered, 
table-condensed), von table-striped und table-hover fehlt jede Spur. 
Gleichzeitig angelegte row- und td-Klassen klappen problemlos.

Füge ich eine der fehlenden Tabellenklassen per Quellcodeeditor hinzu, so wird der entsprechende Style im BE angezeigt, lässt sich speichern und erscheint auch im FE. Im Blockstil-Selektor steht dann "Unbekannter Blockstil". Es scheitert also offensichtlich nur daran, zwei der Tabellenklassen in den Blockstil Selektor zu bekommen. Styles sind für alle 5 Tabellentypen vorhanden. 


Hätte ich noch genügend Haarvorrat, ich würde ihn mir ausreißen.

Grüße,

Thomas





Sodelle. Habe zwar noch keinen Krieg gewonnen, aber zumindest eine Schlacht. 
Die verschwundenen Tabellenklassen sind wieder aufgetaucht. Da der RTE wohl 
ausschließlich auf Klassen triggert, die auch tatsächlich im Stylesheet 
enthalten sind, habe ich leere Klassen für die beiden fehlenden Tabellenklassen 
im Less-File angelegt. Möglicherweise mag der RTE mit leeren Styles zufrieden 
sein, LESS hingegen ist es nicht - und schmeisst sie schnöde raus. Als Bugfix 
habe ich jetzt Styles hinterlegt, die unschädlich sind. Und jetzt gehts.

Falls jemand weiss, wie man leere Klassen in LESS erhalten kann, bitte melden.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Re: Gridelements Bildbreite für Spalte definieren

2013-12-15 Diskussionsfäden Thomas Skierlo


Du denkst zu kompliziert. maxW und maxWInText sind Register, die von CSC 
automatisch zum Rendern herangezogen werden. Wenn Du dir den Standard-Setup von 
GE ansiehst, so siehst Du (auskommentiert), wie Du Register setzen und gesittet 
wieder entfernen kannst.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] rtehtmlarea - eigene Klasse, die 'leer" sein darf

2013-12-15 Diskussionsfäden Thomas Skierlo


Quote: Christian Hennecke wrote on Fri, 13 December 2013 09:45


Am 12.12.13 17:49, schrieb Thomas Skierlo:
> Moin zusammen,
>
> mir ist bewusst, wie ich den RTE dazu bekomme, custom-Klassen zu
> bedienen. Dies funktioniert, solange es für diese Klasse auch einen
> nicht-leeren Style Eintrag gibt. Ist dieser jedoch leer, so ist auch
> diese Klasse nicht ansprechbar.
>
> Das Problem tritt z.B. auf mit der Klasse 'clearfix" aus Bootstrap
> (identisch aber mit jeder vergleichbaren Klasse ohne Inhalt). Für
> .clearfix gibt es grundsätzlich keine normative Style Definition. Für
> .clearfix:before und .clearfix:after hingegen schon.
>
> Ich fände es erstrebenswert, im RTE eine div-Container Klasse zu haben,
> die selbst-clearend wirkt.
>
> Bekommt man das 'normale' Verhalten irgendwie umgangen?

Also, bisher hat in der CSS-Datei für den RTE immer folgendes funktioniert:

..custom_class {}

Gruß
Christian



Hallo Christian,

unterstellt, dass es keine zwei Punkte vor der custom_class {} sein sollen, so 
bringt dies im Falle von .clearfix nichts. Eine leere Definition scheint nicht 
zu reichen.

Habe mittlerweile ähnliche Probleme mit table-Klassen. Bootstrap bietet 5 
vordefinierte Tabellenklassen (table, table-striped, table-bordered, 
table-hover, table-condensed). Nach entsprechender Parametrierung des RTE 
bekomme ich 3 meiner Tabellenklassen zu Gesicht (table, table-bordered, 
table-condensed), von table-striped und table-hover fehlt jede Spur. 
Gleichzeitig angelegte row- und td-Klassen klappen problemlos.

Füge ich eine der fehlenden Tabellenklassen per Quellcodeeditor hinzu, so wird der entsprechende Style im BE angezeigt, lässt sich speichern und erscheint auch im FE. Im Blockstil-Selektor steht dann "Unbekannter Blockstil". Es scheitert also offensichtlich nur daran, zwei der Tabellenklassen in den Blockstil Selektor zu bekommen. Styles sind für alle 5 Tabellentypen vorhanden. 


Hätte ich noch genügend Haarvorrat, ich würde ihn mir ausreißen.

Grüße,

Thomas


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

Re: [TYPO3-german] Responsive / Bootstrap

2013-12-13 Diskussionsfäden Thomas Skierlo


Quote: Jan Kornblum (t3jkb) wrote on Fri, 13 December 2013 15:05


Hi Thomas,

> Eine serverseitige Integration von Less ist zwar ganz hübsch, erfordert aber 
> einen viel tieferen Einstieg in's Thema, als die reine Nutzung mittels 
> Mini-Tools wie z.B. 'Bootswatch'. Das Konzept ist einfach und transparent, 
> und erlaubt eigene Styles direkt in Bootstrap einzukompilieren, ohne die 
> Quellen zu mischen. Ich arbeite mit NetBeans, aber ohne LESS Plugin. Durch 
> kleine Modifikation des Bootswatch Scripts kompiliere ich die Dateien direkt 
> ins TYPO3 Stylesheet Verzeichnis meines Entwicklungssystemes - und gut is.


D.h. du nimmt eines der Themes von "Bootswatch", lädst nur die 
LESS-Files herunter, nimmst darin Anpassungen vor und kompilierst das 
dann von der Console direkt ins "Ressource/Public/Css"?




So ähnlich. Ich nehme kein spezielles Theme von Bootswatch (das default Theme 
basiert auch auf Less). Die Skripte von Swatchmaker habe ich so angepasst, dass 
sie pro Domain wirken, also den Output in ein Verzeichnis meiner Wahl kopieren. 
Also z.B.

make bootswatch PROJECT=myproject

Im makefile dann die Pfade entsprechend gesetzt.


Danke und viele Grüße, Jan




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

Re: [TYPO3-german] Responsive / Bootstrap


Quote: Jan Kornblum (t3jkb) wrote on Thu, 12 December 2013 22:01



Das ist mir erstmal (noch) etwas zu "abgehoben". Mein Plan wäre 
zunächst, das Netbeans Plugin für LESS auszuprobieren (hat da jemand 
Erfahrungswerte, funktioniert das verlässlich?). Die IDE nutze ich, 
Projekte in der Regel als remote-Projekte (sftp). Und erstmal losgelöst 
von Frameworks etwas CSS auf Basis von LESS zu erzeugen (kompiliert). 
Node.js und clientseitige .less Kompilierung sind für mich eher 
uninteressant...




Eine serverseitige Integration von Less ist zwar ganz hübsch, erfordert aber 
einen viel tieferen Einstieg in's Thema, als die reine Nutzung mittels 
Mini-Tools wie z.B. 'Bootswatch'. Das Konzept ist einfach und transparent, und 
erlaubt eigene Styles direkt in Bootstrap einzukompilieren, ohne die Quellen zu 
mischen. Ich arbeite mit NetBeans, aber ohne LESS Plugin. Durch kleine 
Modifikation des Bootswatch Scripts kompiliere ich die Dateien direkt ins TYPO3 
Stylesheet Verzeichnis meines Entwicklungssystemes - und gut is.

Auch die selektive Nutzung der Less-Bausteine stelle ich in Frage. Ich finde an 
Bootstrap nichts, was ich nicht benötige - sowohl auf der CSS als auch der 
JS-Seite. Zwei minifizierte Dateien für alles. Über Client-Side Caching nur 1x 
übermittelt. jQuery direkt vom CDN. Das ergibt allerbeste Performance Werte.

Das schöne an Bootstrap: Man muss nicht viel verstehen. Es reicht, es 
anzuwenden. Für sichere Funktion sorgen qualifizierte Leute, die in CSS und JS 
träumen.



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

Re: [TYPO3-german] rtehtmlarea - eigene Klasse, die 'leer" sein darf


Hallo Peter,

ja, ich weiss, was Du meinst. Aber es hat einen großen Charme, die Bootstrap 
Styles für FE und BE zu nutzen. Man sieht exakt, was man bekommt, und muss auch 
nicht an mehreren Stellen pflegen. Abgesehen von wenigen leeren Elemente 
klappt's auch bestens.

Die Voraussetzung der Existenz einer Klasse wäre ja ok, aber das Verweigern 
einer leeren Klasse empfinde ich an dieser Stelle als falsch. Erfreulicherweise 
kann man die verweigerte Klasse wenigstens per Hand eingeben, wenn man sie 
vorher zugelassen hat.

Grüße,

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

[TYPO3-german] rtehtmlarea - eigene Klasse, die 'leer" sein darf


Moin zusammen,

mir ist bewusst, wie ich den RTE dazu bekomme, custom-Klassen zu bedienen. Dies 
funktioniert, solange es für diese Klasse auch einen nicht-leeren Style Eintrag 
gibt. Ist dieser jedoch leer, so ist auch diese Klasse nicht ansprechbar.

Das Problem tritt z.B. auf mit der Klasse 'clearfix" aus Bootstrap (identisch 
aber mit jeder vergleichbaren Klasse ohne Inhalt). Für .clearfix gibt es 
grundsätzlich keine normative Style Definition. Für .clearfix:before und 
.clearfix:after hingegen schon.

Ich fände es erstrebenswert, im RTE eine div-Container Klasse zu haben, die 
selbst-clearend wirkt.

Bekommt man das 'normale' Verhalten irgendwie umgangen?
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Responsive / Bootstrap


Quote: Cedric Ziel (virtualmachine) wrote on Thu, 12 December 2013 16:46


Warum so spät? Erlaube doch Anderen, dir ein wenig zur Hand zu gehen :)



Um das zu ermöglichen müsste ich zuerst alles dokumentieren. Und vorher noch 
schnell den Doku Standard der Woche verstehen. Das hielte mich derzeit zu sehr 
vom Wesentlichen ab. Später, wenn es darum geht, Dinge rund zu machen, ist 
Hilfe gerne gesehen.

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

Re: [TYPO3-german] Responsive / Bootstrap


Quote: Christian Hennecke wrote on Thu, 12 December 2013 10:56


Am 12.12.13 09:39, schrieb Thomas Skierlo:
> Ich bin zu 95% fertig, bis Weihnachten sollte es mein Entwicklungssystem
> verlassen können. Aber ich bin fast sicher, zwischenzeitig noch über
> irgend eine Blutgrätsche von 6.2 zu stolpern. Sonst wäre das Leben ja
> auch langweilig :-)

Das Ergebnis würd ich gern mal sehen!



Die Extension schiebe ich nach Fertigstellung auf Github. Vorher muss alles aber noch auf 6.2 funktionieren.  
___

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

Re: [TYPO3-german] Responsive / Bootstrap


Hallo Jan,

ich beschäftige mich seit nunmehr 6 Monaten fast ausschließlich mit der BS 
Integration in TYPO3. Als ich mit BS2 fertig war, kam BS3  und es ging fast 
'zurück auf Start'. Ähnliche Folklore also, wie bei TYPO3. Jetzt bin ich erneut 
fast fertig, hänge aber noch auf TYPO3 6.1x.

Der Knackpunkt sind und bleiben Responsive Images. Ein großes Manko von TYPO3 
(aber auch den meisten Anderen): Durch hohe Konzentration auf Aspekte des 
Cores, die sich NICHT im FE auswirken, ist das FE-Rendering von TYPO3 etwas 
'outdated'. CSC ist zwar strukturell geeignet, aber im Detail bleibt dann wohl 
doch eher ein kompletter Ersatz.

Mein bisheriger Weg:

1) Minimale Erweiterung der Pages Tabelle (um eine Seitenklasse, banal)
2) Ein Hook für CSC Image Rendering, um Bilder nicht nur (per derzeit 
favorisiertem) Weg pro Device zu rendern, sondern sie auch noch in ein 
passendes Grid zu zwängen (ziemlich unbanal).
3) Ersatz von ca. 80% des CSC Setups (banal, sobald man Durchblick im Chaos hat)
4) Kräftige Überarbeitung des RTE Renderings für BS Klassen (vergleichsweise 
einfach)
5) Aktive (Javascript) Gimmicks, wie Collapse, Carousel, Slider, Fader per 
Gridelements/TS (bei Gridelements/Fluid bin ich bislang leider gescheitert)
6) Strukturelemente/Subgrids per Gridelements (banal)
7) Navigationsstrukturen a la BS per TS (sehr banal)
8) Rendering von Indexed Search und anderen Sys-Ext. auf BS anpassen (banal)
9) Add-Ons für BS-Javascript Elemente, um sie hinsichtlich visueller Gestaltung 
flexibler zu machen (einfach).
10) Beim Affix Plugin von BS daran scheitern, die "Section Navigation" von 
TYPO3 zu nutzen, weil diese Gridelements schnöde ignoriert.

Ich bin zu 95% fertig, bis Weihnachten sollte es mein Entwicklungssystem 
verlassen können. Aber ich bin fast sicher, zwischenzeitig noch über irgend 
eine Blutgrätsche von 6.2 zu stolpern. Sonst wäre das Leben ja auch langweilig 
:-)

Bleibt die Frage nach der individuellen Gestaltbarkeit. Auch ich erkenne fast 
jede Bootstrap (Foundation) Seite sofort. Dies liegt aber weniger an 
gestalterischen Möglichkeiten der Plattform, sondern eher daran, dass fast alle 
das Standardlayout ganz ok finden (zumindest im Vergleich zu allem, was sie 
bislang mühsam per Hand zusammengeklöppelt haben). Ich bin weit davon entfernt, 
ein guter grafischer Gestalter zu sein, aber gerade deshalb machen CSS 
Frameworks ja Sinn. Sich nicht mehr um das nitty-gritty kümmern müssen  und 
alles klappt, oft sogar im IE.x

Grüße,

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

Re: [TYPO3-german] Responsive / Bootstrap


Hallo Sven,

ich befürchte, der 'picture' Tag hat es bereits hinter sich. Die derzeitige 
Lösung scheint in Richtung 'src-N' zu gehen, wobei 'derzeitig' den Stand aus 
KW42 - 50 beschreibt. src-N bietet nicht nur unterschiedliche Bildgrößen für 
unterschiedliche Devices, es erlaubt auch 'Density' Angaben, um die Retina 
Displays der Apple Jünger nicht als Investitionsruine auf der Strecke zu lassen.

HTML5 still sucks, weil es einfach nicht als Standard existiert, und permanent 
neu erfunden wird.Trotzdem ist es, wie die Bundesmutti sagen würde, 
alternativlos. In den 1990ern wurden Entwickler durch die Browser Wars gequält, 
und damit der Ungemach auch in Zukunft so bleibt, wurden Responsive Images 
erfunden :-)

Grüße,

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

[TYPO3-german] XLIFF Core Dateien nutzen

2013-12-10 Diskussionsfäden Thomas Skierlo


Hallo zusammen,

heute beschäftigt mich die Frage, wie ich zukünftig meine Übersetzungen 
'schlanker' gestalten kann. Derzeit benutze ich für meine Extensions eigene 
Xliff Übersetzungsdateien für BE, DB, FE und CSH. Diese beinhalten auch Strings 
wie 'content', 'disabled' und 'no', die natürlich redundant zu bereits 
existenten Strings im Core (ext/lang) sind. Der Vorteil: Man weiss was man 
kriegt. Der Nachteil: unnötige Redundanz.

Angenommen, ich würde selektiv existente Übersetzungen vom Core nutzen. Kann 
ich mich da grundsätzlich an allen Files bedienen, oder sollte man sich auf 
'locallang_common' und 'locallang_general' beschränken? Habe erfolglos nach 
einer Best-Practice bzw. einer Übersicht verfügbarer Labels gesucht (ausser dem 
mühsamen Durchklicken aller Dateien auf dem Translation Server, dessen 
Suchfunktion abenteuerlich unbrauchbar erscheint).

Danke für allen Input

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

[TYPO3-german] Gridelements/BE-Layouts - Limit = n

2013-12-06 Diskussionsfäden Thomas Skierlo


Hallo zusammen,

beim Erstellen eines Gridelements für eine flexible Modal-Box bin ich auf ein 
Problem gestoßen, welches ich in ähnlicher Form schon einmal bei einem 
BE-Layout hatte (habe). Die Limitierung auf genau EIN CE (welches jedoch ein 
Container für n-CE's sein dürfte). Ich meine nicht ein bestimmtes CE, sondern 
irgend eines  in Menge EINS. Gräbt man in den Tiefen des Core-Codes 
(\TYPO3\CMS\Backend\View\...), so verliert man schlagartig die Lust, weiter zu 
graben. Es ginge wohl, mittels n-Hooks (n scheint dabei gegen Unendlich zu 
gehen). Das BE scheint mir dabei abhakenswürdig.

Anders vielleicht bei Gridelements. Wäre es dort ggf. möglich, etwas wie "limit = 
n" zu implementieren?

Natürlich kann man das per TS regeln, und im FE nur das erste CE rendern. Das 
lässt aber nur gefrustete Redakteure zurück, die 10 CE eingegeben haben, aber 
nur eines zu Gesicht bekommen.

Irgendwelche Ideen?

Grüße,

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

[TYPO3-german] XLIFF Lokalisierung mit Parameterübergabe?

2013-11-29 Diskussionsfäden Thomas Skierlo


Moin,

Aus php ist es mir gelungen, Parameter an meine XLF Lokalisierungsstrings 
anzuhängen, und damit den Übersetzungswust drastisch zu reduzieren. Ich 
scheitere aber gerade daran, gleiches per getText (bzw. LLL:EXT:... Notation) 
zu erreichen.

Irgendwelche Ideen dazu?

Grüße,

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

Re: [TYPO3-german] Gridelements/Fluidtemplate und Register Nutzung

2013-11-27 Diskussionsfäden Thomas Skierlo


Hallo Joey,

hat was gedauert bei mir. Musste erst mal einiges updaten. Bin jetzt auf TYPO3 6.1.6 und GE 2.1.0-dev. Führe 
ich unter diesen Gegebenheiten einen Debug auf {data.tx_gridelements_view_children} im Fluid-Template aus, 
sehe ich zwar rohe Inhalte, aber kein "tx_gridelements_view_raw_columns". Habe verstanden, dass 
"view.column_n" bereits das fertig gerenderte Element enthält, und damit nicht geeignet ist. Aber 
ich blicke nicht durch, wie ich die "raw_columns" in Fluid ansprechen kann. Wahrscheinlich muss ich 
dafür über die Children iterieren? Hast Du vielleicht ein Minimalbeispiel?

Grüße,

Thomas

p.s. Parallel stellt sich mir die Frage, ob ein Rendering über Fluid an dieser 
Stelle überhaupt erstrebenswert ist.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Gridelements/Fluidtemplate und Register Nutzung

2013-11-19 Diskussionsfäden Thomas Skierlo


Meintest Du so etwas?





{data.tx_gridelements_view_column_3}





In diesem Fall liefert das zum testen eingefügte lib.getGrid zwar tatsächlich 
den Registerinhalt zurück, er landet aber nicht im Kontext der GE Spalte.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Gridelements/Fluidtemplate und Register Nutzung

2013-11-18 Diskussionsfäden Thomas Skierlo


Moin Joey,

ja, mit separaten TS Blöcken, also Register setzten wie gehabt, geht es 
natürlich. Das reduziert aber die Vorteile von Fluid an dieser Stelle auf Null 
(spart nur noch ein paar Wraps). Egal, sei's drum.

Grüße,

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

[TYPO3-german] Gridelements/Fluidtemplate und Register Nutzung

2013-11-18 Diskussionsfäden Thomas Skierlo


Hallo zusammen,

ich möchte eine umfangreiche Gridelements/CE Sammlung (bisher TS only) 
alternativ auch per Fluid rendern - weniger aus Vernunft-, eher aus 
Zeitgeistgründen. Das klappt auch grundsätzlich, aber es bleibt ein Problem. 
Ich benötige an einigen Stellen LOAD_REGISTER. Das Register wird nicht im 
Fluid-Template benötigt/ausgewertet, sondern im css_styled_content (bzw. meiner 
Alternative dazu). Gibt es eine Möglichkeit, per Fluid ein Register zu setzen?

Grüße,

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

[TYPO3-german] Re: TempleVoila FCE Galerie - mehrere Bilder, mehrere Untertitel

2013-10-14 Diskussionsfäden Thomas Skierlo


Schau Dir vielleicht mal den Setup von css_styled_content an. Der ist zwar 
alles andere als intuitiv, aber letztlich doch zielführend.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Bilderkarussel mit Responsive Design

2013-10-06 Diskussionsfäden Thomas Skierlo


Hallo Manuel,

ich habe ein entsprechendes Element für Gridelements geschrieben. Es ist für 
Bootstrap 3, und erweitert das Standard Carousel um weitere Effekte, wie z.B. 
Fading (statt nur Sliding). Die Extension ist noch nicht veröffentlicht, alles 
Erforderliche für den Slider findest Du aber unter 
http://forge.typo3.org/issues/51613.
Gedacht ist er als Wrapper für "Images". Hier wird die Description neben das 
jeweilige Bild gerendert. Die Bildposition kann optional wechseln. Wäre auch einfachst an 
Text/w. Images adaptierbar.

Grüße,

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

[TYPO3-german] Re: FAL in css_styled_content

2013-10-04 Diskussionsfäden Thomas Skierlo


so scheint's zu gehen. Keine Ahnung, ob das "richtiger" ist. Wirkt irgendwie sehr 
"teuer":

if ($equalHeight) {
// Initiate gifbuilder object in order to get 
dimensions AND calculate the imageWidth's
$gifCreator = 
GeneralUtility::makeInstance('TYPO3\\CMS\\Frontend\\Imaging\\GifBuilder');
$gifCreator->init();
$relations_cols = array();
// contains the individual width of all images after 
scaling to $equalHeight
$imgWidths = array();

$resFactory = 
GeneralUtility::makeInstance('TYPO3\CMS\Core\Resource\ResourceFactory'); // 
create instance to storage repository


for ($a = 0; $a < $imgCount; $a++) {
$imgKey = $a + $imgStart;

if 
(\TYPO3\CMS\Core\Utility\MathUtility::canBeInterpretedAsInteger($imgs[$imgKey]))
 {
$file = 
$resFactory->getFileObject($imgs[$imgKey]);
$fileProps = $file->getProperties();
$origWidth = $fileProps['width'];
$origHeight = $fileProps['height'];
} else {
$totalImagePath = $imgPath . 
$imgs[$imgKey];
$imgInfo = 
$gifCreator->getImageDimensions($totalImagePath);
$origWidth = $imgInfo[0];
$origHeight = $imgInfo[1];  

}
$rel = $origHeight / $equalHeight;  

// if relations is zero, then the addition of 
this value is omitted as the image is not expected to display because of some 
error.
if ($rel) {
$imgWidths[$a] = $origWidth / $rel;
// counts the total width of the row 
with the new height taken into consideration.
$relations_cols[(int) floor($a / 
$colCount)] += $imgWidths[$a];
}
}

}

Die Frage bleibt offen. Geht das so?
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] FAL in css_styled_content

2013-10-04 Diskussionsfäden Thomas Skierlo


Hallo in die Runde,

ich arbeite gerade an einer Bootstrap 3 kompatiblen Version von css_styled_content, 
welche für den Standardfall (Bild mit oder ohne "width" Angabe) bereits bestens 
funktioniert. Jetzt möchte ich mich um Feinheiten kümmern, wie z.B. Images mit 
equalHeight. Dabei ist mir aufgefallen, dass die Originalfunktionen aus 
css_styled_content nicht funktionieren, sobald es sich um ein FAL Image handelt. Es geht 
um folgenden Block:

if ($equalHeight) {
// Initiate gifbuilder object in order to get 
dimensions AND calculate the imageWidth's
$gifCreator = 
GeneralUtility::makeInstance('TYPO3\\CMS\\Frontend\\Imaging\\GifBuilder');
$gifCreator->init();
$relations_cols = array();
// contains the individual width of all images after 
scaling to $equalHeight
$imgWidths = array();
for ($a = 0; $a < $imgCount; $a++) {
$imgKey = $a + $imgStart;
$imgInfo = 
$gifCreator->getImageDimensions($imgPath . $imgs[$imgKey]);
// relationship between the original height and 
the wished height
$rel = $imgInfo[1] / $equalHeight;
// if relations is zero, then the addition of 
this value is omitted as the image is not expected to display because of some 
error.
if ($rel) {
$imgWidths[$a] = $imgInfo[0] / $rel;
// counts the total width of the row 
with the new height taken into consideration.
$relations_cols[(int) floor($a / 
$colCount)] += $imgWidths[$a];
}
}
}

Der GifBuilder wird zwar instanziert, aber "$imgInfo = 
$gifCreator->getImageDimensions($imgPath . $imgs[$imgKey])" liefert immer Blödsinn, 
bzw. nichts.

Dies dürfte bereits seit der Einführung von FAL so sein, und fällt wohl nicht 
auf, weil entweder niemand neuere TYPO3 Versionen nutzt, oder keine Images mit 
equalHeight.

Um jetzt meine Frage zu abstrahieren: Ich habe eine FAL uid. Wie komme ich an 
die derzeitigen Abmessungen des Originalbildes? Egal ob mit oder ohne 
GifBuilder (letzteren benötige ich an dieser Stelle nicht wirklich).

Habe die Frage bereits erfolglos im Englischen Forum gestellt.

p.s. Die Tatsache, dass am Ende doch Bilder mit equalHeight erzeugt werden, ist 
derzeit eher Zufall. Der gesamte Code zur Berechnung ist wirkungslos.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] gridelements vs fedext

2013-09-27 Diskussionsfäden Thomas Skierlo

Hey, Ihr Lieben,

kommt doch bitte mal wieder runter. Klar sind bei TYPO3 schwere Fehler gemacht
worden - und dies gar über einen recht langen Zeitraum und begleitet auch von
meinem Gemecker. Trotz alledem - das ist zumindest mein Gefühl - hat es vor
nicht allzu langer Zeit einen befreienden Knall gegeben, und Entscheidungen
wurden wieder deutlich rationaler. Heute (ich spreche von 6.1, und Teilen aus
6.2, die ich mir cherry-picke) ist die Basis sehr gut geraten. Man hat die Wahl
der Waffen, Fluid oder semi-klassisch, und auch der Extension Baukasten wird
wieder kompletter.
Wenn Manche zu Drupal oder xyz wechseln, so werden sie für sich Gründe dafür
gefunden haben. Ich empfinde mich zu alt für einen kompletten Systemwechsel -
und sehe auch keine Notwendigkeit mehr dafür.

Um den Schwenk zurück zum Thema kriegen:

Es stand die Frage im Raum, warum es so wenig Packages für Gridelements gibt,
bzw. Extensions, die darauf beruhen. Den Punkt habe ich nicht wirklich
verstanden, denn für mich ist GE eine Erweiterung, die es mir erlaubt,
Erweiterungen einzusparen. Ich habe seit meinem Erstkontakt zu GE nie nach
Erweiterungen dafür gesucht, muss zu meiner Schande gestehen, mich noch nicht
einmal mit Themes beschäftigt zu haben (wahrscheinlich entwickle ich seit einem
Jahr sinnlos etwas Vergleichbares). Warum? Weil es eben geht, mit GE und
wahrscheinlich ebenso gut mit FED/Flux.

Zur umgangssprachlichen Erklärung zum "winzigen Bisschen", an dem es derzeit noch zwischen Core und GE mangelt. Es geht um den uralten Wunsch, BE-Layouts "installierbar" zu gestalten. Das ist etwas Seitenrelevantes, und hat eigentlich mit GE rein gar nix zu tun. Die einzige Verbindung ist die Tatsache, dass GE diese Funktion schon immer beinhaltet. Mit 6.1 kann man die Dinger bereits ins Dateisystem packen, und zusammen mit der Hoffnung, dass das bald noch einfacher wird, kann ich damit derzeit problemlos leben.

Für mich ist das TYPO3 Glas heute nicht mehr "halbleer", sondern mindestens wieder
"halbvoll", und mit einigen gemeinsamen Bemühungen sollten wir locker nachschenken können.

Findet zumindest der

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

Re: [TYPO3-german] Einarbeitung Extbase/Fluid

2013-09-25 Diskussionsfäden Thomas Skierlo


Einen Tipp, den ich Dir mitgeben kann. Es gibt viele Tutorials und Beispiele zu 
Extbase/Fluid. Gehst Du nach diesen Beispielen vor, und es klappt mal etwas 
nicht, so mag dies an einer steilen Entwicklungskurve liegen, innerhalb derer 
sich viel am Code geändert hat - inkl. vielen breaking changes. Du wirst i.d.R. 
gut weiter kommen, wenn Du das depreciation log beobachtest. Ansonsten brauchst 
Du nur Geduld und Ausdauer :-)
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] gridelements vs fedext

2013-09-25 Diskussionsfäden Thomas Skierlo

Hallo Andreas,

ich gebe Dir deutlich Recht, dass TV wesentlicher Motor des einstmals großen
Erfolges von TYPO3 war. Betrachtet man heute die Webpräsenzen verbliebener
TYPO3 Agenturen, so stößt man i.d.R. auf 4.5 in Verbindung mit TV.

Mir war spätestens vor 3 Jahren bewusst, dass die Zukunft nicht unbedingt in TV
zu suchen wäre. Also lernte ich Extbase und Fluid - und mochte es nicht. Eine
Rückportierung von etwas Abstrakten, also etwas, was es noch nicht in
finalisierter Version gibt, kann nur im Chaos enden.
Erste Gehversuche mit FED/Flux endeten bei mir mit Fatals, was sicher
ausschließlich an einer maroden Zwischenversion gelegen haben mag. Damals
brachte jede Extbase Version neue (breaking) Überraschungen, und die Pflege
eines komplexen Paketes muss zu dieser Zeit die Hölle gewesen sein.
Mit 4.7 tauchte plötzlich GE in der Liste der Core-Projekte auf - inklusive der
Hoffnung, dass man nun wohl auch im Core-Team die Notwendigkeit einer
beherrschbaren Templating Lösung eingesehen hätte. Dies war ein Trugschluss,
aber im Nachhinein für mich irrelevant.

Anfangs machte ich genau den Fehler, den alle TV zu GE Migranten machen. Ich bastelte mir einen
eigenen "Text mit Bild" unter intensiver Flexform Nutzung. Da GE, im Gegensatz zu allen
Fluid Varianten, extrem kompakt ist, fiel es mir nicht schwer, den Quellcode zu verstehen (die Doku
war seinerzeit noch nicht sehr vollständig). Je tiefer ich einstieg, desto deutlicher wurde mir,
wie man es mit GE "richtiger" macht, als ich bislang.

Seit etwa einem Jahr arbeite ich an einer Extension, welche die Möglichkeiten von Twitter
Bootstrap (3) vollinhaltlich in TYPO3 abbildet. Dies war und ist mit GE "a piece of
cake" - soll heißen, dass der GE-relevante Teil davon komplett fertig ist. Seit etwa
3 Wochen arbeite ich am letzten, fehlenden Teil: Einem Hook für CSC. Und auch der wird
fertig werden.
Danach benötige ich für eine komplette, komplexe Website noch exakt 4
Extensions: GE, News, RealUrl und meine. Viel schlanker geht es derzeit nicht.
Und würde ich Versionierung tatsächlich verstehen, alles wäre versionierbar.

Du erwähnst den Begriff "Conditional" in Bezug auf die Kostenseite der Nutzung
von GE. Da ich mit TYPO3 derzeit kein Geld verdiene, gebe ich auch keines dafür aus -
abgesehen von zahllosen Stunden, die ich investiere, weil ich mir Basisforschung erlauben
kann. Ich arbeite ausschließlich mit der im TER/Forge für Jede(n) verfügbaren Version von
GE.

Betrachtest Du die Historie von GE, so kommst Du irgendwann an den Punkt, wo GE dann doch keine Core Extension mehr sein sollte. Wäre wohl einfach zu vernünftig gewesen. Jetzt hat man als Entwickler, der auch mal essen möchte, genau zwei Möglichkeiten. Das Ding in die Tonne hauen, oder dafür sorgen, dass man sich die weitere Entwicklung ohne Mittel vom Core erlauben kann. Dadurch kam es zur ersten, mir bekannten Crowdfunding Kampagne zu TYPO3. Diese hat dazu geführt, dass die für Jeden verfügbare Version heute ziemlich ausgereift ist.

Bleibt das Problem, wie man sich denen gegenüber erkenntlich zeigen kann, die das Projekt
angeschoben und finanziell unterstützt haben. Soviel ich weiß, gibt es für diese Gruppe einen
geschützten Bereich, in dem zusätzliche Beispiele, fertige Elemente und "first hand"
Infos verfügbar sind. Dies ist nur fair. M.W. gibt es dort keine "bessere" GE Version,
sondern nur bessere Infos zur für alle verfügbaren TER Version.

Ich denke, man hat heute zwei Wege zum Ziel. Per FED/Flux/../.. oder eben GE. Die erste
basiert ausschließlich auf Extbase/Fluid, der andere erlaubt Fluid oder TS. Welchen man
beschreitet, ist persönlichen Präferenzen überlassen. Einen "Core" Weg gibt es
leider nicht. M.E. das derzeit größte Manko des aktuellen TYPO3.

Grüße,

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

Re: [TYPO3-german] Fast eine Redakteursfrage

2013-09-19 Diskussionsfäden Thomas Skierlo


Hallo Joey,

danke für Dein Feedback. Das hilft mir ziemlich. c) ist auch deutlich am 
einfachsten zu realisieren. Bisher hatte ich mich auf a) eingeschossen, aber 
das wird tatsächlich hochkomplex, zumindest wenn man auch das un-floaten und 
die Beibehaltung der Ursprungsbreite (also kein maxW) abbilden will. 
Andererseits, die Methode ist fast fertig. Ich denke, ich werde per Setup die 
Varianten a) oder c) zulassen, und damit das Rendering jeweils dynamisch 
anpassen.

b) wäre natürlich die optimale Lösung. Aber genau die greift nicht, wenn es 
an's Verschieben eines Elements geht. Da, wo's eben noch nicht passte, könnte 
es plötzlich passen - und umgekehrt. Kann man also wirklich erst beim FE 
Rendering entscheiden.

Meine "doodle" Termine bekommst Du spätestens am Montag. Dann weiß ich, ob und 
wann ich grundsätzlich im Lande bin.

Grüße,

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

[TYPO3-german] Re: Fast eine Redakteursfrage

2013-09-19 Diskussionsfäden Thomas Skierlo


Ich merke schon, die Frage war zu komplex. Deshalb stelle ich sie noch mal - in 
abstrahierter Form:

Existiert in der TYPO3 Philosophie eine "best practice" für Fälle von 
Falscheingabe durch Redakteure? Diese könnte sein:

a) Das Problem graceful reparieren - und den Inhalt so darstellen, wie es geht 
(unter Missachtung der Redakteurseingabe)
b) Ein Speichern der falschen Eingabe verweigern und im BE meckern (erscheint 
mir - wissensbedingt - schwierig)
c) Die nicht-darstellbaren Teile der Redakteurseingabe gar nicht darstellen, 
den Rest schon.
d) Das betroffene Inhaltselement gar nicht rendern.


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

[TYPO3-german] Re: Übersetzungsproblem beim "Reinen Html Inhaltselement"

2013-09-18 Diskussionsfäden Thomas Skierlo


Das HTML CE ist seit TYPO3 4.6 depreciated, und seit 6.0 nicht mehr vorhanden. 
Mit welcher TYPO3 Version arbeitest Du?
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] Fast eine Redakteursfrage

2013-09-18 Diskussionsfäden Thomas Skierlo

Hallo zusammen,

ich arbeite derzeit an einer Extension, die CE in einer für Twitter Bootstrap
optimierten Weise rendert. Beim Image Rendering bedeutet dies, Assets
grundsätzlich in ein (vorher berechnetes) Grid zu packen. Das klappt auch alles
schon. Die Frage, die bleibt, betrifft Situationen, in denen ein Rendering
nicht gemäß den Angaben des Redakteurs erfolgen kann.

Ein Beispiel: CE Text w. Images
12er Seitengrid. Redakteur befindet sich in Eingabe für ein Grid3 Element (also
1/4 des Gesamtgrids). Er/Sie wählt 3 Image Spalten mit umfließendem Text. Dies
ist in einem Grid3 (welches max. 3 Grid1 Elemente umfassen kann) unmöglich.

Derzeit reduziere ich in diesem Fall die Image Spalten bis es passt. Passt es
gar nicht, weil z.B. nur ein Grid1 zur Verfügung steht, so un-floate ich alle
Images und wechsle auf Images über Text Darstellung. Damit werden die Assets
immer dargestellt halt nur nicht so, wie der Redakteur/die Redakteuse es sich
vorstellt.

Alternativ könnte ich die Image Spalten so lange abarbeiten, wie es passt und
alle darüber hinausgehenden Images gar nicht anzeigen (ggf. im devlog geloggt).
Dies könnte in einem sehr kleinen Grid auch dazu führen können, dass
ausschließlich der Text angezeigt wird.

Die Frage: Welche Variante ist besser? Die Redaktion bevormunden, und alles so anzeigen,
wie es geht, oder sich stur an die Redakteurseingabe halten? Der Königsweg wäre wohl eine
Kopplung zum BE mit der Meldung "Think first, you idiot it can't fit in", aber
das übersteigt derzeit meine Fähigkeiten.

Danken für allen Input,

Grüße,

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

Re: [TYPO3-german] Backend-Layout direkt in TS?


Quote: Jo Hasenau (cybercraft) wrote on Tue, 10 September 2013 16:40



http://forge.typo3.org/issues/37208



Betrachtet man die Votes (vor Kurzem waren das noch 2), so sieht man, dass da 
ein Schuh drückt :-)
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Seitentitel in Seite verwenden


myBlaBla = COA
myBlaBla {
10 = TEXT
10.data = page:title // page:nav_title
10.wrap = |
20 = TEXT
20.data = page:subtitle
20.required = 1
20.wrap = |
}

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

Re: [TYPO3-german] Code Blöcke im Forum


Hallo Renzo,

Quote: Renzo Bauen wrote on Tue, 10 September 2013 13:33



Und die Mailingliste verträgt halt die Attachements und Codeblöcke nicht
so gut


Das mit den Attachments verstehe ich ja, aber preformattet Text kann doch nur 
zu einem Problem werden, wenn ein Mail Reader sämtliche Tags entsorgt. Wenn ich 
mich recht erinnere, konnte ich (im Thunderbird) preformatierte Blöcke 
entsprechend auszeichnen.

Die Kopplung von Forum und Mailing Liste ist zwar hübsch, aber sie führt 
schließlich zu einer TYPO3 Metallbearbeitung, die mit zwei stumpfen Feilen 
ausgeführt wird.

Gruß,

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

Re: [TYPO3-german] TYPO3 Slider gesucht


Quote: Basti wrote on Tue, 10 September 2013 15:07




Denke den würden viele verwenden.

--


Da habe ich fast keinen Zweifel. Aber Slider sind grundsätzlich not-accessible, 
so dass man sie nur für sekundären Content nutzen sollte - wenn überhaupt.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] TYPO3 6.2.0alpha2 - Gridelements, News und realUrl


Hallo Joey,

die Woche warte ich noch gerne. Danke für die Bestätigung.

Grüße,

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

[TYPO3-german] TYPO3 6.2.0alpha2 - Gridelements, News und realUrl


Ich würde gerne mit meiner Entwicklungsumgebung von 6.1.3 zu 6.2.0alpha2 
umziehen. Ich setze (neben eigenen Extensions) ausschließlich Gridelements, 
News und realUrl ein. Kann ich den Umzug bereits wagen, oder gibts mit einer 
der Extensions noch einen größeren Knall?

Grüße,

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

Re: [TYPO3-german] Field: longdescURL


Hi Philipp,

Quote: Philipp Gampe (pgampe) wrote on Mon, 09 September 2013 22:51




Es spräche nichts dagegen, zusätzlich ein HTML5 only Setup mit aufzunehmen. 
Jedoch kann man dieses genauso gut als Extension verfügbar machen :)




Ich empfinde das Content Rendering als wesentliche Aufgabe eines CMS - und 
HTML5 als zu wichtig, um es in eine Extension auszulagern. Dies möge man gerne 
mit ungeliebtem Bimbes, wie z.B. Indexed_Search machen.

Am einfachsten ist eine "Separation of Concern" im Setup von css. What do you 
want? Classic (maybe incl. semi HTML5) or HTML5? Der Vorteil dieser Methode: Die Classic 
Variante könnte die sein, die zu allem Murks der Vergangenheit kompatibel bleibt, während 
die neue sich überhaupt nicht um Altlasten kümmern müsste.

Kannst Du etwas zu den Gründen sagen, warum longdescURL im Standard nicht mehr 
angezeigt wird? Bekomme ich FAL Probleme, wenn ich es aktiviere? Ich habe 
gerade festgestellt, dass es in den neuesten HTML5 Specs (July 2013, HTML5 
Image Description Extension) wieder drin ist, inkl. Unterstützung für lokale 
Anker - und damit mutmaßlich ein ARIA Ersatz.

Grüße,

Thomas


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

[TYPO3-german] Code Blöcke im Forum


Hallo zusammen,

mir ist bewusst, dass Forum Beiträge auch kompatibel zu den diversen Mailing Listen sein 
müssen - was ja Letztendlich auch die Attachments "unschön" macht.

Wäre es nicht möglich, zumindest preformattet Text zuzulassen? Hielte ich bei 
einem S/W Forum für eine Minimalanforderung, die sich nicht mit einer 
Mail-Darstellung beißen sollte.

Grüße,

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

Re: [TYPO3-german] TYPO3 Slider gesucht