From simonschaufi at jesus.de Wed Jan 2 02:05:18 2013 From: simonschaufi at jesus.de (Simon Schaufelberger (Schaufi)) Date: Wed, 02 Jan 2013 02:05:18 +0100 Subject: [TYPO3-dev] typoscript rendering: setting cookie and reading during runtime not working? Message-ID: happy and blessed new year! this is the first post in the new year ;) i thought i have some understanding about typoscript rendering but now i am really stuck. what i want is: set a cookie at typoscript runtime and read it later in a condition and render a different page output if its there. Problem: the condition is only true after reloading the page. Why is this code not doing what i want? in the userfunction i just call setCookie... page = PAGE [globalVar = _COOKIE|myCookie =] includeLibs.setCookie = fileadmin/setCookie.php page { 1 = USER 1 { userFunc = user_setCookie } } [end] [globalVar = _COOKIE|myCookie = 1] page { 2 = TEXT 2.value = cookie is there } [end] -- Regards, Schaufi From nicolas.forgerit at gmail.com Wed Jan 2 10:09:07 2013 From: nicolas.forgerit at gmail.com (Nicolas Forgerit) Date: Wed, 02 Jan 2013 10:09:07 +0100 Subject: [TYPO3-dev] typoscript rendering: setting cookie and reading during runtime not working? In-Reply-To: References: Message-ID: Hey Simon, On 2.1.13 2:05 AM, Simon Schaufelberger (Schaufi) wrote: > happy and blessed new year! this is the first post in the new year ;) All the best to you, too. Have a happy new year! > > i thought i have some understanding about typoscript rendering but now > i am really stuck. > > what i want is: set a cookie at typoscript runtime and read it later > in a condition and render a different page output if its there. > > Problem: the condition is only true after reloading the page. > As far as is understand, you want to persist some kind of state and render some output based on the aforementioned state within one page request/response cycle. This is not what client-side cookies are for; they persist client-side state across several request/response cycles. That is why your condition is true after reloading the page. What you're trying to achieve should be done with TS registers (i.e. server-side persistence). Cheerio, Nicolas Forgerit From Stephan.Schuler at netlogix.de Wed Jan 2 11:27:00 2013 From: Stephan.Schuler at netlogix.de (Stephan Schuler) Date: Wed, 2 Jan 2013 10:27:00 +0000 Subject: [TYPO3-dev] typoscript rendering: setting cookie and reading during runtime not working? In-Reply-To: References: Message-ID: Hey Simon. You are mixing different (and very distinct) phases of typo script parsing. The first thing: I didn't know if "globalVar _COOKIE" is supposed to work at all. Didn't try it, ever. Nice to see that it works :). Second thing: You cannot write a cookie by typo script rendering and read it by condition in the same click. At least not by pure typo script object calls. Typo script parsing basically looks like this: 1: Determine page id. 2: Fetch all typo script records for the page id, and fetch linked typo script records as well as files recursively. 3: Concatenate all records and files to one single string. 4: All conditions are parsed, which means not matching parts are skipped out. That's the part where your condition matches. 5: Now the remaining long typo script string is parsed as a whole, being transferred to from string to array structure 6: Here comes the execution of the array, which is the first part that touches your userFunc to set the cookie. I only mentioned logical steps of typo script parsing. There might be steps that are bound to each other or called inside another since it's an easy improvement. But as you can see, the condition stuff is done long before the execution is performed. Third thing: Like Nicolas said, you should not use client side storages such as cookies to determine a single rendering path. If you want to make different rendering steps (plugins, usually) work together, you could simply use a singleton object inside your PHP logic. You even don't need to put this into a cookie or session. If you simply want to make a single plugin store data that is fetched by another plugin later: A class extending t3lib_Singleton is just fine. Drop your data there and fetch it later. This object is destroyed when the TYPO3 process ends. If you want to let a plugin decide which overall output schema to use(say, one column for shoping basket, two columns with right-side adds for checkout-confirmation with the ability for editors to change this content by default content backend): Don't do it. Use different plugins on different pages. That's much more stable and much less confusing. Think about later debugging in case of some bugs. You don't want to have complexity here. Fourth thing: If you really want to make your typo script read and write a cookie within a single rendering cycle, there I currently see two different ways. 1: Use different userFuncs for that. This doesn't interact with condition, but it might work with the typo script "if" clause. http://typo3.org/documentation/document-library/core-documentation/doc_core_tsref/4.7.0/view/1/5/#id553579 2: Use a user defined condition which always returns "TRUE" but internally checks your cookie and writes it if necessary. http://typo3.org/documentation/document-library/core-documentation/doc_core_tsref/4.7.0/view/1/4/#id790103 Regards, Stephan. Stephan Schuler Web-Entwickler Telefon: +49 (911) 539909 - 0 E-Mail: Stephan.Schuler at netlogix.de Website: media.netlogix.de -- netlogix GmbH & Co. KG IT-Services | IT-Training | Media Andernacher Stra?e 53 | 90411 N?rnberg Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99 E-Mail: info at netlogix.de | Internet: http://www.netlogix.de netlogix GmbH & Co. KG ist eingetragen am Amtsgericht N?rnberg (HRA 13338) Pers?nlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634) Umsatzsteuer-Identifikationsnummer: DE 233472254 Gesch?ftsf?hrer: Stefan Buchta, Matthias Schmidt -----Urspr?ngliche Nachricht----- Von: typo3-dev-bounces at lists.typo3.org [mailto:typo3-dev-bounces at lists.typo3.org] Im Auftrag von Simon Schaufelberger (Schaufi) Gesendet: Mittwoch, 2. Januar 2013 02:05 An: typo3-dev at lists.typo3.org Betreff: [TYPO3-dev] typoscript rendering: setting cookie and reading during runtime not working? happy and blessed new year! this is the first post in the new year ;) i thought i have some understanding about typoscript rendering but now i am really stuck. what i want is: set a cooki e at typoscript runtime and read it later in a condition and render a different page output if its there. Problem: the condition is only true after reloading the page. Why is this code not doing what i want? in the userfunction i just call setCookie... page = PAGE [globalVar = _COOKIE|myCookie =] includeLibs.setCookie = fileadmin/setCookie.php page { 1 = USER 1 { userFunc = user_setCookie } } [end] [globalVar = _COOKIE|myCookie = 1] page { 2 = TEXT 2.value = cookie is there } [end] -- Regards, Schaufi _______________________________________________ TYPO3-dev mailing list TYPO3-dev at lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev call setCookie... page = PAGE [globalVar = _COOKIE|myCookie =] includeLibs.setCookie = fileadmin/setCookie.php page { 1 = USER 1 { userFunc = user_setCookie } } [end] [globalVar = _COOKIE|myCookie = 1] page { From simonschaufi at jesus.de Wed Jan 2 12:01:57 2013 From: simonschaufi at jesus.de (Simon Schaufelberger (Schaufi)) Date: Wed, 02 Jan 2013 12:01:57 +0100 Subject: [TYPO3-dev] typoscript rendering: setting cookie and reading during runtime not working? In-Reply-To: References: Message-ID: Hi Stephan thank you for taking so much time to reply me in such a clear way. > Nice to see that it works :) yes it really does! Yeah, i think my problem is that the condition is parsed before the execution of the userfunction. I really want client side storage, i just broke my complex logic down so that you can understand the important stuff without the rest. i want to use this snippet for a shop system and if a parameter/referrer or whatever is set at the very first time requesting the page, the cookie should be set and a different output (in my case google analytics code) will be rendered. i just need the ga code the very first time and not just the second hit ;) the simplest idea is to copy the different output rendering into the [globalVar = _COOKIE|myCookie =] part as well. I think this is the way how i will do it now. Regards, Schaufi Am 02.01.2013 11:27, schrieb Stephan Schuler: > Hey Simon. > > You are mixing different (and very distinct) phases of typo script parsing. > > The first thing: I didn't know if "globalVar _COOKIE" is supposed to work at all. Didn't try it, ever. Nice to see that it works :). > > Second thing: You cannot write a cookie by typo script rendering and read it by condition in the same click. At least not by pure typo script object calls. > > Typo script parsing basically looks like this: > 1: Determine page id. > 2: Fetch all typo script records for the page id, and fetch linked typo script records as well as files recursively. > 3: Concatenate all records and files to one single string. > 4: All conditions are parsed, which means not matching parts are skipped out. That's the part where your condition matches. > 5: Now the remaining long typo script string is parsed as a whole, being transferred to from string to array structure > 6: Here comes the execution of the array, which is the first part that touches your userFunc to set the cookie. > > I only mentioned logical steps of typo script parsing. There might be steps that are bound to each other or called inside another since it's an easy improvement. > But as you can see, the condition stuff is done long before the execution is performed. > > Third thing: Like Nicolas said, you should not use client side storages such as cookies to determine a single rendering path. > If you want to make different rendering steps (plugins, usually) work together, you could simply use a singleton object inside your PHP logic. You even don't need to put this into a cookie or session. If you simply want to make a single plugin store data that is fetched by another plugin later: A class extending t3lib_Singleton is just fine. Drop your data there and fetch it later. This object is destroyed when the TYPO3 process ends. > If you want to let a plugin decide which overall output schema to use(say, one column for shoping basket, two columns with right-side adds for checkout-confirmation with the ability for editors to change this content by default content backend): Don't do it. Use different plugins on different pages. That's much more stable and much less confusing. Think about later debugging in case of some bugs. You don't want to have complexity here. > > Fourth thing: If you really want to make your typo script read and write a cookie within a single rendering cycle, there I currently see two different ways. > 1: Use different userFuncs for that. This doesn't interact with condition, but it might work with the typo script "if" clause. > http://typo3.org/documentation/document-library/core-documentation/doc_core_tsref/4.7.0/view/1/5/#id553579 > > 2: Use a user defined condition which always returns "TRUE" but internally checks your cookie and writes it if necessary. > http://typo3.org/documentation/document-library/core-documentation/doc_core_tsref/4.7.0/view/1/4/#id790103 > > > Regards, > Stephan. > > > Stephan Schuler > Web-Entwickler > > Telefon: +49 (911) 539909 - 0 > E-Mail: Stephan.Schuler at netlogix.de > Website: media.netlogix.de > > > -- > netlogix GmbH & Co. KG > IT-Services | IT-Training | Media > Andernacher Stra?e 53 | 90411 N?rnberg > Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99 > E-Mail: info at netlogix.de | Internet: http://www.netlogix.de > > netlogix GmbH & Co. KG ist eingetragen am Amtsgericht N?rnberg (HRA 13338) > Pers?nlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634) > Umsatzsteuer-Identifikationsnummer: DE 233472254 > Gesch?ftsf?hrer: Stefan Buchta, Matthias Schmidt > > > > -----Urspr?ngliche Nachricht----- > Von: typo3-dev-bounces at lists.typo3.org [mailto:typo3-dev-bounces at lists.typo3.org] Im Auftrag von Simon Schaufelberger (Schaufi) > Gesendet: Mittwoch, 2. Januar 2013 02:05 > An: typo3-dev at lists.typo3.org > Betreff: [TYPO3-dev] typoscript rendering: setting cookie and reading during runtime not working? > > happy and blessed new year! this is the first post in the new year ;) > > i thought i have some understanding about typoscript rendering but now i am really stuck. > > what i want is: set a cooki e at typoscript runtime and read it later in a condition and render a different page output if its there. > > Problem: the condition is only true after reloading the page. > > Why is this code not doing what i want? > > in the userfunction i just call setCookie... > > page = PAGE > > [globalVar = _COOKIE|myCookie =] > includeLibs.setCookie = fileadmin/setCookie.php page { > 1 = USER > 1 { > userFunc = user_setCookie > } > } > [end] > > [globalVar = _COOKIE|myCookie = 1] > page { > 2 = TEXT > 2.value = cookie is there > } > [end] > -- > Regards, Schaufi > _______________________________________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev > call setCookie... > > page = PAGE > > [globalVar = _COOKIE|myCookie =] > includeLibs.setCookie = fileadmin/setCookie.php page { > 1 = USER > 1 { > userFunc = user_setCookie > } > } > [end] > > [globalVar = _COOKIE|myCookie = 1] > page { > From Stephan.Schuler at netlogix.de Wed Jan 2 12:41:35 2013 From: Stephan.Schuler at netlogix.de (Stephan Schuler) Date: Wed, 2 Jan 2013 11:41:35 +0000 Subject: [TYPO3-dev] typoscript rendering: setting cookie and reading during runtime not working? In-Reply-To: References: Message-ID: Hey Simon. If it's only for google analytics code: Why not simply write JavaScript that handles this? It's very easy to create static java script which is the very same on every page but fetches stuff like cookies and only adds google analytics based on such a condition completely on client side. If you create typo script based on condition, I'm not completely sure how this interacts with caching. I guess that this does not play nice with caching, because the cache identifier uses very view parameters (id, L, mp, chash and another one I currently can't remember). So if you create conditions that are based on "internal values", they most likely get cached once with the current values and don't create different output if they change unless the cache is cleared or the page or plugin is set to no-cache. And always think about clients that don't have cookies enabled. It's one thing to have an online shop which can't be used without java script. If you rely on your clients to have java script enabled: Fine. It's up to you to determine which amount of unsatisfied customers this will produce and if you can afford it. But it's a completely other thing if you create frontend output that relies on having cookies enabled and, additionally, is capable to render different output for google. It's very easy to create output that only a view (including google) clients will ever see. But as soon as google uses a single enhanced crawler instance which, compared to all the other google crawler instances, *can* understand cookies and detects that this one receives differently rendered output, you can easily get punished by google. Even if you didn't do it purposely. Regards, Stephan. Stephan Schuler Web-Entwickler Telefon: +49 (911) 539909 - 0 E-Mail: Stephan.Schuler at netlogix.de Website: media.netlogix.de -----Urspr?ngliche Nachricht----- Von: typo3-dev-bounces at lists.typo3.org [mailto:typo3-dev-bounces at lists.typo3.org] Im Auftrag von Simon Schaufelberger (Schaufi) Gesendet: Mittwoch, 2. Januar 2013 12:02 An: typo3-dev at lists.typo3.org Betreff: Re: [TYPO3-dev] typoscript rendering: setting cookie and reading during runtime not working? Hi Stephan thank you for taking so much time to reply me in such a clear way. > Nice to see that it works :) yes it really does! Yeah, i think my problem is that the condition is parsed before the execution of the userfunction. I really want client side storage, i just broke my complex logic down so that you can understand the important stuff without the rest. i want to use this snippet for a shop system and if a parameter/referrer or whatever is set at the very first time requesting the page, the cookie should be set and a different output (in my case google analytics code) will be rendered. i just need the ga code the very first time and not just the second hit ;) the simplest idea is to copy the different output rendering into the [globalVar = _COOKIE|myCookie =] part as well. I think this is the way how i will do it now. Regards, Schaufi Am 02.01.2013 11:27, schrieb Stephan Schuler: > Hey Simon. > > You are mixing different (and very distinct) phases of typo script parsing. > > The first thing: I didn't know if "globalVar _COOKIE" is supposed to work at all. Didn't try it, ever. Nice to see that it works :). > > Second thing: You cannot write a cookie by typo script rendering and read it by condition in the same click. At least not by pure typo script object calls. > > Typo script parsing basically looks like this: > 1: Determine page id. > 2: Fetch all typo script records for the page id, and fetch linked typo script records as well as files recursively. > 3: Concatenate all records and files to one single string. > 4: All conditions are parsed, which means not matching parts are skipped out. That's the part where your condition matches. > 5: Now the remaining long typo script string is parsed as a whole, > being transferred to from string to array structure > 6: Here comes the execution of the array, which is the first part that touches your userFunc to set the cookie. > > I only mentioned logical steps of typo script parsing. There might be steps that are bound to each other or called inside another since it's an easy improvement. > But as you can see, the condition stuff is done long before the execution is performed. > > Third thing: Like Nicolas said, you should not use client side storages such as cookies to determine a single rendering path. > If you want to make different rendering steps (plugins, usually) work together, you could simply use a singleton object inside your PHP logic. You even don't need to put this into a cookie or session. If you simply want to make a single plugin store data that is fetched by another plugin later: A class extending t3lib_Singleton is just fine. Drop your data there and fetch it later. This object is destroyed when the TYPO3 process ends. > If you want to let a plugin decide which overall output schema to use(say, one column for shoping basket, two columns with right-side adds for checkout-confirmation with the ability for editors to change this content by default content backend): Don't do it. Use different plugins on different pages. That's much more stable and much less confusing. Think about later debugging in case of some bugs. You don't want to have complexity here. > > Fourth thing: If you really want to make your typo script read and write a cookie within a single rendering cycle, there I currently see two different ways. > 1: Use different userFuncs for that. This doesn't interact with condition, but it might work with the typo script "if" clause. > > http://typo3.org/documentation/document-library/core-documentation/doc > _core_tsref/4.7.0/view/1/5/#id553579 > > 2: Use a user defined condition which always returns "TRUE" but internally checks your cookie and writes it if necessary. > > http://typo3.org/documentation/document-library/core-documentation/doc > _core_tsref/4.7.0/view/1/4/#id790103 > > > Regards, > Stephan. > > > Stephan Schuler > Web-Entwickler > > Telefon: +49 (911) 539909 - 0 > E-Mail: Stephan.Schuler at netlogix.de > Website: media.netlogix.de > > > -- > netlogix GmbH & Co. KG > IT-Services | IT-Training | Media > Andernacher Stra?e 53 | 90411 N?rnberg > Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99 > E-Mail: info at netlogix.de | Internet: http://www.netlogix.de > > netlogix GmbH & Co. KG ist eingetragen am Amtsgericht N?rnberg (HRA > 13338) Pers?nlich haftende Gesellschafterin: netlogix Verwaltungs GmbH > (HRB 20634) > Umsatzsteuer-Identifikationsnummer: DE 233472254 > Gesch?ftsf?hrer: Stefan Buchta, Matthias Schmidt > > > > -----Urspr?ngliche Nachricht----- > Von: typo3-dev-bounces at lists.typo3.org > [mailto:typo3-dev-bounces at lists.typo3.org] Im Auftrag von Simon > Schaufelberger (Schaufi) > Gesendet: Mittwoch, 2. Januar 2013 02:05 > An: typo3-dev at lists.typo3.org > Betreff: [TYPO3-dev] typoscript rendering: setting cookie and reading during runtime not working? > > happy and blessed new year! this is the first post in the new year ;) > > i thought i have some understanding about typoscript rendering but now i am really stuck. > > what i want is: set a cooki e at typoscript runtime and read it later in a condition and render a different page output if its there. > > Problem: the condition is only true after reloading the page. > > Why is this code not doing what i want? > > in the userfunction i just call setCookie... > > page = PAGE > > [globalVar = _COOKIE|myCookie =] > includeLibs.setCookie = fileadmin/setCookie.php page { > 1 = USER > 1 { > userFunc = user_setCookie > } > } > [end] > > [globalVar = _COOKIE|myCookie = 1] > page { > 2 = TEXT > 2.value = cookie is there > } > [end] > -- > Regards, Schaufi > _______________________________________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev > call setCookie... > > page = PAGE > > [globalVar = _COOKIE|myCookie =] > includeLibs.setCookie = fileadmin/setCookie.php page { > 1 = USER > 1 { > userFunc = user_setCookie > } > } > [end] > > [globalVar = _COOKIE|myCookie = 1] > page { > _______________________________________________ TYPO3-dev mailing list TYPO3-dev at lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev From simonschaufi at jesus.de Wed Jan 2 13:18:31 2013 From: simonschaufi at jesus.de (Simon Schaufelberger (Schaufi)) Date: Wed, 02 Jan 2013 13:18:31 +0100 Subject: [TYPO3-dev] typoscript rendering: setting cookie and reading during runtime not working? In-Reply-To: References: Message-ID: Thanx for pointing me to a completely javascript solution. i dont know yet how we handle the first set of the cookie but js may be the better solution since i think i can do everything with js: set the cookie based on get parameter/referrer and read it. Regards, Schaufi Am 02.01.2013 12:41, schrieb Stephan Schuler: > Hey Simon. > > If it's only for google analytics code: Why not simply write JavaScript that handles this? > It's very easy to create static java script which is the very same on every page but fetches stuff like cookies and only adds google analytics based on such a condition completely on client side. > > If you create typo script based on condition, I'm not completely sure how this interacts with caching. > > I guess that this does not play nice with caching, because the cache identifier uses very view parameters (id, L, mp, chash and another one I currently can't remember). So if you create conditions that are based on "internal values", they most likely get cached once with the current values and don't create different output if they change unless the cache is cleared or the page or plugin is set to no-cache. > > And always think about clients that don't have cookies enabled. It's one thing to have an online shop which can't be used without java script. If you rely on your clients to have java script enabled: Fine. It's up to you to determine which amount of unsatisfied customers this will produce and if you can afford it. > But it's a completely other thing if you create frontend output that relies on having cookies enabled and, additionally, is capable to render different output for google. It's very easy to create output that only a view (including google) clients will ever see. > But as soon as google uses a single enhanced crawler instance which, compared to all the other google crawler instances, *can* understand cookies and detects that this one receives differently rendered output, you can easily get punished by google. Even if you didn't do it purposely. > > Regards, > Stephan. > > > > Stephan Schuler > Web-Entwickler > > Telefon: +49 (911) 539909 - 0 > E-Mail: Stephan.Schuler at netlogix.de > Website: media.netlogix.de > -----Urspr?ngliche Nachricht----- > Von: typo3-dev-bounces at lists.typo3.org [mailto:typo3-dev-bounces at lists.typo3.org] Im Auftrag von Simon Schaufelberger (Schaufi) > Gesendet: Mittwoch, 2. Januar 2013 12:02 > An: typo3-dev at lists.typo3.org > Betreff: Re: [TYPO3-dev] typoscript rendering: setting cookie and reading during runtime not working? > > Hi Stephan > thank you for taking so much time to reply me in such a clear way. > >> Nice to see that it works :) > > yes it really does! > > Yeah, i think my problem is that the condition is parsed before the execution of the userfunction. > > I really want client side storage, i just broke my complex logic down so that you can understand the important stuff without the rest. > i want to use this snippet for a shop system and if a parameter/referrer or whatever is set at the very first time requesting the page, the cookie should be set and a different output (in my case google analytics > code) will be rendered. i just need the ga code the very first time and not just the second hit ;) > > the simplest idea is to copy the different output rendering into the [globalVar = _COOKIE|myCookie =] part as well. I think this is the way how i will do it now. > > Regards, Schaufi > > Am 02.01.2013 11:27, schrieb Stephan Schuler: >> Hey Simon. >> >> You are mixing different (and very distinct) phases of typo script parsing. >> >> The first thing: I didn't know if "globalVar _COOKIE" is supposed to work at all. Didn't try it, ever. Nice to see that it works :). >> >> Second thing: You cannot write a cookie by typo script rendering and read it by condition in the same click. At least not by pure typo script object calls. >> >> Typo script parsing basically looks like this: >> 1: Determine page id. >> 2: Fetch all typo script records for the page id, and fetch linked typo script records as well as files recursively. >> 3: Concatenate all records and files to one single string. >> 4: All conditions are parsed, which means not matching parts are skipped out. That's the part where your condition matches. >> 5: Now the remaining long typo script string is parsed as a whole, >> being transferred to from string to array structure >> 6: Here comes the execution of the array, which is the first part that touches your userFunc to set the cookie. >> >> I only mentioned logical steps of typo script parsing. There might be steps that are bound to each other or called inside another since it's an easy improvement. >> But as you can see, the condition stuff is done long before the execution is performed. >> >> Third thing: Like Nicolas said, you should not use client side storages such as cookies to determine a single rendering path. >> If you want to make different rendering steps (plugins, usually) work together, you could simply use a singleton object inside your PHP logic. You even don't need to put this into a cookie or session. If you simply want to make a single plugin store data that is fetched by another plugin later: A class extending t3lib_Singleton is just fine. Drop your data there and fetch it later. This object is destroyed when the TYPO3 process ends. >> If you want to let a plugin decide which overall output schema to use(say, one column for shoping basket, two columns with right-side adds for checkout-confirmation with the ability for editors to change this content by default content backend): Don't do it. Use different plugins on different pages. That's much more stable and much less confusing. Think about later debugging in case of some bugs. You don't want to have complexity here. >> >> Fourth thing: If you really want to make your typo script read and write a cookie within a single rendering cycle, there I currently see two different ways. >> 1: Use different userFuncs for that. This doesn't interact with condition, but it might work with the typo script "if" clause. >> >> http://typo3.org/documentation/document-library/core-documentation/doc >> _core_tsref/4.7.0/view/1/5/#id553579 >> >> 2: Use a user defined condition which always returns "TRUE" but internally checks your cookie and writes it if necessary. >> >> http://typo3.org/documentation/document-library/core-documentation/doc >> _core_tsref/4.7.0/view/1/4/#id790103 >> >> >> Regards, >> Stephan. >> >> >> Stephan Schuler >> Web-Entwickler >> >> Telefon: +49 (911) 539909 - 0 >> E-Mail: Stephan.Schuler at netlogix.de >> Website: media.netlogix.de >> >> >> -- >> netlogix GmbH & Co. KG >> IT-Services | IT-Training | Media >> Andernacher Stra?e 53 | 90411 N?rnberg >> Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99 >> E-Mail: info at netlogix.de | Internet: http://www.netlogix.de >> >> netlogix GmbH & Co. KG ist eingetragen am Amtsgericht N?rnberg (HRA >> 13338) Pers?nlich haftende Gesellschafterin: netlogix Verwaltungs GmbH >> (HRB 20634) >> Umsatzsteuer-Identifikationsnummer: DE 233472254 >> Gesch?ftsf?hrer: Stefan Buchta, Matthias Schmidt >> >> >> >> -----Urspr?ngliche Nachricht----- >> Von: typo3-dev-bounces at lists.typo3.org >> [mailto:typo3-dev-bounces at lists.typo3.org] Im Auftrag von Simon >> Schaufelberger (Schaufi) >> Gesendet: Mittwoch, 2. Januar 2013 02:05 >> An: typo3-dev at lists.typo3.org >> Betreff: [TYPO3-dev] typoscript rendering: setting cookie and reading during runtime not working? >> >> happy and blessed new year! this is the first post in the new year ;) >> >> i thought i have some understanding about typoscript rendering but now i am really stuck. >> >> what i want is: set a cooki e at typoscript runtime and read it later in a condition and render a different page output if its there. >> >> Problem: the condition is only true after reloading the page. >> >> Why is this code not doing what i want? >> >> in the userfunction i just call setCookie... >> >> page = PAGE >> >> [globalVar = _COOKIE|myCookie =] >> includeLibs.setCookie = fileadmin/setCookie.php page { >> 1 = USER >> 1 { >> userFunc = user_setCookie >> } >> } >> [end] >> >> [globalVar = _COOKIE|myCookie = 1] >> page { >> 2 = TEXT >> 2.value = cookie is there >> } >> [end] >> -- >> Regards, Schaufi >> _______________________________________________ >> TYPO3-dev mailing list >> TYPO3-dev at lists.typo3.org >> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev >> call setCookie... >> >> page = PAGE >> >> [globalVar = _COOKIE|myCookie =] >> includeLibs.setCookie = fileadmin/setCookie.php page { >> 1 = USER >> 1 { >> userFunc = user_setCookie >> } >> } >> [end] >> >> [globalVar = _COOKIE|myCookie = 1] >> page { >> > _______________________________________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev > From info at cybercraft.de Wed Jan 2 14:56:35 2013 From: info at cybercraft.de (JoH asenau) Date: Wed, 02 Jan 2013 14:56:35 +0100 Subject: [TYPO3-dev] Invitation Grid Elements 2.0 Code Sprint Message-ID: Hi folks. Since we managed to reach the goal for our crowd funded project at Startnext, the code sprint will start next weekend. http://www.startnext.de/en/typo3-grid-elements-2-0 We are going to have a warm up weekend followed by up to 7 days of paid coding up in the mountain of the Upper Harz in Clausthal-Zellerfeld. There are up to 9 places available and hotel rooms as well as the catering are already booked. So none of the developers has to take care of anything else but coding. Currently there are still 2 places available, so we are looking for you to join us between January 5th and January 13th. You can also join the team and get paid for coding even though you might not be able to attend the code sprint itself, since our deadline is January 31st. We are especially looking for people who are experienced with TCEmain and/or the list module. And we would really appreciate some people of the core team to join us, since we want to make sure that the stuff we want to create does not conflict with future TYPO3 versions. But other developers are welcome as well. Please join the team here: http://forge.typo3.org/projects/extension-gridelements2 and send your proposals dirtectly to Petra ph at cybercraft.de, since she does not follow the newsgroup threads. Hope to hear from you soon. Cheers 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 From tomas.havner at kansli.lth.se Fri Jan 4 12:20:33 2013 From: tomas.havner at kansli.lth.se (Tomas Havner) Date: Fri, 04 Jan 2013 12:20:33 +0100 Subject: [TYPO3-dev] alt_doc in iframe Message-ID: Hi, I'm trying to load alt-doc.php (in frontend) in an iframe. In this case to edit page properties. It works but I'm keep getting "TypeError: top.TS is undefined". Is it because I'm doing something wrong, or because it's just not possible. Is there a better way than using alt_doc? Thankful for any suggestions. Tomas From simonschaufi at jesus.de Fri Jan 4 13:52:48 2013 From: simonschaufi at jesus.de (Simon Schaufelberger (Schaufi)) Date: Fri, 04 Jan 2013 13:52:48 +0100 Subject: [TYPO3-dev] alt_doc in iframe In-Reply-To: References: Message-ID: top.* refers to the parent of the iframe which is a variable in backend.php which you dont have in your case. Regards, Schaufi Am 04.01.2013 12:20, schrieb Tomas Havner: > Hi, > > I'm trying to load alt-doc.php (in frontend) in an iframe. In this case > to edit page properties. It works but I'm keep getting "TypeError: > top.TS is undefined". Is it because I'm doing something wrong, or > because it's just not possible. Is there a better way than using alt_doc? > > Thankful for any suggestions. > > Tomas From tollepjaer at gmail.com Fri Jan 4 14:00:34 2013 From: tollepjaer at gmail.com (Mattias Nilsson) Date: Fri, 4 Jan 2013 14:00:34 +0100 Subject: [TYPO3-dev] alt_doc in iframe In-Reply-To: References: Message-ID: Hi Tomas, You can use the Advanced Frontend Editing ( https://forge.typo3.org/projects/typo3v4-feedit/repository/show/trunk) for this purpose. I am aware that it?s not truly perfect all the time, but if you get the latest code base from forge. I proves a lot more stable than before! Regards Mattias Nilsson On Fri, Jan 4, 2013 at 12:20 PM, Tomas Havner wrote: > Hi, > > I'm trying to load alt-doc.php (in frontend) in an iframe. In this case to > edit page properties. It works but I'm keep getting "TypeError: top.TS is > undefined". Is it because I'm doing something wrong, or because it's just > not possible. Is there a better way than using alt_doc? > > Thankful for any suggestions. > > Tomas > ______________________________**_________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-dev > From tomas.havner at kansli.lth.se Fri Jan 4 14:23:53 2013 From: tomas.havner at kansli.lth.se (Tomas Havner) Date: Fri, 04 Jan 2013 14:23:53 +0100 Subject: [TYPO3-dev] alt_doc in iframe In-Reply-To: References: Message-ID: Simon Schaufelberger (Schaufi) skrev 2013-01-04 13:52: > top.* refers to the parent of the iframe which is a variable in > backend.php which you dont have in your case. > > Regards, Schaufi > > Am 04.01.2013 12:20, schrieb Tomas Havner: >> Hi, >> >> I'm trying to load alt-doc.php (in frontend) in an iframe. In this case >> to edit page properties. It works but I'm keep getting "TypeError: >> top.TS is undefined". Is it because I'm doing something wrong, or >> because it's just not possible. Is there a better way than using >> alt_doc? >> >> Thankful for any suggestions. >> >> Tomas Thanks Schaufi, Is there a way to get around this? Regards Tomas From steffen.ritter at typo3.org Sat Jan 5 09:35:13 2013 From: steffen.ritter at typo3.org (Steffen Ritter) Date: Sat, 05 Jan 2013 09:35:13 +0100 Subject: [TYPO3-dev] alt_doc in iframe In-Reply-To: References: Message-ID: Am 04.01.2013 14:23, schrieb Tomas Havner: > Simon Schaufelberger (Schaufi) skrev 2013-01-04 13:52: >> top.* refers to the parent of the iframe which is a variable in >> backend.php which you dont have in your case. >> >> Regards, Schaufi >> >> Am 04.01.2013 12:20, schrieb Tomas Havner: >>> Hi, >>> >>> I'm trying to load alt-doc.php (in frontend) in an iframe. In this case >>> to edit page properties. It works but I'm keep getting "TypeError: >>> top.TS is undefined". Is it because I'm doing something wrong, or >>> because it's just not possible. Is there a better way than using >>> alt_doc? >>> >>> Thankful for any suggestions. >>> >>> Tomas > Thanks Schaufi, > > Is there a way to get around this? No -- Steffen Ritter Release Manager TYPO3 4.7 TYPO3 .... inspiring people to share! Get involved: http://typo3.org From simonschaufi at jesus.de Sun Jan 6 23:07:06 2013 From: simonschaufi at jesus.de (Simon Schaufelberger (Schaufi)) Date: Sun, 06 Jan 2013 23:07:06 +0100 Subject: [TYPO3-dev] Slow BE-Performance in 4.5 - doubled system calls? In-Reply-To: References: Message-ID: > a total of 2180 calls vs. > a total of 5002 calls what happened to the core that this number sooooooooo much increased??? Regards, Schaufi Am 18.12.2012 19:02, schrieb Roland Hager: > In 4.4 the request resulted in .... > ##################################### > a total of 2180 calls > 485 Read > 273 Write > 601 stat > 157 fstat > > "grep SELECT" got 255 hits. > > > In 4.5 the request resulted in ... > ################################### > a total of 5002 calls > 960 read > 506 write > 428 lstat > 546 fstat > > "grep SELECT" got 491 hits From tomas.havner at kansli.lth.se Tue Jan 8 10:08:08 2013 From: tomas.havner at kansli.lth.se (Tomas Havner) Date: Tue, 08 Jan 2013 10:08:08 +0100 Subject: [TYPO3-dev] alt_doc in iframe In-Reply-To: References: Message-ID: Tomas Havner skrev 2013-01-04 14:23: > Simon Schaufelberger (Schaufi) skrev 2013-01-04 13:52: >> top.* refers to the parent of the iframe which is a variable in >> backend.php which you dont have in your case. >> >> Regards, Schaufi >> >> Am 04.01.2013 12:20, schrieb Tomas Havner: >>> Hi, >>> >>> I'm trying to load alt-doc.php (in frontend) in an iframe. In this case >>> to edit page properties. It works but I'm keep getting "TypeError: >>> top.TS is undefined". Is it because I'm doing something wrong, or >>> because it's just not possible. Is there a better way than using >>> alt_doc? >>> >>> Thankful for any suggestions. >>> >>> Tomas > Thanks Schaufi, > > Is there a way to get around this? > > Regards > > Tomas The answer is simple (as always). You simply create your own object on the "mother page": var TS = new typoSetup(); function typoSetup() { this.uniqueID = ""; this.passwordDummy = "********"; this.PATH_typo3 = "tjo"; this.decimalSign = "."; } All taken from alt_doc.php. Regards Tomas From kraft at web-consulting.at Wed Jan 9 10:23:55 2013 From: kraft at web-consulting.at (Bernhard Kraft) Date: Wed, 09 Jan 2013 10:23:55 +0100 Subject: [TYPO3-dev] Fluid - or WATE Message-ID: Hello! If you wonder what WATE means: Why another templating engine. I would like to know what the reasons have been that for v6 and NEOS the decision has been made to create a complete new templating engine: Fluid. Just another thing one has to learn. I always wondered why they didn't use "smarty". Or recently I did a lot with XSLT and noticed it is quite not that difficult as it sometimes is said. In fact it is quite simple if one knows about XPath. So a better solution than having a complete new templating engine could have been to use XSLT files as templates and let the content get generated as XML. Then a simple call to some XSLT processor could make the step: XML --> XSLT --> XML/HTML/Text. greetings, Bernhard From christian.mueller at typo3.org Wed Jan 9 10:36:41 2013 From: christian.mueller at typo3.org (=?ISO-8859-1?Q?Christian_M=FCller?=) Date: Wed, 09 Jan 2013 10:36:41 +0100 Subject: [TYPO3-dev] Fluid - or WATE In-Reply-To: References: Message-ID: Hi, On 09/01/13 10:23, Bernhard Kraft wrote: > Hello! > > I would like to know what the reasons have been that for v6 and NEOS > the decision has been made to create a complete new templating engine: > Fluid. Just another thing one has to learn. This is not just for 6 and Neos, Fluid is quite old by now and was available in TYPO3 since quite some time along with Extbase. > > I always wondered why they didn't use "smarty". Or recently I did a > lot with XSLT and noticed it is quite not that difficult as it > sometimes is said. In fact it is quite simple if one knows about XPath. Smarty isn't that nice codewise (I have read that never versions nowadays are better...) other templating engines had other shortcomings... > > So a better solution than having a complete new templating engine > could have been to use XSLT files as templates and let the content get > generated as XML. Then a simple call to some XSLT processor could make > the step: XML --> XSLT --> XML/HTML/Text. I think this indirect approach would have been a challenge for many. A templating engine should allow non PHP frontend developers to work with it. And XML -> XSLT can get pretty complicated as well as first writing a desired markup and then creating a XSLT to get the result from some XML data set. I have worked with XSLT, Smarty and other templating engines and compared to them found Fluid to be a very straight forward and easy way to create templates. > > > greetings, > Bernhard Cheers, Christian From dmitry.dulepov at gmail.com Wed Jan 9 13:05:49 2013 From: dmitry.dulepov at gmail.com (Dmitry Dulepov) Date: Wed, 09 Jan 2013 16:05:49 +0400 Subject: [TYPO3-dev] Slow BE-Performance in 4.5 - doubled system calls? In-Reply-To: References: Message-ID: Hi! Kay Strobach wrote: > I just sumup the basic steps ;) ... Reminds me: http://www.dmitry-dulepov.com/2008/05/eight-performance-tips-for-your-typo3.html http://www.dmitry-dulepov.com/2009/03/cheap-ways-to-increase-performance-of.html > 8. disable .htaccess if possible and make all settings in > the .httpdconf files Did not give any improvement for me. Linux has a good FS cache now, those files are not really read from the disk. I use OpenSuSE. -- Dmitry Dulepov TYPO3 CMS core & security teams member Simplicity will save the world. From dmitry.dulepov at gmail.com Wed Jan 9 13:08:37 2013 From: dmitry.dulepov at gmail.com (Dmitry Dulepov) Date: Wed, 09 Jan 2013 16:08:37 +0400 Subject: [TYPO3-dev] Slow BE-Performance in 4.5 - doubled system calls? In-Reply-To: References: Message-ID: Hi! Roland Hager wrote: > - using mod_deflate This is a bad one actually. It compresses stuff each time, taking a lot of CPU. It caches nothing. It uses chunked encoding without content-length causing browsers to wait more than necessary. If you need compression, use either old mod_gzip or precompress files manually. That would give you a great speed boost. -- Dmitry Dulepov TYPO3 CMS core & security teams member Simplicity will save the world. From typo3 at ringerge.org Wed Jan 9 18:17:40 2013 From: typo3 at ringerge.org (Georg Ringer) Date: Wed, 09 Jan 2013 18:17:40 +0100 Subject: [TYPO3-dev] Fluid - or WATE In-Reply-To: References: Message-ID: Hi bernhard, kind of a bit late ;) Am 09.01.2013 10:23, schrieb Bernhard Kraft: > I would like to know what the reasons have been that for v6 and NEOS the > decision has been made to create a complete new templating engine: > Fluid. Just another thing one has to learn. there is not really much to learn, especially if you are already used other engines. > I always wondered why they didn't use "smarty". Or recently I did a lot > with XSLT and noticed it is quite not that difficult as it sometimes is > said. In fact it is quite simple if one knows about XPath. xpath is certainly not fun for HTML guys ;) Georg From roland.hager at tu-berlin.de Wed Jan 9 18:31:28 2013 From: roland.hager at tu-berlin.de (Roland Hager) Date: Wed, 09 Jan 2013 18:31:28 +0100 Subject: [TYPO3-dev] Slow BE-Performance in 4.5 - doubled system calls? In-Reply-To: References: Message-ID: Hi Kay, > reduced both loading times. > > I just sumup the basic steps ;) > Thanks for your list. Sadly most of the points where already checked or not relevant for us. So I kept seeking deeper ... First I logged all DB queries using slow query log and a long_query_time of 0. Analyzing them with pt-query-digest[1] results in a total execution time of 45ms for all 553 queries. So that should not be the problem. Round trip time between webserver and db-server is around 0.389ms and the throughput around 550MB/s But where's the bottleneck ??? Back to the webserver. I again straced the action "List view of a page" as follows: $ strace -p PIDs -o strace.log -tt -r That results in a pretty overview of all syscalls and the relative execution time. I then summed up some syscalls to see how much they take into account. $ grep poll strace.log | awk '{sum+=$2} END {print sum}' 1.61099 $ grep "stat(" strace.log | awk '{sum+=$2} END {print sum}' 0.46976 So 1.6 seconds are used for polls and nearly 0.5s for stats! OK we are using a network filesystem for both the core and the "fileadmin stuff" so we are used to not have the best performance here. But beside the increase of DB queries also the number of stats seems to increase more and more with each TYPO3 version. Thus increasing the impact for us more and more. stats using TYPO3 4.4: 758 stats using TYPO3 4.5: 3099 So now what about those poll syscalls? Well it seems that before every mysql_query() internally the mysql connection is polled for POLLIN|POLLPRI events. I'm not sure why but maybe it's just some kind of check to see if the server send some abortion signals. I have 553 poll calls which backs nearly the number of queries. 450 of them needed less than 1ms but 24 took more than 10ms. Those 24 poll calls alone took about 1s. Using TYPO3 4.4 I just have 1 poll call that took longer than 10ms. Actually I do not have a proper explanation for that. I already thought there might be a scheduling problem on our virtual servers. Well that's all I got so far. If anybody has further suggestions please tell me. Roland P.S. All numbers where measured as described in the first post. Same server, same Database content, clicking the same page in List view. [1] http://www.percona.com/doc/percona-toolkit/2.1/ From philipp.gampe at typo3.org Wed Jan 9 18:58:48 2013 From: philipp.gampe at typo3.org (Philipp Gampe) Date: Wed, 09 Jan 2013 18:58:48 +0100 Subject: [TYPO3-dev] Slow BE-Performance in 4.5 - doubled system calls? References: Message-ID: Hi Roland Hager, Roland Hager wrote: > Well that's all I got so far. If anybody has further suggestions please > tell me. Nice analysis! One think that came to my mind ... how big is your memory (RAM)? If it gets too low, then the filesystem cache is not so effective, because it caches less in that case. Looking at my current workstation: Mem:7761M used:1346M buffers:393M cache:1965M I guess about half of the memory should be free for the operating system. You should also investigate of using some kind of read cache (based on SSDs) could increase the performance of your network drives. But that higly depends on your system. Best regards -- Philipp Gampe ? PGP-Key 0AD96065 ? TYPO3 UG Bonn/K?ln Documentation ? linkvalidator TYPO3 .... inspiring people to share! From lorenz-typo3 at visol.ch Wed Jan 9 21:57:38 2013 From: lorenz-typo3 at visol.ch (Lorenz Ulrich) Date: Wed, 09 Jan 2013 21:57:38 +0100 Subject: [TYPO3-dev] Fluid - or WATE In-Reply-To: References: Message-ID: Hi Bernhard > If you wonder what WATE means: Why another templating engine. The explanations can be found here: http://de.slideshare.net/skurfuerst/schulung-fluid-templating Best regards, Lorenz Am 09.01.2013 10:23, schrieb Bernhard Kraft: From henrik.remove.this at urlund.com Thu Jan 10 08:35:45 2013 From: henrik.remove.this at urlund.com (Henrik Urlund) Date: Thu, 10 Jan 2013 08:35:45 +0100 Subject: [TYPO3-dev] TER link shows wrong extension Message-ID: Hey, Does anyone know why this link: http://typo3.org/extensions/repository/view/http301 Shows up with an extension with the key "menuclass" but http://typo3.org/extensions/repository/view/menuclass Shows up with the extension "http301". I visited the first link about an hour ago to check if documentation was updated correct, at that time everything work fine at that time. /Henrik From henrik.remove.this at urlund.com Thu Jan 10 08:55:31 2013 From: henrik.remove.this at urlund.com (Henrik Urlund) Date: Thu, 10 Jan 2013 08:55:31 +0100 Subject: [TYPO3-dev] TER link shows wrong extension References: Message-ID: And now it's all back to normal, weird stuff :) On 2013-01-10 07:35:45 +0000, Henrik Urlund said: > Hey, > > Does anyone know why this link: > > http://typo3.org/extensions/repository/view/http301 > Shows up with an extension with the key "menuclass" but > > http://typo3.org/extensions/repository/view/menuclass > Shows up with the extension "http301". > > I visited the first link about an hour ago to check if documentation > was updated correct, at that time everything work fine at that time. > > /Henrik From most.wanted at gmx.at Thu Jan 10 09:34:08 2013 From: most.wanted at gmx.at (Roland) Date: Thu, 10 Jan 2013 09:34:08 +0100 Subject: [TYPO3-dev] pageTSconfig: bug when using TCEFORM.tt_content.CType.keepItems & tt_content_defValues? Message-ID: hi everybody, can anybody reproduce this? i encountered this problem in a TYPO3 4.7.7 project (at the moment the most current 4.x TYPO3 - did/can not test it with TYPO3 6.0.0 at the moment). --- pageTSconfig --- ### only mycontentelement should be selectable TCEFORM.tt_content.CType.keepItems = mycontentelement ### add mycontentelment to the newContentElement wizard mod.wizards.newContentElement { wizardItems.common { elements { mycontentelement { title = My Content Element tt_content_defValues { CType = mycontentelement colPos = 1 } } } show := addToList(mycontentelement) } } --- /pageTSconfig --- the following only occurs, when "TCEFORM.tt_content.CType.keepItems" is used. otherwise everything works like a charm: if I set tt_content_defValues to both "CType" and "colPos" (or any other tt_content field like e.g. bodytext, etc.) the content element "mycontentelement" will no longer be displayed by the newContentElement wizard. the content element "mycontentelement" will only be displayed in the newContentElement wizard when only tt_content_defValues-"CType" is set, although tt_content_defValues should (according to the documentation) should be an array. if only "colPos" is set via tt_content_defValues "mycontentelement" is also NOT displayed in the newContentElement wizard. if someone can reproduce it i would open a ticket on forge.typo3.org kind regards roland From most.wanted at gmx.at Thu Jan 10 09:40:13 2013 From: most.wanted at gmx.at (Roland) Date: Thu, 10 Jan 2013 09:40:13 +0100 Subject: [TYPO3-dev] pageTSconfig: bug when using TCEFORM.tt_content.CType.keepItems & tt_content_defValues? In-Reply-To: References: Message-ID: "TCEFORM.tt_content.CType.removeItems" does not seem to have any negative effect! From henrik.remove.this at urlund.com Thu Jan 10 14:22:08 2013 From: henrik.remove.this at urlund.com (Henrik Urlund) Date: Thu, 10 Jan 2013 14:22:08 +0100 Subject: [TYPO3-dev] TER link shows wrong extension References: Message-ID: And now the bug is back ... something happens when a new version is submitted to TER. /Henrik From typo3 at naegler.net Thu Jan 10 15:51:33 2013 From: typo3 at naegler.net (=?iso-8859-1?Q?Frank_N=E4gler?=) Date: Thu, 10 Jan 2013 15:51:33 +0100 Subject: [TYPO3-dev] Upgrade from 4.5 to 4.7 Message-ID: Hi everbody, after upgrade some installations from 4.5 to 4.7 I have now trouble on my local environment. I am working on a mac with ZendServer (PHP 5.3.15 with Suhosin-Patch (cli) (built: Aug 24 2012 17:45:44)) After switching the source from 4.5.22 to 4.7.7 the browser shows me this error message: Fatal error: Declaration of t3lib_cache_frontend_PhpFrontend::set() must be compatible with that of t3lib_cache_frontend_Frontend::set() in typo3_src-4.7.7/t3lib/cache/frontend/class.t3lib_cache_frontend_phpfrontend.php on line 0 I use the same source folder (same copy) on other systems, and have no problems. Any Idea? _Frank From typo3 at kay-strobach.de Thu Jan 10 17:04:44 2013 From: typo3 at kay-strobach.de (Kay Strobach) Date: Thu, 10 Jan 2013 17:04:44 +0100 Subject: [TYPO3-dev] Upgrade from 4.5 to 4.7 In-Reply-To: References: Message-ID: Hi Frank, perhaps the source folder was corrupted during copy? Regards Kay Am 10.01.13 15:51, schrieb Frank N?gler: > Hi everbody, > after upgrade some installations from 4.5 to 4.7 I have now trouble on my local environment. > I am working on a mac with ZendServer (PHP 5.3.15 with Suhosin-Patch (cli) (built: Aug 24 2012 17:45:44)) > After switching the source from 4.5.22 to 4.7.7 the browser shows me this error message: > > Fatal error: Declaration of t3lib_cache_frontend_PhpFrontend::set() must be compatible with that of t3lib_cache_frontend_Frontend::set() in typo3_src-4.7.7/t3lib/cache/frontend/class.t3lib_cache_frontend_phpfrontend.php on line 0 > > I use the same source folder (same copy) on other systems, and have no problems. > > Any Idea? > > _Frank > > -- http://www.kay-strobach.de - Open Source Rocks TYPO3 .... inspiring people to share! Get involved: http://typo3.org Answer was useful - feel free to donate: - https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=KPM9NAV73VDF2 - https://flattr.com/profile/kaystrobach From typo3 at naegler.net Fri Jan 11 10:03:32 2013 From: typo3 at naegler.net (=?iso-8859-1?Q?Frank_N=E4gler?=) Date: Fri, 11 Jan 2013 10:03:32 +0100 Subject: [TYPO3-dev] Upgrade from 4.5 to 4.7 In-Reply-To: References: Message-ID: Hi Kay, thanks for your reply. I have downloaded a fresh source package, the problem is the same. I think this could be a bug in PHP!? I have no idea. the code looks good for me. The interface define: public function set($entryIdentifier, $data, array $tags = array(), $lifetime = NULL); The implementation in t3lib_cache_frontend_PhpFrontend: public function set($entryIdentifier, $sourceCode, array $tags = array(), $lifetime = NULL) { I think the name of the parameter ($data, $sourceCode) must not be the same, or? _Frank Am 10.01.2013 um 17:04 schrieb Kay Strobach : > Hi Frank, > > perhaps the source folder was corrupted during copy? > > Regards > Kay > > Am 10.01.13 15:51, schrieb Frank N?gler: >> Hi everbody, >> after upgrade some installations from 4.5 to 4.7 I have now trouble on my local environment. >> I am working on a mac with ZendServer (PHP 5.3.15 with Suhosin-Patch (cli) (built: Aug 24 2012 17:45:44)) >> After switching the source from 4.5.22 to 4.7.7 the browser shows me this error message: >> >> Fatal error: Declaration of t3lib_cache_frontend_PhpFrontend::set() must be compatible with that of t3lib_cache_frontend_Frontend::set() in typo3_src-4.7.7/t3lib/cache/frontend/class.t3lib_cache_frontend_phpfrontend.php on line 0 >> >> I use the same source folder (same copy) on other systems, and have no problems. >> >> Any Idea? >> >> _Frank >> >> > > > -- > http://www.kay-strobach.de - Open Source Rocks > > TYPO3 .... inspiring people to share! > Get involved: http://typo3.org > > Answer was useful - feel free to donate: > - > https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=KPM9NAV73VDF2 > - https://flattr.com/profile/kaystrobach > > _______________________________________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev From kraftb at think-open.at Fri Jan 11 16:08:40 2013 From: kraftb at think-open.at (Bernhard Kraft) Date: Fri, 11 Jan 2013 16:08:40 +0100 Subject: [TYPO3-dev] Fluid - or WATE In-Reply-To: References: Message-ID: Hello ! On 01/09/2013 10:36 AM, Christian M?ller wrote: > This is not just for 6 and Neos, Fluid is quite old by now and was > available in TYPO3 since quite some time along with Extbase. I know that fluid is around for some years now. I always just moarn about WATE. > Smarty isn't that nice codewise (I have read that never versions > nowadays are better...) other templating engines had other shortcomings... Recently I read Smarty is very fast compared to other engines... looking it up ... found it: http://umumble.com/blogs/php/249/ > I have worked with XSLT, Smarty and other templating engines and > compared to them found Fluid to be a very straight forward and easy way > to create templates. It's just that XSLT is some established standard. I moarned 3 years ago when fluid was to become the new templating engine and I moarn now. I suggested to contact the developers of Smarty and/or another templating engine to have their engine intergrated into TYPO3. It's like in a big family: I suggested a wedding. But it was rather decided to simply give birth to a new child. My objections are, that the parents (we TYPO3 developers) can't take care about all those childs. Some of them will have to hunger :( Believe me. I learned from my bunch of extensions. I can't support, update and fix bugs for all of them. Probably the developers of other templating engines have been contacted - they disagreed to a "marriage" and thus a new templating engine was created at shorthand at those times. Maybe those developers would have needed to have more time thinking about our suggestions. I could also compare it to the following: Someone is simply not fine with all the weird namespaces in v6 and decided to fork TYPO3. This is something Kasper never wanted. His speak was: A patch a day keeps the fork away. But hey: I guess sending in patches about "remove senseless namespacing" wont make me friends :( BTW: This discussion is in general more about recent ways in the TYPO3 development. Not about flow as the black sheep especially. I have been away from TYPO3 events for some while - I think I am also not entitled to have anything to decide about TYPO3 development. I am just ranting. Sorry ... greetings, Bernhard From kraftb at think-open.at Fri Jan 11 16:16:07 2013 From: kraftb at think-open.at (Bernhard Kraft) Date: Fri, 11 Jan 2013 16:16:07 +0100 Subject: [TYPO3-dev] Fluid - or WATE In-Reply-To: References: Message-ID: Hello Georg, On 01/09/2013 06:17 PM, Georg Ringer wrote: > there is not really much to learn, especially if you are already used > other engines. I know. The learning curve is quite more shallow than those of TYPO3 at all. I also know that neither you nor me are (good?) business man (currently?). But try to compare the following announcements: TYPO3 now features its own powerful and XML compliant templating system TYPO3 now uses the fast and well known Smarty templating engine greetings, Bernhard From kraftb at think-open.at Fri Jan 11 16:19:26 2013 From: kraftb at think-open.at (Bernhard Kraft) Date: Fri, 11 Jan 2013 16:19:26 +0100 Subject: [TYPO3-dev] Fluid - or WATE In-Reply-To: References: Message-ID: Hello ! On 01/11/2013 04:08 PM, Bernhard Kraft wrote: > It's like in a big family: I suggested a wedding. But it was rather > decided to simply give birth to a new child. My objections are, that the > parents (we TYPO3 developers) can't take care about all those childs. > Some of them will have to hunger :( Especially some classes like tslib_gifbuilder seem to linger around in some corner and yell for food :) Well. If I think about people in the third world this is not funny anymore. greetings, Bernhard From jigal.van.hemert at typo3.org Fri Jan 11 15:45:44 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Fri, 11 Jan 2013 15:45:44 +0100 Subject: [TYPO3-dev] Fluid - or WATE In-Reply-To: References: Message-ID: Hi, On 11-1-2013 16:08, Bernhard Kraft wrote: > I know that fluid is around for some years now. I always just moarn > about WATE. > >> Smarty isn't that nice codewise (I have read that never versions >> nowadays are better...) other templating engines had other shortcomings... > > Recently I read Smarty is very fast compared to other engines... looking > it up ... found it: > > http://umumble.com/blogs/php/249/ Funny, this compares Smarty with Twig. Twig is a template engine written by the authors of Symfony. The same question is of course true for Twig: why didn't they use / expand / improve Smarty? In general the answer is that at the moment you need a solution you look around for an existing solution which fits your needs. If nothing exists the easiest solution is to create your own. It's harder to fix, expand and improve existing products, especially if you want those improvements included in that product instead of forking it. -- Jigal van Hemert TYPO3 Core Team member TYPO3 .... inspiring people to share! Get involved: typo3.org From kraftb at think-open.at Fri Jan 11 18:24:47 2013 From: kraftb at think-open.at (Bernhard Kraft) Date: Fri, 11 Jan 2013 18:24:47 +0100 Subject: [TYPO3-dev] Fluid - or WATE In-Reply-To: References: Message-ID: Hello ! On 01/11/2013 03:45 PM, Jigal van Hemert wrote: > In general the answer is that at the moment you need a solution you look > around for an existing solution which fits your needs. If nothing exists > the easiest solution is to create your own. I think sometimes people think: "Hey. I want to have an CMS." Look at TYPO3 and notice that it doesn't fit their needs. Which is obviously wrong. TYPO3 fits any needs :) The just didn't have enought time to dig into TYPO3. Maybe the same is true for the problem of finding a template wife for TYPO3 ... Anyways ... I thin WIFE is some new cool acronym which surely can get used - may it be some new XML or Java technology or another TYPO3 content object. greetings, Bernhard From robertwildling at gmail.com Sat Jan 12 08:39:20 2013 From: robertwildling at gmail.com (Robert Wildling) Date: Sat, 12 Jan 2013 08:39:20 +0100 Subject: [TYPO3-dev] install tool "confirmation" page Message-ID: Hi, Dev Team, In the German list I posted my "observation" that the "confirmation" page of the "All configurations" menu won't list the changes any more after hitting the update button (and there is also one error: thumbnails - 2nd option from the top - won't update). My question: Why was that function removed? Which changes have been made to the install tool that made a removal necessary? Will it come back? This was a good and important feature, I really do not understand why it was removed and ask to reimplement it again. To do that I already posted a bug report on forge. Thank you! Robert From jigal.van.hemert at typo3.org Sat Jan 12 11:30:57 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Sat, 12 Jan 2013 11:30:57 +0100 Subject: [TYPO3-dev] install tool "confirmation" page In-Reply-To: References: Message-ID: Hi, On 12-1-2013 8:39, Robert Wildling wrote: > In the German list I posted my "observation" that the "confirmation" > page of the "All configurations" menu won't list the changes any more > after hitting the update button (and there is also one error: thumbnails > - 2nd option from the top - won't update). Can't reproduce the problem with the option. I can turn it on or off, no problem. > My question: > Why was that function removed? Which changes have been made to the > install tool that made a removal necessary? The configuration file is now completely regenerated when an option is changed. Previously only some lines were modified. The "All configuration" part is just a huge form and when saving it all the values in the form are saved in the new configuration and the configuration file is replaced with a fresh file. > Will it come back? If someone finds the time and motivation to add that feature. I personally don't find it very useful. I changed a setting and then it tells me which settings I've just changed. -- Jigal van Hemert TYPO3 Core Team member TYPO3 .... inspiring people to share! Get involved: typo3.org From rowild at gmx.net Sat Jan 12 13:51:09 2013 From: rowild at gmx.net (Robert Wildling) Date: Sat, 12 Jan 2013 13:51:09 +0100 Subject: [TYPO3-dev] install tool "confirmation" page In-Reply-To: References: Message-ID: Thanks for your response! >> In the German list I posted my "observation" that the "confirmation" >> page of the "All configurations" menu won't list the changes any more >> after hitting the update button (and there is also one error: thumbnails >> - 2nd option from the top - won't update). > > Can't reproduce the problem with the option. I can turn it on or off, no > problem. I forgot to mention that I have no ImageMagick installed on my local dev (MAMP 2.1). This might very well the reason for that as it already has been the source of many troubles in the past. (It is not to important to me at all, but I thought I mention it...) >> My question: >> Why was that function removed? Which changes have been made to the >> install tool that made a removal necessary? > > The configuration file is now completely regenerated when an option is > changed. Previously only some lines were modified. > > The "All configuration" part is just a huge form and when saving it all > the values in the form are saved in the new configuration and the > configuration file is replaced with a fresh file. > >> Will it come back? > > If someone finds the time and motivation to add that feature. I > personally don't find it very useful. I changed a setting and then it > tells me which settings I've just changed. ...which is good for many things (like documentation, as Kay mentiones at another place), not the least it could have become a place of error messages... However, with the confirmation page removed, I then need to ask: why is there a BLANK page showing instead?? That doesn't make sense at all! Wouldn't it be better to just reload the whole new form then? I yould not find any documentation on the removal of that functionality. Do you happen to have a webl link at hand or is there just nothing metioned anywhere? Thanks! Robert From jigal.van.hemert at typo3.org Sat Jan 12 14:57:17 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Sat, 12 Jan 2013 14:57:17 +0100 Subject: [TYPO3-dev] install tool "confirmation" page In-Reply-To: References: Message-ID: Hi, On 12-1-2013 13:51, Robert Wildling wrote: > However, with the confirmation page removed, I then need to ask: why is > there a BLANK page showing instead?? That doesn't make sense at all! > Wouldn't it be better to just reload the whole new form then? There shouldn't be a blank page. Just the list of modified items is no longer displayed. It should show: ---------------------------- About configuration: [ Writing configuration ] Click to continue... ---------------------------- A blank page usually indicates a fatal PHP error. Check your PHP error logs (or activate them first) for any fatal errors. -- Jigal van Hemert TYPO3 Core Team member TYPO3 .... inspiring people to share! Get involved: typo3.org From rowild at gmx.net Sat Jan 12 23:33:53 2013 From: rowild at gmx.net (Robert Wildling) Date: Sat, 12 Jan 2013 23:33:53 +0100 Subject: [TYPO3-dev] install tool "confirmation" page In-Reply-To: References: Message-ID: >> However, with the confirmation page removed, I then need to ask: why is >> there a BLANK page showing instead?? That doesn't make sense at all! >> Wouldn't it be better to just reload the whole new form then? > > There shouldn't be a blank page. Just the list of modified items is no > longer displayed. It should show: > ---------------------------- > About configuration: > > [ Writing configuration ] > > Click to continue... > ---------------------------- Yes, this is what I mean by blank page - sorry for being unclear! However, it is a page that is not needed. At the time, when that particular page shows, the configuration is already written, so it might as well be directed to the form again and maybe include a little information at the top indicating the conclusion of the changes - and maybe even any success/error messages. I know, it is a small little something, but I'd like to have the functionality back. So I wonder if there are more people out there and if so, if we could do something together to get it done - like voting for it on forge where there are some entries suggeting various improvements for the install tool... Thanks. Cheers, Robert From helmut.hummel at typo3.org Sun Jan 13 14:58:09 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Sun, 13 Jan 2013 14:58:09 +0100 Subject: [TYPO3-dev] Add JS file from extbase extension In-Reply-To: References: Message-ID: Hi, On 14.12.12 15:44, Tomi?? MILITARU wrote: > It's not cached ... I guess the initializeAction does not need to be in the > non-cacheable actions list of the plugin, right? What TYPO3 version are you using? If it is anything below 6.0 and your action is not cached, you will not be able to add anything with the pagerenderer.[1] You can only add JS or CSS stuff in the header using the Extbase API: $this->response->addAdditionalHeaderData(''); Kind regards, Helmut [1]http://forge.typo3.org/issues/22273 -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From stormbyte at gmail.com Mon Jan 14 11:37:46 2013 From: stormbyte at gmail.com (David Carlos Manuelda) Date: Mon, 14 Jan 2013 11:37:46 +0100 Subject: [TYPO3-dev] How to load specific tab when loading/reloading plugin page? Message-ID: Hi list, this is my first time submitting to the list, and I am not currently subscribed. I am coding an extension for typo3 and have a question I could not find, neither via google, neither via documentation, so this is my last intent to solve it. It is better explained in a question I posted on stackoverflow, but my problem is, when I add plugin content to a page, I want it to load the "Plugin" tab rather than the first tab, the same when a field changes and have reload property. More info and screenshots here: http://stackoverflow.com/questions/14284786/load-reload-specific-plugin-tab-in- typo3-add-plugin-page Any help will be really apreciated. CC me as I am not subscribed to the list, thank you! ------------------------------------------------------- From stormbyte at gmail.com Mon Jan 14 21:24:57 2013 From: stormbyte at gmail.com (David Carlos Manuelda) Date: Mon, 14 Jan 2013 21:24:57 +0100 Subject: [TYPO3-dev] onChange reload without confirmation? Message-ID: Is it possible to avoid the confirmation when BE is being reloaded when user changes that field? It is annoying have to click OK every time dynamic fields are changed. Thanks From typo3 at kay-strobach.de Tue Jan 15 07:30:58 2013 From: typo3 at kay-strobach.de (Kay Strobach) Date: Tue, 15 Jan 2013 07:30:58 +0100 Subject: [TYPO3-dev] onChange reload without confirmation? In-Reply-To: References: Message-ID: Am 14.01.13 21:24, schrieb David Carlos Manuelda: > Is it possible to avoid the confirmation when BE is being reloaded when user > changes that field? > > It is annoying have to click OK every time dynamic fields are changed. > > Thanks > Hi, in Windows a simple hit of [Enter] closes the dialogue, or you simply save before reload .. Regards Kay -- http://www.kay-strobach.de - Open Source Rocks TYPO3 .... inspiring people to share! Get involved: http://typo3.org Answer was useful - feel free to donate: - https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=KPM9NAV73VDF2 - https://flattr.com/profile/kaystrobach From christian.weiske at netresearch.de Tue Jan 15 09:02:32 2013 From: christian.weiske at netresearch.de (Christian Weiske) Date: Tue, 15 Jan 2013 09:02:32 +0100 Subject: [TYPO3-dev] 6.0 / deleting files the correct way Message-ID: Hello, TYPO3 6.0's file list module currently offers 2 ways to delete a file: 1. Use the context menu by clicking on the file icon and choosing "delete". This action removes the file from hard disk, but keeps the database record unchanged (it does not even mark it "deleted") 2. Click the edit icon and click the delete icon in the top bar then. This action sets the record to "deleted" and keeps the file on the harddisk. Neither of them looks completely correct to me, but I think that #2 is better because it allows to restore the file from trash. The only thing missing is moving the file to the recycler, if there is one. How should TYPO3 behave here? Because of the different implementations, our patch that adds the delete icon to the file list and implements #2 was rejected [1]. Also, our second patch that hides sys_file records marked as deleted was rejected by Helmut Hummel. In my eyes, having a file record marked as "deleted" is a valid case, and TYPO3 should support it by not showing it in the normal file list view. What do you think? [1] http://forge.typo3.org/issues/42294 Missing action button to delete a file [2] http://forge.typo3.org/issues/43216 Deleted files are indicated in list -- Regards/Mit freundlichen Gr??en Christian Weiske -= Geeking around in the name of science since 1982 =- From tomita.militaru at gmail.com Tue Jan 15 10:32:47 2013 From: tomita.militaru at gmail.com (=?UTF-8?B?VG9tacWjxIMgTUlMSVRBUlU=?=) Date: Tue, 15 Jan 2013 11:32:47 +0200 Subject: [TYPO3-dev] Add JS file from extbase extension In-Reply-To: References: Message-ID: On Sun, Jan 13, 2013 at 3:58 PM, Helmut Hummel wrote: > Hi, > > > On 14.12.12 15:44, Tomi?? MILITARU wrote: > > It's not cached ... I guess the initializeAction does not need to be in >> the >> non-cacheable actions list of the plugin, right? >> > > What TYPO3 version are you using? If it is anything below 6.0 and your > action is not cached, you will not be able to add anything with the > pagerenderer.[1] > TYPO3 4.6 > You can only add JS or CSS stuff in the header using the Extbase API: > > $this->response->**addAdditionalHeaderData(''); > Thanks for the tip! > > Kind regards, > Helmut > > > [1]http://forge.typo3.org/**issues/22273 > -- > Helmut Hummel > Release Manager TYPO3 6.0 > TYPO3 Core Developer, TYPO3 Security Team Member > > > TYPO3 .... inspiring people to share! > Get involved: typo3.org > > ______________________________**_________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-dev > -- Engr. Tomi?? MILITARU Certified TYPO3 Integrator Tel. +40741064681 From christian.zenker at 599media.de Tue Jan 15 10:59:15 2013 From: christian.zenker at 599media.de (Christian Zenker) Date: Tue, 15 Jan 2013 10:59:15 +0100 Subject: [TYPO3-dev] Fluid - or WATE References: Message-ID: Hi all. Just my thoughts on the topic even though they might be a little late: > I know that fluid is around for some years now. I always just moarn > about WATE. Right - I love to do that myself - or more generally on the NIH-Syndrom[1]. But I'll have to admit that at the time that decision was made, it was the correct one. That's almost 4 years ago! Smarty was nice from the endusers point, but with its function-based PHP4-compatible codebase it was as ugly as it could get and not at all suited for an object oriented, design pattern following Extbase or even Flow3. > I would like to know what the reasons have been that for v6 and NEOS the > decision has been made to create a complete new templating engine: Fluid. > Just another thing one has to learn. Nowadays I'd also say there are better templating engines than Fluid (at least the TYPO3 CMS version, I don't know about the TYPO3 Flow version). But here comes the good part: It's really easy to integrate your own templating engine into Extbase. I did this for fun with Twig during T3DD12 and it was really simple and straight forward. I wasn't aware that I did not publish it, so I did this now. [2] As said, I did this just for fun, but if anyone wants to join forces to push this project further contact me. So, if you prefer Smarty, just write a quick extension and use it! It's just some templating engine you push some variables to. Done. Maybe there even already is some extension like that out there. I really doubt that one could replace Fluid in either CMS or Flow. But there are lots of extensions out there that are/were defacto standard for some users regardless that they are not core extensions (like templavoila, fed, lib-div, phpunit, extdeveval, ?). So, no need to change the core to make a change. Greetings, Christian. [1] http://en.wikipedia.org/wiki/Not_invented_here [2] https://github.com/czenker/extbase_twig On Fri, 11 Jan 2013 16:08:40 +0100, Bernhard Kraft wrote: > Hello ! > > On 01/09/2013 10:36 AM, Christian M?ller wrote: > >> This is not just for 6 and Neos, Fluid is quite old by now and was >> available in TYPO3 since quite some time along with Extbase. > > I know that fluid is around for some years now. I always just moarn > about WATE. > >> Smarty isn't that nice codewise (I have read that never versions >> nowadays are better...) other templating engines had other >> shortcomings... > > Recently I read Smarty is very fast compared to other engines... looking > it up ... found it: > > http://umumble.com/blogs/php/249/ > > >> I have worked with XSLT, Smarty and other templating engines and >> compared to them found Fluid to be a very straight forward and easy way >> to create templates. > > It's just that XSLT is some established standard. I moarned 3 years ago > when fluid was to become the new templating engine and I moarn now. I > suggested to contact the developers of Smarty and/or another templating > engine to have their engine intergrated into TYPO3. > > It's like in a big family: I suggested a wedding. But it was rather > decided to simply give birth to a new child. My objections are, that the > parents (we TYPO3 developers) can't take care about all those childs. > Some of them will have to hunger :( > > > Believe me. I learned from my bunch of extensions. I can't support, > update and fix bugs for all of them. > > > Probably the developers of other templating engines have been contacted > - they disagreed to a "marriage" and thus a new templating engine was > created at shorthand at those times. Maybe those developers would have > needed to have more time thinking about our suggestions. > > I could also compare it to the following: Someone is simply not fine > with all the weird namespaces in v6 and decided to fork TYPO3. This is > something Kasper never wanted. His speak was: A patch a day keeps the > fork away. But hey: I guess sending in patches about "remove senseless > namespacing" wont make me friends :( > > > BTW: This discussion is in general more about recent ways in the TYPO3 > development. Not about flow as the black sheep especially. I have been > away from TYPO3 events for some while - I think I am also not entitled > to have anything to decide about TYPO3 development. I am just ranting. > > Sorry ... > > > > greetings, > Bernhard From philipp.gampe at typo3.org Tue Jan 15 16:23:15 2013 From: philipp.gampe at typo3.org (Philipp Gampe) Date: Tue, 15 Jan 2013 16:23:15 +0100 Subject: [TYPO3-dev] 6.0 / deleting files the correct way References: Message-ID: Hi Christian, Christian Weiske wrote: > In my eyes, having a file record marked > as "deleted" is a valid case, and TYPO3 should support it by not > showing it in the normal file list view. +1 Files should be marked as deleted, moved to trash after a few days of no references are left and be deleted by a second task after a longer period. Usual periods are 30 and 180 days (moved and deleted). IMHO this should be the default behavior. Direct delete (if no references are left) should be optional. It might also depend on the storage if a trash feature is supported. But the database records should always support delete. Best regards -- Philipp Gampe ? PGP-Key 0AD96065 ? TYPO3 UG Bonn/K?ln Documentation ? linkvalidator TYPO3 .... inspiring people to share! From most.wanted at gmx.at Tue Jan 15 17:01:40 2013 From: most.wanted at gmx.at (Roland) Date: Tue, 15 Jan 2013 17:01:40 +0100 Subject: [TYPO3-dev] PHP Warning in 6.0.1-dev if there are empty columns in Page Module Message-ID: Hi everybody, can anybody reproduce this PHP Warining in Page Module on current TYPO3 6.0.1-dev, when there are content columns without any content element: --- quote --- PHP Warning PHP Warning: Invalid argument supplied for foreach() in /srv/www/typo3/typo3_src-6.0.current.git/typo3/sysext/backend/Classes/View/PageLayoutView.php line 444 --- /quote --- kind regards roland From soren.malling at gmail.com Wed Jan 16 09:47:12 2013 From: soren.malling at gmail.com (=?ISO-8859-1?Q?S=F8ren_Malling?=) Date: Wed, 16 Jan 2013 09:47:12 +0100 Subject: [TYPO3-dev] Remove "defaultCategorizedTables" in favor of database field and TCA field Message-ID: Hi! I had a short look at using categories, but found out that the backend isn't ready-ready to use after installation. I found "defaultCategorizedTables" in the install tool but nowhere used in anycode. I suggest that we remove that install setting and instead provide the needed SQL and register the tables as categorizable as mentioned in the wiki http://wiki.typo3.org/TYPO3_6.0#Category Anything against this? Cheers, S?ren Malling Twitter: twitter.com/sorenmalling From typo3 at ringerge.org Wed Jan 16 09:51:18 2013 From: typo3 at ringerge.org (Georg Ringer) Date: Wed, 16 Jan 2013 09:51:18 +0100 Subject: [TYPO3-dev] Remove "defaultCategorizedTables" in favor of database field and TCA field In-Reply-To: References: Message-ID: Hi, +1 From tollepjaer at gmail.com Wed Jan 16 10:12:09 2013 From: tollepjaer at gmail.com (Mattias Nilsson) Date: Wed, 16 Jan 2013 10:12:09 +0100 Subject: [TYPO3-dev] Remove "defaultCategorizedTables" in favor of database field and TCA field In-Reply-To: References: Message-ID: S?ren, Take a look into this commit: https://review.typo3.org/#/c/12812/4 Maybe the functionality is already there? /Mattias On Wed, Jan 16, 2013 at 9:51 AM, Georg Ringer wrote: > Hi, > > +1 > _______________________________________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev > From soren.malling at gmail.com Wed Jan 16 11:47:05 2013 From: soren.malling at gmail.com (=?ISO-8859-1?Q?S=F8ren_Malling?=) Date: Wed, 16 Jan 2013 11:47:05 +0100 Subject: [TYPO3-dev] Remove "defaultCategorizedTables" in favor of database field and TCA field In-Reply-To: References: Message-ID: Hi Mattias, I'm stil missing the SQL part for tt_content and pages in that commit, right? There is no call to makeCategorizable on any sysext, which I would expect to have tt_content and pages being categorizable. The patch seems to make it legit to put the makeCategorizable call wherever you want to. S?ren Malling Twitter: twitter.com/sorenmalling On Wed, Jan 16, 2013 at 10:12 AM, Mattias Nilsson wrote: > S?ren, > > Take a look into this commit: https://review.typo3.org/#/c/12812/4 > > Maybe the functionality is already there? > > /Mattias > > > On Wed, Jan 16, 2013 at 9:51 AM, Georg Ringer wrote: > > > Hi, > > > > +1 > > _______________________________________________ > > TYPO3-dev mailing list > > TYPO3-dev at lists.typo3.org > > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev > > > _______________________________________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev > From adrien.crivelli at gmail.com Wed Jan 16 16:30:51 2013 From: adrien.crivelli at gmail.com (Adrien Crivelli) Date: Wed, 16 Jan 2013 16:30:51 +0100 Subject: [TYPO3-dev] Git commit for news 1.3.3 ? Message-ID: Hi all, Following recent vulnerability announcement, I try to update the extension "news" to 1.3.3. However I cannot find anything that looks even remotely similar to 1.3.3 in official git repository . I saw no branches and *no tags*. Also grep log --grep=1.3.3 did not yield anything useful as far as I know. I ended up "git bisect"ing manually but from what I understood it looks that news 1.3.3 is not available publicly in git repository (private branch ?). Can anybody confirm that situation ? Or better yet let me know what commit correspond to 1.3.3 ? TIA, Adrien From jigal.van.hemert at typo3.org Wed Jan 16 16:39:56 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Wed, 16 Jan 2013 16:39:56 +0100 Subject: [TYPO3-dev] Git commit for news 1.3.3 ? In-Reply-To: References: Message-ID: Hi, On 16-1-2013 16:30, Adrien Crivelli wrote: > Following recent vulnerability > announcement, > I try to update the extension "news" to 1.3.3. However I cannot find > anything that looks even remotely similar to 1.3.3 in official git > repository . I saw no > branches and *no tags*. Also grep log --grep=1.3.3 did not yield anything > useful as far as I know. It might be old fashioned, but 1.3.3 is available in TER and you can simply update using the Extension Manager. AFAIK the git master version is at least up-to-date and contains all the fixes from that security release. -- Jigal van Hemert TYPO3 Core Team member TYPO3 .... inspiring people to share! Get involved: typo3.org From adrien.crivelli at gmail.com Wed Jan 16 16:51:59 2013 From: adrien.crivelli at gmail.com (Adrien Crivelli) Date: Wed, 16 Jan 2013 16:51:59 +0100 Subject: [TYPO3-dev] Git commit for news 1.3.3 ? In-Reply-To: References: Message-ID: Thank for your quick reply. Master also contains incompatibility with my current environmental (TYPO3 4.5.22). So I only want to upgrade to 1.3.3 and not 1.4.0 if possible. Also I would like to avoid TER as much as possible, since I usually consider git/svn a much better source for up-to-date extensions. On 16 January 2013 16:39, Jigal van Hemert wrote: > Hi, > > > On 16-1-2013 16:30, Adrien Crivelli wrote: > >> Following recent vulnerability >> announcement> bulletins/typo3-extensions/**typo3-ext-sa-2013-001/ >> >, >> I try to update the extension "news" to 1.3.3. However I cannot find >> anything that looks even remotely similar to 1.3.3 in official git >> repository >. >> I saw no >> branches and *no tags*. Also grep log --grep=1.3.3 did not yield anything >> useful as far as I know. >> > > It might be old fashioned, but 1.3.3 is available in TER and you can > simply update using the Extension Manager. > AFAIK the git master version is at least up-to-date and contains all the > fixes from that security release. > > -- > Jigal van Hemert > TYPO3 Core Team member > > TYPO3 .... inspiring people to share! > Get involved: typo3.org > > ______________________________**_________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-dev > From typo3 at ringerge.org Wed Jan 16 16:51:20 2013 From: typo3 at ringerge.org (Georg Ringer) Date: Wed, 16 Jan 2013 16:51:20 +0100 Subject: [TYPO3-dev] Git commit for news 1.3.3 ? In-Reply-To: References: Message-ID: Hi, I have no 1-3 branch in git but applied the security fix too in git version but based on current master Georg From adrien.crivelli at gmail.com Wed Jan 16 17:03:45 2013 From: adrien.crivelli at gmail.com (Adrien Crivelli) Date: Wed, 16 Jan 2013 17:03:45 +0100 Subject: [TYPO3-dev] Git commit for news 1.3.3 ? In-Reply-To: References: Message-ID: Thank you for the confirmation. May I suggest for the future to use branches and/or tags to make our life simpler ? Tags are very easy to use and explicit enough in my opinion. Event though it would not solves the current situation. At least we could "see" that there is actually no 1.3.3 in git. On top of that, branches could be used to solve the current situation, but that imply more work on your part to maintain, so I totally understand if you think that's "too much". As a matter of fact I myself don't do it ;-) Cheers, Adrien PS: Oh, btw, if you feel like publishing 1.3.3 via git, that would be much appreciated On 16 January 2013 16:51, Georg Ringer wrote: > Hi, > > I have no 1-3 branch in git but applied the security fix too in git > version but based on current master > > Georg > _______________________________________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev > From typo3 at ringerge.org Thu Jan 17 10:21:03 2013 From: typo3 at ringerge.org (Georg Ringer) Date: Thu, 17 Jan 2013 10:21:03 +0100 Subject: [TYPO3-dev] Git commit for news 1.3.3 ? In-Reply-To: References: Message-ID: Hi, just as a notice: ter version has been automatically pushed to github with correct tags https://github.com/typo3-ter/news I try to improve my workflow too georg From adrien.crivelli at gmail.com Thu Jan 17 12:06:33 2013 From: adrien.crivelli at gmail.com (Adrien Crivelli) Date: Thu, 17 Jan 2013 12:06:33 +0100 Subject: [TYPO3-dev] Git commit for news 1.3.3 ? In-Reply-To: References: Message-ID: Oh, I didn't know about https://github.com/typo3-ter, that's interesting, thanks. So far I used https://github.com/TYPO3-Extensions which is a git mirror of some SVN repositories. Also to answer my original question, I would suggest to use commit http://git.typo3.org/TYPO3v4/Extensions/news.git/commit/315a06562c3eacdcbfb6ce386d87f974688d0500 to apply security patch on TYPO3 4.5 On 17 January 2013 10:21, Georg Ringer wrote: > Hi, > > just as a notice: > ter version has been automatically pushed to github with correct tags > https://github.com/typo3-ter/news > > I try to improve my workflow too > > georg > _______________________________________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev > From christian.weiske at netresearch.de Thu Jan 17 15:48:44 2013 From: christian.weiske at netresearch.de (Christian Weiske) Date: Thu, 17 Jan 2013 15:48:44 +0100 Subject: [TYPO3-dev] 6.0 / deleting files the correct way References: Message-ID: Hello all, > > In my eyes, having a file record marked > > as "deleted" is a valid case, and TYPO3 should support it by not > > showing it in the normal file list view. > Files should be marked as deleted, moved to trash after a few days of > no references are left and be deleted by a second task after a longer > period. > > IMHO this should be the default behavior. Direct delete (if no > references are left) should be optional. > It might also depend on the storage if a trash feature is supported. > But the database records should always support delete. Steffen Ritter now wrote the following in 42294[1]'s review: > The delete action should definitely delete the file in the file system > - if and only if no existing relations to the file are present. The > file list will always show all files present in file system and won't > show files which are only present in the database This goes away from the database, working directly on files. Should the deleted files be at least marked up as deleted, e.g. by striking them through? Shouldn't deleting the file also delete the record? How is trash handled in this case? [1] http://forge.typo3.org/issues/42294 -- Regards/Mit freundlichen Gr??en Christian Weiske -= Geeking around in the name of science since 1982 =- From jigal.van.hemert at typo3.org Thu Jan 17 16:15:26 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Thu, 17 Jan 2013 16:15:26 +0100 Subject: [TYPO3-dev] 6.0 / deleting files the correct way In-Reply-To: References: Message-ID: Hi, On 17-1-2013 15:48, Christian Weiske wrote: > Steffen Ritter now wrote the following in 42294[1]'s review: > >> The delete action should definitely delete the file in the file system >> - if and only if no existing relations to the file are present. The >> file list will always show all files present in file system and won't >> show files which are only present in the database > > This goes away from the database, working directly on files. > > Should the deleted files be at least marked up as deleted, e.g. by > striking them through? > > Shouldn't deleting the file also delete the record? > > How is trash handled in this case? And what about the recycler feature of the filelist in TYPO3 < 6.0 [1] ? [1] http://xavier.perseguers.ch/tutoriels/typo3/articles/trash-in-fileadmin.html -- Jigal van Hemert TYPO3 Core Team member TYPO3 .... inspiring people to share! Get involved: typo3.org From philipp.gampe at typo3.org Thu Jan 17 16:41:31 2013 From: philipp.gampe at typo3.org (Philipp Gampe) Date: Thu, 17 Jan 2013 16:41:31 +0100 Subject: [TYPO3-dev] 6.0 / deleting files the correct way References: Message-ID: Hi Jigal, Jigal van Hemert wrote: > And what about the recycler feature of the filelist in TYPO3 < 6.0 [1] That would be the logical implementation of a trash feature in the local file system. However this is the task of the driver and not the task of FAL or the interface. A final and unrecoverable delete is a no-go in a modern data management system. You always want to have a safety period (usually 30 days) where you can recover anything your editors have done. A direct and final delete should be optional and be not the default behavior. BTW: I think that deleted files should be shown as stroked through (if at all) in the file list module and physically deleted files with still existing records should be shown as stroked and grayed out. But this is up to the UX/UI Team. Best regards -- Philipp Gampe ? PGP-Key 0AD96065 ? TYPO3 UG Bonn/K?ln Documentation ? linkvalidator TYPO3 .... inspiring people to share! From woebchr at gmx.de Mon Jan 21 16:23:17 2013 From: woebchr at gmx.de (Christian Woebbeking) Date: Mon, 21 Jan 2013 16:23:17 +0100 Subject: [TYPO3-dev] Working as a developer instead of making documentation Message-ID: Hello, I opened a thread inside T3-about regarding motivation to work inside the T3- community as a developer or making documentation. http://lists.typo3.org/pipermail/typo3-about/2013-January/000024.html I would be happy if you give me some feedback there. Best regards Christian. From kraftb at think-open.at Mon Jan 21 22:51:43 2013 From: kraftb at think-open.at (Bernhard Kraft) Date: Mon, 21 Jan 2013 22:51:43 +0100 Subject: [TYPO3-dev] Fluid - or WATE In-Reply-To: References: Message-ID: Hi ! On 01/15/2013 10:59 AM, Christian Zenker wrote: > Right - I love to do that myself - or more generally on the NIH-Syndrom[1]. AFAIR I read this one some time ago and found it quite interesting as quite some "dont's" can be found in the TYPO3 project and most probably in every other large software project: http://en.wikipedia.org/wiki/Anti-pattern > But I'll have to admit that at the time that decision was made, [...] Hopefully they give alternate solutions a better chance next time :) greetings, Bernhard From kraft at web-consulting.at Wed Jan 23 09:11:57 2013 From: kraft at web-consulting.at (Bernhard Kraft) Date: Wed, 23 Jan 2013 09:11:57 +0100 Subject: [TYPO3-dev] Extension documentation in ReST format Message-ID: Hello ! I have a question about extension documentation. In there is a page about the Documentation Team [1] on which the following sentence can be found: [...] Change the infrastructure of the manuals from OpenOffice .sxw to ReST [...] On the other hand on a page about extension development [2] still the traditional SXW way is suggested. So I tought I'll be clever and directly create the extension manual in ReST format. Now I noticed it doesn't look nice to have a "Manual: Not available" shown on typo3.org TER. Of course I know all extension documentation is (was?) usually written using OpenOffice (LibreOffice now). So is the plan to also migrate extension documentation to ReST format or will those manuals stay in SWX format? greetings, Bernhard [1] http://wiki.typo3.org/DocumentationTeam [2] http://wiki.typo3.org/Extension_Development#Documentation From typo3 at ringerge.org Wed Jan 23 09:18:44 2013 From: typo3 at ringerge.org (Georg Ringer) Date: Wed, 23 Jan 2013 09:18:44 +0100 Subject: [TYPO3-dev] Extension documentation in ReST format In-Reply-To: References: Message-ID: Hi, also extensions should move to rest, however the TER is not really ready yet. E.g. my news extension has been moved already, see http://docs.typo3.org/typo3cms/extensions/news/ Georg From fsu-lists at cobweb.ch Wed Jan 23 09:56:38 2013 From: fsu-lists at cobweb.ch (=?ISO-8859-1?Q?Fran=E7ois_Suter?=) Date: Wed, 23 Jan 2013 09:56:38 +0100 Subject: [TYPO3-dev] Extension documentation in ReST format In-Reply-To: References: Message-ID: Hi Bernhard, > So is the plan to also migrate extension documentation to ReST format or > will those manuals stay in SWX format? Yes and no. The plan is to enable all extension authors who want it to use ReST. Normally, your documentation should appear here: http://docs.typo3.org/typo3cms/extensions/ but doesn't. I don't know why. Maybe it's just a question of time. Of course this page should be improved over time. But we also plan to keep supporting SXW, because some authors will not want to update and - most importantly - many extension authors are not around anymore to update all manuals. So we currently handle both, with some on the fly conversion for SXW-based manuals. Using ReST gives better control over the structure of the manual. Hope this helps you a bit. Cheers -- Francois Suter Cobweb Development Sarl - http://www.cobweb.ch From philipp.gampe at typo3.org Wed Jan 23 10:14:14 2013 From: philipp.gampe at typo3.org (Philipp Gampe) Date: Wed, 23 Jan 2013 10:14:14 +0100 Subject: [TYPO3-dev] Extension documentation in ReST format References: Message-ID: Hi Bernhard, Bernhard Kraft wrote: > So I tought I'll be clever and directly create the extension manual in > ReST format. Now I noticed it doesn't look nice to have a "Manual: Not > available" shown on typo3.org TER. Are you sure you put the documentation at Documentation/Index.rst? Otherwise please get in touch with Martin as he maintains the server. It will then appear at http://docs.typo3.org/typo3cms/extensions/ However it will not appear in TER right now, because this code still need adjustments. The best thing you can do is to add link the the extension description and the readme. Best regards -- Philipp Gampe ? PGP-Key 0AD96065 ? TYPO3 UG Bonn/K?ln Documentation ? linkvalidator TYPO3 .... inspiring people to share! From kraftb at think-open.at Fri Jan 25 11:54:04 2013 From: kraftb at think-open.at (Bernhard Kraft) Date: Fri, 25 Jan 2013 11:54:04 +0100 Subject: [TYPO3-dev] Extension documentation in ReST format In-Reply-To: References: Message-ID: Hello! On 01/23/2013 10:14 AM, Philipp Gampe wrote: > Are you sure you put the documentation at Documentation/Index.rst? Thanks. This was the information I was missing. I put the index document under "doc/source/index.rst" - somewhere it was suggested to have the ReST documentation in a directory named "source" (Maybe this is just the default as Spinx created it). But then I found some TYPO3 documentation ReST template (sorry, can't remember where) and maybe simply assumed it has to get put into the old way "doc" directory. Anyways: Could someone point me to a valid TYPO3 ReST extension manual template. Would be nice to check if it was the one I used (I work at 3 different PCs - so finding the one where I should look in Browser history is already a challenge) greetings, Bernhard From kraftb at think-open.at Fri Jan 25 11:58:00 2013 From: kraftb at think-open.at (Bernhard Kraft) Date: Fri, 25 Jan 2013 11:58:00 +0100 Subject: [TYPO3-dev] Extension documentation in ReST format In-Reply-To: References: Message-ID: Hello ! On 01/23/2013 09:18 AM, Georg Ringer wrote: > also extensions should move to rest, however the TER is not really ready > yet. E.g. my news extension has been moved already, see > http://docs.typo3.org/typo3cms/extensions/news/ I assumed I have to do something - not simply waiting for getting it rendered. Because when uploading a manual.sxw theres at least a message: Not rendered yet (or so). But Phillip already pointed me in the right direction: "Documentation/Index.rst" which is not the case for the extension I uploaded: http://typo3.org/extensions/repository/view/webcon_ftptransfer greetings, Bernhard From typo3 at ringerge.org Fri Jan 25 12:03:30 2013 From: typo3 at ringerge.org (Georg Ringer) Date: Fri, 25 Jan 2013 12:03:30 +0100 Subject: [TYPO3-dev] Extension documentation in ReST format In-Reply-To: References: Message-ID: Hi, Am 25.01.2013 11:54, schrieb Bernhard Kraft: > Anyways: Could someone point me to a valid TYPO3 ReST extension manual > template. Would be nice to check if it was the one I used (I work at 3 > different PCs - so finding the one where I should look in Browser > history is already a challenge) http://git.typo3.org/TYPO3v4/Extensions/news.git/tree/HEAD:/Documentation From philipp.gampe at typo3.org Fri Jan 25 12:13:14 2013 From: philipp.gampe at typo3.org (Philipp Gampe) Date: Fri, 25 Jan 2013 12:13:14 +0100 Subject: [TYPO3-dev] Extension documentation in ReST format References: Message-ID: Hi Bernhard, Bernhard Kraft wrote: > Anyways: Could someone point me to a valid TYPO3 ReST extension manual > template. Would be nice to check if it was the one I used (I work at 3 > different PCs - so finding the one where I should look in Browser > history is already a challenge) Best match: http://git.typo3.org/Documentation/TYPO3/Example/ExtensionManual.git Also have a look at the official documentation template, because last commit is newer. Take a look at Georg's documentation for his news extension, because he is in contect which Martin, the person that sets up the renderer on http://docs.typo3.org. Best regards -- Philipp Gampe ? PGP-Key 0AD96065 ? TYPO3 UG Bonn/K?ln Documentation ? linkvalidator TYPO3 .... inspiring people to share! From tomasnorre at gmail.com Fri Jan 25 15:06:36 2013 From: tomasnorre at gmail.com (Tomas Norre Mikkelsen) Date: Fri, 25 Jan 2013 15:06:36 +0100 Subject: [TYPO3-dev] EM - Autoupdate Extension Message-ID: Hi, I don't know whom or where to write this message, so if its the wrong place I hope you can point me into the right direction. We want to be able to keep our TYPO3 instances up to date, even better than already done. How about create a schedule-task for sysext EM (extension manager) that allow certain whitelisted extensions to be auto update when new updates available. This could be done in various ways, but I'm thinking something like this: Extensions like realurl, static_info_tables etc. is most likely to be updated without future issues/problems. If the developer can mark and extension as autoUpdateable, you as maintainer could accept or overrule this decission by a locale whitelisting of extensions. I don't know if there is any plans in the future for topics like this, or if the TYPO3 SURF project will take over in the future. But till the future kicks in, i think this could be a step forward to keeping TYPO3 instances up to date. Is my idea understandable and what do you think? -- Best Regards Tomas Norre Mikkelsen TYPO3 Profile: http://forge.typo3.org/users/4289 TYPO3 Developer @ netimage.dk Follow me at twitter.com/tomasnorre From dmitry.dulepov at gmail.com Fri Jan 25 15:27:07 2013 From: dmitry.dulepov at gmail.com (Dmitry Dulepov) Date: Fri, 25 Jan 2013 18:27:07 +0400 Subject: [TYPO3-dev] Fluid - or WATE In-Reply-To: References: Message-ID: Hi! Bernhard Kraft wrote: > NIH-Syndrom[1]. This is historical in TYPO3: own translation handling is another example. The main problem is that we often focus on secondary things instead of doing what we really need to do... -- Dmitry Dulepov TYPO3 CMS core & security teams member Simplicity will save the world. From philipp.gampe at typo3.org Fri Jan 25 15:37:21 2013 From: philipp.gampe at typo3.org (Philipp Gampe) Date: Fri, 25 Jan 2013 15:37:21 +0100 Subject: [TYPO3-dev] EM - Autoupdate Extension References: Message-ID: Hi Tomas, Tomas Norre Mikkelsen wrote: > Is my idea understandable and what do you think? I do not think this is a good idea. An extension might ship with an upgrade task or might even ship a breaking change which is noted in the notes. The best thing you can do is to get notified and then maybe autoupdate all of your websites. But automatic update of extensions will only work in rare situation. You can of course create an extension for that and share it on TER. Best regards -- Philipp Gampe ? PGP-Key 0AD96065 ? TYPO3 UG Bonn/K?ln Documentation ? linkvalidator TYPO3 .... inspiring people to share! From typo3 at kay-strobach.de Sat Jan 26 12:09:48 2013 From: typo3 at kay-strobach.de (Kay Strobach) Date: Sat, 26 Jan 2013 12:09:48 +0100 Subject: [TYPO3-dev] EM - Autoupdate Extension In-Reply-To: References: Message-ID: Hello Guys, I'm currently working on something similar for corepatch releases. Currently the extension just notifies about changes, lateron i hope updates will be possible :D http://forge.typo3.org/projects/show/extension-coreupdate Perhaps we can you forces :D Regards Kay Am 25.01.13 15:37, schrieb Philipp Gampe: > Hi Tomas, > > Tomas Norre Mikkelsen wrote: > >> Is my idea understandable and what do you think? > > I do not think this is a good idea. > > An extension might ship with an upgrade task or might even ship a breaking > change which is noted in the notes. > The best thing you can do is to get notified and then maybe autoupdate all > of your websites. > But automatic update of extensions will only work in rare situation. You can > of course create an extension for that and share it on TER. > > Best regards > -- http://www.kay-strobach.de - Open Source Rocks TYPO3 .... inspiring people to share! Get involved: http://typo3.org Answer was useful - feel free to donate: - https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=KPM9NAV73VDF2 - https://flattr.com/profile/kaystrobach From simonschaufi at jesus.de Sat Jan 26 14:46:49 2013 From: simonschaufi at jesus.de (Simon Schaufelberger (Schaufi)) Date: Sat, 26 Jan 2013 14:46:49 +0100 Subject: [TYPO3-dev] HTTP Header output on 404 page with domain redirect Message-ID: Hello dear community, i have a really strange problem that i never saw on any other hosting server so far. I have a domain example.com and redirect that to www.example.com in the backend with domain records. now when requesting a non existing page with example.com/notexisting then i get the following output above my normal typo3 page rendering output of my 404 page but when calling www.example.com/notexisting i don't get this output. can anybody tell me where this is coming from? PS: i still use PHP/5.2.17 on this server since its a domainfactory server and i cannot set another php version for the subdomains as there are still some websites that don't work properly with PHP 5.3... HTTP/1.1 200 OK Date: Sat, 26 Jan 2013 13:30:06 GMT Server: Apache/2.2.22 X-Powered-By: PHP/5.2.17 Set-Cookie: fe_typo_user=acfac12a8ef780923b6b5832ae6d9901; path=/ Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=utf-8 X-Pad: avoid browser bug page ... -- Regards, Schaufi From jigal.van.hemert at typo3.org Sat Jan 26 23:14:21 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Sat, 26 Jan 2013 23:14:21 +0100 Subject: [TYPO3-dev] EM - Autoupdate Extension In-Reply-To: References: Message-ID: Hi, Both for extensions and core updates we have seen situations in the past where automatic updates would not be the success you'd hope for. RealURL had an update which required multiple database compare actions to finally have the tables up-to-date. The core can have security updates which require manual actions. You can use extensions like caretaker to monitor multiple TYPO3 installations and get notifications if updates are needed. For core updates you can create scripts that do the download-unpack-change_symlink actions for several installations. -- Jigal van Hemert TYPO3 Core Team member TYPO3 .... inspiring people to share! Get involved: typo3.org From typo3ml at schams.net Sun Jan 27 01:27:25 2013 From: typo3ml at schams.net (Michael) Date: Sun, 27 Jan 2013 11:27:25 +1100 Subject: [TYPO3-dev] EM - Autoupdate Extension In-Reply-To: References: Message-ID: On 27/01/13 09:14, Jigal van Hemert wrote: > Both for extensions and core updates we have seen situations in the past > where automatic updates would not be the success you'd hope for. I agree with Phillip and Jigal. An "auto-update" functionality makes sense for a standardized system. TYPO3 is always customized: you can not predict how it has been configured, which extensions have been installed and if an extension or core update could clash with a specific version of another extension or configuration. Even if an extension developer would have the option to mark his/her extension as "autoUpdateable" - what does that mean? Update-able from which version? What's about new dependencies to other extensions, etc.? > You can use extensions like caretaker to monitor multiple TYPO3 > installations and get notifications if updates are needed. ...or use a monitoring system such as Nagios [1] and the ext:nagios for TYPO3 [2] which monitors much more than just the TYPO3 core and extensions but also the server, network, other services running on the server, etc. :-) > For core updates you can create scripts that do the > download-unpack-change_symlink actions for several installations. In fact, in most cases it's only executing a few commands on the command line, double-checking the backend ("DB compare" in the Install Tool) and maybe clearing the cache. Sometimes this also works for extension updates, but again: this is not predictable and I prefer spending 5 to 10 minutes in manually checking each site instead of receiving support requests from clients who complain about a broken TYPO3 instance. Cheers Michael [1] http://www.nagios.org [2] http://schams.net/nagios From tolleiv.nietsch at typo3.org Sun Jan 27 09:36:07 2013 From: tolleiv.nietsch at typo3.org (Tolleiv Nietsch) Date: Sun, 27 Jan 2013 09:36:07 +0100 Subject: [TYPO3-dev] Extension documentation in ReST format In-Reply-To: References: Message-ID: Hi, actually this assumption is imho wrong. THe documentation team has hardly managed to build up their services, but we (T3O-Team + Doc-Team) haven't been able to integrate both "services" properly by now. There hasn't been any kind of official announcement that ReST should be used for extensions. Once you start using it for your extension you'll break usability for typo3.org users, because nobody would be able to reach your documentation through the normal search etc... So please be a bit patient with that and don't announce such things. Cheers. Georg Ringer schrieb: > Hi, > > also extensions should move to rest, however the TER is not really ready > yet. E.g. my news extension has been moved already, see > http://docs.typo3.org/typo3cms/extensions/news/ > > Georg -- Tolleiv Nietsch TYPO3 Core Developer TYPO3 .... inspiring people to share! Get involved: typo3.org From fsu-lists at cobweb.ch Sun Jan 27 15:07:27 2013 From: fsu-lists at cobweb.ch (=?ISO-8859-1?Q?Fran=E7ois_Suter?=) Date: Sun, 27 Jan 2013 15:07:27 +0100 Subject: [TYPO3-dev] Extension documentation in ReST format In-Reply-To: References: Message-ID: Hi Tolleiv, > actually this assumption is imho wrong. THe documentation team has > hardly managed to build up their services, but we (T3O-Team + Doc-Team) > haven't been able to integrate both "services" properly by now. There > hasn't been any kind of official announcement that ReST should be used > for extensions. Once you start using it for your extension you'll break > usability for typo3.org users, because nobody would be able to reach > your documentation through the normal search etc... Yes, that's right. I think this integration should be the aim of the next code sprint, so that extension authors can switch safely. Since we can also transform OpenOffice manuals to ReST (and then to HTML again), we have all extension manuals on docs.typo3.org. The most important next step IMO is to change the links from the TER to docs.typo3.org. Of course, this also means changing the detection of an existing manual. Indeed if there's neither an SXW file, nor ReST files, the documentation should be marked as missing, as is done now. An extra step, but one we are not ready for yet, would be to trigger the rendering of the manual when an extension is uploaded. We don't have the endpoint on docs.typo3.org yet and neither is the TER ready for it. We currently rely on a cron running on docs.typo3.org. But it's still a good sign that some developers start adopting REST I think, even if it may create an awkward situation for users. Hopefully it could help "bring back to the fold" developers who chose an entirely separate solution (for example, Claus Due, who has developed a lot of clever extensions, has included no documentation for the; it is all located on his own web site). It's clearly better than having no documentation, but it's also a shame that it exists outside the global scheme. Cheers -- Francois Suter Cobweb Development Sarl - http://www.cobweb.ch From fsu-lists at cobweb.ch Sun Jan 27 15:10:21 2013 From: fsu-lists at cobweb.ch (=?ISO-8859-1?Q?Fran=E7ois_Suter?=) Date: Sun, 27 Jan 2013 15:10:21 +0100 Subject: [TYPO3-dev] Extension documentation in ReST format In-Reply-To: References: Message-ID: Hi again, > But it's still a good sign that some developers start adopting REST I > think, even if it may create an awkward situation for users. Hopefully > it could help "bring back to the fold" developers who chose an entirely > separate solution (for example, Claus Due, who has developed a lot of > clever extensions, has included no documentation for the; it is all > located on his own web site). It's clearly better than having no > documentation, but it's also a shame that it exists outside the global > scheme. BTW Claus, if you read this, it is in no way meant as a criticism. I fully understand that working with OpenOffice is not only a pain but certainly did not allow you to do what you wanted with your documentation. I just hope that you might find ReST more inspiring ;-) Cheers -- Francois Suter Cobweb Development Sarl - http://www.cobweb.ch From typo3 at kay-strobach.de Sun Jan 27 15:45:36 2013 From: typo3 at kay-strobach.de (Kay Strobach) Date: Sun, 27 Jan 2013 15:45:36 +0100 Subject: [TYPO3-dev] EM - Autoupdate Extension In-Reply-To: References: Message-ID: Hello Together, coreupdate uses a scheduler task to check if the installed version matches the latest patch release! If not it creates a warning in the reports mail. The idea of the extension is to make the described change of the link with an easy to use interface (NOT automatically ;) No automatic updates are not good for big sites, but clickable updates can make things easier :D Regards Kay Am 27.01.13 01:27, schrieb Michael: > On 27/01/13 09:14, Jigal van Hemert wrote: > >> Both for extensions and core updates we have seen situations in the past >> where automatic updates would not be the success you'd hope for. > > I agree with Phillip and Jigal. An "auto-update" functionality makes > sense for a standardized system. TYPO3 is always customized: you can not > predict how it has been configured, which extensions have been installed > and if an extension or core update could clash with a specific version > of another extension or configuration. > > Even if an extension developer would have the option to mark his/her > extension as "autoUpdateable" - what does that mean? Update-able from > which version? What's about new dependencies to other extensions, etc.? > >> You can use extensions like caretaker to monitor multiple TYPO3 >> installations and get notifications if updates are needed. > > ...or use a monitoring system such as Nagios [1] and the ext:nagios for > TYPO3 [2] which monitors much more than just the TYPO3 core and > extensions but also the server, network, other services running on the > server, etc. :-) > >> For core updates you can create scripts that do the >> download-unpack-change_symlink actions for several installations. > > In fact, in most cases it's only executing a few commands on the command > line, double-checking the backend ("DB compare" in the Install Tool) and > maybe clearing the cache. Sometimes this also works for extension > updates, but again: this is not predictable and I prefer spending 5 to > 10 minutes in manually checking each site instead of receiving support > requests from clients who complain about a broken TYPO3 instance. > > > Cheers > Michael > > [1] http://www.nagios.org > [2] http://schams.net/nagios > -- http://www.kay-strobach.de - Open Source Rocks TYPO3 .... inspiring people to share! Get involved: http://typo3.org Answer was useful - feel free to donate: - https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=KPM9NAV73VDF2 - https://flattr.com/profile/kaystrobach From typo3 at ringerge.org Mon Jan 28 07:26:07 2013 From: typo3 at ringerge.org (Georg Ringer) Date: Mon, 28 Jan 2013 07:26:07 +0100 Subject: [TYPO3-dev] Extension documentation in ReST format In-Reply-To: References: Message-ID: Hi Tolleiv, sorry for my wrong assumptions georg From tomasnorre at gmail.com Mon Jan 28 08:21:34 2013 From: tomasnorre at gmail.com (Tomas Norre Mikkelsen) Date: Mon, 28 Jan 2013 08:21:34 +0100 Subject: [TYPO3-dev] EM - Autoupdate Extension In-Reply-To: References: Message-ID: On 01/26/2013 11:14 PM, Jigal van Hemert wrote: > Hi, > > Both for extensions and core updates we have seen situations in the past > where automatic updates would not be the success you'd hope for. > RealURL had an update which required multiple database compare actions > to finally have the tables up-to-date. > The core can have security updates which require manual actions. > > You can use extensions like caretaker to monitor multiple TYPO3 > installations and get notifications if updates are needed. I use caretaker, but when have both, development environment, Staging and production, I need a better way to push both file-changes (SVN/GIT etc), no problem and database-changes, this is what causes me the most troubles. > For core updates you can create scripts that do the > download-unpack-change_symlink actions for several installations. I Use Phing already for this purpose, and its very satisfying. -- Best Regards Tomas Norre Mikkelsen TYPO3 Profile: http://forge.typo3.org/users/4289 TYPO3 Developer @ netimage.dk Follow me at twitter.com/tomasnorre From benni at typo3.org Mon Jan 28 16:17:34 2013 From: benni at typo3.org (Benjamin Mack) Date: Mon, 28 Jan 2013 16:17:34 +0100 Subject: [TYPO3-dev] PHP Warning in 6.0.1-dev if there are empty columns in Page Module In-Reply-To: References: Message-ID: Hey, I got the same issue. A fix is on the way... I'll post the review.typo3.org link soon. All the best, Benni. On 15.01.13 17:01, Roland wrote: > Hi everybody, > > can anybody reproduce this PHP Warining in Page Module on current TYPO3 > 6.0.1-dev, when there are content columns without any content element: > > --- quote --- > PHP Warning > PHP Warning: Invalid argument supplied for foreach() in > /srv/www/typo3/typo3_src-6.0.current.git/typo3/sysext/backend/Classes/View/PageLayoutView.php > line 444 > --- /quote --- > > kind regards > > roland From k.szymukowicz at gmail.com Mon Jan 28 18:29:33 2013 From: k.szymukowicz at gmail.com (Krystian Szymukowicz) Date: Mon, 28 Jan 2013 18:29:33 +0100 Subject: [TYPO3-dev] phpStorm code formatting Message-ID: hi here we have some example of phpStorm formatting for TYPO3 http://wiki.typo3.org/File:Standard.xml Does someone use it? I am writing because it is strange for me that is set space intend instead of tab for PHP