From hagelstein at shr.cc Wed May 2 18:59:21 2007 From: hagelstein at shr.cc (Nikolas Hagelstein) Date: Wed, 2 May 2007 18:59:21 +0200 Subject: [TYPO3-irre] IRRE + dbal without pid :) Message-ID: Hi, I am currently integrating a 3rd party table which doesnt onws a PID field. I was able to prepend a pid by using dbal mapping but obviously it doesnt work common with IRRE (to be honest a very special situation but may be intressting anyway). "Create new record" results in an access denied error due to fact that "parseStructureString()" recieves : "data[][tx_myext_cost_centres][8][fe_groups][tx_myext_cost_centres_fe_gr oups]" (not the missing PID within the first brackets.) This obviously screws up the whole thing since e.g. $this->inlineFirstPid becomes something like: "][tx_myext_cost_centres" etc. I do not expect any help since as i mentioned above this is a very special "environment" i just wondered if there is a way to "preset" the PID instead of inheritating it from the parent record. Furhter more i am conviced that the current pid should be avaible "somewhere" else within the "environment" so it is probably worth thinking about something like a fallback mechanismn (e.g. withing getSingleField_typeInline). (Which should actually already exist for inline records of "new parent records"). If all else fails i could set a "fake PID" via "processDatamap_preProcessFieldArray" but i thought it would a good idea to ask you guys first :) Cheers, Nikolas From oh at inpublica.de Thu May 3 08:14:43 2007 From: oh at inpublica.de (Oliver Hader) Date: Thu, 03 May 2007 08:14:43 +0200 Subject: [TYPO3-irre] IRRE + dbal without pid :) In-Reply-To: References: Message-ID: Hi Nikolas, Nikolas Hagelstein wrote: > I am currently integrating a 3rd party table which doesnt onws a PID > field. > I was able to prepend a pid by using dbal mapping but obviously it > doesnt work common with > IRRE (to be honest a very special situation but may be intressting > anyway). > > "Create new record" results in an access denied error due to fact that > "parseStructureString()" recieves : > > "data[][tx_myext_cost_centres][8][fe_groups][tx_myext_cost_centres_fe_gr > oups]" > (not the missing PID within the first brackets.) I'm wondering if it is possible to create new records for the table without the pid field e.g. via list module. TCEmain tries to check access to the page by pid - currently I don't know how this will work without a proper pid. But possibly there's a way and I have to dig deeper in DBAL. > This obviously screws up the whole thing since e.g. > $this->inlineFirstPid becomes something like: > "][tx_myext_cost_centres" etc. The identifiert "data[...][][][]..." is split for AJAX calls. Currently IRRE expects to have something set as pid and fails if this is empty. I think this could be fixed with no bigger efforts. > I do not expect any help since as i mentioned above this is a very > special "environment" i just wondered if there is a way to "preset" the > PID instead of inheritating it from the parent record. Furhter more i > am conviced that the current pid should be avaible "somewhere" else > within the "environment" so it is probably worth thinking about > something like a fallback mechanismn (e.g. withing > getSingleField_typeInline). (Which should actually already exist for > inline records of "new parent records"). $this->inlineFirstPid is set to the pid of the first parent record (the one you select in the list module to edit). > If all else fails i could set a "fake PID" via > "processDatamap_preProcessFieldArray" but i thought it would a good > idea to ask you guys first :) Thus you would set the pid to a fixed value - but if the involved records (parent, children, etc.) don't have pids at all, how should the system automatically determine this value? You can send me your extension via PM. Maybe it would also possible to change the DBAL to use MySQL only, because I don't have PostgreSQL or any other DBMS installed. Thanks in advance! olly -- Oliver Hader http://inpublica.de/ From hagelstein at shr.cc Thu May 3 10:27:41 2007 From: hagelstein at shr.cc (Nikolas Hagelstein) Date: Thu, 3 May 2007 10:27:41 +0200 Subject: [TYPO3-irre] IRRE + dbal without pid :) References: Message-ID: Oliver Hader wrote: > I'm wondering if it is possible to create new records for the table > without the pid field e.g. via list module. To clearify things i "predented" a pid by setting the DBAL mapping to : 'tx_myext_cost_centres' => array ( 'mapTableName' => 'KOSTST', 'mapFieldNames' => array ( 'uid' => 'KST_ID', 'pid' => 76, 'navtitle' => 'KST_NAME', 'title' => 'KST_NAME', 'code' => 'KST_CODE', 'parent' => 'KST_PARENT' ) ), This makes the cost centre records appear on PID 76 (virtually) >TCEmain tries to check > access to the page by pid - currently I don't know how this will work > without a proper pid. Yes right that causses the "access denied atm" because in fact the records show up at Pid 76 since they are fetched by something like: "select * from table where pid=76" Which gets rewritten by DBAL To "select * from table where 76=76" but obviously the record itself doesnt own a pid field itself. :) Therefore i thought of hooking in at : - processDatamap_preProcessFieldArray and fake pid - processDatamap_PostProcessFieldArray unset the fake pid (otherwise a DB error would occure) > The identifiert "data[...][
][][]..." is split for > AJAX calls. Currently IRRE expects to have something set as pid and > fails if this is empty. I think this could be fixed with no bigger > efforts. Yes right if the pid is set to '' the parsing rexep fails and the whole parsing gets screwed up. :) > $this->inlineFirstPid is set to the pid of the first parent record > (the one you select in the list module to edit). Right but as mentioned before this one doesnt ows a pid, therefor it should be fixed implementing the hook idea mentioned above right? > Thus you would set the pid to a fixed value - but if the involved > records (parent, children, etc.) don't have pids at all, how should > the system automatically determine this value? The related records own pids since they are "real typo3 tables" ... > You can send me your extension via PM. Maybe it would also possible > to change the DBAL to use MySQL only, It would be pretty hard to extract the relevant parts. All you have to do is to create a table in mysql in a db different to typo3. Configure DBAL as follows: $TYPO3_CONF_VARS['EXTCONF']['dbal']['handlerCfg'] = array ( '_DEFAULT' => array ( 'type' => 'native', 'config' => array ( 'username' => '', // Set by default (overridden) 'password' => '', // Set by default (overridden) 'host' => '', // Set by default (overridden) 'database' => '' ) ), 'testDB' => array ( 'type' => 'adodb', 'config' => array( 'username' => 'whatever', 'password' => 'whatever', 'host' => 'localhost', 'database' => 'testDB', 'driver' => 'mysql', ) ), ); $TYPO3_CONF_VARS['EXTCONF']['dbal']['table2handlerKeys'] = array ( 'testTbl' => 'testDB', ); $TYPO3_CONF_VARS['EXTCONF']['dbal']['mapping'] = array ( 'testTbl' => array ( 'mapFieldNames' => array ( 'uid' => 'id', 'pid' => 76, ) ), Afterwards create some dummy records in testTbl. They shoud appear at pid 76 in listmode. Change TCA of testTBL to some IRRE relational stuff e.g. assign pages or fe_users to it .... Well that is basically what i am doing atm. BEWARE: there is a ugly bug in DBAL which makes record saving fail if DBAL Debug is turned on (even on the _DEFAULT handler) so make sure you turn it of :) > because I don't have PostgreSQL Even more worse it is MSSQL in this case :) Cheers, Nikolas From oh at inpublica.de Thu May 3 13:35:40 2007 From: oh at inpublica.de (Oliver Hader) Date: Thu, 03 May 2007 13:35:40 +0200 Subject: [TYPO3-irre] IRRE + dbal without pid :) In-Reply-To: References: Message-ID: Hi Nikolas, Nikolas Hagelstein wrote: > Oliver Hader wrote: >> TCEmain tries to check >> access to the page by pid - currently I don't know how this will work >> without a proper pid. > Yes right that causses the "access denied atm" because in fact the > records show up at > Pid 76 since they are fetched by something like: > "select * from table where pid=76" > Which gets rewritten by DBAL To "select * from table where 76=76" but > obviously the record itself doesnt own a pid field itself. :) > > Therefore i thought of hooking in at : > - processDatamap_preProcessFieldArray and fake pid > - processDatamap_PostProcessFieldArray unset the fake pid (otherwise a > DB error would occure) There is a hook in TCEforms "getMainFields_preProcess". You could use this one to fake the pid of the parent/child record to the fixed value "76". Doing this should also prevent from screwing up the variable "inlineFirstPid" with nonsense. When the data should be save using TCEmain you have to catch the "virtual things" to prevent from writing to the field pid which doesn't exist at all. I didn't test it, but I think it could work. To get this working without the disposal of hooks IMO the DBAL should add the pid virtually to records if it's defined in the mapping. olly -- Oliver Hader http://inpublica.de/ From oh at inpublica.de Thu May 3 13:43:02 2007 From: oh at inpublica.de (Oliver Hader) Date: Thu, 03 May 2007 13:43:02 +0200 Subject: [TYPO3-irre] RTE in child elements overwrites field in parent element In-Reply-To: References: Message-ID: Hi Gregor, Gregor Gold wrote: > Hi everyone, > > i'm just trying to set up my first extension using IRRE and I am struggling > with a weird problem, which I do not understand. > > I created a parent table called "...downloads" and a child table called > "...credits". The credit info is set up as a child element of downloads. > Both contain a RTE element. > > If I create a new downloads item, fill out all fields including the RTE > field "description", create a new child element "credits" and fill out its > RTE field "credits", too, the RTE content of the parent element is replaced > by the content of the "credits" child element after saving. Meaning, both > RTE elements now contain the same data. The same happens, if I do save the > parent element before creating a "credits" child element. All other fields > remain unchanged. > > If I edit the RTE field of the parent element afterwards and replace the > credits content by the original content for the parent element, everything > is saved as intended. No overwriting of foreign fields or something like > this I can reproduce this behaviour. You found a bug! Please open a new bug report at http://bugs.typo3.org/ and insert your description of the problem. I'm going to fix this ASAP. Thanks! olly -- Oliver Hader http://inpublica.de/ From pimpmysims at googlemail.com Thu May 3 14:15:21 2007 From: pimpmysims at googlemail.com (Gregor Gold) Date: Thu, 3 May 2007 14:15:21 +0200 Subject: [TYPO3-irre] RTE in child elements overwrites field in parent element In-Reply-To: References: Message-ID: Hi Olly, I did open a new bug report. I hope, it includes all neccessary information and that I did not miss anything important. Attached the whole tca.php file, if needed. Here is the link to the new bug report: http://bugs.typo3.org/view.php?id=5556 Greetings Gregor 2007/5/3, Oliver Hader : > > Hi Gregor, > > Gregor Gold wrote: > > Hi everyone, > > > > i'm just trying to set up my first extension using IRRE and I am > struggling > > with a weird problem, which I do not understand. > > > > I created a parent table called "...downloads" and a child table called > > "...credits". The credit info is set up as a child element of downloads. > > Both contain a RTE element. > > > > If I create a new downloads item, fill out all fields including the RTE > > field "description", create a new child element "credits" and fill out > its > > RTE field "credits", too, the RTE content of the parent element is > replaced > > by the content of the "credits" child element after saving. Meaning, > both > > RTE elements now contain the same data. The same happens, if I do save > the > > parent element before creating a "credits" child element. All other > fields > > remain unchanged. > > > > If I edit the RTE field of the parent element afterwards and replace the > > credits content by the original content for the parent element, > everything > > is saved as intended. No overwriting of foreign fields or something like > > this > > I can reproduce this behaviour. You found a bug! > Please open a new bug report at http://bugs.typo3.org/ and insert your > description of the problem. I'm going to fix this ASAP. Thanks! > > > olly > -- > Oliver Hader > http://inpublica.de/ > _______________________________________________ > TYPO3-project-irre mailing list > TYPO3-project-irre at lists.netfielders.de > http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-project-irre > From oh at inpublica.de Thu May 3 14:17:59 2007 From: oh at inpublica.de (Oliver Hader) Date: Thu, 03 May 2007 14:17:59 +0200 Subject: [TYPO3-irre] RTE in child elements overwrites field in parent element In-Reply-To: References: Message-ID: Hi, Oliver Hader wrote: > Gregor Gold wrote: >> If I edit the RTE field of the parent element afterwards and replace the >> credits content by the original content for the parent element, everything >> is saved as intended. No overwriting of foreign fields or something like >> this > > I can reproduce this behaviour. You found a bug! > Please open a new bug report at http://bugs.typo3.org/ and insert your > description of the problem. I'm going to fix this ASAP. Thanks! The problem is located in the RTEcounter variable in TCEforms. It will be incremented each time a RTE is rendered. When a new child record is renderen using AJAX this process doesn't know how many RTE instances have been created before. I'm trying to find a solution for this... olly -- Oliver Hader http://inpublica.de/ From hagelstein at shr.cc Thu May 3 14:31:50 2007 From: hagelstein at shr.cc (Nikolas Hagelstein) Date: Thu, 3 May 2007 14:31:50 +0200 Subject: [TYPO3-irre] IRRE + dbal without pid :) References: Message-ID: Oliver Hader wrote: > There is a hook in TCEforms "getMainFields_preProcess". You could use > this one to fake the pid of the parent/child record to the fixed > value "76". Doing this should also prevent from screwing up the > variable "inlineFirstPid" with nonsense. Did that already and it worked. :) But there is one issue left you probably could gimme a hand on: The parent record isnt allowed to be save (readonly) but due to the fact that Inline childs get added at "saving time" i set : $fieldArray = 0 withing processDatamap_postProcessFieldArray. According to: http://doxygen.frozenkiwi.com/typo3/html/dd/da6/class_8t3lib__tcemain_8p hp-source.html#l00775 This should prevent the record from being saved. I works quite well execpt for one thing: If i add new an inline child to the parent record the parent records "save" routine gets trigger anyway. Any ideas? > I didn't test it, but I think it could work. To get this working > without the disposal of hooks IMO the DBAL should add the pid > virtually to records if it's defined in the mapping. Yes right but DBAL isnt aware of virtuall fields yet. Bye, Nikolas From oh at inpublica.de Thu May 3 14:53:13 2007 From: oh at inpublica.de (Oliver Hader) Date: Thu, 03 May 2007 14:53:13 +0200 Subject: [TYPO3-irre] IRRE + dbal without pid :) In-Reply-To: References: Message-ID: Hi Nikolas, Nikolas Hagelstein wrote: > Oliver Hader wrote: >> There is a hook in TCEforms "getMainFields_preProcess". You could use >> this one to fake the pid of the parent/child record to the fixed >> value "76". Doing this should also prevent from screwing up the >> variable "inlineFirstPid" with nonsense. > Did that already and it worked. :) > But there is one issue left you probably could gimme a hand on: > The parent record isnt allowed to be save (readonly) but due to the fact > that > Inline childs get added at "saving time" i set : > $fieldArray = 0 withing processDatamap_postProcessFieldArray. > According to: > http://doxygen.frozenkiwi.com/typo3/html/dd/da6/class_8t3lib__tcemain_8p > hp-source.html#l00775 > > This should prevent the record from being saved. > > I works quite well execpt for one thing: > If i add new an inline child to the parent record the parent records > "save" routine gets trigger anyway. > Any ideas? Yepp... if the parent relates to unsaved (new) child records there will be an entry on $this->remapStack in TCEmain. This stack will be processed if all children have been saved and afterwards the parent record gets updated by calling t3lib_TCEmain::updateDB(). Unfortunatelly this method doesn't have any hooks. A dirty workaround could be to use any of the processDatamap_* hooks to revert the entry for the parent table on $this->remapStack. Using processDatamap_afterDatabaseOperations might no be a good idea, but give it a try. There is pending bugfix for this hook - have a look: http://bugs.typo3.org/view.php?id=5074 >> I didn't test it, but I think it could work. To get this working >> without the disposal of hooks IMO the DBAL should add the pid >> virtually to records if it's defined in the mapping. > Yes right but DBAL isnt aware of virtuall fields yet. So go ahead with a feature request for DBAL in bugtracker if you'd like to see this one day... ;-) olly -- Oliver Hader http://inpublica.de/ From hagelstein at shr.cc Thu May 3 15:35:56 2007 From: hagelstein at shr.cc (Nikolas Hagelstein) Date: Thu, 3 May 2007 15:35:56 +0200 Subject: [TYPO3-irre] IRRE + dbal without pid :) References: Message-ID: Oliver Hader wrote: > Yepp... if the parent relates to unsaved (new) child records there > will be an entry on $this->remapStack in TCEmain. This stack will be > processed if all children have been saved and afterwards the parent > record gets updated by calling t3lib_TCEmain::updateDB(). > Unfortunatelly this method doesn't have any hooks. A dirty workaround > could be to use any of the processDatamap_* hooks to revert the entry > for the parent table on $this->remapStack. Hmm i tried to remove the particular entry from the stack. This results in an incomplete intermediate tabel entry: Meaning the id of the parent record is missing (i.e 0). I thought it would be set at creation time if it is known. Could you enlighten me? > So go ahead with a feature request for DBAL in bugtracker if you'd > like to see this one day... ;-) Not the the first one that came up during this project ;) Bye, NIkolas From hagelstein at shr.cc Thu May 3 15:58:17 2007 From: hagelstein at shr.cc (Nikolas Hagelstein) Date: Thu, 3 May 2007 15:58:17 +0200 Subject: [TYPO3-irre] IRRE + dbal without pid :) References: Message-ID: Oliver Hader wrote: > A dirty workaround > could be to use any of the processDatamap_* hooks to revert the entry > for the parent table on $this->remapStack. $pObj->remapStack[0]['args'][$pObj->remapStack[0]['pos']['table']] = ''; Did the trick ... :) Bye, Nikolas From oh at inpublica.de Thu May 3 18:19:44 2007 From: oh at inpublica.de (Oliver Hader) Date: Thu, 03 May 2007 18:19:44 +0200 Subject: [TYPO3-irre] RTE in child elements overwrites field in parent element In-Reply-To: References: Message-ID: Hi Gregor, Gregor Gold wrote: > I did open a new bug report. I hope, it includes all neccessary information > and that I did not miss anything important. Attached the whole tca.php > file, > if needed. > > Here is the link to the new bug report: > http://bugs.typo3.org/view.php?id=5556 Thanks for creating the bug report. I attached a patch file in the bugtracke which should solve this issue. Please give me some feedback if it works on your system or if there were still any side-effects. olly -- Oliver Hader http://inpublica.de/ From hagelstein at shr.cc Thu May 3 18:31:57 2007 From: hagelstein at shr.cc (Nikolas Hagelstein) Date: Thu, 3 May 2007 18:31:57 +0200 Subject: [TYPO3-irre] ItemProcFunc and title Message-ID: Hi, Using itemProcFunc within the intermediate table results in "[no title]" after saving. Is there a way to make IRRE resolve the correct label? Bye, nikolas From oh at inpublica.de Thu May 3 18:42:22 2007 From: oh at inpublica.de (Oliver Hader) Date: Thu, 03 May 2007 18:42:22 +0200 Subject: [TYPO3-irre] ItemProcFunc and title In-Reply-To: References: Message-ID: Hi Nikolas, Nikolas Hagelstein wrote: > Hi, > > Using itemProcFunc within the intermediate table results in > "[no title]" after saving. > Is there a way to make IRRE resolve the correct label? Could you please post the TCA configuration of that field of the intermediate table? olly -- Oliver Hader http://inpublica.de/ From hagelstein at shr.cc Thu May 3 18:45:10 2007 From: hagelstein at shr.cc (Nikolas Hagelstein) Date: Thu, 3 May 2007 18:45:10 +0200 Subject: [TYPO3-irre] foreign_selector problem. Message-ID: Using a foreign_selector of size 1 leads to strange results: E.g. Lets assume i got a Selectbox of size 1 containing 5 entries On Clicking on it it folds out like : ([item 1]^) [item 1] [item 2] [item 3]* [item 4] [item 5] But clicking on item 3 adds item 1 ...which is kinda confusing :) Is there anything i did wrong? Btw: how to increase the foreign_selectors selectbox? Like e.g. shown at : http://wiki.typo3.org/index.php/Image:Irre_ff_attr_combo_be_unique.png Bye, Nikolas From hagelstein at shr.cc Thu May 3 18:53:58 2007 From: hagelstein at shr.cc (Nikolas Hagelstein) Date: Thu, 3 May 2007 18:53:58 +0200 Subject: [TYPO3-irre] ItemProcFunc and title References: Message-ID: Oliver Hader wrote: > Could you please post the TCA configuration of that field of the > intermediate table? Sure: Parent: $TCA["tx_myext_cost_centres"] = array ( .... "admin_users" => Array ( "exclude" => 1, "label" => "LLL:EXT:myextension/locallang_db.xml:whatever", 'config' => Array( 'type' => 'inline', 'foreign_table' => 'tx_myext_mm', 'foreign_field' => 'cost_centre', 'foreign_selector' => 'admin_user', 'foreign_unique' => 'admin_user', 'foreign_label' => 'admin_user', 'appearance' => Array( 'useCombination' => 0, ), ), ), ), Intermediate: $TCA["tx_myext_mm"] = array ( ... 'admin_user' => Array( 'label' => 'LLL:EXT:myextension/locallang_db.xml:whatever', 'config' => Array( 'type' => 'select', 'itemsProcFunc' => 'tx_meyext_itemFunc->adminUsers', 'size' => 1, 'minitems' => 0, 'maxitems' => 1, ), ), .... Bye, Nikolas From hagelstein at shr.cc Thu May 3 19:12:53 2007 From: hagelstein at shr.cc (Nikolas Hagelstein) Date: Thu, 3 May 2007 19:12:53 +0200 Subject: [TYPO3-irre] foreign_selector problem. References: Message-ID: Nikolas Hagelstein wrote: > Using a foreign_selector of size 1 leads to strange results: > E.g. Lets assume i got a Selectbox of size 1 containing 5 entries On > Clicking on it it folds out like : > > ([item 1]^) > [item 1] > [item 2] > [item 3]* > [item 4] > [item 5] > > But clicking on item 3 adds item 1 ...which is kinda confusing :) > > Is there anything i did wrong? > Btw: how to increase the foreign_selectors selectbox? Ok got that meanwhile. Furthermore i was able to narrow the problem down: I occurs regardless of the selectbox size. The effect disappears if i disable: foreign_unique. So it is probably a combinatino problem of foreign_unique and foreign_selector :| Bye, nikolas From hagelstein at shr.cc Thu May 3 19:19:16 2007 From: hagelstein at shr.cc (Nikolas Hagelstein) Date: Thu, 3 May 2007 19:19:16 +0200 Subject: [TYPO3-irre] foreign_selector problem. References: Message-ID: Nikolas Hagelstein wrote: > Using a foreign_selector of size 1 leads to strange results: > E.g. Lets assume i got a Selectbox of size 1 containing 5 entries On > Clicking on it it folds out like : > > ([item 1]^) > [item 1] > [item 2] > [item 3]* > [item 4] > [item 5] > > But clicking on item 3 adds item 1 ...which is kinda confusing :) This issue can be reproduced using the IRRE tutorial extension and setting: TCEFORM.tx_irretutorial_mnasym_hotel.offers.config { foreign_selector = offerid foreign_unique = offerid size = 5 } At the "m:n asymmetric selector" - page Cheers, NIkolas From pimpmysims at googlemail.com Thu May 3 22:11:30 2007 From: pimpmysims at googlemail.com (Gregor Gold) Date: Thu, 3 May 2007 22:11:30 +0200 Subject: [TYPO3-irre] RTE in child elements overwrites field in parent element In-Reply-To: References: Message-ID: Works perfect for me. Please see the notes in the bug report. I did manually change the files mentioned in the patch file (did not know, if there is any automatic solution), but it works just perfect. Child records do not overwrite parent RTE fields anymore. Tried several combinations of"creating parent/child objects. All work fine. Thx for this really fast solution! Gregor 2007/5/3, Oliver Hader : > > Hi Gregor, > > Gregor Gold wrote: > > I did open a new bug report. I hope, it includes all neccessary > information > > and that I did not miss anything important. Attached the whole tca.php > > file, > > if needed. > > > > Here is the link to the new bug report: > > http://bugs.typo3.org/view.php?id=5556 > > Thanks for creating the bug report. > I attached a patch file in the bugtracke which should solve this issue. > Please give me some feedback if it works on your system or if there were > still any side-effects. > > > olly > -- > Oliver Hader > http://inpublica.de/ > _______________________________________________ > TYPO3-project-irre mailing list > TYPO3-project-irre at lists.netfielders.de > http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-project-irre > From oh at inpublica.de Fri May 4 08:16:34 2007 From: oh at inpublica.de (Oliver Hader) Date: Fri, 04 May 2007 08:16:34 +0200 Subject: [TYPO3-irre] RTE in child elements overwrites field in parent element In-Reply-To: References: Message-ID: Hi Gregor, Gregor Gold wrote: > Works perfect for me. Please see the notes in the bug report. I did > manually > change the files mentioned in the patch file (did not know, if there is any > automatic solution), but it works just perfect. Child records do not > overwrite parent RTE fields anymore. Tried several combinations of"creating > parent/child objects. All work fine. Thanks for testing the patch. I just posted a RFC on the list of the Core-Team to have this integrated into the next TYPO3 release. For applying patches you could have a look to the bug fixing page: http://typo3.org/development/bug-fixing/diff-and-patch/ > Thx for this really fast solution! I thought I now got almost all RTE stuff related to IRRE - but this one was missing and nobody noticed until now. Thanks for pointing it out! olly -- Oliver Hader http://inpublica.de/ From vg_typo3 at e-netconsulting.de Fri May 4 10:05:04 2007 From: vg_typo3 at e-netconsulting.de (Volker Graubaum) Date: Fri, 04 May 2007 09:05:04 +0100 Subject: [TYPO3-irre] RTE in child elements overwrites field in parent element In-Reply-To: References: Message-ID: Hi Oliver, we'd the same problem too, and the patch solved it too. BUT I found another thing related to this. :-) When the server reponse for the AJAX element takes to long, and a user clicks more often to create a new one, some RTE's aren't loaded. (getting the same error as we get after the FF 2.0.3 Update "Editor is beeing loaded" ) Greetings Volker From oh at inpublica.de Sat May 5 11:22:46 2007 From: oh at inpublica.de (Oliver Hader) Date: Sat, 05 May 2007 11:22:46 +0200 Subject: [TYPO3-irre] RTE in child elements overwrites field in parent element In-Reply-To: References: Message-ID: Hi Volker, Volker Graubaum schrieb: > Hi Oliver, > > we'd the same problem too, and the patch solved it too. > > BUT I found another thing related to this. :-) > > When the server reponse for the AJAX element takes to long, and a user > clicks more often to create a new one, some RTE's aren't loaded. > (getting the same error as we get after the FF 2.0.3 Update > "Editor is beeing loaded" ) You're right. The previous fix for this problem was to tell TCEforms how many instances of the RTEhtmlarea are existing (since TCEforms starts again counting by zero when used on AJAX/IRRE calls). On clicking the "create new record" link more than once - what is okay in general - TCEforms gets the same value for the $RTEcounter variable. Thus, it will again overwrite another RTEhtmlarea instance... (*argh*) A solution could be to process and index the newly RTE after it has been fetched from server via AJAX. Currently the index is set by PHP/TCEforms, in future I could imagine that JavaScript is doing this dynamically (only in IRRE context, not for regular standard tt_content!). But to do this there are some changes necessary in RTEhtmlarea which would be covered by the term "bugfix" and thus could only be fixed in Trunk. Thus, I'm working on a solution for Trunk and possibly my colleagues in the Core-Team will approve this also for the TYPO3_4-1 branch. We will see... olly -- Oliver Hader http://inpublica.de/ From ingmar at typo3.org Sat May 5 17:11:29 2007 From: ingmar at typo3.org (Ingmar Schlecht) Date: Sat, 05 May 2007 17:11:29 +0200 Subject: [TYPO3-irre] RTE in child elements overwrites field in parent element In-Reply-To: References: Message-ID: Hi Olly, would it be possible to use random indexes instead of just a count? I mean, what if you just set the RTE index to something like 9283 or such random numbers for IRRE elements? cheers Ingmar Oliver Hader schrieb: > Hi Volker, > > Volker Graubaum schrieb: >> Hi Oliver, >> >> we'd the same problem too, and the patch solved it too. >> >> BUT I found another thing related to this. :-) >> >> When the server reponse for the AJAX element takes to long, and a user >> clicks more often to create a new one, some RTE's aren't loaded. >> (getting the same error as we get after the FF 2.0.3 Update >> "Editor is beeing loaded" ) > > You're right. The previous fix for this problem was to tell TCEforms how > many instances of the RTEhtmlarea are existing (since TCEforms starts > again counting by zero when used on AJAX/IRRE calls). > > On clicking the "create new record" link more than once - what is okay > in general - TCEforms gets the same value for the $RTEcounter variable. > Thus, it will again overwrite another RTEhtmlarea instance... (*argh*) > > A solution could be to process and index the newly RTE after it has been > fetched from server via AJAX. Currently the index is set by > PHP/TCEforms, in future I could imagine that JavaScript is doing this > dynamically (only in IRRE context, not for regular standard > tt_content!). But to do this there are some changes necessary in > RTEhtmlarea which would be covered by the term "bugfix" and thus could > only be fixed in Trunk. > > Thus, I'm working on a solution for Trunk and possibly my colleagues in > the Core-Team will approve this also for the TYPO3_4-1 branch. We will > see... > > > olly From oh at inpublica.de Mon May 7 08:25:59 2007 From: oh at inpublica.de (Oliver Hader) Date: Mon, 07 May 2007 08:25:59 +0200 Subject: [TYPO3-irre] RTE in child elements overwrites field in parent element In-Reply-To: References: Message-ID: Hi Ingmar, Ingmar Schlecht wrote: > Hi Olly, > > would it be possible to use random indexes instead of just a count? > > I mean, what if you just set the RTE index to something like 9283 or > such random numbers for IRRE elements? Some (="many" *g*) things have to be changed. Currently there are lots of iterations which step through all RTEs in the array. So if you have a random integer of e.g. "123456" all from 0 to this value will be processed. I thought about a more specific and explicit allocation of field to RTE like "RTEarea['
__']" like it's done for TCEforms fields. But this would also cause many changes because the identifier is currently seen as integer only in JavaScript. But this would be a clean solution and you always have a relationship between TCEforms field and RTE instances. This was also the reason for my RFC on the Core-List for moving the JSON function from t3lib_TCEforms_inline to t3lib_div as a more common place, because it would be required here. olly -- Oliver Hader http://inpublica.de/ From hagelstein at shr.cc Mon May 7 13:04:36 2007 From: hagelstein at shr.cc (Nikolas Hagelstein) Date: Mon, 7 May 2007 13:04:36 +0200 Subject: [TYPO3-irre] foreign_selector problem. References: Message-ID: Hi, I was able to narrow to problem down to jsfunc.inline.js : setUnique ( ~ line 212) If i comment out the lines beyond 212 it seems to work: // remove all before used items from the new select-item for (var i=0; i Message-ID: Hi, The following patch should solve this issue: (see http://bugs.typo3.org/view.php?id=5564 ) Could anyone please confirm? Cheers, Nikolas --- jsfunc.inline.js 2007-04-02 23:41:34.000000000 +0200 +++ ../../../typo3_src-4.1.1/t3lib/jsfunc.inline.js 2007-05-07 15:54:45.000000000 +0200 @@ -210,8 +210,10 @@ // remove all before used items from the new select-item for (var i=0; i Hi When I make a translation of a record that has relations to som subrecords all the subrecords are also duplication even though they dont need to be translated. How do I solve this? /Brian Bendtsen From j.rieger at connecta.ag Mon May 7 17:15:27 2007 From: j.rieger at connecta.ag (Jochen Rieger) Date: Mon, 07 May 2007 17:15:27 +0200 Subject: [TYPO3-irre] RTE in child elements overwrites field in parent element In-Reply-To: References: Message-ID: Hi Oliver & all, > The problem is located in the RTEcounter variable in TCEforms. It will > be incremented each time a RTE is rendered. When a new child record is > renderen using AJAX this process doesn't know how many RTE instances > have been created before. okay... this might explain why I'm having similar issues without having a parent record RTE. As soon as I have more than one child attached with RTE field I will only be able to write in the first one that has been loaded or even into none. The strange thing about it is: in IE7 it's working! Only FF (2.0.0.3) has those problems. Even after applying '0005556_v3.patch'. From oh at inpublica.de Mon May 7 17:37:44 2007 From: oh at inpublica.de (Oliver Hader) Date: Mon, 07 May 2007 17:37:44 +0200 Subject: [TYPO3-irre] foreign_selector problem (solved). In-Reply-To: References: Message-ID: Hi Nikolas, Nikolas Hagelstein wrote: > The following patch should solve this issue: > (see http://bugs.typo3.org/view.php?id=5564 ) I'm going to take a closer look at this one and test the patch tomorrow. olly -- Oliver Hader http://inpublica.de/ From pimpmysims at googlemail.com Tue May 8 09:21:38 2007 From: pimpmysims at googlemail.com (Gregor Gold) Date: Tue, 8 May 2007 09:21:38 +0200 Subject: [TYPO3-irre] RTE in child elements overwrites field in parent element In-Reply-To: References: Message-ID: Hi Jochen, do those RTE fields have the same label? I experienced something like this, when all the RTE fields had the same label like "Description" etc. in FF. After renaming those fields to "Description A", "Description B" etc., FF let me access all RTE fields. Gregor 2007/5/7, Jochen Rieger : > > Hi Oliver & all, > > > The problem is located in the RTEcounter variable in TCEforms. It will > > be incremented each time a RTE is rendered. When a new child record is > > renderen using AJAX this process doesn't know how many RTE instances > > have been created before. > > okay... this might explain why I'm having similar issues without having > a parent record RTE. > > As soon as I have more than one child attached with RTE field I will > only be able to write in the first one that has been loaded or even into > none. > > The strange thing about it is: in IE7 it's working! Only FF (2.0.0.3) > has those problems. > > Even after applying '0005556_v3.patch'. > _______________________________________________ > TYPO3-project-irre mailing list > TYPO3-project-irre at lists.netfielders.de > http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-project-irre > From oh at inpublica.de Tue May 8 09:30:30 2007 From: oh at inpublica.de (Oliver Hader) Date: Tue, 08 May 2007 09:30:30 +0200 Subject: [TYPO3-irre] foreign_selector problem (solved). In-Reply-To: References: Message-ID: Hi Nikolas, Nikolas Hagelstein wrote: > The following patch should solve this issue: > (see http://bugs.typo3.org/view.php?id=5564 ) > > Could anyone please confirm? The patch in file "foreign_unique.diff" just removed the problem for the given situation but didn't solve it. It is possible to use uniqueness with and without a selector. If used without a selector, newly created children on an intermediate table don't have an information about which record is related - thus the first one of the remaining possibilities is used. If uniqueness is used with a selector, this information is already given. The solution is to execute the "set the selected item automatically to the first of the remaining items" party only in the situation that no selector is available. Please try the patch in file "0005564_v2.diff" attached to the bugtracker report at http://bugs.typo3.org/view.php?id=5564 olly -- Oliver Hader http://inpublica.de/ From hagelstein at shr.cc Tue May 8 10:28:06 2007 From: hagelstein at shr.cc (Nikolas Hagelstein) Date: Tue, 8 May 2007 10:28:06 +0200 Subject: [TYPO3-irre] foreign_selector problem (solved). References: Message-ID: Oliver Hader wrote: >The patch in file "foreign_unique.diff" just removed the problem >for the given situation but didn't solve it. Right, i wasnt aware of any possible combination. > Please try the patch in file "0005564_v2.diff" attached to the > bugtracker report at http://bugs.typo3.org/view.php?id=5564 Works :) Bye, nikolas From oh at inpublica.de Tue May 8 10:49:22 2007 From: oh at inpublica.de (Oliver Hader) Date: Tue, 08 May 2007 10:49:22 +0200 Subject: [TYPO3-irre] foreign_selector problem (solved). In-Reply-To: References: Message-ID: Hi Nikolas, Nikolas Hagelstein wrote: > Oliver Hader wrote: >> The patch in file "foreign_unique.diff" just removed the problem >> for the given situation but didn't solve it. > Right, i wasnt aware of any possible combination. Never mind. But you pointed to the correct part in the source what save some time again. Thanks! :-) >> Please try the patch in file "0005564_v2.diff" attached to the >> bugtracker report at http://bugs.typo3.org/view.php?id=5564 > Works :) Great, I'm going to put this on the Core-List the next few days. olly -- Oliver Hader http://inpublica.de/ From hagelstein at shr.cc Tue May 8 11:30:52 2007 From: hagelstein at shr.cc (Nikolas Hagelstein) Date: Tue, 8 May 2007 11:30:52 +0200 Subject: [TYPO3-irre] foreign_selector problem (solved). References: Message-ID: Oliver Hader wrote: > Great, I'm going to put this on the Core-List the next few days. Ok great :) Bye, Nikolas From j.rieger at connecta.ag Tue May 8 21:04:56 2007 From: j.rieger at connecta.ag (Jochen Rieger) Date: Tue, 08 May 2007 21:04:56 +0200 Subject: [TYPO3-irre] RTE in child elements overwrites field in parent element In-Reply-To: References: Message-ID: Hi Gregor, thanks for your hint, but the situation is not that I'm having 2 RTE fields in ONE child record. Each child record only contains 1 RTE. But I'm attaching one or more child records to my parent. So of cause the field name will be the same, but each time in a different child record. I'd guess there is some JS adressing trouble... Unfortunately I did not have time to dig deeper into the code yet. Cheers, Jochen Gregor Gold schrieb: > Hi Jochen, > > do those RTE fields have the same label? I experienced something like this, > when all the RTE fields had the same label like "Description" etc. in FF. > After renaming those fields to "Description A", "Description B" etc., FF > let > me access all RTE fields. > > Gregor From oh at inpublica.de Sat May 12 20:07:27 2007 From: oh at inpublica.de (Oliver Hader) Date: Sat, 12 May 2007 20:07:27 +0200 Subject: [TYPO3-irre] ItemProcFunc and title In-Reply-To: References: Message-ID: Hi Nikolas, Nikolas Hagelstein wrote: > Oliver Hader wrote: >> Could you please post the TCA configuration of that field of the >> intermediate table? > Sure: > > Parent: [TCA config] I tested this on a IRRE selector and the items were correctly processed. What did you experience/what happened on your system? olly -- Oliver Hader http://inpublica.de/ From hagelstein at shr.cc Mon May 14 10:24:41 2007 From: hagelstein at shr.cc (Nikolas Hagelstein) Date: Mon, 14 May 2007 10:24:41 +0200 Subject: [TYPO3-irre] ItemProcFunc and title References: Message-ID: Oliver Hader wrote: > I tested this on a IRRE selector and the items were correctly > processed. What did you experience/what happened on your system? The child record's label got lost after saving. I solved this using a label_procFunc meanwhile. Cheers, Nikolas From oh at inpublica.de Wed May 23 13:28:04 2007 From: oh at inpublica.de (Oliver Hader) Date: Wed, 23 May 2007 13:28:04 +0200 Subject: [TYPO3-irre] foreign_selector problem. In-Reply-To: References: Message-ID: FYI: This bug is fixed in SVN and will be available with TYPO3 4.1.2 olly Nikolas Hagelstein schrieb: > Using a foreign_selector of size 1 leads to strange results: > E.g. Lets assume i got a Selectbox of size 1 containing 5 entries > On Clicking on it it folds out like : > > ([item 1]^) > [item 1] > [item 2] > [item 3]* > [item 4] > [item 5] > > But clicking on item 3 adds item 1 ...which is kinda confusing :) > > Is there anything i did wrong? > Btw: how to increase the foreign_selectors selectbox? > Like e.g. shown at : > http://wiki.typo3.org/index.php/Image:Irre_ff_attr_combo_be_unique.png -- Oliver Hader http://inpublica.de/ From hagelstein at shr.cc Wed May 23 14:45:57 2007 From: hagelstein at shr.cc (Nikolas Hagelstein) Date: Wed, 23 May 2007 14:45:57 +0200 Subject: [TYPO3-irre] foreign_selector problem. References: Message-ID: Oliver Hader wrote: > FYI: This bug is fixed in SVN and will be available with TYPO3 4.1.2 Great, thanx a lot. Bye, Nikolas From franz at fholzinger.com Thu May 24 14:11:15 2007 From: franz at fholzinger.com (Franz Holzinger) Date: Thu, 24 May 2007 14:11:15 +0200 Subject: [TYPO3-irre] Create new relation does nothing Message-ID: Hello, I am using the almost the same as described in "Bidirectional asymmetric m:n relations" 'appearance' => Array ('collapseAll' => TRUE, 'useCombination' => TRUE), In TCE I see the select box with one entry already made before. And right of it the Link which never works. this.data.unique is undefined. Then the selected is always set to false. Maybe the function setUniqueElement should have been called before? importNewRecord: function(objectId) { var selector = $(objectId+'_selector'); if (selector.selectedIndex != -1) { var selectedValue = selector.options[selector.selectedIndex].value; if (!this.data.unique || !this.data.unique[objectId]) { selector.options[selector.selectedIndex].selected = false; } Under the select box there is also a link. 'Neu anlegen' the same in German now. This one works if clicked. Then a new relation can be entered. But how should the first 'create new relation' work? Should this be the place to select and modify a former entry or what? - Franz From oh at inpublica.de Thu May 24 18:22:56 2007 From: oh at inpublica.de (Oliver Hader) Date: Thu, 24 May 2007 18:22:56 +0200 Subject: [TYPO3-irre] Create new relation does nothing In-Reply-To: References: Message-ID: Hi Franz, Franz Holzinger schrieb: > Hello, > > I am using the almost the same as described in "Bidirectional asymmetric > m:n relations" > > 'appearance' => Array ('collapseAll' => TRUE, 'useCombination' => TRUE), Is this the difference to the "bidi asym m:n relations" in the tutorial? The combined mode has still some difficulties mentioned at http://bugs.typo3.org/view.php?id=5514 > In TCE I see the select box with one entry already made before. And > right of it the Link which never works. Maybe in this case you might want to try to patch at http://bugs.typo3.org/view.php?id=5564 which was also committed to TYPO3_4-1 and Trunk yesterday. Do you get a JavaScript error/warning? > this.data.unique is undefined. Then the selected is always set to false. > Maybe the function setUniqueElement should have been called before? Yes, the selected property of the option of the selector is set to false. Otherwise it would not be possible to create a relation to the same object again - in case the no uniquness is required. > Under the select box there is also a link. 'Neu anlegen' the same in > German now. This one works if clicked. Then a new relation can be entered. > > But how should the first 'create new relation' work? Should this be the > place to select and modify a former entry or what? The "create new relation" wasn't yet translated to German - maybe it should be called "import record" or "re-use record". The "Neu anlegen" or "create new" is for a completely new record. olly -- Oliver Hader http://inpublica.de/ From franz at fholzinger.com Thu May 24 19:52:22 2007 From: franz at fholzinger.com (Franz Holzinger) Date: Thu, 24 May 2007 19:52:22 +0200 Subject: [TYPO3-irre] Create new relation does nothing In-Reply-To: References: Message-ID: Hello Oliver, >> I am using the almost the same as described in "Bidirectional asymmetric >> m:n relations" >> >> 'appearance' => Array ('collapseAll' => TRUE, 'useCombination' => TRUE), > > Is this the difference to the "bidi asym m:n relations" in the tutorial? > The combined mode has still some difficulties mentioned at > http://bugs.typo3.org/view.php?id=5514 > I am using the latest most current SVN trunk. Unfortunately I get rejections when applying the patch. Maybe it's because there are already some code changes inside. t3lib/class.t3lib_tcemain.php.rej --- 4424,4438 ---- if(is_array($valueArray)) { foreach($valueArray as $key => $value) { if(strpos($value, 'NEW') !== false) { + // Fetch the proper uid as integer for the NEW... id: + if ($type == 'group') { + $valueParts = t3lib_div::revExplode('_', $value, 2); + $valueParts[1] = $this->substNEWwithIDs[$valueParts[1]]; + $valueArray[$key] = implode('_', $valueParts); + } else { + $valueArray[$key] = $this->substNEWwithIDs[$value]; + } >> In TCE I see the select box with one entry already made before. And >> right of it the Link which never works. > > Maybe in this case you might want to try to patch at > http://bugs.typo3.org/view.php?id=5564 which was also committed to > TYPO3_4-1 and Trunk yesterday. Do you get a JavaScript error/warning? > I am using this already. There is no JavaScript error or warning. Only CSS: Avertissement : Propri?t? ? border-radius ? inconnue. D?claration abandonn?e. Fichier source : http://localhost/typo3/stylesheet.css Ligne : 187 I could apply this patch partly. Now there is a reaction on 'Create new relation' and it really creates a new record with some default settings which seem to be the same what has recently entered. >> this.data.unique is undefined. Then the selected is always set to false. >> Maybe the function setUniqueElement should have been called before? > > Yes, the selected property of the option of the selector is set to > false. Otherwise it would not be possible to create a relation to the > same object again - in case the no uniquness is required. > >> Under the select box there is also a link. 'Neu anlegen' the same in >> German now. This one works if clicked. Then a new relation can be entered. >> >> But how should the first 'create new relation' work? Should this be the >> place to select and modify a former entry or what? > > The "create new relation" wasn't yet translated to German - maybe it > should be called "import record" or "re-use record". The "Neu anlegen" > or "create new" is for a completely new record. Thanks for this info. I still wonder what the 'Create new relation' does. But maybe its because of the pach rejections. The select box always shows the first entry. But the second record is shown. If you could provide a patch against SVN I will test it and give you feedback. - Franz From oh at inpublica.de Thu May 24 20:54:55 2007 From: oh at inpublica.de (Oliver Hader) Date: Thu, 24 May 2007 20:54:55 +0200 Subject: [TYPO3-irre] Create new relation does nothing In-Reply-To: References: Message-ID: Hi Franz, Franz Holzinger schrieb: > Thanks for this info. I still wonder what the 'Create new relation' > does. But maybe its because of the pach rejections. > The select box always shows the first entry. But the second record is > shown. > If you could provide a patch against SVN I will test it and give you > feedback. I see, most of the patches are bugfixes for the 4.1 branch. I'll create patches for the SVN Trunk. The reason in TCEmain is, that there were several changes by Dmitry concerning workspaces and the patches have to be adjusted. olly -- Oliver Hader http://inpublica.de/ From mbarts at gmx.ch Fri May 25 23:22:27 2007 From: mbarts at gmx.ch (Martin Borer) Date: Fri, 25 May 2007 23:22:27 +0200 Subject: [TYPO3-irre] Localisation and IRRE Message-ID: Hi list, I've made a small extension, witch is IRRE based. It works very good! I like this feature. Great work! The Extension is a quiz. I have quiz records -> with 1:n "questions" -> with 1:n "answer possibilities". It's realy easy to create and edit the quiz. Now I want to have the possibility to translate a quiz. How could I do it? I saw that the localisation is on the wishlist... If there is no support for this prupose at the moment, I think i will implement it by adding 2 more tables (question and answer language overlay). The quiz woul'd be like this: quiz -> with 1:n "questions" -> with 1:n "Question Translations" and 1:n "answer possibilities" -> with 1:n "answer translations". Does make this sense? Or is there an easier way to translate my quiz? Greets Martin From franz at fholzinger.com Wed May 30 14:14:13 2007 From: franz at fholzinger.com (Franz Holzinger) Date: Wed, 30 May 2007 14:14:13 +0200 Subject: [TYPO3-irre] Localisation and IRRE In-Reply-To: References: Message-ID: Hello Martin, > Now I want to have the possibility to translate a quiz. How could I do it? I > saw that the localisation is on the wishlist... > If there is no support for this prupose at the moment, I think i will > implement it by adding 2 more tables (question and answer language overlay). I think this would be a very good solution. Or you could use a language translation CSV file or XML file. The latter would be easier for translators. They would not have to edit the records in the backend then. - Franz From franz at fholzinger.com Wed May 30 14:19:55 2007 From: franz at fholzinger.com (Franz Holzinger) Date: Wed, 30 May 2007 14:19:55 +0200 Subject: [TYPO3-irre] Attempt to modify record (''tablename:0) without permission. Message-ID: Hello, somehow an empty IRRE record has been left and the mm table filled with uid_first_table=0. This causes the error message in TCE upon saving. This comes from an empty record. I think there should be a check not to save an empty record and also not into the intermediate relation table. - Franz