Hallo Freunde,
folgende Unstimmigkeiten habe ich mit dem Kickstarter.
Ich habe die FE USERS Tabelle mit dem Kickstarter um 52 Felder erweitert.
Hier kann der User ganz spezielle Angaben zu sich machen. (Größe, Gewicht,Schuhgröße,Haar-farbe und -länge ect.pp.).
Gestern wollte ich ein paar Felder "removen". Das hat nicht funktioniert.
Flag (im KS)gesetzt und Update geklickt, danach sogar view Results, Cache löschen gemacht.
Hat sonst auch immer genauso funktioniert.
Desweitern kann ich keine neuen Felder mehr erzeugen (egal welche Art: String Input, Checkbox, ect.).
Nach dem Update Prozess werden weder Felder removed noch neu angelegt.
Meine Frage ist nun warum :-).
Hat der Kickstarter vielleicht ein Limit an Feldern (kann ich mir nicht vorstellen)?
Ist das vielleicht ein PHP Laufzeitproblem (das das zu lange dauert und PHP abbricht o.s.ä.).
Muß dazu noch sagen, dass viele Felder auch noch Selectorboxen sind mit bis zu 10 Auswahlfeldern.
Also schon eine ziemlich umfangreiche Erweiterung :-) (sonst hätte ich sie schnell mal neu erstellt)
Infos zum System:
TYPO3 CMS ver. 4.2.8
Kickstarter 0.4.0
Vielleicht hat jemand eine Ahnung?
Lieben Gruß Andreas
Hallo Andreas.
Hast Du Deine Extension nach dem "Update" via Kickstarter deinstalliert/neu installiert? Oder via Install-Tool ein DB-Compare durchgeführt?
Via Kickstarter wird "nur" festgelegt, was Deine Extension an DB-Felder/-Tabellen braucht. Die Umsetzung erfolgt aber erst beim Installieren (bzw. Überprüfen via DB-Compare).
Viele Grüße
Julian
Schon :-)
Eigentlich die gesamte Prozedur.
Zuerst UPDATE, dann View Results
Dann deinstallieren, dann installieren.
Selbst in phpMyAdmin habe ich schonmal alle Tabellen die raus sollten gelöscht.
Dann habe ich das Update übersprungen (Beim Aufrufen der Extension im Kickstarter)
Hab dann die Felder die ich raushaben möchte auf REMOVE geflaggt. Dann wieder
von vorne...UPDATE,VIEW RESULTS....u.s.w.
Am Ende sind die Felder alle wieder da :-( In der DB und wenn ich im KS auf die EXTENDED TABLES schaue.
Eigentlich ja auch ganz klar, weil nach dem UPDATE im TCA File eindeutig
CREATE Table ... (und da sind meine Felder drin) steht, obwohl sie auf Remove geflaggt sind.
Sehr strange... #angry#
Andreas
Also ich glaube, das das Problem in den Flags "REMOVE" liegt, denn das wird vollkommen ignoriert, beim Update oder doch die gesamte Prozedur zu lange dauert oder zuviel Speicher benötigt und deswegen garnichts ausgeführt wird.
Was ich auch festgestellt habe (ZEIT/SPEICHER).
Normalerweise wenn man auf UPDATE klickt, baut sich die Seite wieder am Anfang auf und zwar mit den gesamten Feldern (so wie es am Anfang aussieht, wenn man auf Extend existing Tables klickt.
Bei mir bleibt die Seite aber leer. Links ist das Kickstarter Menu.
Wenn ich dann auf Extend existing Tables klicke, dann wird mir erst die Ansicht gezeigt.
Deshalb glaube ich das die Prozedur (REMOVE) beim UPDATE vielleicht garnicht erst ausgeführt wird. Vielleicht also doch SPEICHER oder ZEIT.
Jedenfalls wenn ich z.B. 3 Felder auf REMOVE schalte und mir dann die Felder erneut anschaue, dann sind die Flags wieder deaktiviert.
Also erzeugt mein VIEW RESULTS jedesmal wieder diese Felder :-(.
BAHHH o.O
Lieben Gruß Andreas
So ich nochmal:
Was ich auch eben festgestellt habe ist,dass die Datei
doc/wizard_form.html
im BE im Kickstarter nicht dargestellt wird (Seite bleibt leer)
In anderen Extensions ist dort aber Inhalt.
Hab sie mir downgeloaded und im Browser Quelltext nachgeschaut.
Die ist natürlich sehr umfangreich und wenn ich mir alles genau anschauen würde bräuchte ich mindesten Tage :-) um mir jedes Detail zu analysieren, aber vielleicht reicht ja die Tatsache, dass sie nicht angezeigt wird (im BE Kickstarter) um evt. eine Ahnung zu haben.
Hoffentlich o.O
Andreas
Und ich nochmal!
Habe die letzten 3 Stunden damit verbracht die Extension NEU zu erstellen.
Alles Prima bis ich zum ca. 45 ten Feld kam.
Kein Update der Tabellen mehr :-). Genau das gleiche Problem wieder.
Also entweder kann der Kickstarter nicht mehr als xx Tabellen, oder es liegt am Speicher des Apachen was PHP angeht oder am Timeout, also das das Updaten zu lange dauert für das Script. Es dauert ca. 4 Sekunden wenn man auf Update klickt, bis der Reload einsetzt.
Andreas
Hallo Andreas.
Falls es an Speicher/Timeout liegt, dann kannst Du das ganze auch händisch machen. Datenbankfelder sind relativ leicht eingebunden. Sind immer vier Stellen
1. SQL-File: dort wird das Feld zum anlegen ind er Datenbank definiert
2. TCA (ext_tables.php oder tca.php): dort wird das Feld gegenüber TYPO3 bekanntgemacht bzw. definiert (eval-Funktion usw.)
3. TCA: hier wird auch noch festgelegt, wo im Backend das Feld erscheinen soll
4. Labels in der Sprachdatei
Klingt anfangs etwas wirr und kompliziert, aber via copy&paste sollte es gehen.
Viele Grüße
Julian
:-) Danke, ich werde es wohl so machen müssen.
Ich habe jetzt aber Testweise diese (an die Grenzen gekommene) Extension exportiert und auf einem anderen Server installiert. Ich checke jetzt mal, ob ich dort weiterkomme. Wenn ja, dann ist der Kickstarter erstmal rehabilitiert ;-). Wenn es dort genauso ist, werde ich es dann wohl händisch machen und später mal checken woran es liegen könnte. Vielleicht auch mal auf ner LOCALen Maschine mit ordentlich Speicher für PHP und nen Timeout bis Weihnachten :-)
Wie auch immer, werde ich meine Erfahrungen und den Ausgang hier nochmal posten.
Frohes Schaffen
Andreas
OK, Entwarnung für den Kickstarter. 😃
Ich konnte auf einem anderen Account (anderer Provider), problemlos meine Extenstion weiterbauen. Habe dort noch Testweise 10 weitere Felder angelegt und mal ein paar geändert und dann gelöscht.
Also scheints am Speicher oder an der Laufzeit bei dem jetztigen Provider zu liegen.
Abschießend bleibt also festzuhalten.
Umfangreiche Extensions mit dem Kickstarter können irgendwann an die Grenzen, von den vom Provider eingestellten Werten für PHP Interaktionen stoßen. #giggle#
Andreas
Ich hatte das Problem schon abgehakt, aber jetzt komme ich erneut zu einem andern, aber irgendwie gleichen Problem.
Nun kann ich meine pi1/class.tx_..extension.._pi1.php
nicht mehr speichern, wenn sie zu groß ist!!!
Welches LIMIT beim Provider könnte es denn sein?
Die maxExecution Time ist 30 Sek..
Das sollte doch genug sein, denn in beiden Fällen
(bei "VIEW RESULTS" und jetzt das "SAVE" in der pi Datei) dauert das nicht länger als 3 Sekunden.
Die Entwicklungsdatei (_pi1.php) läßt sich problemlos bis ca. 54 k speichern, jede Zeile mehr darin, geht nicht mehr.
Weiß hier jemand was o.O ?
LG Andreas
Habe den Eindruck, dass Du von Deiner Arbeit her langsam einfach an die Grenzen der Möglichkeiten via Webfrontend stößt. Bei umfangreichen Arbeiten innerhalb von Extensions ist der Weg via Direktzugriff auf die Dateien geeigneter. Damit steht Dir z.B. auch eine vernünftige Entwicklungsumgebung (Syntaxhighlighting, Autocomplete etc.) bei Dir am Rechner zur Verfügung.
Oder Du bastelst Dir ein Entwicklungssystem, auf dem Du hinsichtlich der Beschränkungen von Laufzeiten, Speicher usw. mehr Möglichkeiten hast.
Ja, das scheint mir auch so 😉
Also um ehrlich zu sein, entwickle ich meine Extensions immer direkt im Kickstarter. Hier code ich mit EDIT in den einzelnen Dateien, indem ich den Standartinhalt durch meine Codes ersetze. Prinzipiell geht das auch gut, für meine "kleinen" Projekte. Der Code ist wirklich nicht kompliziert, aber natürlich sehr umfangreich.
Ich würde es sehr gerne auch anders machen, aber ich habe das Problem, dass ich immer an LIVE Servern arbeite und dann stoße ich immer auf die Rechtevergabe.
Will sagen, dass eine Extension, welche vom Kickstarter angelegt wurde, so auf der Server gespeichert wird, dass ich keine Möglichkeit habe per FTP darauf zuzugreifen (also SPEICHERN).
Auch ein Speichern der Attribute des Ordners oder einzelner Dateien in z.B. 777 geht nicht, weil sich die EXTENSION nur vom ROOT kontrollieren läßt.
Wenn ich mal rauskriegen könnte, wie man eine Extension per FTP bearbeiten kann, dann würde ich auch gerne mit PHP Interpreter coden :p
Kannst du mir da einen Tipp geben. Wie macht man das?
LG Andreas
Oh, die alte Rechteproblematik. o.O
Da gibt es leider nicht den einen, ultimativen Lösungsweg. Hier hängt's vor allem davon ab, wie der Server konfiguriert ist. Es gibt zwar theoretisch auch die Möglichkeit via 777 zu arbeiten, aber zum einen müsste dafür auch der FTP-Server Dateien entsprechend anlegen, und zum anderen hat es auch einen Sinn, warum Dateirechte nicht als für alle schreibbar angelegt werden
Idealerweise hat man einen Hoster, der sich mit TYPO3 auskennt und das System passend bereitstellt. 😉
Ja, mit dem Problem kämpfe ich schon seit ich angefangen habe meine eigenen Extensions zu entwickeln.
Das mit den rechten auf 777 könnte schon die Lösung sein, aber wie gesagt, ich komme mit den Rechten die der FTP Client auf dem Server hat, ja noch nicht mal dazu die Rechte zu ändern #angry#
Ich denke, dass ich das wohl nur mit Hilfe des Providers in den Griff bekomme.
Die Alternative wäre es auf einer LOCAL Maschine zu arbeiten und wenn alles funktioniert, die Extension zu speichern und dann hochzuladen.
Dummerweise sind die meisten Projekte aber immer LIVE. Also Andere designen und bauen das Typo und ich entwickle die Extension. Dazu braucht man aber immer Ausgaben der Extension. Also bastel ich auch immer LIVE dran rum :p .
Es ist ja nicht so, dass ich hier wilde Entwicklungen erarbeite, sondern wirklich nur einfache Ausgaben der DB z.B. zusätzliche Felder in der FE USER. Oder verschiedene Templates für Benutzer. Das läßt sich normalerweise schon nur im Kickstarter machen. Hab da ja so meine Standartcodes.
Dummerweise ist das diesmal etwas anders, denn ich habe 5 Templates mit verschieden Ansichten und dazu jedesmal andere Funktionen der Bildausgabe. Dazu kommen einige Funktionen für Berechnungen. Somit ist mein Code zum ersten Mal einfach zu lang....
Bin aber sicher, dass irgendwo in den Tiefen vom Apachen eine Restriktion dafür sorgt, dass das nicht geht. Weiß nur nicht welche!!!
Aber vielen Dank für deine Antwort
LG Andreas
Ein kleiner Nachtrag!
Habe eben mal schnell den WINSTALLER (TYPO + APACHE, SQL)auf meiner Kiste installiert.
Ganz schnell 3 Seiten angelegt, den Kickstarter und meine Extension installiert.
Im Kickstarter auf EDIT und fertig!!!!
Keinerlei Probleme den Code zu speichern.
Um dem Ganzen dann noch den Rest zu geben, habe ich die Zeilen (ca. 140)per COPY/PASTE gleich 5 x reingejagt also ca. 700 Zeilen EXTRA
:p .
Auch kein Problem.
Wie schon mal am Anfang des Threats erwähnt, scheint das doch ne Einstellung vom Provider zu sein.
Der Kickstarter kanns auf jeden Fall ausführen, zumindest LOCAL.
Hab auch weiter keine Einstellungen mehr vorgenommen, sondern direkt mit dem WINSTALLER losgelegt.
Ich werde jetzt Local so gut wie alles fertig machen und dann mal schauen, was das mit dem Provider so aufsich hat!!
Bis Dann
Andreas
Hatte soeben das identische Problem und ein Blick ins Fehler-Log brachte die Lösung.
In der php.ini die folgenden Werte erhöhen bzw. setzen. In meinem Fall komme ich mit den folgenden Werten gut aus.
suhosin.post.max_value_length = 650000
suhosin.request.max_value_length = 650000