From bart at samson-it.nl Tue Feb 1 17:35:46 2011 From: bart at samson-it.nl (Bart van den Burg) Date: Tue, 01 Feb 2011 17:35:46 +0100 Subject: [TYPO3-dev] meta data from plugin Message-ID: Hi, I wish to set meta description and meta keywords from within my plugin, but I don't quite understand how... In my main template setup i have the following two lines: page.meta.keywords.field = keywords page.meta.description.field = description These work fine, they fetch the values from whatever is configured for the page. Now I have a plugin from which i want to dynamically set these values. How do I do this? I tried $GLOBALS['TSFE']->page['meta.']['keywords.']['overwrite'], but it doesn't work... Thanks in advance, Regards, Bart From martin.weissen at me.com Tue Feb 1 17:57:47 2011 From: martin.weissen at me.com (Martin Weissen) Date: Tue, 01 Feb 2011 17:57:47 +0100 Subject: [TYPO3-dev] meta data from plugin In-Reply-To: References: Message-ID: Hi Bart > I wish to set meta description and meta keywords from within my plugin, but I don't quite understand how... > > In my main template setup i have the following two lines: > > page.meta.keywords.field = keywords > page.meta.description.field = description Have you tried to override these values in your extension? $GLOBALS['TSFE']->page['meta.']['keywords.'] = 'mykeyword1, mykeyword2'; Untested, but should work if you remove the lines from your setup. Cheers Martin From bart at samson-it.nl Wed Feb 2 09:17:38 2011 From: bart at samson-it.nl (Bart van den Burg) Date: Wed, 02 Feb 2011 09:17:38 +0100 Subject: [TYPO3-dev] meta data from plugin In-Reply-To: References: Message-ID: Op 1-2-2011 17:57, Martin Weissen schreef: > Hi Bart > >> I wish to set meta description and meta keywords from within my plugin, but I don't quite understand how... >> >> In my main template setup i have the following two lines: >> >> page.meta.keywords.field = keywords >> page.meta.description.field = description > Have you tried to override these values in your extension? > > $GLOBALS['TSFE']->page['meta.']['keywords.'] = 'mykeyword1, mykeyword2'; > > Untested, but should work if you remove the lines from your setup. > > > Cheers > Martin Doesn't work, unfortunately. Nothing appears in the HEAD section of the page... Regards, Bart From soren.malling at gmail.com Wed Feb 2 09:26:18 2011 From: soren.malling at gmail.com (=?ISO-8859-1?Q?S=F8ren_Malling?=) Date: Wed, 2 Feb 2011 09:26:18 +0100 Subject: [TYPO3-dev] meta data from plugin In-Reply-To: References: Message-ID: Hi Bart, Have a look at tt_news and how it sets the tag equals to the news entry. You should be able to reuse that in the case you want to :) Regards, S?ren Malling TYPO3 Brugergruppe Danmark: www.typo3danmark.dk Twitter: twitter.com/sorenmalling On Wed, Feb 2, 2011 at 9:17 AM, Bart van den Burg <bart at samson-it.nl> wrote: > Op 1-2-2011 17:57, Martin Weissen schreef: >> >> Hi Bart >> >>> I wish to set meta description and meta keywords from within my plugin, >>> but I don't quite understand how... >>> >>> In my main template setup i have the following two lines: >>> >>> page.meta.keywords.field = keywords >>> page.meta.description.field = description >> >> Have you tried to override these values in your extension? >> >> $GLOBALS['TSFE']->page['meta.']['keywords.'] = 'mykeyword1, mykeyword2'; >> >> Untested, but should work if you remove the lines from your setup. >> >> >> Cheers >> Martin > > Doesn't work, unfortunately. Nothing appears in the HEAD section of the > page... > > Regards, > Bart > _______________________________________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev > From jacob at lightbulb.dk Wed Feb 2 10:24:57 2011 From: jacob at lightbulb.dk (Jacob Rasmussen) Date: Wed, 02 Feb 2011 10:24:57 +0100 Subject: [TYPO3-dev] meta data from plugin In-Reply-To: <mailman.1.1296578326.23262.typo3-dev@lists.typo3.org> References: <mailman.1.1296578326.23262.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296638797.25058.typo3-dev@lists.typo3.org> Den 01/02/11 17.35, Bart van den Burg skrev: > I wish to set meta description and meta keywords from within my plugin, > but I don't quite understand how... > > In my main template setup i have the following two lines: > > page.meta.keywords.field = keywords > page.meta.description.field = description > > These work fine, they fetch the values from whatever is configured for > the page. Now I have a plugin from which i want to dynamically set these > values. How do I do this? > > I tried $GLOBALS['TSFE']->page['meta.']['keywords.']['overwrite'], but > it doesn't work... > Hi Bart, I had to do it through Typoscript instead of coding it directly in my plugin. The plugin has a list and single view mode on different pages - and on the single view page I added this to Typoscript setup: page.meta.description.cObject = RECORDS page.meta.description.cObject { source = {GPvar:tx_blnews_pi1|n} source.insertData = 1 tables = tx_blnews_items conf.tx_blnews_items > conf.tx_blnews_items = TEXT conf.tx_blnews_items { field = teaser } } ? Where tx_blnews_pi1|n is the identifier variable from the plugin. It is a bit annoying that I have to do more than one database lookup, but it's working at least :) -- Regards Jacob Rasmussen Certified TYPO3 Integrator From bart at samson-it.nl Wed Feb 2 13:36:46 2011 From: bart at samson-it.nl (Bart van den Burg) Date: Wed, 02 Feb 2011 13:36:46 +0100 Subject: [TYPO3-dev] meta data from plugin In-Reply-To: <mailman.1.1296638797.25058.typo3-dev@lists.typo3.org> References: <mailman.1.1296578326.23262.typo3-dev@lists.typo3.org> <mailman.1.1296638797.25058.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296650318.13101.typo3-dev@lists.typo3.org> Op 2-2-2011 10:24, Jacob Rasmussen schreef: > Den 01/02/11 17.35, Bart van den Burg skrev: >> I wish to set meta description and meta keywords from within my plugin, >> but I don't quite understand how... >> >> In my main template setup i have the following two lines: >> >> page.meta.keywords.field = keywords >> page.meta.description.field = description >> >> These work fine, they fetch the values from whatever is configured for >> the page. Now I have a plugin from which i want to dynamically set these >> values. How do I do this? >> >> I tried $GLOBALS['TSFE']->page['meta.']['keywords.']['overwrite'], but >> it doesn't work... >> > > Hi Bart, > > I had to do it through Typoscript instead of coding it directly in my > plugin. > > The plugin has a list and single view mode on different pages - and on > the single view page I added this to Typoscript setup: > > page.meta.description.cObject = RECORDS > page.meta.description.cObject { > source = {GPvar:tx_blnews_pi1|n} > source.insertData = 1 > tables = tx_blnews_items > conf.tx_blnews_items > > conf.tx_blnews_items = TEXT > conf.tx_blnews_items { > field = teaser > } > } > ? > Where tx_blnews_pi1|n is the identifier variable from the plugin. > It is a bit annoying that I have to do more than one database lookup, > but it's working at least :) > Hi, Thanks! It works like a charm. Regards, Bart From typo3.RemoveForMessage at elements-net.de Wed Feb 2 16:44:01 2011 From: typo3.RemoveForMessage at elements-net.de (Franz Koch) Date: Wed, 02 Feb 2011 16:44:01 +0100 Subject: [TYPO3-dev] 4.5: Backend layout selector In-Reply-To: <mailman.1.1296383485.22058.typo3-dev@lists.typo3.org> References: <mailman.1.1296383485.22058.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296661542.2075.typo3-dev@lists.typo3.org> Hey, > With the new backend layout selector (Gridview) you can assign icons to > the selector box. This is a great feature. But, when I don't assign > icons at all I do get the prepared links for them in the page > properties. Inluding the arrow icons for the selected one. This looks a > bit weird to me. > > Is this on purpose or should this be fixed? Or, use a default icon when > no icon is attached to a layout record? same here, but for all select fields having relations to other tables as it seems. Kinda sucks if you have a dropdown with hundreds of records - then you get a horizontal scrollbar due to hundreds of invisible icons below the selectbox. -- kind regards, Franz Koch From typo3.RemoveForMessage at elements-net.de Wed Feb 2 16:52:16 2011 From: typo3.RemoveForMessage at elements-net.de (Franz Koch) Date: Wed, 02 Feb 2011 16:52:16 +0100 Subject: [TYPO3-dev] 4.5: Backend layout selector In-Reply-To: <mailman.1.1296661542.2075.typo3-dev@lists.typo3.org> References: <mailman.1.1296383485.22058.typo3-dev@lists.typo3.org> <mailman.1.1296661542.2075.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296662036.2932.typo3-dev@lists.typo3.org> Hey again, > same here, but for all select fields having relations to other tables as > it seems. Kinda sucks if you have a dropdown with hundreds of records - > then you get a horizontal scrollbar due to hundreds of invisible icons > below the selectbox. ok - just found the 'suppress_icons' as well as the 'noIconsBelowSelect' setting for select fields. Never had to set them before, so I think there slipped a breaking change into 4.5. I nowhere provide any icons, nor have I configured anything to display those - and I think those should be hidden by default like in earlier versions. Does anybody know why that behavior might have changed? -- kind regards, Franz Koch From jacco at id-internetservices.com Wed Feb 2 17:23:45 2011 From: jacco at id-internetservices.com (Jacco van der Post) Date: Wed, 02 Feb 2011 17:23:45 +0100 Subject: [TYPO3-dev] LinkValidator In-Reply-To: <mailman.1.1296504491.20257.typo3-dev@lists.typo3.org> References: <mailman.1.1296140211.24730.typo3-dev@lists.typo3.org> <mailman.1.1296504491.20257.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296663924.5925.typo3-dev@lists.typo3.org> Hi Op 31-1-2011 21:08, Michael Miousse schreef: > Le Thu, 27 Jan 2011 15:55:17 +0100, Jacco van der Post a ?crit : > > Your tsconfig looks good to me. > > linkvalidator cant find any broken link on your site? > > Did you try with the checklink tab or with the scheduler task option?? > With the checklink tab. Has anybody succeeded in getting dead links from other tables than tt_content? -- Kind Regards Jacco van der Post From typo3.RemoveForMessage at elements-net.de Wed Feb 2 17:38:47 2011 From: typo3.RemoveForMessage at elements-net.de (Franz Koch) Date: Wed, 02 Feb 2011 17:38:47 +0100 Subject: [TYPO3-dev] pagetree in 4.5 always expands db-mounts - can this be prevented? Message-ID: <mailman.1.1296664827.7513.typo3-dev@lists.typo3.org> Hey guys, it seems that the new pagetree is always expanding the db-mounts set for a editor. Having only one or two db-mounts this might be a nice feature, but having multiple websites in one installation and having master editors that have up to 8 or 10 db-mounts assigned, this is anything else then userfriendly. Anybody else noticed this behavior? Is there a switch to turn that off? As I see it, the pagetree has to remember the last status of the pages, which is working for subpages, but not for DB-mounts. -- kind regards, Franz Koch From info at sk-typo3.de Wed Feb 2 18:36:42 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Wed, 02 Feb 2011 18:36:42 +0100 Subject: [TYPO3-dev] pagetree in 4.5 always expands db-mounts - can this be prevented? In-Reply-To: <mailman.1.1296664827.7513.typo3-dev@lists.typo3.org> References: <mailman.1.1296664827.7513.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296668304.12925.typo3-dev@lists.typo3.org> Hi, Am 02.02.2011 17:38, schrieb Franz Koch: > Hey guys, > > it seems that the new pagetree is always expanding the db-mounts set for > a editor. Having only one or two db-mounts this might be a nice feature, > but having multiple websites in one installation and having master > editors that have up to 8 or 10 db-mounts assigned, this is anything > else then userfriendly. > > Anybody else noticed this behavior? Is there a switch to turn that off? > As I see it, the pagetree has to remember the last status of the pages, > which is working for subpages, but not for DB-mounts. > i think this is not included, as root is always expanded. And mounts are "root" items. Please fill a BT entry. vg Steffen From ernst at cron-it.de Wed Feb 2 19:29:41 2011 From: ernst at cron-it.de (Ernesto Baschny [cron IT]) Date: Wed, 02 Feb 2011 19:29:41 +0100 Subject: [TYPO3-dev] Fwd: [TYPO3-v4] 4.5 and incompatible extensions Message-ID: <mailman.8967.1296671702.648.typo3-dev@lists.typo3.org> FYI, please use the original thread in the v4 list: -------- Original-Nachricht -------- Betreff: [TYPO3-v4] 4.5 and incompatible extensions Datum: Wed, 02 Feb 2011 19:29:03 +0100 Von: Ernesto Baschny [cron IT] <ernst at cron-it.de> Organisation: TYPO3 Association Newsgruppen: typo3.projects.v4 Hi, I would like to maintain a list of extensions which are known to be "broken" after the 4.5 upgrade. Usually this happens if an extension relies on XCLASSing some core class which was refactored during the 4.5 development. One case I just was made aware of is: * be_acl See #17437, also for an "hot fix". But maybe you know of others, so that we can see what we can do to: a) either find a solution in the extension itself, or b) maybe add some more backwards compatibility in 4.5, if something is clearly missing. We'll use this thread first to collect some information, and later bring that to the public through Wiki or some News (or 4.5.1 release notes). Thanks! Cheers, Ernesto [1] http://bugs.typo3.org/view.php?id=17437 From ernst at cron-it.de Wed Feb 2 19:46:56 2011 From: ernst at cron-it.de (Ernesto Baschny [cron IT]) Date: Wed, 02 Feb 2011 19:46:56 +0100 Subject: [TYPO3-dev] 4.5: Backend layout selector In-Reply-To: <mailman.1.1296662036.2932.typo3-dev@lists.typo3.org> References: <mailman.1.1296383485.22058.typo3-dev@lists.typo3.org> <mailman.1.1296661542.2075.typo3-dev@lists.typo3.org> <mailman.1.1296662036.2932.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296672516.19779.typo3-dev@lists.typo3.org> Franz Koch schrieb am 02.02.2011 16:52: > Hey again, > >> same here, but for all select fields having relations to other tables as >> it seems. Kinda sucks if you have a dropdown with hundreds of records - >> then you get a horizontal scrollbar due to hundreds of invisible icons >> below the selectbox. > > ok - just found the 'suppress_icons' as well as the 'noIconsBelowSelect' > setting for select fields. Never had to set them before, so I think > there slipped a breaking change into 4.5. I nowhere provide any icons, > nor have I configured anything to display those - and I think those > should be hidden by default like in earlier versions. > > Does anybody know why that behavior might have changed? Could you paste some sample TCA snippet (or a text extension) where we see this misbehaviour? Cheers, Ernesto From sgalinski at df.eu Wed Feb 2 19:53:47 2011 From: sgalinski at df.eu (Stefan Galinski) Date: Wed, 02 Feb 2011 19:53:47 +0100 Subject: [TYPO3-dev] pagetree in 4.5 always expands db-mounts - can this be prevented? References: <mailman.1.1296664827.7513.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296672926.21084.typo3-dev@lists.typo3.org> Franz Koch wrote: > Hey guys, > > it seems that the new pagetree is always expanding the db-mounts set for > a editor. Having only one or two db-mounts this might be a nice feature, > but having multiple websites in one installation and having master > editors that have up to 8 or 10 db-mounts assigned, this is anything > else then userfriendly. > > Anybody else noticed this behavior? Is there a switch to turn that off? > As I see it, the pagetree has to remember the last status of the pages, > which is working for subpages, but not for DB-mounts. > http://bugs.typo3.org/view.php?id=17457 -- Stefan Galinski staatl. gepr?fter Informatiktechniker From ernesto.baschny at typo3.org Wed Feb 2 21:41:58 2011 From: ernesto.baschny at typo3.org (Ernesto Baschny) Date: Wed, 02 Feb 2011 21:41:58 +0100 Subject: [TYPO3-dev] [TYPO3-v4] Minutes from the first meeting of the release team after 4.5.0 release Message-ID: <mailman.8973.1296679502.648.typo3-dev@lists.typo3.org> Hi, you thought you would get rid of my minutes just because 4.5.0 was released. Not quite yet! ;) After the very refreshing and enthusiastic welcome that the release 4.5.0 has been given by the community, we decided to meet again in our release team to discuss the first impressions. We feel that people no longer can live without our release meeting "minutes", so here we are... ;) Present were: Olly Hader (core team leader), Ben van't Ende (community manager), Steffen Kamper (4.5 technical leader) and Ernesto Baschny (4.5 release manager). ----------------------------------------------------------------------- General feeling after the release ----------------------------------------------------------------------- The days after the 4.5.0 have been characterized by: * lack of core activity (everybody exhausted after that last sprints, slowly warming up again) * great activity through Twitter & Co spreading the word about the release * many positive feedback, plenty of articles in blogs / news sites about 4.5 LTS Ernesto feels that the main reasons for so much enthusiasms (compared to previous releases) were: * Shipping at the planned date: We all had full concentration on *the day* of the release * More features compared to the previous version than ever before: Mainly due to more streamlined processes with teamworks, more regular meetings, better information flow and coordination. * First ever "LTS", bringing many people a special attention to this release, also the press and enthusiasts. Ernesto has been noticing plenty of "4.1 users" now upgrading to 4.5. TYPO3 4.1 has been a "de facto" LTS, supported by the core team for over 3 years. 4.5 is now the natural continuation, 6 months after 4.1's deprecation. ----------------------------------------------------------------------- Issues with 4.5.0 ----------------------------------------------------------------------- We then discussed the main issues reported and seen so far. Overall we can see a very mature and stable release already, plenty of production sites have been running 4.5 since the beta phase. So despite the several new features, the core functionality is very mature and stable. Nevertheless we are faced with some problems still to solve: ExtDirect -------------------------------------- One main problem are still ExtDirect issues. Since we are now using more and more ExtDirect, they are popping up more and more. E.g. the New Extension Manager makes lots of ExtDirect calls, and thus plenty of errors are related to this: * json "null" in Debug Console * Browser offering "ajax.php" to "Download" (instead of saving an extensions configuration) Most errors are browser specific and the reason is as usual with Ajax and a complex ExtJS stack difficult to spot. On the day before the release Steffen Kamper, Ernesto, Stefan Galinski and Helmut Hummel tried hard to solve it. Main issue was that some browsers (FF 4 beta, Opera, Safari) would split up the ExtDirect request in two different calls. Steffen feels that "something was fixed" but cannot recall exactly. He will further check and see if we can narrow down the source of it. Maybe bringing more ExtJS experts to debug that would help. stdWrapization, some things missing -------------------------------------- Some minor things were broken by the "stdWrap-everywhere" project, affecting Upgrades which relied on specific parts of TypoScript: * beforeWrap property of TMENU ("17297":http://bugs.typo3.org/view.php?id=17297) => Pending in core, by Joey. Also affecting the "GLUECK" template ("16756":http://bugs.typo3.org/view.php?id=16756) * LOAD_REGISTER misbehaviour with stdWrap depending on the order of properties ("17385":http://bugs.typo3.org/view.php?id=17385) => Fix available in tracker, by Joey * stdWrap .current and .setContentToCurrent do not return content ("17372":http://bugs.typo3.org/view.php?id=17372) => Fixed Pagetree "endless loop" -------------------------------------- The ExtJS Layout rendering has still some issues and is most noticeable in the Pagetree. Either the Pagetree was not loaded at all or the CPU went crazy (most annoying under IE6). So basically Steffen's patch for "17340":http://bugs.typo3.org/view.php?id=17340 (already ready to commit, will be in 4.5.1) solves this (also "17407":http://bugs.typo3.org/view.php?id=17407, the IE6 issue). Shifting up of backend problem -------------------------------------- We still have the unsolved problem that whenever a link in the backend points to a target with an anchor (e.g. the Constant Editor after saving some value), the whole content area will be shifted up by some 2-3 px. It seems to be an ExtJS issue with the panels. Steffen found the "typo3-content-container" has 2.5px too much and already tried hard spotting the problem together with Steffen Gebert. He even deactivated prototype, unloaded all skin CSS and the problem remained. We have tried to get ExtJS expert "Condor":http://www.sencha.com/forum/member.php?343-Condor to help out on that (a supporter from the ExtJS forums), but he hasn't given us any feedback yet. Steffen will ask some friend from Munich to take a look at it. Ernesto will ask Nils Dehl for help. ----------------------------------------------------------------------- TYPO3 4.5.1 ----------------------------------------------------------------------- Many people are already asking about "when will 4.5.1 will be released". We haven't had that many fixed included in our branch so we will have to wait for more activity / reports / fixes to be included. Since we will have a "TYPO3 Code Sprint in Berlin":http://wiki.typo3.org/Code_Sprint_Berlin_2011 from 28th February to 4th March, we decided to plan a 4.5.1 release for the week after that sprint, meaning: *4.5.1 planned for 9th of March* Sprints -------------------------------------- Apart from the Code Sprint in Berlin, Steffen Kamper plans a "Performance Sprint" (or maybe "Performance Day(s)") with Rupi Germann and maybe some other interested people at some days during February. No dates are settled but it will be properly announced so that others can participate in time. ----------------------------------------------------------------------- Upgrade Process ----------------------------------------------------------------------- Ernesto is collecting found issues around the "Upgrade Process" to get the Upgrade Wizard more streamlined in future (see "17353":http://bugs.typo3.org/view.php?id=17353). Those are tiny little improvements, which would even make sense to add to 4.5.x because we expect people to try upgrading to 4.5 from older sites on the next 2 years. Steffen mentioned the "Install Tool Refactoring" project, but Ernesto doesn't want to wait for that for these fixes. The Install Tool Refactoring is nevertheless an important project which will be a goal for 4.6. New Install Guide -------------------------------------- While talking about the Upgrade process, Steffen said that we have a "new Guide for Installing and Upgrading":http://typo3.org/documentation/document-library/installation/doc_guide_install/2.0.0/view/ online which is now linked at the "Installation" menu entry of the documentation section on typo3.org. So it hasn't got many attention yet, but its pretty good! ----------------------------------------------------------------------- Download statistics ----------------------------------------------------------------------- Since Olly is hosting the current TYPO3 Download (because of the SF troubles), he was able to make some statistics: * 4.5.0 has been downloaded about 25.000 times already (and it has been released only for one week!) * almost 1 TB of traffic * Half of the downloads were the Introduction Package (>13.000) SourceForge problems -------------------------------------- Sourceforge has had known troubles with hacking in the previous week (discovered exactly during our release day). See "SF blog":https://sourceforge.net/blog/ for more info on that. It seems to be getting back online. Olly will do further checks. At least our released files (RC2 and RC3) haven't been manipulated according to the MD5 checksums. RC3 was not available on all mirrors (thus many people got broken downloads). As soon as we confirm that everything is normal, Olly will upload our 4.5.0 files back to SF and change the links on the downloads page again. He will then also delete all alpha / beta / RC releases of 4.5. ----------------------------------------------------------------------- Translations ----------------------------------------------------------------------- People are wanting to "translate the introduction package" (see german translation list). Steffen asked on how to proceed here. Ben mentioned that its difficult as there is no workflow established yet. And the introduction package team very much disappeared and noone is really active anymore, except Peter Beernick. Ernesto suggested to maybe invite the interested german translator to be "part of the team" and maybe kick start more on that. The whole workflow should be supported by Issue Trackers so that pending issues can be better collected. Meanwhile the French translation efforts for the IP are at an unknown status. Ben will further check on that. Olly will respond to the question from Henning Nelihsen in the german translation list. ----------------------------------------------------------------------- TYPO3 4.6 ----------------------------------------------------------------------- h3. Teams for 4.6 * FAL will continue to make it a reality for 4.6. * Workspace team: was the most active team and will of course continue throughout 4.6. * Skinning team: had a nice start, but will need more "care". Steffen mentioned that not much was solved through that channel. Ernesto was satisfied with the split up we made (Design & Usability / Skin Team) and that the workflow has to be further refined. Currently the members also lack a bit of experience with dealing with core issues. So more meetings with the whole team would definitively help in keeping the members active and aware of the "next steps" and everyone motivated and all aiming at the same goal. * Linkvalidator: team is very motivated to continue development now that the extension is in core. They are also active throughout the lists responding to questions. * Extension Manager: We briefly discussed if it still makes sense to continue developing through Forge, because only Steffen K is working on it. We decided that it will be kept in forge until 4.5.1, and then everything will be merged back to the Core and issues will be further maintained via Mantis. Ernesto said that maybe we'll have the GIT / Gerrit migration "by then", but if this really happens, we just change the plan. :) Release Manager of 4.6 -------------------------------------- Olly mentioned a potential candidate for a release manager of 4.6. And we also discussed other candidates and some potential constellations. But we cannot announce it officially yet. ;) Goals in 4.6 -------------------------------------- We listed some potential "high level" goals for the 4.6 release: * Cleanup old legacy code, remove deprecated functionality * Performance optimization in frontend and backend * Better support for HA websites in clouds (e.g. CDN, static file cache layer, etc.) * Possibility of data exchange by using standards (CMIS, REST, SOAP) * Continous integration process with night builds * Better translation handling * Possible features * TCEforms refactoring * File Abstraction Layer ----------------------------------------------------------------------- Next steps ----------------------------------------------------------------------- We decided to keep our meeting routing active (Steffen misses a week without a meeting...) but will do it more sporadically. During the 4.6 release process Ernesto and Steffen agreed to keep on participating (as time permits) in the regular release meetings (just as Benni did in ours), supporting the new release manager. Ernesto mentioned that he won't have the time to write the minutes thou. :) We planned a next meeting in two weeks, on 14th of February, at 14h. The TYPO3 Code Sprint in Berlin will happen from 28th February to 4th March http://wiki.typo3.org/Code_Sprint_Berlin_2011 Cheers, Ernesto -- Ernesto Baschny Core Developer V4 Team Release Manager TYPO3 4.5 TYPO3 .... inspiring people to share! Get involved: typo3.org From typo3.RemoveForMessage at elements-net.de Thu Feb 3 10:06:51 2011 From: typo3.RemoveForMessage at elements-net.de (Franz Koch) Date: Thu, 03 Feb 2011 10:06:51 +0100 Subject: [TYPO3-dev] pagetree in 4.5 always expands db-mounts - can this be prevented? In-Reply-To: <mailman.1.1296672926.21084.typo3-dev@lists.typo3.org> References: <mailman.1.1296664827.7513.typo3-dev@lists.typo3.org> <mailman.1.1296672926.21084.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296724112.14681.typo3-dev@lists.typo3.org> Hey, > http://bugs.typo3.org/view.php?id=17457 thanks. -- kind regards, Franz Koch From typo3.RemoveForMessage at elements-net.de Thu Feb 3 11:16:44 2011 From: typo3.RemoveForMessage at elements-net.de (Franz Koch) Date: Thu, 03 Feb 2011 11:16:44 +0100 Subject: [TYPO3-dev] 4.5: Backend layout selector In-Reply-To: <mailman.1.1296672516.19779.typo3-dev@lists.typo3.org> References: <mailman.1.1296383485.22058.typo3-dev@lists.typo3.org> <mailman.1.1296661542.2075.typo3-dev@lists.typo3.org> <mailman.1.1296662036.2932.typo3-dev@lists.typo3.org> <mailman.1.1296672516.19779.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296728305.22166.typo3-dev@lists.typo3.org> Hey Ernesto, > Could you paste some sample TCA snippet (or a text extension) where we > see this misbehaviour? Here is a TCA example - nothing special though. 'type' => 'select', 'foreign_table' => 'some_table', 'size' => 1, 'minitems' => 1, 'items' => array( array('',''), ), Using a setup like this never showed any icons before. -- kind regards, Franz Koch From info at cybercraft.de Thu Feb 3 12:13:49 2011 From: info at cybercraft.de (JoH asenau) Date: Thu, 03 Feb 2011 12:13:49 +0100 Subject: [TYPO3-dev] 4.5: Backend layout selector In-Reply-To: <mailman.1.1296728305.22166.typo3-dev@lists.typo3.org> References: <mailman.1.1296383485.22058.typo3-dev@lists.typo3.org> <mailman.1.1296661542.2075.typo3-dev@lists.typo3.org> <mailman.1.1296662036.2932.typo3-dev@lists.typo3.org> <mailman.1.1296672516.19779.typo3-dev@lists.typo3.org> <mailman.1.1296728305.22166.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296731690.29374.typo3-dev@lists.typo3.org> Am 03.02.2011 11:16, schrieb Franz Koch: > Hey Ernesto, > >> Could you paste some sample TCA snippet (or a text extension) where we >> see this misbehaviour? > > Here is a TCA example - nothing special though. > > 'type' => 'select', > 'foreign_table' => 'some_table', > 'size' => 1, > 'minitems' => 1, > 'items' => array( > array('',''), > ), > > Using a setup like this never showed any icons before. Taking a look at the history of the class you will notice that suppress_icons has always been there and noIconsBelowSelect has been introduced to still remove them in case that icons will be used within the selectbox (like with doktypes). This means, even though you didn't notice it, the HTML output of the selicons has always been active unless suppress_icons and/or noIconsBelowSelect had been set to the correct value in the TCA setup. Currently noIconsBelowSelect is set for pages.doktype, pages.module, tt_content.CType and tt_content.list_type but suppress_icons is not used in any of the core TCA settings and AFAIR this has never been the case. Conclusion: The fact that you now see these icons below all the dropdown selectors is due to some CSS values changing the size of the "blind" HTML containers. Solutions: 1) Change the CSS setting so that it affects the content of these containers only - which is IMHO just a dirty hack that will remove the symptom but not the cause 2) Remove the cause by changing the way selicons are created, so that they will only create HTML output if there really are icons to choose from. The second solution will still leave the problem of handling a mixed case with only some items having icons. Any other suggestions? HTH 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 typo3.RemoveForMessage at elements-net.de Thu Feb 3 12:45:42 2011 From: typo3.RemoveForMessage at elements-net.de (Franz Koch) Date: Thu, 03 Feb 2011 12:45:42 +0100 Subject: [TYPO3-dev] 4.5: Backend layout selector In-Reply-To: <mailman.1.1296731690.29374.typo3-dev@lists.typo3.org> References: <mailman.1.1296383485.22058.typo3-dev@lists.typo3.org> <mailman.1.1296661542.2075.typo3-dev@lists.typo3.org> <mailman.1.1296662036.2932.typo3-dev@lists.typo3.org> <mailman.1.1296672516.19779.typo3-dev@lists.typo3.org> <mailman.1.1296728305.22166.typo3-dev@lists.typo3.org> <mailman.1.1296731690.29374.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296733642.658.typo3-dev@lists.typo3.org> Hey Joey, >>> Could you paste some sample TCA snippet (or a text extension) where we >>> see this misbehaviour? >> >> Here is a TCA example - nothing special though. >> >> 'type' => 'select', >> 'foreign_table' => 'some_table', >> 'size' => 1, >> 'minitems' => 1, >> 'items' => array( >> array('',''), >> ), >> >> Using a setup like this never showed any icons before. > > Taking a look at the history of the class you will notice that > suppress_icons has always been there and noIconsBelowSelect has been > introduced to still remove them in case that icons will be used within > the selectbox (like with doktypes). I don't doubt that those settings are around for quite a while, but I wonder why select fields not having a related foreign_table won't show up any icons whereas ones with foreign_table certainly do. Does it even make sense to automatically display icons for select fields getting their options filled by a foreign table? I suppose most relations won't need or have icons. So in my eyes it would make more sense to have icons disabled by default (at least for foreign table relations) and have a TCA option to explicitly enable them. Having negative switches isn't a good design anyway. For now I changed the 40 select fields of my extension to suppress the icons. -- kind regards, Franz Koch From rik at actiview.nl Fri Feb 4 10:53:48 2011 From: rik at actiview.nl (Rik Willems) Date: Fri, 04 Feb 2011 10:53:48 +0100 Subject: [TYPO3-dev] 4.5: Backend layout selector In-Reply-To: <mailman.1.1296731690.29374.typo3-dev@lists.typo3.org> References: <mailman.1.1296383485.22058.typo3-dev@lists.typo3.org> <mailman.1.1296661542.2075.typo3-dev@lists.typo3.org> <mailman.1.1296662036.2932.typo3-dev@lists.typo3.org> <mailman.1.1296672516.19779.typo3-dev@lists.typo3.org> <mailman.1.1296728305.22166.typo3-dev@lists.typo3.org> <mailman.1.1296731690.29374.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296813327.18819.typo3-dev@lists.typo3.org> Op 3-2-2011 12:13, JoH asenau schreef: > > Solutions: > 1) Change the CSS setting so that it affects the content of these > containers only - which is IMHO just a dirty hack that will remove the > symptom but not the cause > 2) Remove the cause by changing the way selicons are created, so that > they will only create HTML output if there really are icons to choose from. > > The second solution will still leave the problem of handling a mixed > case with only some items having icons. Solutions two looks to be the way to go. Without looking at the code as I can't seem to find it... Can't there be a check in the code to see if a icon was added? If true display right icons plus 'placeholders' for empty ones. If false don't output the icon code at all. Rik From tomasnorre at gmail.com Fri Feb 4 14:25:22 2011 From: tomasnorre at gmail.com (Tomas Norre Mikkelsen) Date: Fri, 04 Feb 2011 14:25:22 +0100 Subject: [TYPO3-dev] GIFBUILDER Problem after upgrade to 4.5 Message-ID: <mailman.1.1296826030.9609.typo3-dev@lists.typo3.org> Hi, I have just update a typo3-website, from 4.2.12 -> 4.5 ( I know large gap), after upgrade typo3_src and typo3-ext it almost works like a charm, except my Menu and Header build with GIFBUILDER. Any know issues on this topic that i'm not aware of? Tried to google but not much data indexed on the topic yet =) Any hints? /Tomas From thasmo at gmail.com Fri Feb 4 16:25:54 2011 From: thasmo at gmail.com (Thomas "Thasmo" Deinhamer) Date: Fri, 04 Feb 2011 16:25:54 +0100 Subject: [TYPO3-dev] TCA, set allowed files based on record type Message-ID: <mailman.1.1296833255.21829.typo3-dev@lists.typo3.org> Hi all! In the TCA of my table I got this field: 'files' => array( 'exclude' => 1, 'label' => 'Files', 'config' => array( 'type' => 'group', 'internal_type' => 'file', 'allowed' => 'gif,png,jpg,jpeg,webm,mp4,ogv,wav,mp3', 'max_size' => 1024, 'uploadfolder' => 'uploads/', 'size' => 3, 'autoSizeMax' => 10, 'minitems' => 0, 'maxitems' => 100, 'show_thumbs' => TRUE, ), ), which accepts all sorts of file types. Now I added a 'type' field to the table which lets me choose a media type: 'type' => array( 'exclude' => 1, 'label' => 'Type', 'config' => array( 'type' => 'select', 'default' => 'image', 'items' => array( array('Image', 'image'), array('Video', 'video'), array('Audio', 'audio'), ), ), ), For every media type a specific set of file types should be allowed for the 'files' field. I don't wanna add 3 different 'files' fields, one for every media type, but I'd like to rather dynamically change the 'allowed' definition when the type of the record is changed. Is there any chance of using some "simple" code inside the tca.php, or will I need to code a TCA "save hook"? Thanks a lot, Thomas From vsbies at wp.pl Fri Feb 4 18:34:44 2011 From: vsbies at wp.pl (Marcus 'biesior' Biesioroff) Date: Fri, 04 Feb 2011 18:34:44 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 Message-ID: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> ellou' Geeks I just realized that one of my small extensions (EXT:ogonki) is not working anymore in 4.5 it uses standard stdWrap hooks as described in German wiki: http://wiki.typo3.org/De:TSref/stdWrap#Anleitung:_Hook_f.C3.BCr_stdWrap_erstellen It was working before (at least in 4.3) so I have no idea either I missed something or I sholud write a new issue in BT. What is your opinion?? -- Marcus 'biesior' Biesioroff http://www.typo3.pl | TYPO3 Polish Community T3CI From jigal at xs4all.nl Fri Feb 4 20:16:19 2011 From: jigal at xs4all.nl (Jigal van Hemert) Date: Fri, 04 Feb 2011 20:16:19 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 In-Reply-To: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> References: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> Hi, On 4-2-2011 18:34, Marcus 'biesior' Biesioroff wrote: > I just realized that one of my small extensions (EXT:ogonki) is not > working anymore in 4.5 > > it uses standard stdWrap hooks as described in German wiki: > http://wiki.typo3.org/De:TSref/stdWrap#Anleitung:_Hook_f.C3.BCr_stdWrap_erstellen > > It was working before (at least in 4.3) so I have no idea either I > missed something or I sholud write a new issue in BT. Look in typo3/sysext/cms/tslib/class.tslib_content.php lines 577-591. In 4.5 your hook code has to implement the interface tslib_content_stdWrapHook (see typo3/sysext/cms/tslib/interfaces/interface.tslib_content_stdwraphook.php) In tslib_cObj::stdWrap_stdWrapPreProcess(), etc. you can find the calls to your hook object. This is the new way of making hooks in the core. HTH -- Kind regards / met vriendelijke groet, Jigal van Hemert skype:jigal.van.hemert msn: jigal at xs4all.nl http://twitter.com/jigalvh From jigal at xs4all.nl Fri Feb 4 21:29:23 2011 From: jigal at xs4all.nl (Jigal van Hemert) Date: Fri, 04 Feb 2011 21:29:23 +0100 Subject: [TYPO3-dev] GIFBUILDER Problem after upgrade to 4.5 In-Reply-To: <mailman.1.1296826030.9609.typo3-dev@lists.typo3.org> References: <mailman.1.1296826030.9609.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296851466.14938.typo3-dev@lists.typo3.org> Hi, On 4-2-2011 14:25, Tomas Norre Mikkelsen wrote: > I have just update a typo3-website, from 4.2.12 -> 4.5 ( I know large > gap), after upgrade typo3_src and typo3-ext it almost works like a > charm, except my Menu and Header build with GIFBUILDER. > > Any know issues on this topic that i'm not aware of? If you have safe_mode enabled or if you're using PHP 5.2.x on Windows there may be a problem. For the first situation the general advise (also from the PHP manual) is to disable safe_mode (see PHP manual for the reasons). For the latter I have to say that you've encountered a PHP bug. Because PHP 5.2.x is end of life, this won't be fixed in PHP. Both issues are on my radar, but we haven't found a solution yet which works in all situations. I hope to have a solution ready for 4.5.1 -- Kind regards / met vriendelijke groet, Jigal van Hemert skype:jigal.van.hemert msn: jigal at xs4all.nl http://twitter.com/jigalvh From vsbies at wp.pl Fri Feb 4 21:47:59 2011 From: vsbies at wp.pl (Marcus 'biesior' Biesioroff) Date: Fri, 04 Feb 2011 21:47:59 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 In-Reply-To: <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> References: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296852582.16518.typo3-dev@lists.typo3.org> ellou' W dniu 11-02-04 20:16, Jigal van Hemert pisze: > Hi, > > On 4-2-2011 18:34, Marcus 'biesior' Biesioroff wrote: >> I just realized that one of my small extensions (EXT:ogonki) is not >> working anymore in 4.5 >> >> it uses standard stdWrap hooks as described in German wiki: >> http://wiki.typo3.org/De:TSref/stdWrap#Anleitung:_Hook_f.C3.BCr_stdWrap_erstellen >> >> >> It was working before (at least in 4.3) so I have no idea either I >> missed something or I sholud write a new issue in BT. > > Look in typo3/sysext/cms/tslib/class.tslib_content.php lines 577-591. In > 4.5 your hook code has to implement the interface > tslib_content_stdWrapHook (see > typo3/sysext/cms/tslib/interfaces/interface.tslib_content_stdwraphook.php) > > In tslib_cObj::stdWrap_stdWrapPreProcess(), etc. you can find the calls > to your hook object. > > This is the new way of making hooks in the core. it implements the interface: http://typo3.org/extensions/repository/view/ogonki/current/info/class.tx_ogonki_hook.php/ the problem in above case is that the $configuration variable is not read anymore... if I use ie: function stdWrapProcess($content, array $configuration, tslib_cObj &$parentObject) { debug($configuration); return $content; } in debug it returns only array: stdWrapProcess 1 stdWrapProcess. no more $configuration['glueOrphans'] is available, although it's in TS I still hasn't got it, maybe I was not quite clear - hooks are called if no $configuration read try occures regards -- Marcus 'biesior' Biesioroff http://www.typo3.pl | TYPO3 Polish Community T3CI From jigal at xs4all.nl Fri Feb 4 23:48:07 2011 From: jigal at xs4all.nl (Jigal van Hemert) Date: Fri, 04 Feb 2011 23:48:07 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 In-Reply-To: <mailman.1.1296852582.16518.typo3-dev@lists.typo3.org> References: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> <mailman.1.1296852582.16518.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296859790.26581.typo3-dev@lists.typo3.org> Hi, On 4-2-2011 21:47, Marcus 'biesior' Biesioroff wrote: > the problem in above case is that the $configuration variable is not > read anymore... The refactoring of class.tslib_content.php also changed the way the stdWrap properties were processed. There's an array $stdWrapOrder in tslib_cObj which determines both which properties are available and in which order they are executed. The $conf array is intersected with this array and this way the custom stdWrap property you use is removed. You can use the stdWrapPreProcess hook to modify the array and add your own property to the array. -- Kind regards / met vriendelijke groet, Jigal van Hemert skype:jigal.van.hemert msn: jigal at xs4all.nl http://twitter.com/jigalvh From tomasnorre at gmail.com Sat Feb 5 21:15:44 2011 From: tomasnorre at gmail.com (Tomas Norre Mikkelsen) Date: Sat, 05 Feb 2011 21:15:44 +0100 Subject: [TYPO3-dev] Extbase - Layout problem. Message-ID: <mailman.1.1296937050.14988.typo3-dev@lists.typo3.org> Hi, I'm started looking into Extbase extension development, startet with a very simple extension, that list name and value of a item. But my problem is that it will not find my templates files the error is: The template files "/usr/dana/data/developers/tnm/fritdrop/docs/typo3conf/ext/tnm_test/Resources/Private/Layouts/default.html", "/usr/dana/data/developers/tnm/fritdrop/docs/typo3conf/ext/tnm_test/Resources/Private/Layouts/default", "/usr/dana/data/developers/tnm/fritdrop/docs/typo3conf/ext/tnm_test/Resources/Private/Layouts/default.html", "/usr/dana/data/developers/tnm/fritdrop/docs/typo3conf/ext/tnm_test/Resources/Private/Layouts/default" could not be loaded. And the Layout dir looks like this: # pwd /usr/dana/data/developers/tnm/fritdrop/docs/typo3conf/ext/tnm_test/Resources/Private/Layouts #ls -l -rwxrw-r-- 1 www internal 64 5 feb 20:43 Default.html So why does it throgh the exception when the file is there and is reable? I'm newbie on this topic, so perhaps, its just my lack of knowledge, bare with me. /Tomas From typo3 at mbh-web.de Sat Feb 5 22:58:49 2011 From: typo3 at mbh-web.de (Marc Bastian Heinrichs) Date: Sat, 05 Feb 2011 22:58:49 +0100 Subject: [TYPO3-dev] Extbase - Layout problem. In-Reply-To: <mailman.1.1296937050.14988.typo3-dev@lists.typo3.org> References: <mailman.1.1296937050.14988.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1296943232.23831.typo3-dev@lists.typo3.org> Hi Tomas, > The template files > "/usr/dana/data/developers/tnm/fritdrop/docs/typo3conf/ext/tnm_test/Resources/Private/Layouts/default.html", > "/usr/dana/data/developers/tnm/fritdrop/docs/typo3conf/ext/tnm_test/Resources/Private/Layouts/default", > "/usr/dana/data/developers/tnm/fritdrop/docs/typo3conf/ext/tnm_test/Resources/Private/Layouts/default.html", > "/usr/dana/data/developers/tnm/fritdrop/docs/typo3conf/ext/tnm_test/Resources/Private/Layouts/default" > could not be loaded. > #ls -l > -rwxrw-r-- 1 www internal 64 5 feb 20:43 Default.html Default != default First option is to change the filename, second option is to change <f:layout name="default" /> to <f:layout name="Default" /> in your template file. Please use the newsgroup typo3.projects.typo3v4mvc for extbase and fluid related questions. Best Marc Bastian From typo3 at t3node.com Sun Feb 6 22:17:32 2011 From: typo3 at t3node.com (=?UTF-8?B?U3RlZmZlbiBNw7xsbGVy?=) Date: Sun, 06 Feb 2011 22:17:32 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 In-Reply-To: <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> References: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297027127.27813.typo3-dev@lists.typo3.org> Hi. On 04.02.2011 20:16 Jigal van Hemert wrote: > Look in typo3/sysext/cms/tslib/class.tslib_content.php lines 577-591. In > 4.5 your hook code has to implement the interface > tslib_content_stdWrapHook (see > typo3/sysext/cms/tslib/interfaces/interface.tslib_content_stdwraphook.php) I am a bit confused now. Did I get it right, that this is a breaking change of behaviour of hooks? Implementing interfaces is not documented in TYPO3 core API docs. Or is the interface just meant as a "friendly hint" to use the hook like the interface demonstrates? -- cheers, Steffen TYPO3 Blog: http://www.t3node.com/ Twitter: http://twitter.com/t3node From jigal at xs4all.nl Sun Feb 6 23:06:29 2011 From: jigal at xs4all.nl (Jigal van Hemert) Date: Sun, 06 Feb 2011 23:06:29 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 In-Reply-To: <mailman.1.1297027127.27813.typo3-dev@lists.typo3.org> References: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> <mailman.1.1297027127.27813.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297030094.32085.typo3-dev@lists.typo3.org> Hi, On 6-2-2011 22:17, Steffen M?ller wrote: > On 04.02.2011 20:16 Jigal van Hemert wrote: >> Look in typo3/sysext/cms/tslib/class.tslib_content.php lines 577-591. In >> 4.5 your hook code has to implement the interface >> tslib_content_stdWrapHook (see >> typo3/sysext/cms/tslib/interfaces/interface.tslib_content_stdwraphook.php) >> > > I am a bit confused now. Did I get it right, that this is a breaking > change of behaviour of hooks? Implementing interfaces is not documented > in TYPO3 core API docs. Or is the interface just meant as a "friendly > hint" to use the hook like the interface demonstrates? I didn't look in earlier versions, but in 4.4, 4.3, 4.2 (I stopped looking there) the stdWrap hooks are done in the same way. It is actually one of the documented way of doing hooks (a certain defined function in a class supplied by the hook subscriber), but uses the interface for validating that the function is declared in the right way. -- Kind regards / met vriendelijke groet, Jigal van Hemert skype:jigal.van.hemert msn: jigal at xs4all.nl http://twitter.com/jigalvh From vsbies at wp.pl Sun Feb 6 23:30:28 2011 From: vsbies at wp.pl (Marcus 'biesior' Biesioroff) Date: Sun, 06 Feb 2011 23:30:28 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 In-Reply-To: <mailman.1.1297027127.27813.typo3-dev@lists.typo3.org> References: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> <mailman.1.1297027127.27813.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297031533.1546.typo3-dev@lists.typo3.org> W dniu 11-02-06 22:17, Steffen M?ller pisze: > Hi. > > On 04.02.2011 20:16 Jigal van Hemert wrote: >> Look in typo3/sysext/cms/tslib/class.tslib_content.php lines 577-591. In >> 4.5 your hook code has to implement the interface >> tslib_content_stdWrapHook (see >> typo3/sysext/cms/tslib/interfaces/interface.tslib_content_stdwraphook.php) >> > > I am a bit confused now. Did I get it right, that this is a breaking > change of behaviour of hooks? Implementing interfaces is not documented > in TYPO3 core API docs. Or is the interface just meant as a "friendly > hint" to use the hook like the interface demonstrates? > > I'm _totally_ confused, I was trying to fix my hooks to reflect news rules with no luck :/ What's more I reviewed other similar extensions (even published in january 2011 (before official 4.5 publishing)) and none of them is working anymore... Maybe somebody who was working on new hooking ways could create simple example ext in ter for this job? -- Marcus 'biesior' Biesioroff http://www.typo3.pl | TYPO3 Polish Community T3CI From info at cybercraft.de Mon Feb 7 10:08:14 2011 From: info at cybercraft.de (JoH asenau) Date: Mon, 07 Feb 2011 10:08:14 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 In-Reply-To: <mailman.1.1297031533.1546.typo3-dev@lists.typo3.org> References: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> <mailman.1.1297027127.27813.typo3-dev@lists.typo3.org> <mailman.1.1297031533.1546.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297069756.3184.typo3-dev@lists.typo3.org> > I'm _totally_ confused, I was trying to fix my hooks to reflect news > rules with no luck :/ What's more I reviewed other similar extensions > (even published in january 2011 (before official 4.5 publishing)) and > none of them is working anymore... > > Maybe somebody who was working on new hooking ways could create simple > example ext in ter for this job? The problem is not the hook or the way it's implemented but Jigal already mentioned what could be the reason: There's an array $stdWrapOrder in tslib_cObj which determines both which properties are available and in which order they are executed. This has been done to make it possible to replace the huge "if" construct with real classes and function calls. The $conf array is intersected with this array and this way the custom stdWrap property you want to use is removed. So it's not enough to just implement the function. It has to be added to this array as well. You can use the stdWrapPreProcess hook to modify the array and add your own property to $stdWrapOrder. HTH 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 info at sk-typo3.de Mon Feb 7 10:46:39 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 07 Feb 2011 10:46:39 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 In-Reply-To: <mailman.1.1297069756.3184.typo3-dev@lists.typo3.org> References: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> <mailman.1.1297027127.27813.typo3-dev@lists.typo3.org> <mailman.1.1297031533.1546.typo3-dev@lists.typo3.org> <mailman.1.1297069756.3184.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297072103.7093.typo3-dev@lists.typo3.org> Hi Joey, could you add the needed part on that wiki page? vg Steffen From ernst at cron-it.de Mon Feb 7 16:50:59 2011 From: ernst at cron-it.de (Ernesto Baschny [cron IT]) Date: Mon, 07 Feb 2011 16:50:59 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 In-Reply-To: <mailman.1.1297069756.3184.typo3-dev@lists.typo3.org> References: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> <mailman.1.1297027127.27813.typo3-dev@lists.typo3.org> <mailman.1.1297031533.1546.typo3-dev@lists.typo3.org> <mailman.1.1297069756.3184.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297093963.15457.typo3-dev@lists.typo3.org> JoH asenau schrieb am 07.02.2011 10:08: >> I'm _totally_ confused, I was trying to fix my hooks to reflect news >> rules with no luck :/ What's more I reviewed other similar extensions >> (even published in january 2011 (before official 4.5 publishing)) and >> none of them is working anymore... >> >> Maybe somebody who was working on new hooking ways could create simple >> example ext in ter for this job? > > The problem is not the hook or the way it's implemented but Jigal > already mentioned what could be the reason: > > There's an array $stdWrapOrder in tslib_cObj which determines both which > properties are available and in which order they are executed. > This has been done to make it possible to replace the huge "if" > construct with real classes and function calls. > > The $conf array is intersected with this array and this way the custom > stdWrap property you want to use is removed. So it's not enough to just > implement the function. It has to be added to this array as well. > You can use the stdWrapPreProcess hook to modify the array and add your > own property to $stdWrapOrder. In my opinion this has to be fixed to make it robust and backwards compatible again. In case there are hooks registered, pass the whole unaltered array of "$conf" to these methods (stdWrap_stdWrapPreProcess, etc), instead of the stripped down $singleConf, which is always empty. Haven't tested it, but it looks like this when reading the code. Joey, opinions? Cheers, Ernesto From info at auxnet.de Mon Feb 7 17:42:02 2011 From: info at auxnet.de (Maximilian Kalus) Date: Mon, 07 Feb 2011 17:42:02 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 Message-ID: <mailman.9283.1297097031.648.typo3-dev@lists.typo3.org> I can also copy the problems of Marcus. Having studied the code in class.tslib_content.php, I am not quite sure how "new" hooks are supposed to work. The method Joey and Jigal described does not work, as far as I see. I can manipulate $stdWrapOrder in the stdWrapPreProcess hook, but in line 2047, $this->$functionName is called. So just adding a function won't work. Well, in line 2036, there is an if that queries $conf[$functionName] == 'stdWrapHookObject'. What is this for? Hunting for this obscure string, I found that some of the original discussions in bugs.typo3.org regarding "Optimize stdWrap" defined the strings in the configuration of hooks arount line 1974: foreach ($this->stdWrapHookObjects as $hookObject) { if (is_callable(array($hookObject, 'stdWrapPreProcess'))) { $conf['stdWrapPreProcess'] = 'stdWrapHookObject'; } ; if (is_callable(array($hookObject, 'stdWrapOverride'))) { $conf['stdWrapOverride'] = 'stdWrapHookObject'; } ; if (is_callable(array($hookObject, 'stdWrapProcess'))) { $conf['stdWrapProcess'] = 'stdWrapHookObject'; } ; if (is_callable(array($hookObject, 'stdWrapPostProcess'))) { $conf['stdWrapPostProcess'] = 'stdWrapHookObject'; } ; } In the 4.5.0 release, the are assigned the value 1 instead of 'stdWrapHookObject' in each of the four lines. Having not followed the development, I guess there is a good reason for this.But if I change the 1 to 'stdWrapHookObject', my hooks start working again, because line 2037 assigns $singleConf correctly again. Is this a bug or a feature, I have not grasped correctly yet? Best regards, Max. From ernst at cron-it.de Mon Feb 7 17:44:12 2011 From: ernst at cron-it.de (Ernesto Baschny [cron IT]) Date: Mon, 07 Feb 2011 17:44:12 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 In-Reply-To: <mailman.9283.1297097031.648.typo3-dev@lists.typo3.org> References: <mailman.9283.1297097031.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297097157.21052.typo3-dev@lists.typo3.org> Maximilian Kalus schrieb am 07.02.2011 17:42: > I can also copy the problems of Marcus. Having studied the code in > class.tslib_content.php, I am not quite sure how "new" hooks are > supposed to work. > > The method Joey and Jigal described does not work, as far as I see. I > can manipulate $stdWrapOrder in the stdWrapPreProcess hook, but in line > 2047, $this->$functionName is called. So just adding a function won't > work. > > Well, in line 2036, there is an if that queries $conf[$functionName] == > 'stdWrapHookObject'. What is this for? Hunting for this obscure string, > I found that some of the original discussions in bugs.typo3.org > regarding "Optimize stdWrap" defined the strings in the configuration of > hooks arount line 1974: > > foreach ($this->stdWrapHookObjects as $hookObject) { > if (is_callable(array($hookObject, 'stdWrapPreProcess'))) { > $conf['stdWrapPreProcess'] = 'stdWrapHookObject'; > } > ; > if (is_callable(array($hookObject, 'stdWrapOverride'))) { > $conf['stdWrapOverride'] = 'stdWrapHookObject'; > } > ; > if (is_callable(array($hookObject, 'stdWrapProcess'))) { > $conf['stdWrapProcess'] = 'stdWrapHookObject'; > } > ; > if (is_callable(array($hookObject, 'stdWrapPostProcess'))) { > $conf['stdWrapPostProcess'] = 'stdWrapHookObject'; > } > ; > } > > > In the 4.5.0 release, the are assigned the value 1 instead of > 'stdWrapHookObject' in each of the four lines. Having not followed the > development, I guess there is a good reason for this.But if I change the > 1 to 'stdWrapHookObject', my hooks start working again, because line > 2037 assigns $singleConf correctly again. > > Is this a bug or a feature, I have not grasped correctly yet? Thanks for investigating! This is the bug I just mentioned in my previous post (to the original thread). I also consider it important to get fixed in 4.5.1 (maintaining backwards compatibility). If you found a fix which works, it sounds pretty good, and you might post it as an RFC to the core list, so that more people can review it. Cheers, Ernesto From typo3.RemoveForMessage at elements-net.de Mon Feb 7 18:10:57 2011 From: typo3.RemoveForMessage at elements-net.de (Franz Koch) Date: Mon, 07 Feb 2011 18:10:57 +0100 Subject: [TYPO3-dev] Workspace-Issues with menus in 4.5 Message-ID: <mailman.1.1297098769.24077.typo3-dev@lists.typo3.org> Hey list, I seem to have a rather strange problem with workspaces and menus using TYPO3 4.5 (didn't check a older version yet). Imagine this pagetree: # WORKSPACE-PAGETREE # root |- section1 (existing, renamed/versioned) | |- page1-1 (new in workspace) | |- page1-2 (new in workspace) | |- page1-3 (existing, hidden) | |- page1-4 (live) |- section2 (new in workspace) | |- page2-1 (new in workspace) | |- page2-2 (moved from section1, was page1-5) |- section3 (live) While in workspace preview mode - as long as I'm navigating on pages which are either "live" or are based on live pages ("existing") the menu is just fine. But as soon as I klick on a page created out of the workspace (thus new) I see all hidden pages (like page1-3) in all menus. Also page2-2 permanently appears as page1-5 on some menus (like in a CE "menu/sitemap -> subpages of these pages -> startingPoint:section1), regardless if I'm on a new or existing page. So something's definitely wrong here. Looks like the admPanel option "display hidden pages" is turned on when on new pages while it shouldn't (admPanel is disabled btw). Haven't checked yet if this also applies for content elements - didn't see any issues on a first look. Anybody else experienced a similar behavior? Can this be related to a configuration issue, or might it be a bug? I'm using TMENUs all over the place - no itemProcFunc etc. - just ordinary TMENUs. Thanks. -- kind regards, Franz Koch From info at cybercraft.de Mon Feb 7 20:00:34 2011 From: info at cybercraft.de (JoH asenau) Date: Mon, 07 Feb 2011 20:00:34 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 In-Reply-To: <mailman.1.1297093963.15457.typo3-dev@lists.typo3.org> References: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> <mailman.1.1297027127.27813.typo3-dev@lists.typo3.org> <mailman.1.1297031533.1546.typo3-dev@lists.typo3.org> <mailman.1.1297069756.3184.typo3-dev@lists.typo3.org> <mailman.1.1297093963.15457.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297105298.2307.typo3-dev@lists.typo3.org> > In case there are hooks registered, pass the whole unaltered array of > "$conf" to these methods (stdWrap_stdWrapPreProcess, etc), instead of > the stripped down $singleConf, which is always empty. > > Haven't tested it, but it looks like this when reading the code. Joey, > opinions? Actually this is what has been intended with the current code, I just completely forgot that point - so sorry for the misleading information. The problem is, that it doesn't work as expected, so this is "just" a bug. I'm already working at the fix and I guess I will come up with an RFC tonight. HTH 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 thomas.kieslich at gmail.com Mon Feb 7 20:25:07 2011 From: thomas.kieslich at gmail.com (Thomas Kieslich) Date: Mon, 07 Feb 2011 20:25:07 +0100 Subject: [TYPO3-dev] Introduction package - imagewidths Message-ID: <mailman.1.1297106808.4649.typo3-dev@lists.typo3.org> Hi I want to use the Introduction package for the doc screenshots of tkcropthumbs. I see the four column Layouts but max.imagewidth is set for 3 columns Layout. I wrote a new template to respect the imagewidths in all 4 Templates. new: page_blocks_configuration > lib.imagewidth Content: ## width of content lib.user_content_width = CASE lib.user_content_width{ key.data = levelfield:-1,layout default = TEXT default.value = 417 0 < default 1 = TEXT 1.value = 650 2 = TEXT 2.value = 650 3 = TEXT 3.value = 840 } tt_content { # Define max image width for each content column separately image.20.maxW.cObject = CASE image.20.maxW.cObject { key.field = colPos default = TEXT default.value = 417 # normal 0 < lib.user_content_width # left 1 = TEXT 1.value = 155 # right 2 = TEXT 2.value = 155 } image.20.maxWInText.cObject = CASE image.20.maxWInText.cObject { key.field = colPos default = TEXT default.value = 417 # normal 0 < lib.user_content_width # left 1 = TEXT 1.value = 155 # right 2 = TEXT 2.value = 155 } Works great, perhaps you like to integrate in an future Version of Introduction Package. kind regards, thomas From info at cybercraft.de Mon Feb 7 21:33:30 2011 From: info at cybercraft.de (JoH asenau) Date: Mon, 07 Feb 2011 21:33:30 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 In-Reply-To: <mailman.1.1297105298.2307.typo3-dev@lists.typo3.org> References: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> <mailman.1.1297027127.27813.typo3-dev@lists.typo3.org> <mailman.1.1297031533.1546.typo3-dev@lists.typo3.org> <mailman.1.1297069756.3184.typo3-dev@lists.typo3.org> <mailman.1.1297093963.15457.typo3-dev@lists.typo3.org> <mailman.1.1297105298.2307.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297110873.10517.typo3-dev@lists.typo3.org> > The problem is, that it doesn't work as expected, so this is "just" a > bug. I'm already working at the fix and I guess I will come up with an > RFC tonight. After discussing this with Jigal it seems that the solution is quite simple. Please check the patch attached to this BT entry: http://bugs.typo3.org/view.php?id=17507 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 vsbies at wp.pl Mon Feb 7 22:48:23 2011 From: vsbies at wp.pl (Marcus 'biesior' Biesioroff) Date: Mon, 07 Feb 2011 22:48:23 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 In-Reply-To: <mailman.1.1297110873.10517.typo3-dev@lists.typo3.org> References: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> <mailman.1.1297027127.27813.typo3-dev@lists.typo3.org> <mailman.1.1297031533.1546.typo3-dev@lists.typo3.org> <mailman.1.1297069756.3184.typo3-dev@lists.typo3.org> <mailman.1.1297093963.15457.typo3-dev@lists.typo3.org> <mailman.1.1297105298.2307.typo3-dev@lists.typo3.org> <mailman.1.1297110873.10517.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297115408.16784.typo3-dev@lists.typo3.org> W dniu 11-02-07 21:33, JoH asenau pisze: >> The problem is, that it doesn't work as expected, so this is "just" a >> bug. I'm already working at the fix and I guess I will come up with an >> RFC tonight. > > After discussing this with Jigal it seems that the solution is quite > simple. Please check the patch attached to this BT entry: > http://bugs.typo3.org/view.php?id=17507 > > Cheers > > Joey > +2 from me :) works with ext:ogonki and also with new ext. thank you for your investigation, in next few days I'll re-review mentioned other-side extensions as well. -- Marcus 'biesior' Biesioroff http://www.typo3.pl | TYPO3 Polish Community T3CI From info at auxnet.de Mon Feb 7 23:32:27 2011 From: info at auxnet.de (Maximilian Kalus) Date: Mon, 07 Feb 2011 23:32:27 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 In-Reply-To: <mailman.1.1297115408.16784.typo3-dev@lists.typo3.org> References: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> <mailman.1.1297027127.27813.typo3-dev@lists.typo3.org> <mailman.1.1297031533.1546.typo3-dev@lists.typo3.org> <mailman.1.1297069756.3184.typo3-dev@lists.typo3.org> <mailman.1.1297093963.15457.typo3-dev@lists.typo3.org> <mailman.1.1297105298.2307.typo3-dev@lists.typo3.org> <mailman.1.1297110873.10517.typo3-dev@lists.typo3.org> <mailman.1.1297115408.16784.typo3-dev@lists.typo3.org> Message-ID: <mailman.9303.1297118055.648.typo3-dev@lists.typo3.org> > +2 from me :) works with ext:ogonki and also with new ext. thank you for > your investigation, in next few days I'll re-review mentioned other-side > extensions as well. +2 here, too. Bugfix works also for my extension mak_stdwrapext. Elegant solution! Best regards, Max. From info at sk-typo3.de Tue Feb 8 00:09:29 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Tue, 08 Feb 2011 00:09:29 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 In-Reply-To: <mailman.1.1297110873.10517.typo3-dev@lists.typo3.org> References: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> <mailman.1.1296847081.9434.typo3-dev@lists.typo3.org> <mailman.1.1297027127.27813.typo3-dev@lists.typo3.org> <mailman.1.1297031533.1546.typo3-dev@lists.typo3.org> <mailman.1.1297069756.3184.typo3-dev@lists.typo3.org> <mailman.1.1297093963.15457.typo3-dev@lists.typo3.org> <mailman.1.1297105298.2307.typo3-dev@lists.typo3.org> <mailman.1.1297110873.10517.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297120274.24084.typo3-dev@lists.typo3.org> Hi, Am 07.02.2011 21:33, schrieb JoH asenau: >> The problem is, that it doesn't work as expected, so this is "just" a >> bug. I'm already working at the fix and I guess I will come up with an >> RFC tonight. > > After discussing this with Jigal it seems that the solution is quite > simple. Please check the patch attached to this BT entry: > http://bugs.typo3.org/view.php?id=17507 > lol - big description, small fix :) Awaiting in the list ... vg Steffen From jbl at deweblop.de Tue Feb 8 09:41:44 2011 From: jbl at deweblop.de (J. Lingott) Date: Tue, 08 Feb 2011 09:41:44 +0100 Subject: [TYPO3-dev] EXT: Realurl multi-domain Message-ID: <mailman.9330.1297154594.648.typo3-dev@lists.typo3.org> Hey list, well, I know there is plenty of stuff around for multi-domain setups with Realurl, but the simple setup is not the problem. All is working like a charm with different root page ids for all the different domains, sharing some of them. The thing I am wondering about is more the fact of Realurl prepending the root page id's post var to all the links it generates (although the links work fine without it). Is there any way to override that behaviour? Cheers J?rg Lingott From ernst at cron-it.de Tue Feb 8 11:01:27 2011 From: ernst at cron-it.de (Ernesto Baschny [cron IT]) Date: Tue, 08 Feb 2011 11:01:27 +0100 Subject: [TYPO3-dev] stdWrap hooks - problem in 4.5 (SOLVED) In-Reply-To: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> References: <mailman.1.1296840986.1101.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297159393.30081.typo3-dev@lists.typo3.org> Marcus 'biesior' Biesioroff schrieb am 04.02.2011 18:34: > ellou' Geeks > > I just realized that one of my small extensions (EXT:ogonki) is not > working anymore in 4.5 > > it uses standard stdWrap hooks as described in German wiki: > http://wiki.typo3.org/De:TSref/stdWrap#Anleitung:_Hook_f.C3.BCr_stdWrap_erstellen > > > It was working before (at least in 4.3) so I have no idea either I > missed something or I sholud write a new issue in BT. > > What is your opinion?? FYI, this has been solved already in the core and will be part of the 4.5.1 release. trunk rev: 10414 4_5 rev: 10415 Thanks for your input and the easy found solution at the end. :) Cheers, Ernesto From j.rieger at connecta.ag Tue Feb 8 17:18:59 2011 From: j.rieger at connecta.ag (Jochen Rieger) Date: Tue, 08 Feb 2011 17:18:59 +0100 Subject: [TYPO3-dev] IRRE, TYPO3 4.4.6 , MM and localization - not working? Message-ID: <mailman.1.1297182045.7417.typo3-dev@lists.typo3.org> Hi all, in configuration mentioned above in TYPO3 4.4.6 somehow the "Localize All" button (as well as the single item localize-button) does not do anything for me. Anyone experiencing the same? Am I missing something? All tables got the localization fields (sys_language_uid, l18n_parent, l18n_diffsource, t3_origuid). TCA config should be fine: === 'type' => 'inline', 'foreign_table' => 'tx_myext_domain_model_files', 'MM' => 'tx_myext_product_files_mm', 'appearance' => array( 'showAllLocalizationLink' => 1, 'showPossibleLocalizationRecords' => 1, 'showRemovedLocalizationRecords' => 1, 'showSynchronizationLink' => 1, ), 'behaviour' => array( 'localizationMode' => 'select', ), === But none of the localize / syncronize links has any effect. This is what the console says would be the response of typo3/ajax.php after clicking one of the links: {"scriptCall":["\n\n\n\t\t\tTBE_EDITOR.loginRefreshed();\n\t\t"]} Any ideas? Regards, Jochen From bas.vander.togt at efocus.nl Tue Feb 8 17:32:27 2011 From: bas.vander.togt at efocus.nl (Bas van der Togt) Date: Tue, 08 Feb 2011 17:32:27 +0100 Subject: [TYPO3-dev] add custom records to existing TMENU with IProcFunc Message-ID: <mailman.1.1297182853.8851.typo3-dev@lists.typo3.org> Hello list, I'm trying to add some custom items from another table to my existing TMENU underneath pid=5 I found some examples typo3/sysext/cms/tslib/media/scripts/example_itemArrayProcFunc.php but those are not what i'm looking for. Example what i want: page 1 (pid=1) page 2 (pid=2) --subpage 1 (pid=3) --subpage 2 (pid=4) page 3 (pid=5) --custom record 1 --custom record 2 page 4 (pid=6) --subpage 3 (pid=7) ... My TS: obj.mainnav = HMENU obj.mainnav { special = directory special.value = 370 excludeUidList = 431,373,372 1 = TMENU 1 { expAll = 1 wrap = <ul class="mainnav">|</ul> noBlur = 1 IProcFunc = user_itemArrayProcFuncTest NO = 1 NO { ATagTitle.field = subtitle // title wrapItemAndSub = <li>|</li> stdWrap.wrap = <span class="arrow"></span> | allWrap = <h2>|</h2> } ... Can anybody help me to this? regards, Bas From ernesto.baschny at typo3.org Tue Feb 8 19:11:36 2011 From: ernesto.baschny at typo3.org (Ernesto Baschny) Date: Tue, 08 Feb 2011 19:11:36 +0100 Subject: [TYPO3-dev] [TYPO3-v4] Migrating TYPO3 core to git.typo3.org commencing soon Message-ID: <mailman.9405.1297188902.648.typo3-dev@lists.typo3.org> Hi dear developers and TYPO3 contributors, if you follow our development and have been to the latest T3DD, you might have noticed that we are for a long time already planning on migrating our TYPO3 core repository to GIT. --------------------------------------------------------------------- To make it short --------------------------------------------------------------------- We will be migrating the TYPO3 core repository to GIT during the Code Sprint 2011 in Berlin (on some day between 28th February and 4th of March). --------------------------------------------------------------------- What does it mean? --------------------------------------------------------------------- 1) The core list as we know it will no longer be used for voting on patches (it might even be deactivated...). We will be using the Gerrit reviewing system (http://review.typo3.org) which will speed up our development and reviewing pace. 2) We will have the external system extensions (dbal, extbase, fluid, linkvalidator, t3editor, workspaces, version) also migrated to GIT as separate projects at the same time. Those will be integrated into the core as Submodules, a feature from GIT similar to svn:external. This will ease the process of packaging a release. 3) We will no longer manually maintain a "ChangeLog" file. This will be generated automatically before the releases, which eases up the process of merging bug fixes from one branch onto the other. 4) Third party extensions hosting on forge using SVN are not affected at first by this. There are no current plans on making git.typo3.org available to the "masses" of extension development on forge, but there are wishes to make it happen (at least on a "can have" basis, where the developer can opt to use git or svn when setting up their projects). But this is out of our scope *currently*. --------------------------------------------------------------------- Current migration plan --------------------------------------------------------------------- We have a git task force [1], which is working on getting that done and trying to consider all implications. We are: - Karsten Dambekalns - Michael Stucki - Peter Niederlag - Xavier Perseguers - Ernesto Baschny We already met twice to discuss the route. And today we decided the further steps: 1) ASAP (during the next week) we will start with Stucki, Karsten and Peter migrating our current SVN to git.typo3.org and integrating it with the Gerrit System in an environment which will be exactly like the "Live System" afterwards. 2) The "Testing" can then begin, with patches being pushed to Gerrit, test-reviews being done, testing the whole work flow (e.g. also backporting fixes from trunk to 4-5, 4-4, etc) 3) Present the results and make a Q&A round during our Core Sprint in Berlin [2]. After having all details cleared and walking through the process: 4) Refresh the projects on git.typo3.org with the current happenings from svn.typo3.org and have git / gerrit go LIVE for v4! 5) Make svn.typo3.org "read-only" and have it there for historical reasons... [1] http://forge.typo3.org/projects/team-git [2] http://wiki.typo3.org/Code_Sprint_Berlin_2011 --------------------------------------------------------------------- Documentation --------------------------------------------------------------------- Our main current focus is getting the migration done and the work flow established. There is plenty of documentation on git already available (e.g. http://progit.org/book/) and we will constrain ourselves in documenting our specific work flow. At least for the Live-Going we will have to update the documentation on typo3.org regarding "Contributing patches to the core" because of the new work flow. We will update the current documentation available on Forge on using Git / Gerrit (already in use for FLOW3 / Phoenix), adapting it to our new TYPO3v4 work flow. --------------------------------------------------------------------- Issues / caveats --------------------------------------------------------------------- We are trying hard to cover all potential pitfalls, here are some (but not all): - We want to keep our current "SVN rev-ids" in the commit messages after migrating, because they can be useful to find historical fixes (e.g. when reading an issue in the bug tracker referring to "commited to rev. xyz"). For newer post-GIT commits they are not relevant anymore (because every commit will have a SHA-hash) - We will migrate from svn.typo3.org and *not* from the currently synchronized repository (kindly provided by Peter) on github.org [3]. This will lead to new SHA hashes for our history. This is not definitively decided and Peter feels that the amount of work to do either one of them is the same. - When migrating, we will include all current SVN branches and tags, so that they are available for research under GIT. While doing that we might rename some wrongly marked branches (like "TYPO3_3-6-0") or remove really obsolete and never used branches (like "indexed_search_refactoring"). - During the migration, we will need to remove the Submodules from our core, so that they can after the migration point to a remote repository. E.g. currently typo3/sysext/dbal/ is part of the core and is merged from time to time (before releases) from the external repository. We will "git rm typo3/sysext/dbal" and include a reference to the external Submodule instead, so that keeping up to date with "current trunk and all current trunk of all external projects" will turn out to be much easier in future. Cheers, Ernesto [1] http://forge.typo3.org/projects/team-git [2] http://wiki.typo3.org/Code_Sprint_Berlin_2011 [3] https://github.com/typo3/typo3v4core -- Ernesto Baschny Core Developer V4 Team Release Manager TYPO3 4.5 TYPO3 .... inspiring people to share! Get involved: typo3.org From ben.vantende at typo3.org Wed Feb 9 08:57:47 2011 From: ben.vantende at typo3.org (ben van 't ende) Date: Wed, 09 Feb 2011 08:57:47 +0100 Subject: [TYPO3-dev] Introduction package - imagewidths In-Reply-To: <mailman.1.1297106808.4649.typo3-dev@lists.typo3.org> References: <mailman.1.1297106808.4649.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297238374.8498.typo3-dev@lists.typo3.org> Hey Thomas, We will definitely want that in. Please report it as an issue here: http://forge.typo3.org/projects/show/extension-introduction, so we will remember it ;-) tHNx ben On 07/02/11 20:25, Thomas Kieslich wrote: > Hi > I want to use the Introduction package for the doc screenshots of tkcropthumbs. > I see the four column Layouts but max.imagewidth is set for 3 columns Layout. I > wrote a new template to respect the imagewidths in all 4 Templates. > > new: page_blocks_configuration > lib.imagewidth > > Content: > ## width of content > lib.user_content_width = CASE > lib.user_content_width{ > key.data = levelfield:-1,layout > default = TEXT > default.value = 417 > > 0 < default > > 1 = TEXT > 1.value = 650 > > 2 = TEXT > 2.value = 650 > > 3 = TEXT > 3.value = 840 > } > > tt_content { > # Define max image width for each content column separately > image.20.maxW.cObject = CASE > image.20.maxW.cObject { > key.field = colPos > > default = TEXT > default.value = 417 > # normal > > 0 < lib.user_content_width > > # left > 1 = TEXT > 1.value = 155 > > # right > 2 = TEXT > 2.value = 155 > } > > image.20.maxWInText.cObject = CASE > image.20.maxWInText.cObject { > key.field = colPos > > default = TEXT > default.value = 417 > > # normal > 0 < lib.user_content_width > > # left > 1 = TEXT > 1.value = 155 > > # right > 2 = TEXT > 2.value = 155 > } > > Works great, perhaps you like to integrate in an future Version of Introduction > Package. > > kind regards, thomas -- TYPO3 Community Manager From thomas.kieslich at gmail.com Wed Feb 9 09:35:24 2011 From: thomas.kieslich at gmail.com (Thomas Kieslich) Date: Wed, 09 Feb 2011 09:35:24 +0100 Subject: [TYPO3-dev] Introduction package - imagewidths In-Reply-To: <mailman.1.1297238374.8498.typo3-dev@lists.typo3.org> References: <mailman.1.1297106808.4649.typo3-dev@lists.typo3.org> <mailman.1.1297238374.8498.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297240627.12758.typo3-dev@lists.typo3.org> Hi ben, no Problem #12889 Thomas Am 09.02.2011 08:57, schrieb ben van 't ende: > Hey Thomas, > > We will definitely want that in. Please report it as an issue here: > http://forge.typo3.org/projects/show/extension-introduction, so we will remember > it ;-) > > tHNx > > ben > > > On 07/02/11 20:25, Thomas Kieslich wrote: >> Hi >> I want to use the Introduction package for the doc screenshots of tkcropthumbs. >> I see the four column Layouts but max.imagewidth is set for 3 columns Layout. I >> wrote a new template to respect the imagewidths in all 4 Templates. >> >> new: page_blocks_configuration> lib.imagewidth >> >> Content: >> ## width of content >> lib.user_content_width = CASE >> lib.user_content_width{ >> key.data = levelfield:-1,layout >> default = TEXT >> default.value = 417 >> >> 0< default >> >> 1 = TEXT >> 1.value = 650 >> >> 2 = TEXT >> 2.value = 650 >> >> 3 = TEXT >> 3.value = 840 >> } >> >> tt_content { >> # Define max image width for each content column separately >> image.20.maxW.cObject = CASE >> image.20.maxW.cObject { >> key.field = colPos >> >> default = TEXT >> default.value = 417 >> # normal >> >> 0< lib.user_content_width >> >> # left >> 1 = TEXT >> 1.value = 155 >> >> # right >> 2 = TEXT >> 2.value = 155 >> } >> >> image.20.maxWInText.cObject = CASE >> image.20.maxWInText.cObject { >> key.field = colPos >> >> default = TEXT >> default.value = 417 >> >> # normal >> 0< lib.user_content_width >> >> # left >> 1 = TEXT >> 1.value = 155 >> >> # right >> 2 = TEXT >> 2.value = 155 >> } >> >> Works great, perhaps you like to integrate in an future Version of Introduction >> Package. >> >> kind regards, thomas > > From info at tolleiv.de Wed Feb 9 14:03:14 2011 From: info at tolleiv.de (Tolleiv Nietsch) Date: Wed, 09 Feb 2011 14:03:14 +0100 Subject: [TYPO3-dev] cookieSecure & cli_dispatcher Message-ID: <mailman.1.1297256701.8932.typo3-dev@lists.typo3.org> Hi, having $TYPO3_CONF_VARS[SYS][cookieSecure] set to '1' seems to avoid any cli_dispatch.phpsh action. Is anybody aware of this, anybody experiencing the same problems and is there some kind of workaround? Cheers, Tolleiv -- Tolleiv Nietsch www.tolleiv.de - www.aoemedia.de From helmut.hummel at typo3.org Wed Feb 9 14:40:30 2011 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Wed, 09 Feb 2011 14:40:30 +0100 Subject: [TYPO3-dev] cookieSecure & cli_dispatcher In-Reply-To: <mailman.1.1297256701.8932.typo3-dev@lists.typo3.org> References: <mailman.1.1297256701.8932.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297258937.13321.typo3-dev@lists.typo3.org> Hi, Tolleiv Nietsch wrote: > having $TYPO3_CONF_VARS[SYS][cookieSecure] set to '1' seems to avoid any > cli_dispatch.phpsh action. Is anybody aware of this, anybody > experiencing the same problems and is there some kind of workaround? I cannot reproduce this with TYPO3 v4.4.x. Any error messeages you get? Kind regards, Helmut -- Helmut Hummel TYPO3 Security Team Leader TYPO3 .... inspiring people to share! Get involved: typo3.org From helmut.hummel at typo3.org Wed Feb 9 14:48:43 2011 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Wed, 09 Feb 2011 14:48:43 +0100 Subject: [TYPO3-dev] cookieSecure & cli_dispatcher In-Reply-To: <mailman.1.1297258937.13321.typo3-dev@lists.typo3.org> References: <mailman.1.1297256701.8932.typo3-dev@lists.typo3.org> <mailman.1.1297258937.13321.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297259430.14326.typo3-dev@lists.typo3.org> Helmut Hummel wrote: > Hi, > > Tolleiv Nietsch wrote: >> having $TYPO3_CONF_VARS[SYS][cookieSecure] set to '1' seems to avoid any >> cli_dispatch.phpsh action. Is anybody aware of this, anybody >> experiencing the same problems and is there some kind of workaround? > > I cannot reproduce this with TYPO3 v4.4.x. Ah, OK. Did set the configuration in the wrong place. An Exception is thrown: "Cookie was not set since HTTPS was forced in $TYPO3_CONF_VARS[SYS][cookieSecure]." This is a bug. Some time ago I wondered that setting $TYPO3_CONF_VARS['BE']['adminOnly'] = '1' also prevents any cli script from running... Kind regards, Helmut -- Helmut Hummel TYPO3 Security Team Leader TYPO3 .... inspiring people to share! Get involved: typo3.org From jigal at xs4all.nl Wed Feb 9 16:20:43 2011 From: jigal at xs4all.nl (Jigal van Hemert) Date: Wed, 09 Feb 2011 16:20:43 +0100 Subject: [TYPO3-dev] cookieSecure & cli_dispatcher In-Reply-To: <mailman.1.1297259430.14326.typo3-dev@lists.typo3.org> References: <mailman.1.1297256701.8932.typo3-dev@lists.typo3.org> <mailman.1.1297258937.13321.typo3-dev@lists.typo3.org> <mailman.1.1297259430.14326.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297264948.25640.typo3-dev@lists.typo3.org> Hi, On 9-2-2011 14:48, Helmut Hummel wrote: >> Tolleiv Nietsch wrote: >>> having $TYPO3_CONF_VARS[SYS][cookieSecure] set to '1' seems to avoid any >>> cli_dispatch.phpsh action. (...) > This is a bug. I agree. > Some time ago I wondered that setting > $TYPO3_CONF_VARS['BE']['adminOnly'] = '1' > > also prevents any cli script from running... In general this would be a good behaviour. An Admin will only close the BE if there is work to be done which can go wrong if others are changing the contents too. _cli_* users should also not mess around with the content. It could be a feature to explicitly allow this exception for cli scripts. -- Kind regards / met vriendelijke groet, Jigal van Hemert skype:jigal.van.hemert msn: jigal at xs4all.nl http://twitter.com/jigalvh From bjoern.pedersen at frm2.tum.de Wed Feb 9 17:30:52 2011 From: bjoern.pedersen at frm2.tum.de (Bjoern Pedersen) Date: Wed, 09 Feb 2011 17:30:52 +0100 Subject: [TYPO3-dev] cookieSecure & cli_dispatcher In-Reply-To: <mailman.1.1297264948.25640.typo3-dev@lists.typo3.org> References: <mailman.1.1297256701.8932.typo3-dev@lists.typo3.org> <mailman.1.1297258937.13321.typo3-dev@lists.typo3.org> <mailman.1.1297259430.14326.typo3-dev@lists.typo3.org> <mailman.1.1297264948.25640.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297269159.1138.typo3-dev@lists.typo3.org> Am 09.02.2011 16:20, schrieb Jigal van Hemert: >> Some time ago I wondered that setting >> $TYPO3_CONF_VARS['BE']['adminOnly'] = '1' >> >> also prevents any cli script from running... > > In general this would be a good behaviour. An Admin will only close the > BE if there is work to be done which can go wrong if others are changing > the contents too. _cli_* users should also not mess around with the > content. > > It could be a feature to explicitly allow this exception for cli scripts. > I think http://bugs.typo3.org/view.php?id=13164 did introduce such a feature. Bj?rn From helmut.hummel at typo3.org Wed Feb 9 18:08:25 2011 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Wed, 09 Feb 2011 18:08:25 +0100 Subject: [TYPO3-dev] cookieSecure & cli_dispatcher In-Reply-To: <mailman.1.1297269159.1138.typo3-dev@lists.typo3.org> References: <mailman.1.1297256701.8932.typo3-dev@lists.typo3.org> <mailman.1.1297258937.13321.typo3-dev@lists.typo3.org> <mailman.1.1297259430.14326.typo3-dev@lists.typo3.org> <mailman.1.1297264948.25640.typo3-dev@lists.typo3.org> <mailman.1.1297269159.1138.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297271412.5421.typo3-dev@lists.typo3.org> Hi Bjoern, Bjoern Pedersen wrote: > > I think http://bugs.typo3.org/view.php?id=13164 did introduce such a > feature. Ah, cool, I missed that somehow. Thanks. Kind regards, Helmut -- Helmut Hummel TYPO3 Security Team Leader TYPO3 .... inspiring people to share! Get involved: typo3.org From ernesto.baschny at typo3.org Wed Feb 9 18:19:54 2011 From: ernesto.baschny at typo3.org (Ernesto Baschny) Date: Wed, 09 Feb 2011 18:19:54 +0100 Subject: [TYPO3-dev] [TYPO3-v4] Schedule for TYPO3 4.5.1 Message-ID: <mailman.9715.1297272302.648.typo3-dev@lists.typo3.org> Hi, we decided to make a sooner release of "4.5.1" as planned (plan was 9th March). Since we have already plenty of issues fixed, we don't want to wait too much with it and share it with the public as soon as possible. So current plan is to release: TYPO3 v4.5.1 on 23th February This release will contain all fixes of the most annoying issues we have encountered so far after the 4.5.0 release. You will love it! But until then, we still need your help, mainly in reviewing and testing fixes which are already pending. So now its your chance to "do your part". Here is a list of issues which would be good to have fixed in 4.5.1: * The refresh login dialog is shown even if session already timed out http://bugs.typo3.org/view.php?id=17498 => Pending in core (Helmut): needs one +1 * Open forms cannot be saved after "Relogin" (Security Token errors) http://bugs.typo3.org/view.php?id=17383 http://bugs.typo3.org/view.php?id=17378 => Helmut is working on it (#17383 resolves both), depends on #17498 being resolved first * GifBuilder - meaningfulTempFilePrefix can cause invalid image urls http://bugs.typo3.org/view.php?id=17483 => Pending in core (Galinksi), needs reviews * pages with Enforce Protocol(SSL) generate false URL http://bugs.typo3.org/view.php?id=17118 => Discussion in bug tracker, solution proposed by Jigal. Needs reviews, testing and brainstorming. * Status "500 Internal Server Error" returned, if page is not found http://bugs.typo3.org/view.php?id=17471 => Needs solution * Fatal error in tslib_content_text http://bugs.typo3.org/view.php?id=16902 => Pending in core (Joey's v4): needs one +1 by testing * LOAD_REGISTER different behaviour since 4.5.0 (depending on ordering) http://bugs.typo3.org/view.php?id=17385 => Pending in bug tracker (Joey): needs RFC and more reviews * Content type "mailform" no longer accepts list of addresses for "Recipient List" http://bugs.typo3.org/view.php?id=17518 => Pending in core (Jigal): Needs one more review * Suggest wizard does not work with drop-down select fields http://bugs.typo3.org/view.php?id=16636 => Pending in core (Francois): Needs two reviews * javascript error after contextmenu -> delete a page http://bugs.typo3.org/view.php?id=17479 => Needs solution * Dependencies in sysext 'version' and 'workspaces' http://bugs.typo3.org/view.php?id=17355 => Pending in core (Olly): Needs reviews * Error Message while Updating 4.4.6 > 4.5 http://bugs.typo3.org/view.php?id=17244 => Pending in core (Olly): Needs one +1 Cheers, Ernesto -- Ernesto Baschny Core Developer V4 Team Release Manager TYPO3 4.5 TYPO3 .... inspiring people to share! Get involved: typo3.org From bedlamhotel at gmail.com Wed Feb 9 18:35:49 2011 From: bedlamhotel at gmail.com (Christopher Torgalson) Date: Wed, 9 Feb 2011 09:35:49 -0800 Subject: [TYPO3-dev] [TYPO3-v4] Schedule for TYPO3 4.5.1 In-Reply-To: <mailman.9715.1297272302.648.typo3-dev@lists.typo3.org> References: <mailman.9715.1297272302.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.9719.1297273058.648.typo3-dev@lists.typo3.org> Hi Ernesto, These updates you've been sending around the core team's activity and releases are *fantastic*. It's great to know what's happening 'behind the curtain' :) -- Christopher Torgalson http://www.typo3apprentice.com/ On Wed, Feb 9, 2011 at 9:19 AM, Ernesto Baschny <ernesto.baschny at typo3.org> wrote: > Hi, > > we decided to make a sooner release of "4.5.1" as planned (plan was 9th > March). Since we have already plenty of issues fixed, we don't want to > wait too much with it and share it with the public as soon as possible. > > So current plan is to release: > > ? ?TYPO3 v4.5.1 on 23th February > > This release will contain all fixes of the most annoying issues we have > encountered so far after the 4.5.0 release. You will love it! > > But until then, we still need your help, mainly in reviewing and testing > fixes which are already pending. So now its your chance to "do your part". > > Here is a list of issues which would be good to have fixed in 4.5.1: > > * The refresh login dialog is shown even if session already timed out > http://bugs.typo3.org/view.php?id=17498 > ?=> Pending in core (Helmut): needs one +1 > > * Open forms cannot be saved after "Relogin" (Security Token errors) > http://bugs.typo3.org/view.php?id=17383 > http://bugs.typo3.org/view.php?id=17378 > ?=> Helmut is working on it (#17383 resolves both), depends on #17498 > being resolved first > > * GifBuilder - meaningfulTempFilePrefix can cause invalid image urls > http://bugs.typo3.org/view.php?id=17483 > ?=> Pending in core (Galinksi), needs reviews > > * pages with Enforce Protocol(SSL) generate false URL > http://bugs.typo3.org/view.php?id=17118 > ?=> Discussion in bug tracker, solution proposed by Jigal. Needs > reviews, testing and brainstorming. > > * Status "500 Internal Server Error" returned, if page is not found > http://bugs.typo3.org/view.php?id=17471 > ?=> Needs solution > > * Fatal error in tslib_content_text > http://bugs.typo3.org/view.php?id=16902 > ?=> Pending in core (Joey's v4): needs one +1 by testing > > * LOAD_REGISTER different behaviour since 4.5.0 (depending on ordering) > http://bugs.typo3.org/view.php?id=17385 > ?=> Pending in bug tracker (Joey): needs RFC and more reviews > > * Content type "mailform" no longer accepts list of addresses for > "Recipient List" > http://bugs.typo3.org/view.php?id=17518 > ?=> Pending in core (Jigal): Needs one more review > > * Suggest wizard does not work with drop-down select fields > http://bugs.typo3.org/view.php?id=16636 > ?=> Pending in core (Francois): Needs two reviews > > * javascript error after contextmenu -> delete a page > http://bugs.typo3.org/view.php?id=17479 > ?=> Needs solution > > * Dependencies in sysext 'version' and 'workspaces' > http://bugs.typo3.org/view.php?id=17355 > ?=> Pending in core (Olly): Needs reviews > > * Error Message while Updating 4.4.6 > 4.5 > http://bugs.typo3.org/view.php?id=17244 > ?=> Pending in core (Olly): Needs one +1 > > Cheers, > Ernesto > > -- > Ernesto Baschny > Core Developer V4 Team > Release Manager TYPO3 4.5 > > 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 ernesto.baschny at typo3.org Wed Feb 9 18:45:50 2011 From: ernesto.baschny at typo3.org (Ernesto Baschny) Date: Wed, 09 Feb 2011 18:45:50 +0100 Subject: [TYPO3-dev] [TYPO3-v4] Schedule for TYPO3 4.5.1 In-Reply-To: <mailman.9719.1297273058.648.typo3-dev@lists.typo3.org> References: <mailman.9715.1297272302.648.typo3-dev@lists.typo3.org> <mailman.9719.1297273058.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297273657.9436.typo3-dev@lists.typo3.org> Christopher Torgalson schrieb am 09.02.2011 18:35: > Hi Ernesto, > > These updates you've been sending around the core team's activity and > releases are *fantastic*. It's great to know what's happening 'behind > the curtain' :) Yes, that's the idea! My goal was also to get people more connected to our beloved TYPO3 development process, and with this motivate them into participating more actively. Previously it was a bit of a "black whole" where it was difficult to understand who was doing what and why, and suddenly a "new release" was there. By being able to follow the happenings I hope to allow other people to see that we're just humans doing stuff that others might do as well (no "super-powers" required), and thus activate more talented people that we *have* in our community, but were too shy to participate until now. Nice that you appreciate it, others also seem to be liking it too. Cheers, Ernesto -- Ernesto Baschny Core Developer V4 Team Release Manager TYPO3 4.5 TYPO3 .... inspiring people to share! Get involved: typo3.org From info at sk-typo3.de Wed Feb 9 22:39:15 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Wed, 09 Feb 2011 22:39:15 +0100 Subject: [TYPO3-dev] cookieSecure & cli_dispatcher In-Reply-To: <mailman.1.1297271412.5421.typo3-dev@lists.typo3.org> References: <mailman.1.1297256701.8932.typo3-dev@lists.typo3.org> <mailman.1.1297258937.13321.typo3-dev@lists.typo3.org> <mailman.1.1297259430.14326.typo3-dev@lists.typo3.org> <mailman.1.1297264948.25640.typo3-dev@lists.typo3.org> <mailman.1.1297269159.1138.typo3-dev@lists.typo3.org> <mailman.1.1297271412.5421.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297287664.31094.typo3-dev@lists.typo3.org> Hi, Am 09.02.2011 18:08, schrieb Helmut Hummel: > Hi Bjoern, > > Bjoern Pedersen wrote: >> >> I think http://bugs.typo3.org/view.php?id=13164 did introduce such a >> feature. > > Ah, cool, I missed that somehow. Thanks. > overdocumented? ;) vg Steffen From info at tolleiv.de Thu Feb 10 01:16:31 2011 From: info at tolleiv.de (Tolleiv.Nietsch) Date: Thu, 10 Feb 2011 01:16:31 +0100 Subject: [TYPO3-dev] cookieSecure & cli_dispatcher In-Reply-To: <mailman.1.1297264948.25640.typo3-dev@lists.typo3.org> References: <mailman.1.1297256701.8932.typo3-dev@lists.typo3.org> <mailman.1.1297258937.13321.typo3-dev@lists.typo3.org> <mailman.1.1297259430.14326.typo3-dev@lists.typo3.org> <mailman.1.1297264948.25640.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297297098.12721.typo3-dev@lists.typo3.org> Am 09.02.2011 16:20, schrieb Jigal van Hemert: > (...) >> This is a bug. > > I agree. > Ok thanks for the confirmation. Hope to find some time for the resolution in the next days. Cheers, Tolleiv -- Tolleiv Nietsch www.tolleiv.de - www.aoemedia.de Twitter: http://www.twitter.com/tolleiv From jigal at xs4all.nl Thu Feb 10 07:32:46 2011 From: jigal at xs4all.nl (Jigal van Hemert) Date: Thu, 10 Feb 2011 07:32:46 +0100 Subject: [TYPO3-dev] cookieSecure & cli_dispatcher In-Reply-To: <mailman.1.1297297098.12721.typo3-dev@lists.typo3.org> References: <mailman.1.1297256701.8932.typo3-dev@lists.typo3.org> <mailman.1.1297258937.13321.typo3-dev@lists.typo3.org> <mailman.1.1297259430.14326.typo3-dev@lists.typo3.org> <mailman.1.1297264948.25640.typo3-dev@lists.typo3.org> <mailman.1.1297297098.12721.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297319672.9816.typo3-dev@lists.typo3.org> Hi, On 10-2-2011 1:16, Tolleiv.Nietsch wrote: > Ok thanks for the confirmation. Hope to find some time for the > resolution in the next days. I think it's pretty useless to set cookies in CLI mode at all. This could be arranged by changing init.php: // ******************************* // BackEnd User authentication // ******************************* /* NOTICE: if constant TYPO3_PROCEED_IF_NO_USER is defined true (in the mainscript), this script will return even though a user did not log in! */ /** @var $BE_USER t3lib_beUserAuth */ $BE_USER = t3lib_div::makeInstance('t3lib_beUserAuth'); // New backend user object $BE_USER->warningEmail = $TYPO3_CONF_VARS['BE']['warning_email_addr']; $BE_USER->lockIP = $TYPO3_CONF_VARS['BE']['lockIP']; $BE_USER->auth_timeout_field = intval($TYPO3_CONF_VARS['BE']['sessionTimeout']); $BE_USER->OS = TYPO3_OS; if (TYPO3_REQUESTTYPE & TYPO3_REQUESTTYPE_CLI) { $BE_USER->dontSetCookie = TRUE; } $BE_USER->start(); // Object is initialized $BE_USER->checkCLIuser(); $BE_USER->backendCheckLogin(); // Checking if there's a user logged in (I added the @var to help IDEs) -- Kind regards / met vriendelijke groet, Jigal van Hemert skype:jigal.van.hemert msn: jigal at xs4all.nl http://twitter.com/jigalvh From y-saito at iiz.co.jp Thu Feb 10 10:19:58 2011 From: y-saito at iiz.co.jp (yuichiro saito) Date: Thu, 10 Feb 2011 18:19:58 +0900 Subject: [TYPO3-dev] I'd like to work perfectly to copy and move and paste Inline Relational Record on Workspace. Message-ID: <mailman.9775.1297329729.648.typo3-dev@lists.typo3.org> Hi, all! I'm Japanese Web developer. My original extension that show a list of database's records is getting closer to completion, Thanks to you! Now I try to apply Inline Relational Record Edit 1:n [ex:post(1) - tag(n)]. That's success, so refer to other extension "checklists" Francois introduced me in this dev-ML (Thanks Francois! I think this is very simple and superior Ext!), "irre_tutorial" and etc... How lot of extension on TER, I surprised! But there is a problem, if parent record(ex:parentA) copy and paste in BE on workspace, don't show children records in TCAform of pasted parent record(ex:parentB). I confirm there are parentA and parentB's children records in DB table(made by my original extension), and that show on livespace after parentB published. I think this is TYPO3 specifications. But I'd like to work it perfectly. Is there good solution? Thank you. yoroshiku onegaishimasu- :-) -- Yuichiro Saito From y-saito at iiz.co.jp Thu Feb 10 10:28:12 2011 From: y-saito at iiz.co.jp (yuichiro saito) Date: Thu, 10 Feb 2011 18:28:12 +0900 Subject: [TYPO3-dev] I'd like to work perfectly to copy and move and paste Inline Relational Record on Workspace. In-Reply-To: <mailman.9775.1297329729.648.typo3-dev@lists.typo3.org> References: <mailman.9775.1297329729.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.9777.1297330223.648.typo3-dev@lists.typo3.org> Additional Information : typo3 4.5.0 PHP5.2 Thank you :-) -- Yuichiro Saito 2011/2/10 yuichiro saito <y-saito at iiz.co.jp>: > Hi, all! > > I'm Japanese Web developer. > > My original extension that show a list of database's records is > getting closer to completion, > Thanks to you! > > Now I try to apply Inline Relational Record Edit 1:n [ex:post(1) - tag(n)]. > > That's success, so refer to other extension "checklists" Francois > introduced me in this dev-ML > (Thanks Francois! I think this is very simple and superior Ext!), > "irre_tutorial" and etc... How lot of extension on TER, I surprised! > > But there is a problem, if parent record(ex:parentA) copy and paste in > BE on workspace, > don't show children records in TCAform of pasted parent record(ex:parentB). > > I confirm there are parentA and parentB's children records in DB > table(made by my original extension), > and that show on livespace after parentB published. > > I think this is TYPO3 specifications. But I'd like to work it perfectly. > Is there good solution? > > Thank you. yoroshiku onegaishimasu- :-) > > -- > > Yuichiro Saito > _______________________________________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev > -- ???? ????????? ?????? <y-saito at iiz.co.jp> Web : http://www.iiz.co.jp/ Tel : 03-5549-9580 Fax : 03-5549-9583 -- From dmitry.dulepov at gmail.com Thu Feb 10 10:51:51 2011 From: dmitry.dulepov at gmail.com (Dmitry Dulepov) Date: Thu, 10 Feb 2011 11:51:51 +0200 Subject: [TYPO3-dev] EXT: Realurl multi-domain In-Reply-To: <mailman.9330.1297154594.648.typo3-dev@lists.typo3.org> References: <mailman.9330.1297154594.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297331619.15121.typo3-dev@lists.typo3.org> Hi! J. Lingott wrote: > I am wondering about is more the fact of Realurl prepending the root > page id's post var to all the links it generates Never heard of that. Most likely your configuration is incorrect. -- Dmitry Dulepov TYPO3 core&security team member E-mail: dmitry.dulepov at typo3.org Web: http://dmitry-dulepov.com/ From typo3.RemoveForMessage at elements-net.de Thu Feb 10 13:49:37 2011 From: typo3.RemoveForMessage at elements-net.de (Franz Koch) Date: Thu, 10 Feb 2011 13:49:37 +0100 Subject: [TYPO3-dev] Workspace-Issues with menus in 4.5 In-Reply-To: <mailman.1.1297098769.24077.typo3-dev@lists.typo3.org> References: <mailman.1.1297098769.24077.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297342286.11321.typo3-dev@lists.typo3.org> Hey, > I seem to have a rather strange problem with workspaces and menus using > TYPO3 4.5 (didn't check a older version yet). ... > While in workspace preview mode - as long as I'm navigating on pages > which are either "live" or are based on live pages ("existing") the menu > is just fine. But as soon as I klick on a page created out of the > workspace (thus new) I see all hidden pages (like page1-3) in all menus. > > Also page2-2 permanently appears as page1-5 on some menus (like in a CE > "menu/sitemap -> subpages of these pages -> startingPoint:section1), > regardless if I'm on a new or existing page. anybody? Do you need further information about the workspace setup or about anything else? Would be good if the possible bug could make it into 4.5.1. -- kind regards, Franz Koch From jbl at deweblop.de Thu Feb 10 14:12:41 2011 From: jbl at deweblop.de (J. Lingott) Date: Thu, 10 Feb 2011 14:12:41 +0100 Subject: [TYPO3-dev] EXT: Realurl multi-domain In-Reply-To: <mailman.1.1297331619.15121.typo3-dev@lists.typo3.org> References: <mailman.9330.1297154594.648.typo3-dev@lists.typo3.org> <mailman.1.1297331619.15121.typo3-dev@lists.typo3.org> Message-ID: <mailman.9829.1297343646.648.typo3-dev@lists.typo3.org> Hey Dmitry, list! Thanks for your reply. Dmitry Dulepov wrote: > Never heard of that. Most likely your configuration is incorrect. Using a configuration which is actually what you described in your article 'realurl made easy' page 2. And well guess to be more clear, what is happening is the following (and its the page path, not the post var). Page tree looks somthing like this: Page 1 (root page of domain A) - Page 2 - Page 2.1 (root page of domain B) - Page 2.1.1 - Page 2.1.1.1 - Page 2.1.2 - Page 2.1.3 (hidden from menu) ... - Page 3 ... When accessing Page 2 or sub pages (not if they are hidden from menu though), the url generated for the page itself and sub pages looks like this: domainB.tld/page-21/. Although leaving out the page path part for Page 2 would just work fine as well (as mentioned Realurl generates links like that for pages hidden from menu). Additionally, for instance page-2111, i.e. a sub page of a sub page of the current domain's root page gets the link without the page path part of Page 2 as well. To visualize it here's the pages and generated urls again. Page 1 - Page 2 - Page 2.1 domainB.tld/page-21 - Page 2.1.1 domainB.tld/page-21/page-211 - Page 2.1.1.1 domainB.tld/page-2111 - Page 2.1.2 domainB.tld/page-21/page-212 - Page 2.1.3 domainB.tld/page-213 ... - Page 3 ... Thanks for your time J?rg Lingott From dmitry.dulepov at gmail.com Thu Feb 10 14:46:36 2011 From: dmitry.dulepov at gmail.com (Dmitry Dulepov) Date: Thu, 10 Feb 2011 15:46:36 +0200 Subject: [TYPO3-dev] EXT: Realurl multi-domain In-Reply-To: <mailman.9829.1297343646.648.typo3-dev@lists.typo3.org> References: <mailman.9330.1297154594.648.typo3-dev@lists.typo3.org> <mailman.1.1297331619.15121.typo3-dev@lists.typo3.org> <mailman.9829.1297343646.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297345704.17321.typo3-dev@lists.typo3.org> Hi! J. Lingott wrote: > Page tree looks somthing like this: > Page 1 (root page of domain A) > - Page 2 > - Page 2.1 (root page of domain B) Nested domains: source of biiiiiiiiiiiiiig troubles... -- Dmitry Dulepov TYPO3 core&security team member E-mail: dmitry.dulepov at typo3.org Web: http://dmitry-dulepov.com/ From info at tolleiv.de Thu Feb 10 18:39:30 2011 From: info at tolleiv.de (Tolleiv Nietsch) Date: Thu, 10 Feb 2011 18:39:30 +0100 Subject: [TYPO3-dev] cookieSecure & cli_dispatcher In-Reply-To: <mailman.1.1297319672.9816.typo3-dev@lists.typo3.org> References: <mailman.1.1297256701.8932.typo3-dev@lists.typo3.org> <mailman.1.1297258937.13321.typo3-dev@lists.typo3.org> <mailman.1.1297259430.14326.typo3-dev@lists.typo3.org> <mailman.1.1297264948.25640.typo3-dev@lists.typo3.org> <mailman.1.1297297098.12721.typo3-dev@lists.typo3.org> <mailman.1.1297319672.9816.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297359595.10622.typo3-dev@lists.typo3.org> Great thanks, see http://bugs.typo3.org/view.php?id=17541 in core list. Cheers, Tolleiv -- Tolleiv Nietsch www.tolleiv.de - www.aoemedia.de From rik at actiview.nl Thu Feb 10 20:30:18 2011 From: rik at actiview.nl (Rik Willems) Date: Thu, 10 Feb 2011 20:30:18 +0100 Subject: [TYPO3-dev] Page title as cObject Message-ID: <mailman.1.1297366325.22423.typo3-dev@lists.typo3.org> Hi, Currently we can combine config.noPageTitle = 2 and page.headerData.5 = TEXT (COA) to create a custom <title> tag for our pages. This works, but not for indexers (in my case Solr). This is because this technique doesn't actually change the page title for TYPO3, but only the output. tt_news changes the page title for single view by: $GLOBALS['TSFE']->page['title'] = $row['title']; $GLOBALS['TSFE']->indexedDocTitle = $row['title']; When I use typoscript to display lists or records on pages the page title for TYPO3 remains the title of the page it is shown on. For the Solr indexer (and perhaps the indexed_search indexer too) this is very uncomfortable. The search results all display the same titles. Would it be a good idea to create an option to render the page title through a cObject? Now I used config.titleTagFunction to use a userfunction which is a bit of a detour. What do you think? Cheers! From mark at nasaustralia.com.au Fri Feb 11 03:07:03 2011 From: mark at nasaustralia.com.au (Mark Roemermann) Date: Fri, 11 Feb 2011 12:07:03 +1000 Subject: [TYPO3-dev] [TYPO3-v4] Schedule for TYPO3 4.5.1 In-Reply-To: <mailman.9719.1297273058.648.typo3-dev@lists.typo3.org> References: <mailman.9715.1297272302.648.typo3-dev@lists.typo3.org> <mailman.9719.1297273058.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297390215.23683.typo3-dev@lists.typo3.org> I agree. As a non-programmer I've loved reading Ernesto's 'minutes' over the course of 4.5 development. Really helps outsiders get a feeling for the progress and the speed bumps during a cycle, and creates a great impression of cohesive organisation. I hope whoever takes on the release manager/team mantle for 4.6 continues with something similar. keep up the great work. On 10/02/2011 3:35 AM, Christopher Torgalson wrote: > Hi Ernesto, > > These updates you've been sending around the core team's activity and > releases are *fantastic*. It's great to know what's happening 'behind > the curtain' :) > From tomasnorre at gmail.com Fri Feb 11 09:53:54 2011 From: tomasnorre at gmail.com (Tomas Norre Mikkelsen) Date: Fri, 11 Feb 2011 09:53:54 +0100 Subject: [TYPO3-dev] GIFBUILDER Problem after upgrade to 4.5 In-Reply-To: <mailman.1.1296826030.9609.typo3-dev@lists.typo3.org> References: <mailman.1.1296826030.9609.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297414544.8845.typo3-dev@lists.typo3.org> On 04-02-2011 14:25, Tomas Norre Mikkelsen wrote: > Hi, > > I have just update a typo3-website, from 4.2.12 -> 4.5 ( I know large > gap), after upgrade typo3_src and typo3-ext it almost works like a > charm, except my Menu and Header build with GIFBUILDER. > > Any know issues on this topic that i'm not aware of? Tried to google but > not much data indexed on the topic yet =) I found more details on the problem. I have following TS for my Gifbuilder: lib.primary_navigation_level2 = HMENU lib.primary_navigation_level2.entryLevel =1 lib.primary_navigation_level2.1 = GMENU lib.primary_navigation_level2.1 { entryLevel =2 NO { #backColor = #c4c4c4 XY = [10.w]+52,21 4 = IMAGE 4.file = fileadmin/templates/beierholm/images/menu_level2_no.gif 10 = TEXT 10.text.field = title 10.fontColor = #000000 10.offset = 0,15 10.fontFile = fileadmin/templates/beierholm/fonts/Founmm__.ttf 10.fontSize = 12 10.align = center 10.niceText = 1 10.antiAlias =1 } If using: 4.file = fileadmin/templates/beierholm/images/menu_level2_no.gif [1] I will not render the menu the background image is displayed, but the text is added after to the right as dots. When using this: 4.file = fileadmin/templates/beierholm/images/menu_level2_new.gif [2] it works. The to gif are made excatly the same, but will not render the same. If using the backColor = #c4c4c4 (grey) It works too. but the backColor = #d16103 (orange) does not work. Any hints on this topic, i found this very strange. [1]: http://dl.dropbox.com/u/14455043/menu_level2_no.gif [2]: http://dl.dropbox.com/u/14455043/menu_level2_new.gif Best Regards Tomas From jigal at xs4all.nl Fri Feb 11 12:06:22 2011 From: jigal at xs4all.nl (Jigal van Hemert) Date: Fri, 11 Feb 2011 12:06:22 +0100 Subject: [TYPO3-dev] GIFBUILDER Problem after upgrade to 4.5 In-Reply-To: <mailman.1.1297414544.8845.typo3-dev@lists.typo3.org> References: <mailman.1.1296826030.9609.typo3-dev@lists.typo3.org> <mailman.1.1297414544.8845.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297422490.24277.typo3-dev@lists.typo3.org> Hi, On 11-2-2011 9:53, Tomas Norre Mikkelsen wrote: > On 04-02-2011 14:25, Tomas Norre Mikkelsen wrote: >> I have just update a typo3-website, from 4.2.12 -> 4.5 ( I know large >> gap), after upgrade typo3_src and typo3-ext it almost works like a >> charm, except my Menu and Header build with GIFBUILDER. The two GIF files are byte-wise identical except for the colour palette. It seems that there is a palette issue on your installation, which might have become visible because of some changes in the graphics routines. I'll try to take a look at the settings you've sent me by private mail to see if there's option missing to process this better. -- Kind regards / met vriendelijke groet, Jigal van Hemert skype:jigal.van.hemert msn: jigal at xs4all.nl http://twitter.com/jigalvh From gloichot at cross-systems.com Fri Feb 11 13:18:45 2011 From: gloichot at cross-systems.com (Gregory Loichot) Date: Fri, 11 Feb 2011 13:18:45 +0100 Subject: [TYPO3-dev] sql insert... what happen ??? !!! Message-ID: <mailman.1.1297426834.31676.typo3-dev@lists.typo3.org> Hello, I'm using TYPO3 4.4.6 and I'm doing a simple thing : $aQ = array ( 'date' => time(), 'action'=> $action, 'username'=> $username, 'rubicsid' => $rubicsid, 'email' => $email, 'service' => $service); $GLOBALS['TYPO3_DB']->exec_INSERTquery('tx_cr', $aQ); The executed query is..... : INSERT INTO tx_cr (date,action,username,rubicsid,email,service) VALUES ('','echec signin unknown','','','xxx at yopmail.com','global'); Question : why "date" field is empty ? I inspect into class.t3lib_db.php, in fullQuoteArray function. Before the foreach, we have $arr : Array ( [date] => 1297426187 [action] => echec signin unknown [username] => [rubicsid] => [email] => xxx at yopmail.com [service] => global ) and AFTER : Array ( [date] => '' [action] => 'echec signin unknown' [username] => '' [rubicsid] => '' [email] => 'xxx at yopmail.com' [service] => 'global' ) Any ideas ? From rik at actiview.nl Fri Feb 11 14:45:13 2011 From: rik at actiview.nl (Rik Willems) Date: Fri, 11 Feb 2011 14:45:13 +0100 Subject: [TYPO3-dev] maxImageWidth register in css_styled_content Message-ID: <mailman.1.1297432022.8326.typo3-dev@lists.typo3.org> Hi all, In my quest for cool typoscript solutions I came across the maxImageWidth register in the css_styled_content setup. Through a quick grep I couldn't find any real reference to this register. Does anybody know a case where it is actually set? Cheers! From typo3.RemoveForMessage at elements-net.de Fri Feb 11 16:23:58 2011 From: typo3.RemoveForMessage at elements-net.de (Franz Koch) Date: Fri, 11 Feb 2011 16:23:58 +0100 Subject: [TYPO3-dev] maxImageWidth register in css_styled_content In-Reply-To: <mailman.1.1297432022.8326.typo3-dev@lists.typo3.org> References: <mailman.1.1297432022.8326.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297437947.18194.typo3-dev@lists.typo3.org> Hi, > In my quest for cool typoscript solutions I came across the > maxImageWidth register in the css_styled_content setup. Through a quick > grep I couldn't find any real reference to this register. > > Does anybody know a case where it is actually set? Isn't it sufficient to know that you can set it to adjust the image width let's say for different content columns? ;) -- kind regards, Franz Koch From tomasnorre at gmail.com Fri Feb 11 20:18:48 2011 From: tomasnorre at gmail.com (Tomas Norre Mikkelsen) Date: Fri, 11 Feb 2011 20:18:48 +0100 Subject: [TYPO3-dev] =?iso-8859-1?q?_=B4TYPO3_Development_Invironment?= Message-ID: <mailman.1.1297452037.7654.typo3-dev@lists.typo3.org> Hi, I have a topic I you like to discuss. My question is: How to setup a proper TYPO3 development invironment, as I see it there are several issues need to consider. How do you manage to keep track of changes in development and production invironment ? The php files is simple, cause svn/cvs/git etc. We consider making the TS as plain files too, such they are easier to versioning. The main problem is, how to maintain the Database, do you make sql-patches or how do you apply new fields etc on production data? Hope my question are clear, think its a difficult topic to explain clearly by mail. Behaps a skype-talk could help =) All inputs are welcome, and if more information is prefered, i'll be glad to share. ps: I'm so sorry, if any recieve duplets of this email, I didn't recieve it my self, so took the chance of sending it again.. Sorry if so. Best Regards Tomas Norre Mikkelsen From soren.malling at gmail.com Fri Feb 11 21:29:49 2011 From: soren.malling at gmail.com (=?ISO-8859-1?Q?S=F8ren_Malling?=) Date: Fri, 11 Feb 2011 21:29:49 +0100 Subject: [TYPO3-dev] =?iso-8859-1?q?=B4TYPO3_Development_Invironment?= In-Reply-To: <mailman.1.1297452037.7654.typo3-dev@lists.typo3.org> References: <mailman.1.1297452037.7654.typo3-dev@lists.typo3.org> Message-ID: <mailman.10022.1297456301.648.typo3-dev@lists.typo3.org> Hi Thomas > > How do you manage to keep track of / > The main problem is, how to maintain the Database, do you make sql-patches or how do you apply new fields etc on production data? > May I add the same question type for example be_groups which is stored in the database and exportable by a t3d files only (am I wrong?) I'm looking forward to any response :) Regards S?ren -- S?ren Malling TYPO3 Brugergruppe Danmark: www.typo3danmark.dk Twitter: twitter.com/sorenmalling From tomasnorre at gmail.com Fri Feb 11 21:30:09 2011 From: tomasnorre at gmail.com (Tomas Norre Mikkelsen) Date: Fri, 11 Feb 2011 21:30:09 +0100 Subject: [TYPO3-dev] Ignoring warnings in T3 src, why ? Message-ID: <mailman.1.1297456318.14572.typo3-dev@lists.typo3.org> Hi List, I have a question regarding coding standard in the TYPO3-core. The other day I was trying to send some test-emails from my development server. Cause the server has safe_mode = on as default, the mails were not sent. I found out that it was because of the safe_mode = on and the conditions in the t3lib_utility_Mail class[1] in the static mail function. If safe_mode is disable and the "$additionalParameters = null" then the mail is not sent. Line 69 is as follows: $success = @mail($to, $subject, $messageBody, $additionalHeaders, $additionalParameters); My question is, why is the @ used such warnings are ignored, if this was not set, It would have been easier for me to see that my problems were caused by safe_mode = on. It there reason for using the @ such warnings etc. are ignored ? Perhaps i'm not the developer to see the point, but if there is an explaination, I would like it such I can learn from it. =) [1] http://pastebin.com/kZPB8tsu -- Best Regards Tomas Norre Mikkelsen Tomasnorre at gmail.com From jigal at xs4all.nl Fri Feb 11 23:09:41 2011 From: jigal at xs4all.nl (Jigal van Hemert) Date: Fri, 11 Feb 2011 23:09:41 +0100 Subject: [TYPO3-dev] Ignoring warnings in T3 src, why ? In-Reply-To: <mailman.1.1297456318.14572.typo3-dev@lists.typo3.org> References: <mailman.1.1297456318.14572.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297462290.23510.typo3-dev@lists.typo3.org> Hi, On 11-2-2011 21:30, Tomas Norre Mikkelsen wrote: > I have a question regarding coding standard in the TYPO3-core. > > The other day I was trying to send some test-emails from my development > server. Cause the server has safe_mode = on as default, the mails were > not sent. safe_mode is a bad concept [1] and should not be enabled. > I found out that it was because of the safe_mode = on and the conditions > in the t3lib_utility_Mail class[1] in the static mail function. > > If safe_mode is disable and the "$additionalParameters = null" then the > mail is not sent. In this case there is no extra parameter passed to sendmail and mails can be rejected by the receiving server, etc. > My question is, why is the @ used such warnings are ignored, if this was > not set, It would have been easier for me to see that my problems were > caused by safe_mode = on. The @ is added to suppress the *display* of warnings and errors. It is simply not good to display PHP warnings or error when visitors use the website. In safe_mode the additional_parameters parameter is disabled, so it will not be used at all by the mail() command. The PHP mail() command is pretty easy, but has a lot of drawbacks. It is very hard to find the reason why mails are not received, it's virtually impossible to handle errors in mail sending, etc. If you upgrade to 4.5.0LTS TYPO3 will use the Swift Mailer library to send mails. This has better configuration options and can handle the whole SMTP process internally (thus providing feedback on the results). The 4.5 core uses Swift Mailer internally and calls to t3lib_utility_Mail are also passed to the Swift Mailer library. [1] http://www.php.net/manual/en/features.safe-mode.php -- Kind regards / met vriendelijke groet, Jigal van Hemert skype:jigal.van.hemert msn: jigal at xs4all.nl http://twitter.com/jigalvh From tomasnorre at gmail.com Sat Feb 12 07:42:07 2011 From: tomasnorre at gmail.com (Tomas Norre Mikkelsen) Date: Sat, 12 Feb 2011 07:42:07 +0100 Subject: [TYPO3-dev] Ignoring warnings in T3 src, why ? In-Reply-To: <mailman.1.1297462290.23510.typo3-dev@lists.typo3.org> References: <mailman.1.1297456318.14572.typo3-dev@lists.typo3.org> <mailman.1.1297462290.23510.typo3-dev@lists.typo3.org> Message-ID: <mailman.10047.1297493067.648.typo3-dev@lists.typo3.org> Thanks for the anserw. I know the function is changed in 4.5. But was interrested in knowing why. My point of view is, It's ok to suppress warnings/errors If you Can ensure there are none :) A simple If arround checking the additional parameters would been enough. But thx anyway. Just wanted to get a view at the topic why done this way. -- Tomas Norre Mikkelsen Tomasnorre at gmail.com :: Sent from my iPhone :: Den 11/02/2011 kl. 23.13 skrev Jigal van Hemert <jigal at xs4all.nl>: > Hi, > > On 11-2-2011 21:30, Tomas Norre Mikkelsen wrote: >> I have a question regarding coding standard in the TYPO3-core. >> >> The other day I was trying to send some test-emails from my development >> server. Cause the server has safe_mode = on as default, the mails were >> not sent. > > safe_mode is a bad concept [1] and should not be enabled. > >> I found out that it was because of the safe_mode = on and the conditions >> in the t3lib_utility_Mail class[1] in the static mail function. >> >> If safe_mode is disable and the "$additionalParameters = null" then the >> mail is not sent. > > In this case there is no extra parameter passed to sendmail and mails can be rejected by the receiving server, etc. > >> My question is, why is the @ used such warnings are ignored, if this was >> not set, It would have been easier for me to see that my problems were >> caused by safe_mode = on. > > The @ is added to suppress the *display* of warnings and errors. It is simply not good to display PHP warnings or error when visitors use the website. > In safe_mode the additional_parameters parameter is disabled, so it will not be used at all by the mail() command. > > The PHP mail() command is pretty easy, but has a lot of drawbacks. It is very hard to find the reason why mails are not received, it's virtually impossible to handle errors in mail sending, etc. > > If you upgrade to 4.5.0LTS TYPO3 will use the Swift Mailer library to send mails. This has better configuration options and can handle the whole SMTP process internally (thus providing feedback on the results). > The 4.5 core uses Swift Mailer internally and calls to t3lib_utility_Mail are also passed to the Swift Mailer library. > > [1] http://www.php.net/manual/en/features.safe-mode.php > > -- > Kind regards / met vriendelijke groet, > > Jigal van Hemert > skype:jigal.van.hemert > msn: jigal at xs4all.nl > http://twitter.com/jigalvh > _______________________________________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev From jigal at xs4all.nl Sat Feb 12 14:36:28 2011 From: jigal at xs4all.nl (Jigal van Hemert) Date: Sat, 12 Feb 2011 14:36:28 +0100 Subject: [TYPO3-dev] GIFBUILDER Problem after upgrade to 4.5 In-Reply-To: <mailman.1.1297414544.8845.typo3-dev@lists.typo3.org> References: <mailman.1.1296826030.9609.typo3-dev@lists.typo3.org> <mailman.1.1297414544.8845.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297517899.14912.typo3-dev@lists.typo3.org> Hi, On 11-2-2011 9:53, Tomas Norre Mikkelsen wrote: > I will not render the menu the background image is displayed, but the > text is added after to the right as dots. I could reproduce the problem partly; with another font (I don't have the font you use) the text was not displayed at all in the circumstances you described. The problem occurs with ImageMagick-6.6.6-10-Q16 and ImageMagick-6.6.7-6-Q16. With ImageMagick-6.6.7-6-Q8 the Install Tool mage tests with Nicetext, shadow, etc. simply fail. With GraphicsMagick (1.3.12) the menu renders correctly with both backColors and both GIF files. It seems that IM is really messed up with handling of transparency :-( Things you can try: - turn of Nicetext; with most fonts it doesn't look very well at all. If a TrueType font looks bad the Type1 version can look better - use only a background color instead of a GIF with a single solid colour - use GraphicsMagick (it also seems to be faster) -- Kind regards / met vriendelijke groet, Jigal van Hemert skype:jigal.van.hemert msn: jigal at xs4all.nl http://twitter.com/jigalvh From rik at actiview.nl Sat Feb 12 14:47:39 2011 From: rik at actiview.nl (Rik Willems) Date: Sat, 12 Feb 2011 14:47:39 +0100 Subject: [TYPO3-dev] maxImageWidth register in css_styled_content In-Reply-To: <mailman.1.1297437947.18194.typo3-dev@lists.typo3.org> References: <mailman.1.1297432022.8326.typo3-dev@lists.typo3.org> <mailman.1.1297437947.18194.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297518567.15613.typo3-dev@lists.typo3.org> That is exactly what I had in mind. But before screwing things up by override behaviour in certain places I thought to ask here. I used a different technique before to change widths per column, but this register seems much more suitable. Although I never saw an example of this before on any of the snippets sites. Cheers! Op 11-2-2011 16:23, Franz Koch schreef: > Hi, > >> In my quest for cool typoscript solutions I came across the >> maxImageWidth register in the css_styled_content setup. Through a quick >> grep I couldn't find any real reference to this register. >> >> Does anybody know a case where it is actually set? > > Isn't it sufficient to know that you can set it to adjust the image > width let's say for different content columns? ;) > From peter at clioonline.dk Sun Feb 13 14:31:38 2011 From: peter at clioonline.dk (Peter Klein) Date: Sun, 13 Feb 2011 14:31:38 +0100 Subject: [TYPO3-dev] tslib_content_stdWrapHook and TYPO3 v4.5.0 different from previous versions Message-ID: <mailman.1.1297604006.11456.typo3-dev@lists.typo3.org> In one of my extensions (PMK Forced Download), I use the "tslib_content_stdWrapHook" hook in "/sysext/cms/tslib/interfaces/interface.tslib_content_stdwraphook.php" to extend stdWrap. In TYPO3 versions prior to v4.5.0, I could pass a parameter from TypoScript like this: -- cut -- 10 = TEXT 10.value = download 10.typolink.parameter = fileadmin/templates/testfile.pdf 10.typolink.parameter.makeDownloadLink = 1 -- cut -- And then in the hook I access my custom stdWrap parameter "makeDownloadLink", like this: -- cut -- public function stdWrapProcess($content, array $configuration, tslib_cObj &$parentObject) { if ($configuration['makeDownloadLink']) { $content = tx_pmkfdl::makeDownloadLink($content,$configuration); } return $content; } -- cut -- But in TYPO3 v4.5.0 this no longer works. I now have to specify the TypoScript parameter like this: -- cut -- 10 = TEXT 10.value = download 10.typolink.parameter = fileadmin/templates/testfile.pdf 10.typolink.parameter.stdWrapProcess.makeDownloadLink = 1 -- cut -- And to access it in the hook I need to do this: -- cut -- public function stdWrapProcess($content, array $configuration, tslib_cObj &$parentObject) { if ($configuration['stdWrapProcess.']['makeDownloadLink']) { $content = tx_pmkfdl::makeDownloadLink($content,$configuration); } return $content; } -- cut -- Is this intentional or a bug? -- Peter Klein / Clio Online From info at cybercraft.de Sun Feb 13 14:41:26 2011 From: info at cybercraft.de (JoH asenau) Date: Sun, 13 Feb 2011 14:41:26 +0100 Subject: [TYPO3-dev] tslib_content_stdWrapHook and TYPO3 v4.5.0 different from previous versions In-Reply-To: <mailman.1.1297604006.11456.typo3-dev@lists.typo3.org> References: <mailman.1.1297604006.11456.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297604557.12936.typo3-dev@lists.typo3.org> Am 13.02.2011 14:31, schrieb Peter Klein: > In one of my extensions (PMK Forced Download), I use the > "tslib_content_stdWrapHook" hook in > "/sysext/cms/tslib/interfaces/interface.tslib_content_stdwraphook.php" > to extend stdWrap. > > Is this intentional or a bug? http://bugs.typo3.org/view.php?id=17507 HTH 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 peter at clioonline.dk Sun Feb 13 14:55:35 2011 From: peter at clioonline.dk (Peter Klein) Date: Sun, 13 Feb 2011 14:55:35 +0100 Subject: [TYPO3-dev] tslib_content_stdWrapHook and TYPO3 v4.5.0 different from previous versions References: <mailman.1.1297604006.11456.typo3-dev@lists.typo3.org> <mailman.1.1297604557.12936.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297605443.14566.typo3-dev@lists.typo3.org> Thanks for the quick reply.. I'll just wait for the 4.5.1 update :) -- Peter klein / Clio Online. On Sun, 13 Feb 2011 14:41:26 +0100, JoH asenau <info at cybercraft.de> wrote: >Am 13.02.2011 14:31, schrieb Peter Klein: >> In one of my extensions (PMK Forced Download), I use the >> "tslib_content_stdWrapHook" hook in >> "/sysext/cms/tslib/interfaces/interface.tslib_content_stdwraphook.php" >> to extend stdWrap. >> >> Is this intentional or a bug? > >http://bugs.typo3.org/view.php?id=17507 > >HTH > >Joey From info at sk-typo3.de Sun Feb 13 22:51:35 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Sun, 13 Feb 2011 22:51:35 +0100 Subject: [TYPO3-dev] TYPO3 4.5 performance session Message-ID: <mailman.1.1297634006.24936.typo3-dev@lists.typo3.org> Hi, today i met Rupi and we did some profiling with TYPO3 4.5. As FE page generation is nearly the same like in 4.4, we concentrated on BE. The basic was usage of cachegrind, and we examined one initial load of the BE with about module. Further we examined pagetree and the list module with pid 0. We found many issues and tried to break it down for possible solutions. One main thing we examined are the ajax.php calls mainly for ExtDirect. On initial BE load, there are 6 calls to ajax.php for the ExtDirect API. Each call is a single instance, which use init.php, and makes a complete init of a BE session including be_user init, localconf analysis (extMgm) and many other things. You can imagine that this takes time and resources. So i had an idea to get rid of all of these ajax calls. They are only needed to generate the ExtDirect API for a given namespace, each namespace need a single instance. My idea bases on a register function in pageRenderer for needed ExtDirect namespace. The API can be generated in php and can be included in render process of pageRenderer. This would mean: no request for namespace is needed, getting rid of 6+ requests. Then we found some other issues, where i already created patches for. jsMinify is called for each js script in BE that is included. This is mot needed at all, all scripts are processed from compressor anyway. BErootline, mostly neaded for the viewonclick calculation, is called with anchor (list view). That means, if you have 20 content elements on page 2, the rootline is called with following uids: 2#421 2#845 2#666 a.s.o. Unnecessary to mention that no cache entry will be used for each of them, as calculatet ident is different for each CE. So i made a patch to strip out anchor if present, and all of them use the cache. One more finding, and very surprising, was the security token generation. On first place of php used functions for external resources was fread, which happens in security token generation. Base is the function t3lib_div::generateRandomBytes which use @fopen('/dev/urandom', 'rb') MySQL was on place 4 here, i expected other ranking. Rupi will research if there is an alternative way to generate random bytes, i will ask Helmut to look also for something. We also examined CSH in user setupo, which behaves different as it should - there was new request on any hover on the next label. It should be the case, that one request get all CSH for a specific file and hold it in memory, so you get one request for all CSH on one page (normally) These are the findings so far, and i look forward to come with patches soon. vg Steffen From info at sk-typo3.de Sun Feb 13 22:54:40 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Sun, 13 Feb 2011 22:54:40 +0100 Subject: [TYPO3-dev] TYPO3 4.5 performance session In-Reply-To: <mailman.1.1297634006.24936.typo3-dev@lists.typo3.org> References: <mailman.1.1297634006.24936.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297634191.25208.typo3-dev@lists.typo3.org> Hi, long term solution: we need a smaller init.php for ajax calls. It's not necessary to load all TCA / localconfs etc just for save a setting in BE-USER->uc. Ideal would be to have defined what you need for a special request, so eg BE_USER save/get only need user initialization. vg Steffen From steffen.gebert at typo3.org Sun Feb 13 23:12:54 2011 From: steffen.gebert at typo3.org (Steffen Gebert) Date: Sun, 13 Feb 2011 23:12:54 +0100 Subject: [TYPO3-dev] TYPO3 4.5 performance session In-Reply-To: <mailman.1.1297634006.24936.typo3-dev@lists.typo3.org> References: <mailman.1.1297634006.24936.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297635285.26379.typo3-dev@lists.typo3.org> Hi, > Then we found some other issues, where i already created patches for. > jsMinify is called for each js script in BE that is included. This is > mot needed at all, all scripts are processed from compressor anyway. It's only for the inline JS, isn't it? I also noticed JSmin to take lots of time for only saving few bytes. > On first place of php used functions for external resources was fread, > which happens in security token generation. Base is the function > t3lib_div::generateRandomBytes which use > @fopen('/dev/urandom', 'rb') Marcus already created an issue for restructuring of this function. There's also a PHP bug, where others discuss our solution and say it's not optimal (regarding the order of functions used to generate random data). Kind regards Steffen -- Steffen Gebert TYPO3 v4 Core Team Member TYPO3 .... inspiring people to share! Get involved: http://typo3.org From info at sk-typo3.de Sun Feb 13 23:28:44 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Sun, 13 Feb 2011 23:28:44 +0100 Subject: [TYPO3-dev] TYPO3 4.5 performance session In-Reply-To: <mailman.1.1297635285.26379.typo3-dev@lists.typo3.org> References: <mailman.1.1297634006.24936.typo3-dev@lists.typo3.org> <mailman.1.1297635285.26379.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297636235.28398.typo3-dev@lists.typo3.org> Hi, Am 13.02.2011 23:12, schrieb Steffen Gebert: > Hi, > >> Then we found some other issues, where i already created patches for. >> jsMinify is called for each js script in BE that is included. This is >> mot needed at all, all scripts are processed from compressor anyway. > It's only for the inline JS, isn't it? I also noticed JSmin to take lots > of time for only saving few bytes. > yes, it's for inline. We really have a lot of inline script in the BE, and we should do the same we suggest for each FE page: write it to a temp file. >> On first place of php used functions for external resources was fread, >> which happens in security token generation. Base is the function >> t3lib_div::generateRandomBytes which use >> @fopen('/dev/urandom', 'rb') > Marcus already created an issue for restructuring of this function. > There's also a PHP bug, where others discuss our solution and say it's > not optimal (regarding the order of functions used to generate random > data). > fine! vg Steffen From steffen.gebert at typo3.org Mon Feb 14 08:22:09 2011 From: steffen.gebert at typo3.org (Steffen Gebert) Date: Mon, 14 Feb 2011 08:22:09 +0100 Subject: [TYPO3-dev] TYPO3 4.5 performance session In-Reply-To: <mailman.1.1297636235.28398.typo3-dev@lists.typo3.org> References: <mailman.1.1297634006.24936.typo3-dev@lists.typo3.org> <mailman.1.1297635285.26379.typo3-dev@lists.typo3.org> <mailman.1.1297636235.28398.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297668240.17205.typo3-dev@lists.typo3.org> > yes, it's for inline. We really have a lot of inline script in the BE, > and we should do the same we suggest for each FE page: write it to a > temp file. There's no dynamic content inside? Thus can we really extract all of it? Kind regards Steffen -- Steffen Gebert TYPO3 v4 Core Team Member TYPO3 .... inspiring people to share! Get involved: http://typo3.org From fsu-lists at cobweb.ch Mon Feb 14 08:43:04 2011 From: fsu-lists at cobweb.ch (=?ISO-8859-15?Q?Fran=E7ois_Suter?=) Date: Mon, 14 Feb 2011 08:43:04 +0100 Subject: [TYPO3-dev] TYPO3 4.5 performance session In-Reply-To: <mailman.1.1297634191.25208.typo3-dev@lists.typo3.org> References: <mailman.1.1297634006.24936.typo3-dev@lists.typo3.org> <mailman.1.1297634191.25208.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297669498.19533.typo3-dev@lists.typo3.org> Hi, > long term solution: we need a smaller init.php for ajax calls. It's not > necessary to load all TCA / localconfs etc just for save a setting in > BE-USER->uc. Ideal would be to have defined what you need for a special > request, so eg BE_USER save/get only need user initialization. That was the whole idea of refactoring init.php: cut it into small functional chunks, that can be included as needed. This was it would be very easy to create a variety of initialization scripts, tailored to suit particular needs. As I'm concentrating on documentation I won't have time to push this further, but Christian picked it up recently under the heading of "bootstrapping" and I know Benni is also interested in the topic. IMO it would be a very good project to kickstart in Berlin. Cheers -- Francois Suter Cobweb Development Sarl - http://www.cobweb.ch From info at sk-typo3.de Mon Feb 14 09:16:31 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 14 Feb 2011 09:16:31 +0100 Subject: [TYPO3-dev] TYPO3 4.5 performance session In-Reply-To: <mailman.1.1297668240.17205.typo3-dev@lists.typo3.org> References: <mailman.1.1297634006.24936.typo3-dev@lists.typo3.org> <mailman.1.1297635285.26379.typo3-dev@lists.typo3.org> <mailman.1.1297636235.28398.typo3-dev@lists.typo3.org> <mailman.1.1297668240.17205.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297671503.22635.typo3-dev@lists.typo3.org> Hi, Am 14.02.2011 08:22, schrieb Steffen Gebert: >> yes, it's for inline. We really have a lot of inline script in the BE, >> and we should do the same we suggest for each FE page: write it to a >> temp file. > > There's no dynamic content inside? Thus can we really extract all of it? > while rendering the content is calculated. vg Steffen From info at sk-typo3.de Mon Feb 14 09:18:29 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 14 Feb 2011 09:18:29 +0100 Subject: [TYPO3-dev] TYPO3 4.5 performance session In-Reply-To: <mailman.1.1297669498.19533.typo3-dev@lists.typo3.org> References: <mailman.1.1297634006.24936.typo3-dev@lists.typo3.org> <mailman.1.1297634191.25208.typo3-dev@lists.typo3.org> <mailman.1.1297669498.19533.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297671621.22635.typo3-dev@lists.typo3.org> Hi, Am 14.02.2011 08:43, schrieb Fran?ois Suter: > Hi, > >> long term solution: we need a smaller init.php for ajax calls. It's not >> necessary to load all TCA / localconfs etc just for save a setting in >> BE-USER->uc. Ideal would be to have defined what you need for a special >> request, so eg BE_USER save/get only need user initialization. > > That was the whole idea of refactoring init.php: cut it into small > functional chunks, that can be included as needed. This was it would be > very easy to create a variety of initialization scripts, tailored to > suit particular needs. > > As I'm concentrating on documentation I won't have time to push this > further, but Christian picked it up recently under the heading of > "bootstrapping" and I know Benni is also interested in the topic. IMO it > would be a very good project to kickstart in Berlin. > i have this in mind, and i see this as a very important project. I remember your document about init.php process, and this can help for kickstarting. I will support it too. vg Steffen From info at sk-typo3.de Mon Feb 14 09:23:42 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 14 Feb 2011 09:23:42 +0100 Subject: [TYPO3-dev] TYPO3 4.5 performance session In-Reply-To: <mailman.1.1297634006.24936.typo3-dev@lists.typo3.org> References: <mailman.1.1297634006.24936.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297671934.23654.typo3-dev@lists.typo3.org> Hi, i made a pre-test patch which does the static include of ExtDirect API. If you are intersted you can try it out, it boosts the performance immense. It's not cleaned up yet, but can be taken as base for discussion. After this patch you don't need to include the api script in your page. It doesn't break the code, it only slows down. This is also very logical imho, if you use ExtDirect you only have to make one init call: $this->pageRenderer->addExtDirectCode(); vg Steffen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: extdirect_api.patch URL: <http://lists.typo3.org/pipermail/typo3-dev/attachments/20110214/ac03254b/attachment.asc> From alexander_all at yahoo.de Mon Feb 14 10:29:29 2011 From: alexander_all at yahoo.de (Alexander All) Date: Mon, 14 Feb 2011 09:29:29 +0000 (GMT) Subject: [TYPO3-dev] "nested" domain object with fluid and extbase Message-ID: <mailman.10182.1297675882.648.typo3-dev@lists.typo3.org> Hello Everybody, i try to creat an new, "nested" domain object with fluid and extbase. The problem is that company-object contains another object. My question is: how should the fluid template looks like? Is that action in one step possible? Thanks Below are the models, template and the action: Tx_MyExt_Domain_Model_Company extends Tx_Extbase_DomainObject_AbstractEntity { /** * @var string */ protected $name = ''; /** * @var Tx_Extbase_Persistence_ObjectStorage<Tx_MyExt_Domain_Model_Employee> * @lazy * @cascade remove **/ protected $employees; /** * Constructs a new Company */ public function __construct() { $this->employees = new Tx_Extbase_Persistence_ObjectStorage(); } /* Setter & Getter for $name */ .. /** * @param Tx_MyExt_Domain_Model_Employee * @return void */ public function addEmployee(Tx_MyExt_Domain_Model_Employee $employee) { $this->employees->attach($employee); } /** * @param Tx_MyExt_Domain_Model_Employee * @return void */ public function removeEmployee(Tx_MyExt_Domain_Model_Employee $employee) { $this->employees->detach($employee); } } Tx_MyExt_Domain_Model_Employee extends Tx_Extbase_DomainObject_AbstractEntity { /** * @var string */ protected $name = ''; /* Setter & Getter for $name */ .. } Fluid-Template <f:form method="post" controller="Foo" action="create" name="newCompany" object="{newCompany}"> <f:form.textfield property="name" /> <!-- does not work however --> <f:form.textfield property="employees.name" /> <f:form.submit value="Submit"/> </f:form> Controller /** * Creates a new Company * * @param Tx_MyExt_Domain_Model_Company $newCompany * @return void * @dontverifyrequesthash */ public function createAction(Tx_MyExt_Domain_Model_Company $newCompany) { } From simon at srchild.com Mon Feb 14 10:48:36 2011 From: simon at srchild.com (Simon Child) Date: Mon, 14 Feb 2011 09:48:36 -0000 Subject: [TYPO3-dev] Password reset links breaking - felogin Message-ID: <mailman.1.1297676802.3714.typo3-dev@lists.typo3.org> Password reset email links for felogin tend to break in the email client, and then the user complains that it doesn't work when they click on it. There are at least three issues here: 1. The links are very long and wrap which causes a break in some email clients 2. Some email clients break on the opening [ 3. Thunderbird breaks a link at the pipe symbol | For myself, in a non-transferrable way, I've fixed the first two. I've hacked the source of class.tx_felogin_pi1.php to send shorter links, without any [, by inserting at line 371 $link='http://www.example.com/pH/'.$randHash.'/'.$user['uid']; (where pH is just an arbitrary short name of a non-existent directory, www.example.com is my domain) and in .htaccess rewrite this back to the form that felogin expects RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC] RewriteCond %{HTTP_HOST} !^$ RewriteCond %{REQUEST_URI} ^/pH/.* RewriteRule ^pH/(.*)/(.*)$ https://www.example.com/login.html?&tx_felogin_pi1[forgothash]=$1&tx_felogin_pi1[user]=$2 [L,NE,R=PERMANENT] I haven't yet addressed the link break on pipe in thunderbird, that would need more hacking of felogin I wonder if anyone cleverer than me could look at this and make a more generally useable solution / patch for all. It does seem to be a general problem - same issue (except for the pipe) applies with sr_feuser_register emailed links too. (using TYPO3 4.4.6) -- Simon Child From info at sk-typo3.de Mon Feb 14 10:58:48 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 14 Feb 2011 10:58:48 +0100 Subject: [TYPO3-dev] Password reset links breaking - felogin In-Reply-To: <mailman.1.1297676802.3714.typo3-dev@lists.typo3.org> References: <mailman.1.1297676802.3714.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297677641.4676.typo3-dev@lists.typo3.org> Hi, one simple way would be to use realurl and configure those getvars to something speeaking :) vg Steffen From info at tolleiv.de Mon Feb 14 12:35:43 2011 From: info at tolleiv.de (Tolleiv Nietsch) Date: Mon, 14 Feb 2011 12:35:43 +0100 Subject: [TYPO3-dev] cookieSecure =1 & exception in the frontend? Message-ID: <mailman.1.1297683455.16317.typo3-dev@lists.typo3.org> Hi, another thing I found when working with cookieSecure=1 was that TYPO3 throws an Exception (#1254325546) when the frontend was used via HTTP. This is also what you'd have to expect since this is also documented in the Installtool. But I wonder why this makes sense, there's no lockSSL setting for the frontend (even if #11950 added the general option for that). So shouldn't we limit the Exception to appear if the backend is opened with HTTP? Or should we just add some additional documentation to the Installtool and e.g. point users to the "typolink.forceAbsoluteUrl.scheme" option? Cheers, Tolleiv -- Tolleiv Nietsch www.tolleiv.de - www.aoemedia.de From jigal at xs4all.nl Mon Feb 14 13:35:11 2011 From: jigal at xs4all.nl (Jigal van Hemert) Date: Mon, 14 Feb 2011 13:35:11 +0100 Subject: [TYPO3-dev] Password reset links breaking - felogin In-Reply-To: <mailman.1.1297676802.3714.typo3-dev@lists.typo3.org> References: <mailman.1.1297676802.3714.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297687029.22521.typo3-dev@lists.typo3.org> Hi, On 14-2-2011 10:48, Simon Child wrote: > Password reset email links for felogin tend to break in the email client, > and then the user complains that it doesn't work when they click on it. I checked the URLs a while ago and according to the web RFCs they are completely valid. Several email clients can't handle them and suggest various solutions for recognizing the links correctly, but nothing works in all mail clients. -- Kind regards / met vriendelijke groet, Jigal van Hemert skype:jigal.van.hemert msn: jigal at xs4all.nl http://twitter.com/jigalvh From scecere at krur.com Mon Feb 14 13:37:35 2011 From: scecere at krur.com (Stefano Cecere) Date: Mon, 14 Feb 2011 13:37:35 +0100 Subject: [TYPO3-dev] Password reset links breaking - felogin References: <mailman.1.1297676802.3714.typo3-dev@lists.typo3.org> <mailman.1.1297687029.22521.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297687167.22986.typo3-dev@lists.typo3.org> On Mon, 14 Feb 2011 13:35:11 +0100, Jigal van Hemert <jigal at xs4all.nl> wrote: > Hi, > > On 14-2-2011 10:48, Simon Child wrote: >> Password reset email links for felogin tend to break in the email >> client, >> and then the user complains that it doesn't work when they click on it. > > I checked the URLs a while ago and according to the web RFCs they are > completely valid. > Several email clients can't handle them and suggest various solutions > for recognizing the links correctly, but nothing works in all mail > clients. this is exactly what i explain to my clients complaining about this problem! -- ____ ___ __ _ ______________________ Stefano Cecere KRUR.com From ernesto.baschny at typo3.org Mon Feb 14 16:33:56 2011 From: ernesto.baschny at typo3.org (Ernesto Baschny) Date: Mon, 14 Feb 2011 16:33:56 +0100 Subject: [TYPO3-dev] [TYPO3-v4] Minutes from the pre-4.5.1 release meeting Message-ID: <mailman.10368.1297698002.648.typo3-dev@lists.typo3.org> Hi! We now are in a transition phase to the 4.6 development. The release manager for 4.6 is yet to be decided and announced and the official kickstart of 4.6 development will be done during the Code Sprint in Berlin [1] [1] http://wiki.typo3.org/Code_Sprint_Berlin_2011. So we in our Today's meeting we discussed overall TYPO3 related topics, and of course also our next release of 4.5.1. Present were: Olly Hader (core team leader), Ben van't Ende (community manager), Steffen Kamper (4.5 technical leader) and Ernesto Baschny (4.5 release manager). ------------------------------------------------------------------------- Performance session ------------------------------------------------------------------------- Steffen sat with Rupi Germann this weekend to explore some performance bottlenecks for a whole day. The full report can be read in the typo3.dev list. Basically they analysed the backend using cachegrind. It turned out to be very effective and they already found some optimization potential. Two patches already available: * extdirect fetching the API through multiple "ajax.php" calls (also fixeable for 4.5, see thread and patch in typo3.dev list). Steffen will refine that to make a RFC out of it. * BEgetRootLine doesn't use a cache when list view is called in "extended mode" (problem with viewOnClick). Discussion in core list. Fix will be done also for 4.5 (and potentially 4.4). * ajax.php doing "less stuff", this requires major refactoring of init.php: A project for 4.6, not for 4.5. * The random byte generator (generating our new security tokens, taking lots of time reading /dev/urandom). Steffen already contacted Helmut to see what can be done about it. * jsMinify is not performant for applying to inline javascript. Instead try to outsource more JS to external files (in typo3temp). Ernesto mentioned that we should try to make more methods "static" because lots of inline javascript currently could easily be just written out to static files shipped with the core. Steffen will take a closer look at it. A project for 4.6. Some of the optimizations will be able to be ported to 4.5 still, while some which require some refactoring will be only included in 4.6 and later. ------------------------------------------------------------------------- Release Schedule ------------------------------------------------------------------------- We still keep our release plan. Next week on Wednesday we will release: * 4.5.1 * 4.4.7 * 4.3.11 Ernesto noted that there are still some pending issues left to be solved (as mentioned in the previous news [2]). But since that news, some developers were activated again and work is being done on the issues. [2] http://forge.typo3.org/news/421 ------------------------------------------------------------------------- Articles ------------------------------------------------------------------------- Ernesto mentioned that he wrote an article about 4.5 which will appear on the next issue of the german magazin T3N. It goes a bit more in technical details, compared to our press release. Ben also is waiting for more articles about specific features of the new TYPO3 release from our developers. E.g.: * Sonja about Workspaces * Stefan Galinksi about the trees * Stan about the current state of the RTE * Steffen Kamper about the new extension manager ------------------------------------------------------------------------- typo3.org Relaunch Week ------------------------------------------------------------------------- On the next days the "t3o relaunch week" (in April) will be officially announced: intensive team-work sessions with the goal on getting issues for the typo3.org relaunch completed. The relaunch won't be ready after the week, but the groundwork should be done at least. Steffen reminded that there is already a TER-FE team [3] working on a new version of TER-FE (the extension which runs on typo3.org and handles the extension list and the TER connectivity). It will be completely rewritten, provide the same features but based on Extbase/Fluid. Current active members are Kay Vogel, Thomas Loeffler and maybe also Fabien Udriot. Steffen thinks it would make sense to also invite them to the typo3.org relaunch week. [3] http://forge.typo3.org/projects/extension-terfe/ Steffen asks to integrate his http://snippets.typo3.org also on the new typo3.org (so that its not an external server anymore). Olly noted that the current snippets site is not working (caching issues). Steffen will look into it, but notes that he's not satisfied with the current site anyway. Olly asked about http://support.typo3.org. Steffen said that this project is not active anymore. But there is a project for integrating a "Forum" view to our newsgroups. It's already running on a development installation, based on FUDforum software. Currently it works, but some issues remaining (attachments, bidirectional posts, ..) and also integration of a TYPO3 design. We should coordinate with Ingmar and his team, maybe invite them also to the week. We mentioned http://news.typo3.org which currently has some unsolved problems (e.g. RTE images not being exported and displayed on remote sites like typo3.org). And also the known caching issues after the import at typo3.org (news pointing to wrong articles..). Topic upgrade typo3.org to 4.5 was touched. It's a "work in progress", Stucki has it in his hand. Ben will contact him again to see the status. Basically the upgrade process needs lots of insight know how because our core is heavily patched to our demands and the implementation has grown biologically over time. It has to be well tested. ------------------------------------------------------------------------- Next meet-ups ------------------------------------------------------------------------- Ernesto and Steffen will do a short meeting next Monday to discuss the open matters. And then meet also with Olly and Benni for coordinating the releases on Wednesday, 23th February. Cheers, Ernesto -- Ernesto Baschny Core Developer V4 Team Release Manager TYPO3 4.5 TYPO3 .... inspiring people to share! Get involved: typo3.org From tomasnorre at gmail.com Mon Feb 14 20:06:05 2011 From: tomasnorre at gmail.com (Tomas Norre Mikkelsen) Date: Mon, 14 Feb 2011 20:06:05 +0100 Subject: [TYPO3-dev] GIFBUILDER Problem after upgrade to 4.5 In-Reply-To: <mailman.1.1297517899.14912.typo3-dev@lists.typo3.org> References: <mailman.1.1296826030.9609.typo3-dev@lists.typo3.org> <mailman.1.1297414544.8845.typo3-dev@lists.typo3.org> <mailman.1.1297517899.14912.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297710471.30815.typo3-dev@lists.typo3.org> Hi, On 12-02-2011 14:36, Jigal van Hemert wrote: > It seems that IM is really messed up with handling of transparency :-( > > Things you can try: > - turn of Nicetext; with most fonts it doesn't look very well at all. If > a TrueType font looks bad the Type1 version can look better Works when NiceText is disabled, the question is now, will the client accept. =) > - use only a background color instead of a GIF with a single solid colour Gives the same problem as with images. > - use GraphicsMagick (it also seems to be faster) Gives the same problem as with im6. -- Tomas Norre Mikkelsen twitter.com/tomasnorre Member of TYPO3: Documentation Teams & Skin Team. From lorenz-typo3 at visol.ch Mon Feb 14 20:38:45 2011 From: lorenz-typo3 at visol.ch (Lorenz Ulrich) Date: Mon, 14 Feb 2011 20:38:45 +0100 Subject: [TYPO3-dev] Module paths in extensions Message-ID: <mailman.1.1297712434.1578.typo3-dev@lists.typo3.org> Hi everyone TYPO3 standard behaviour is to modify the module paths when fetching an extension from TER. If you decide to move an extension from typo3conf/ext to typo3/ext, extensions with modules will stop working. I know this is not a bug since you can re-install the extension directly as a global extension. But after reading a request [1] to make the module path dynamic for DAM, I'm interested in your opinion: Is the standard behaviour still best practice or should it be improved? Lorenz [1] http://bugs.typo3.org/view.php?id=13778 From helmut.hummel at typo3.org Mon Feb 14 20:44:21 2011 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Mon, 14 Feb 2011 20:44:21 +0100 Subject: [TYPO3-dev] Module paths in extensions In-Reply-To: <mailman.1.1297712434.1578.typo3-dev@lists.typo3.org> References: <mailman.1.1297712434.1578.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297712773.2207.typo3-dev@lists.typo3.org> On 14.02.11 20:38, Lorenz Ulrich wrote: > Hi everyone > > TYPO3 standard behaviour is to modify the module paths when fetching an > extension from TER. If you decide to move an extension from > typo3conf/ext to typo3/ext, extensions with modules will stop working. > > I know this is not a bug since you can re-install the extension directly > as a global extension. But after reading a request [1] to make the > module path dynamic for DAM, I'm interested in your opinion: > > Is the standard behaviour still best practice or should it be improved? I would say, that using the module dispatcher is the right way to go. Then you do not need to mess around with static paths or BACK_PATH. Kind regards, Helmut -- Helmut Hummel TYPO3 Security Team Leader TYPO3 .... inspiring people to share! Get involved: typo3.org From bedlamhotel at gmail.com Mon Feb 14 20:37:07 2011 From: bedlamhotel at gmail.com (Christopher Torgalson) Date: Mon, 14 Feb 2011 11:37:07 -0800 Subject: [TYPO3-dev] GIFBUILDER Problem after upgrade to 4.5 In-Reply-To: <mailman.1.1297710471.30815.typo3-dev@lists.typo3.org> References: <mailman.1.1296826030.9609.typo3-dev@lists.typo3.org> <mailman.1.1297414544.8845.typo3-dev@lists.typo3.org> <mailman.1.1297517899.14912.typo3-dev@lists.typo3.org> <mailman.1.1297710471.30815.typo3-dev@lists.typo3.org> Message-ID: <mailman.10395.1297714046.648.typo3-dev@lists.typo3.org> Hi there, On Mon, Feb 14, 2011 at 11:06 AM, Tomas Norre Mikkelsen <tomasnorre at gmail.com> wrote: > Hi, > > On 12-02-2011 14:36, Jigal van Hemert wrote: >> >> It seems that IM is really messed up with handling of transparency :-( >> >> Things you can try: >> - turn of Nicetext; with most fonts it doesn't look very well at all. If >> a TrueType font looks bad the Type1 version can look better > > Works when NiceText is disabled, the question is now, will the client > accept. =) If it works with niceText disabled, it will probably work if you create the images twice as large as required then scale the images down to size. I'm about 90% sure I've done this and retained transparency with IM6. Just for the record, I've never encountered any problems with the IM6/GIFBUILDER combo. YMMV of course :) -- Christopher Torgalson http://www.typo3apprentice.com/ From lorenz-typo3 at visol.ch Mon Feb 14 21:12:52 2011 From: lorenz-typo3 at visol.ch (Lorenz Ulrich) Date: Mon, 14 Feb 2011 21:12:52 +0100 Subject: [TYPO3-dev] Module paths in extensions In-Reply-To: <mailman.1.1297712773.2207.typo3-dev@lists.typo3.org> References: <mailman.1.1297712434.1578.typo3-dev@lists.typo3.org> <mailman.1.1297712773.2207.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297714481.4891.typo3-dev@lists.typo3.org> Hi Helmut > I would say, that using the module dispatcher is the right way to go. > Then you do not need to mess around with static paths or BACK_PATH. Is there any documentation about the usage? Looking at your patch in [1] i have to use a construct like t3lib_BEfunc::getModuleUrl('web_list', array(), '', TRUE) instead of t3lib_extMgm::extRelPath('list') . 'mod1/db_list.php for every call of the module? And to register the module I need to change conf.php like this $MCONF['name'] = 'web_list'; $MCONF['script'] = '_DISPATCH'; Besides that I don't know in what version this has been introduced. Thanks, Lorenz [1] http://bugs.typo3.org/view.php?id=15686 Am 14.02.2011 20:44, schrieb Helmut Hummel: > On 14.02.11 20:38, Lorenz Ulrich wrote: >> Hi everyone >> >> TYPO3 standard behaviour is to modify the module paths when fetching an >> extension from TER. If you decide to move an extension from >> typo3conf/ext to typo3/ext, extensions with modules will stop working. >> >> I know this is not a bug since you can re-install the extension directly >> as a global extension. But after reading a request [1] to make the >> module path dynamic for DAM, I'm interested in your opinion: >> >> Is the standard behaviour still best practice or should it be improved? > > > Kind regards, > Helmut > From fsu-lists at cobweb.ch Mon Feb 14 21:21:23 2011 From: fsu-lists at cobweb.ch (=?UTF-8?B?RnJhbsOnb2lzIFN1dGVy?=) Date: Mon, 14 Feb 2011 21:21:23 +0100 Subject: [TYPO3-dev] Module paths in extensions In-Reply-To: <mailman.1.1297714481.4891.typo3-dev@lists.typo3.org> References: <mailman.1.1297712434.1578.typo3-dev@lists.typo3.org> <mailman.1.1297712773.2207.typo3-dev@lists.typo3.org> <mailman.1.1297714481.4891.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297714996.5578.typo3-dev@lists.typo3.org> Hi, > Besides that I don't know in what version this has been introduced. In TYPO3 4.1, so you're pretty safe :-) Cheers -- Francois Suter Cobweb Development Sarl - http://www.cobweb.ch From jigal at xs4all.nl Mon Feb 14 21:59:28 2011 From: jigal at xs4all.nl (Jigal van Hemert) Date: Mon, 14 Feb 2011 21:59:28 +0100 Subject: [TYPO3-dev] GIFBUILDER Problem after upgrade to 4.5 In-Reply-To: <mailman.1.1297710471.30815.typo3-dev@lists.typo3.org> References: <mailman.1.1296826030.9609.typo3-dev@lists.typo3.org> <mailman.1.1297414544.8845.typo3-dev@lists.typo3.org> <mailman.1.1297517899.14912.typo3-dev@lists.typo3.org> <mailman.1.1297710471.30815.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297717281.8966.typo3-dev@lists.typo3.org> Hi, On 14-2-2011 20:06, Tomas Norre Mikkelsen wrote: >> - use GraphicsMagick (it also seems to be faster) > Gives the same problem as with im6. If you feel a bit comfortable with editing PHP you could log / display / mail $gifCreator->IM_commands after line 2287 in typo3/sysext/cms/tslib/class.tslib_menu.php (the line is: $gifCreator->destroy(); $gifCreator->IM_commands is an array with all the IM/GM commands that were used for the creation of an image. This would be the first step in trying to follow the exact generation process. You would actually need to keep the temporary images and repeat the process manually to see which steps are going wrong. It is rather strange that GM is giving the same problems as IM does. -- Kind regards / met vriendelijke groet, Jigal van Hemert skype:jigal.van.hemert msn: jigal at xs4all.nl http://twitter.com/jigalvh From tomasnorre at gmail.com Mon Feb 14 22:15:15 2011 From: tomasnorre at gmail.com (Tomas Norre Mikkelsen) Date: Mon, 14 Feb 2011 22:15:15 +0100 Subject: [TYPO3-dev] GIFBUILDER Problem after upgrade to 4.5 In-Reply-To: <mailman.10395.1297714046.648.typo3-dev@lists.typo3.org> References: <mailman.1.1296826030.9609.typo3-dev@lists.typo3.org> <mailman.1.1297414544.8845.typo3-dev@lists.typo3.org> <mailman.1.1297517899.14912.typo3-dev@lists.typo3.org> <mailman.1.1297710471.30815.typo3-dev@lists.typo3.org> <mailman.10395.1297714046.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297718220.10247.typo3-dev@lists.typo3.org> On 14-02-2011 20:37, Christopher Torgalson wrote: >> Works when NiceText is disabled, the question is now, will the client >> accept. =) > > If it works with niceText disabled, it will probably work if you > create the images twice as large as required then scale the images > down to size. I'm about 90% sure I've done this and retained > transparency with IM6. > > Just for the record, I've never encountered any problems with the > IM6/GIFBUILDER combo. YMMV of course :) I'll try. Thanks for the hint. -- Tomas Norre Mikkelsen twitter.com/tomasnorre Member of TYPO3: Documentation Teams & Skin Team. From tomasnorre at gmail.com Mon Feb 14 22:16:32 2011 From: tomasnorre at gmail.com (Tomas Norre Mikkelsen) Date: Mon, 14 Feb 2011 22:16:32 +0100 Subject: [TYPO3-dev] GIFBUILDER Problem after upgrade to 4.5 In-Reply-To: <mailman.1.1297717281.8966.typo3-dev@lists.typo3.org> References: <mailman.1.1296826030.9609.typo3-dev@lists.typo3.org> <mailman.1.1297414544.8845.typo3-dev@lists.typo3.org> <mailman.1.1297517899.14912.typo3-dev@lists.typo3.org> <mailman.1.1297710471.30815.typo3-dev@lists.typo3.org> <mailman.1.1297717281.8966.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297718297.10247.typo3-dev@lists.typo3.org> On 14-02-2011 21:59, Jigal van Hemert wrote: > If you feel a bit comfortable with editing PHP you could log / display / > mail > $gifCreator->IM_commands > after line 2287 in typo3/sysext/cms/tslib/class.tslib_menu.php (the line > is: > $gifCreator->destroy(); > > $gifCreator->IM_commands is an array with all the IM/GM commands that > were used for the creation of an image. This would be the first step in > trying to follow the exact generation process. You would actually need > to keep the temporary images and repeat the process manually to see > which steps are going wrong. I will try that, thanks. > It is rather strange that GM is giving the same problems as IM does. To be honest, i'm not very much into the difference between IM an GM, so i cannot comment on that specific =) -- Tomas Norre Mikkelsen twitter.com/tomasnorre Member of TYPO3: Documentation Teams & Skin Team. From typo3ml at schams.net Tue Feb 15 12:52:19 2011 From: typo3ml at schams.net (Michael) Date: Tue, 15 Feb 2011 22:52:19 +1100 Subject: [TYPO3-dev] Password reset links breaking - felogin In-Reply-To: <mailman.1.1297687029.22521.typo3-dev@lists.typo3.org> References: <mailman.1.1297676802.3714.typo3-dev@lists.typo3.org> <mailman.1.1297687029.22521.typo3-dev@lists.typo3.org> Message-ID: <mailman.10552.1297770856.648.typo3-dev@lists.typo3.org> On 14/02/11 23:35, Jigal van Hemert wrote: >> Password reset email links for felogin tend to break in the email client, >> and then the user complains that it doesn't work when they click on it. > > I checked the URLs a while ago and according to the web RFCs they are > completely valid. hmmm... I am not 100% sure about this statement to be honest :-) According to RFC 1738 square brackets should be encoded as %5B and %5D. http://www.ietf.org/rfc/rfc1738.txt (section 2.2. URL Character Encoding Issues) There is also a very old Mantis ticket going back and forth since 2006: http://bugs.typo3.org/view.php?id=3808 I suspect the problem is more that using [ and ] in links is a common practice in TYPO3 since years and therefore settled. Even if someone could prove that this is not RFC conform, it's not worth the effort changing this. ...and I am pretty sure, someone will name two, three other RFCs which disprove RFC 1738 ;-) See discussion: http://bugs.typo3.org/view.php?id=12892 Cheers Michael From info at sk-typo3.de Tue Feb 15 14:02:04 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Tue, 15 Feb 2011 14:02:04 +0100 Subject: [TYPO3-dev] TYPO3 4.5 performance session In-Reply-To: <mailman.1.1297671934.23654.typo3-dev@lists.typo3.org> References: <mailman.1.1297634006.24936.typo3-dev@lists.typo3.org> <mailman.1.1297671934.23654.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297775036.8434.typo3-dev@lists.typo3.org> Hi, the final patch is now in core list, #17592 vg Steffen From jigal at xs4all.nl Tue Feb 15 14:13:41 2011 From: jigal at xs4all.nl (Jigal van Hemert) Date: Tue, 15 Feb 2011 14:13:41 +0100 Subject: [TYPO3-dev] Password reset links breaking - felogin In-Reply-To: <mailman.10552.1297770856.648.typo3-dev@lists.typo3.org> References: <mailman.1.1297676802.3714.typo3-dev@lists.typo3.org> <mailman.1.1297687029.22521.typo3-dev@lists.typo3.org> <mailman.10552.1297770856.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297775736.9617.typo3-dev@lists.typo3.org> Hi, On 15-2-2011 12:52, Michael wrote: > On 14/02/11 23:35, Jigal van Hemert wrote: >> I checked the URLs a while ago and according to the web RFCs they are >> completely valid. > > hmmm... I am not 100% sure about this statement to be honest :-) > > According to RFC 1738 square brackets should be encoded as %5B and %5D. According to RFC 3986 [1] (which updates 1738), section 2.2 Reserved Characters, square bracked are Reserved Characters (category gen-delims). The text says that these can be used "by the implementation-specific syntax of a URI's dereferencing algorithm". If these characters are used as part of normal data in a URI (e.g. part of a path, value of a query parameter) they should be percent-encoded. No matter how the square brackets are used at the receiving end a URL must never be cut off when a reserved character is found. This becomes very clear when you look at the list of gen-delims: gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" IMO this behaviour of mail clients is simply wrong. [1] http://www.faqs.org/rfcs/rfc3986.html > ...and I am pretty sure, someone will name two, three other RFCs which > disprove RFC 1738 ;-) Absolutely spot on! :-D Maybe it'd be a nice feature to provide a generic URL shortener in TYPO3 -- Kind regards / met vriendelijke groet, Jigal van Hemert skype:jigal.van.hemert msn: jigal at xs4all.nl http://twitter.com/jigalvh From typo3-german-02 at oliverklee.de Tue Feb 15 15:02:58 2011 From: typo3-german-02 at oliverklee.de (Oliver Klee) Date: Tue, 15 Feb 2011 15:02:58 +0100 Subject: [TYPO3-dev] Password reset links breaking - felogin In-Reply-To: <mailman.1.1297775736.9617.typo3-dev@lists.typo3.org> References: <mailman.1.1297676802.3714.typo3-dev@lists.typo3.org> <mailman.1.1297687029.22521.typo3-dev@lists.typo3.org> <mailman.10552.1297770856.648.typo3-dev@lists.typo3.org> <mailman.1.1297775736.9617.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297778692.14073.typo3-dev@lists.typo3.org> Hi, Am 15.02.2011 14:13, schrieb Jigal van Hemert: > No matter how the square brackets are used at the receiving end a URL > must never be cut off when a reserved character is found. This becomes > very clear when you look at the list of gen-delims: > gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" > > IMO this behaviour of mail clients is simply wrong. > > [1] http://www.faqs.org/rfcs/rfc3986.html However, encoding the square brackets as %5B and %5D makes the URLs in the e-mails no less valid, but allows them to work in most e-mail clients. So I think the encoding would make sense and save our clients some frustration. Oli -- Certified TYPO3 Integrator | TYPO3 Security Team Member From bart at samson-it.nl Wed Feb 16 15:04:42 2011 From: bart at samson-it.nl (Bart van den Burg) Date: Wed, 16 Feb 2011 15:04:42 +0100 Subject: [TYPO3-dev] Multilingual plugin Message-ID: <mailman.1.1297865372.8716.typo3-dev@lists.typo3.org> Hi, Our clients wishes for the plugin we created recently, to be transformed to a multilingual one. Can anyone give me a link to a page explaining how to do this? I'm especially interested in how to define the TCA for this. Regards, Bart From scecere at krur.com Wed Feb 16 15:12:04 2011 From: scecere at krur.com (Stefano Cecere) Date: Wed, 16 Feb 2011 15:12:04 +0100 Subject: [TYPO3-dev] Multilingual plugin References: <mailman.1.1297865372.8716.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297865638.9367.typo3-dev@lists.typo3.org> hi i suggest you to recreate the plugin with the kickstarter, enabling translation for the db tables you'll see the generated TCA! ciao s On Wed, 16 Feb 2011 15:04:42 +0100, Bart van den Burg <bart at samson-it.nl> wrote: > Hi, > > Our clients wishes for the plugin we created recently, to be transformed > to a multilingual one. > > Can anyone give me a link to a page explaining how to do this? I'm > especially interested in how to define the TCA for this. > > Regards, > Bart -- ____ ___ __ _ ______________________ Stefano Cecere krur.com multimedia From simon at srchild.com Wed Feb 16 18:52:26 2011 From: simon at srchild.com (Simon Child) Date: Wed, 16 Feb 2011 17:52:26 -0000 Subject: [TYPO3-dev] Password reset links breaking - felogin References: <mailman.1.1297676802.3714.typo3-dev@lists.typo3.org> <mailman.1.1297687029.22521.typo3-dev@lists.typo3.org> <mailman.10552.1297770856.648.typo3-dev@lists.typo3.org> <mailman.1.1297775736.9617.typo3-dev@lists.typo3.org> <mailman.1.1297778692.14073.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297878632.31836.typo3-dev@lists.typo3.org> "Oliver Klee" <typo3-german-02 at oliverklee.de> wrote in message news:mailman.1.1297778692.14073.typo3-dev at lists.typo3.org... > Am 15.02.2011 14:13, schrieb Jigal van Hemert: >> IMO this behaviour of mail clients is simply wrong. >> >> [1] http://www.faqs.org/rfcs/rfc3986.html > > However, encoding the square brackets as %5B and %5D makes the URLs in > the e-mails no less valid, but allows them to work in most e-mail > clients. So I think the encoding would make sense and save our clients > some frustration. Even when mail clients break RFC, it sitll makes sense to make it easier for users where possible. (like coding for IE even though IE has never been all that good at meeting standards :). And it reduces the support calls too! And I hadn't thought of realurl because I rarely use that, though have done on a couple of sites recently. I've always preferred the way that simulate static gives URLs that don't change (and hence break incoming links) when pages are moved around thepage tree. Thanks Simon From simon at srchild.com Wed Feb 16 22:54:27 2011 From: simon at srchild.com (Simon Child) Date: Wed, 16 Feb 2011 21:54:27 -0000 Subject: [TYPO3-dev] felogin - return path Message-ID: <mailman.1.1297893154.20350.typo3-dev@lists.typo3.org> felogin doesn't set the return path to the From address in password reset emails. This makes the emails more likely to get marked as spam. t3lib_utility_Mail::mail can set the return path via additionalParameters, so perhaps this could be considered. I had a look but it seems to need more changes than just changing class.tx_felogin_pi1.php looks like class.tx_felogin_pi1.php hands it to sendNotifyEmail but I don't see a parameter to indicate wanting to set return path and sendNotifyEmail likewise hands it to $GLOBALS['TSFE']->plainMailEncoded which also doesn't seem to have a parameter to indicate wanting to set return path and t3lib_utility_Mail::mail hands it to t3lib_utility_Mail::mail - quite a paper trail! [Why am I fussing about felogin this week? Too many users saying emails didn't arrive / emails went in spam / they clicked on the email link but it didn't work...] Cheers -- Simon Child From kraftb at think-open.at Thu Feb 17 00:14:50 2011 From: kraftb at think-open.at (Bernhard Kraft) Date: Thu, 17 Feb 2011 00:14:50 +0100 Subject: [TYPO3-dev] Extension auction Message-ID: <mailman.1.1297898206.27271.typo3-dev@lists.typo3.org> Hello everybody, Maybe some of you know that I will leave the world of TYPO3. As my interests and my life situation has changedI am heading for new directions. So what still remains are a lot of extension created by me for the TYPO3 community. I guess many of you know how tedious it can be to take care of an extension. You have to fix bugs and adopt it to changes in the TYPO3 core. So usually it takes you time to be the owner of an extension. But on the other hand it also brings you some customers and a little bit of fame. As most of my extension have been more work than they made me money, and we are living in a world where I have to pay for almost everything I am going to sell them on an e-bay auction. Yes. An extension auction. But ok. This could get seen as a donation for all the work on those extensions. By giving the highest offer you get all rights on an extension as far as the GPL allows this. Then the extension key on typo3.org (and forge.typo3.org) will get transfered to your TYPO3 user account. Here is the a list of extension you can purchase: kb_imageedit http://cgi.ebay.at/ws/eBayISAPI.dll?ViewItem&item=190502895612 kb_conttable http://cgi.ebay.at/ws/eBayISAPI.dll?ViewItem&item=190502909660 kb_filequota http://cgi.ebay.at/ws/eBayISAPI.dll?ViewItem&item=190502914211 kb_game_mahjongg http://cgi.ebay.at/ws/eBayISAPI.dll?ViewItem&item=190502921728 kb_tv_cont_slide http://cgi.ebay.at/ws/eBayISAPI.dll?ViewItem&item=190502922903 Some more will follow in 30 days as ebay allows me to submit more items If you have any questions feel free to ask. greetings, Bernhard From ben.vantende at typo3.org Thu Feb 17 11:02:13 2011 From: ben.vantende at typo3.org (ben van 't ende) Date: Thu, 17 Feb 2011 11:02:13 +0100 Subject: [TYPO3-dev] TYPO3 relaunch week Message-ID: <mailman.1.1297937048.2781.typo3-dev@lists.typo3.org> Heyla, You might have already seen it, but I want to bring the TYPO3 relaunch week under your attention once more. This is your chance to get involved. The main TYPO3 website typo3.org needs a new lay-out, a new structure and new functionality. The "typo3.org Relaunch Week" (T3O) will take place from April 16-23 in the Linuxhotel, Essen, Germany and is aimed at just that. 20 experts will work on the project in that week and we need you to participate to complete this huge task we have ahead of us. If you have what it takes you are encouraged to apply. The same goes for sponsors. If TYPO3 has brought you fame and fortune then sponsor T3O. T3O is organized by the Marketing Team of the TYPO3 Association. http://t3o.typo3.org/ gRTz ben -- TYPO3 Community Manager From olivier.dobberkau at dkd.de Thu Feb 17 15:46:39 2011 From: olivier.dobberkau at dkd.de (Olivier Dobberkau) Date: Thu, 17 Feb 2011 15:46:39 +0100 Subject: [TYPO3-dev] Extension auction In-Reply-To: <mailman.1.1297898206.27271.typo3-dev@lists.typo3.org> References: <mailman.1.1297898206.27271.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297954114.32677.typo3-dev@lists.typo3.org> Am 17.02.11 00:14, schrieb Bernhard Kraft: > Maybe some of you know that I will leave the world of TYPO3. As my > interests and my life situation has changed I am heading for new > directions. Wish you all the Best Bernhard! We will miss your ideas! Olivier From bjoern.pedersen at frm2.tum.de Thu Feb 17 16:41:08 2011 From: bjoern.pedersen at frm2.tum.de (Bjoern Pedersen) Date: Thu, 17 Feb 2011 16:41:08 +0100 Subject: [TYPO3-dev] Override allow ed extension list of media element Message-ID: <mailman.1.1297957382.6811.typo3-dev@lists.typo3.org> Hi, as the medai element has a flexform for it's BE layout ( typo3/sysext/cms/flexform_media.xml ), is there a way to define the allowed extensions without patching this file? Is setting $TCA['tt_content']['pi_flexform']['config']['ds'][',media']=file_get_contents(<some xml file>); OK? Bj?rn From bjoern.pedersen at frm2.tum.de Thu Feb 17 17:11:25 2011 From: bjoern.pedersen at frm2.tum.de (Bjoern Pedersen) Date: Thu, 17 Feb 2011 17:11:25 +0100 Subject: [TYPO3-dev] performace of cachingframework Message-ID: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> Hi, hafter analyzing my slow-query log, it seems that the caching framework table structure is suboptimal: Quite a lot of query like: SELECT identifier FROM cachingframework_cache_hash WHERE crdate + lifetime < 1297803600 AND lifetime > 0; or DELETE FROM cachingframework_cache_hash WHERE crdate + lifetime < 1297803600 AND lifetime > 0; Count: 20 Time=33.48s (669s) Lock=0.00s (0s) Rows=0.0 (0), typo3_frm2[typo3_frm2]@localhost DELETE FROM cachingframework_cache_hash WHERE crdate + lifetime < N AND lifetime > N Count: 20 Time=55.02s (1100s) Lock=0.00s (0s) Rows=0.0 (0), typo3_frm2[typo3_frm2]@localhost DELETE FROM cachingframework_cache_pages WHERE crdate + lifetime < N AND lifetime > N Count: 20 Time=17.54s (350s) Lock=0.00s (0s) Rows=3401.6 (68032), typo3_frm2[typo3_frm2]@localhost SELECT identifier FROM cachingframework_cache_hash WHERE crdate + lifetime < N AND lifetime > N These query require a full table scan. If we had a expires column set to crdate+lifetime, an index could be used, thus speeding up the queries. Bj?rn From info at rs-websystems.de Thu Feb 17 17:16:25 2011 From: info at rs-websystems.de (Steffen Ritter) Date: Thu, 17 Feb 2011 17:16:25 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297959492.27286.typo3-dev@lists.typo3.org> Am 17.02.2011 17:11, schrieb Bjoern Pedersen: > Hi, HI, > hafter analyzing my slow-query log, it seems that the caching framework > table structure is suboptimal: > Quite a lot of query like: .. > If we had a expires column set to crdate+lifetime, an index could be > used, thus speeding up the queries. > > Bj?rn sound reasonable just from reading... redudancy should not be the problem in this case... let's see what CK - the so called king of CF - says. regards steffen From peter.russ at 4many.net Thu Feb 17 17:49:28 2011 From: peter.russ at 4many.net (Peter Russ) Date: Thu, 17 Feb 2011 17:49:28 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297961483.12948.typo3-dev@lists.typo3.org> --- Original Nachricht --- Absender: Bjoern Pedersen Datum: 17.02.2011 17:11: > Hi, > > hafter analyzing my slow-query log, it seems that the caching framework > table structure is suboptimal: > Quite a lot of query like: > > SELECT identifier FROM cachingframework_cache_hash WHERE crdate + > lifetime < 1297803600 AND lifetime > 0; > > or DELETE FROM cachingframework_cache_hash WHERE crdate + lifetime < > 1297803600 AND lifetime > 0; > > > Count: 20 Time=33.48s (669s) Lock=0.00s (0s) Rows=0.0 (0), > typo3_frm2[typo3_frm2]@localhost > DELETE FROM cachingframework_cache_hash WHERE crdate + lifetime < N > AND lifetime > N > > Count: 20 Time=55.02s (1100s) Lock=0.00s (0s) Rows=0.0 (0), > typo3_frm2[typo3_frm2]@localhost > DELETE FROM cachingframework_cache_pages WHERE crdate + lifetime < N > AND lifetime > N > > Count: 20 Time=17.54s (350s) Lock=0.00s (0s) Rows=3401.6 (68032), > typo3_frm2[typo3_frm2]@localhost > SELECT identifier FROM cachingframework_cache_hash WHERE crdate + > lifetime < N AND lifetime > N > > These query require a full table scan. > > If we had a expires column set to crdate+lifetime, an index could be > used, thus speeding up the queries. > > Bj?rn Fix it and provide patch. Peter. -- docendo discimus _____________________________ uon GbR http://www.uon.li http://www.xing.com/profile/Peter_Russ From info at sk-typo3.de Thu Feb 17 17:54:41 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Thu, 17 Feb 2011 17:54:41 +0100 Subject: [TYPO3-dev] Override allow ed extension list of media element In-Reply-To: <mailman.1.1297957382.6811.typo3-dev@lists.typo3.org> References: <mailman.1.1297957382.6811.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1297961797.13044.typo3-dev@lists.typo3.org> Hi, Am 17.02.2011 16:41, schrieb Bjoern Pedersen: > Hi, > > as the medai element has a flexform for it's BE layout > ( typo3/sysext/cms/flexform_media.xml ), > is there a way to define the allowed extensions without patching this file? > > Is setting > $TCA['tt_content']['pi_flexform']['config']['ds'][',media']=file_get_contents(<some > xml file>); > this is one possibility, to point to an own xml for the flexform. The other way is to override single fields with typoscript. This is new and so not well known, but you can do the following as well: http://wiki.typo3.org/Documentation_changes_in_4.4_and_4.5#16334:_Make_FlexForms_editable_via_TSConfig_and_group_access_lists_.5Bclosed_to_Steffen_Kamper.5D.5B4.5.5D vg Steffen From lolli at schwarzbu.ch Thu Feb 17 22:50:47 2011 From: lolli at schwarzbu.ch (Christian Kuhn) Date: Thu, 17 Feb 2011 22:50:47 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> Message-ID: <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> Hey, On 02/17/2011 05:11 PM, Bjoern Pedersen wrote: > SELECT identifier FROM cachingframework_cache_hash WHERE crdate + > lifetime< 1297803600 AND lifetime> 0; ... Those queries are only fired by the garbage collection task, they are no usual production queries from frontend? Regards Christian From peter.russ at 4many.net Fri Feb 18 08:01:31 2011 From: peter.russ at 4many.net (Peter Russ) Date: Fri, 18 Feb 2011 08:01:31 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298012606.766.typo3-dev@lists.typo3.org> --- Original Nachricht --- Absender: Christian Kuhn Datum: 17.02.2011 22:50: > Hey, > > On 02/17/2011 05:11 PM, Bjoern Pedersen wrote: > >> SELECT identifier FROM cachingframework_cache_hash WHERE crdate + >> lifetime< 1297803600 AND lifetime> 0; > > ... > > Those queries are only fired by the garbage collection task, they are no > usual production queries from frontend? > > Regards > Christian But there is no reason that GB is blocking the server ;-) Production or not doesn't really matter. Peter -- docendo discimus _____________________________ uon GbR http://www.uon.li http://www.xing.com/profile/Peter_Russ From bjoern.pedersen at frm2.tum.de Fri Feb 18 09:00:52 2011 From: bjoern.pedersen at frm2.tum.de (Bjoern Pedersen) Date: Fri, 18 Feb 2011 09:00:52 +0100 Subject: [TYPO3-dev] Override allow ed extension list of media element In-Reply-To: <mailman.1.1297961797.13044.typo3-dev@lists.typo3.org> References: <mailman.1.1297957382.6811.typo3-dev@lists.typo3.org> <mailman.1.1297961797.13044.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298016168.6367.typo3-dev@lists.typo3.org> Am 17.02.2011 17:54, schrieb Steffen Kamper: > Hi, > > Am 17.02.2011 16:41, schrieb Bjoern Pedersen: >> Hi, >> >> as the medai element has a flexform for it's BE layout >> ( typo3/sysext/cms/flexform_media.xml ), >> is there a way to define the allowed extensions without patching this >> file? >> >> Is setting >> $TCA['tt_content']['pi_flexform']['config']['ds'][',media']=file_get_contents(<some >> >> xml file>); >> > > this is one possibility, to point to an own xml for the flexform. > > The other way is to override single fields with typoscript. > This is new and so not well known, but you can do the following as well: > > http://wiki.typo3.org/Documentation_changes_in_4.4_and_4.5#16334:_Make_FlexForms_editable_via_TSConfig_and_group_access_lists_.5Bclosed_to_Steffen_Kamper.5D.5B4.5.5D > > > vg Steffen Yes, I actually thougt of something like that. [tablename].[field].[dataStructKey].[flexSheet].[flexField].config.[key] But I am not shure wether i can get at the key ['wizards']['links']['params']['allowedExtensions'], as wizards is not in the list of possible keys in the docs. So that would be: $TCEFORM['tt_content']['pi_flexform']['media']['sDef']['mmFile']['wizards']['links']['params']['allowedExtensions']='xxx' I will give it a try. Bj?rn From bjoern.pedersen at frm2.tum.de Fri Feb 18 09:05:36 2011 From: bjoern.pedersen at frm2.tum.de (Bjoern Pedersen) Date: Fri, 18 Feb 2011 09:05:36 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298016451.6669.typo3-dev@lists.typo3.org> Am 17.02.2011 22:50, schrieb Christian Kuhn: > Hey, > > On 02/17/2011 05:11 PM, Bjoern Pedersen wrote: > >> SELECT identifier FROM cachingframework_cache_hash WHERE crdate + >> lifetime< 1297803600 AND lifetime> 0; > > ... > > Those queries are only fired by the garbage collection task, they are no > usual production queries from frontend? > > Regards > Christian Yes, that is correct. For normal cache retrieval the indentifier serves as key. I will see wether I can create a patch. Bj?rn From peter.russ at 4many.net Fri Feb 18 10:47:05 2011 From: peter.russ at 4many.net (Peter Russ) Date: Fri, 18 Feb 2011 10:47:05 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1298016451.6669.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298016451.6669.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298022540.16647.typo3-dev@lists.typo3.org> --- Original Nachricht --- Absender: Bjoern Pedersen Datum: 18.02.2011 09:05: > Am 17.02.2011 22:50, schrieb Christian Kuhn: >> Hey, >> >> On 02/17/2011 05:11 PM, Bjoern Pedersen wrote: >> >>> SELECT identifier FROM cachingframework_cache_hash WHERE crdate + >>> lifetime< 1297803600 AND lifetime> 0; >> ... >> >> Those queries are only fired by the garbage collection task, they are no >> usual production queries from frontend? >> >> Regards >> Christian > Yes, that is correct. For normal cache retrieval the indentifier serves > as key. > > I will see wether I can create a patch. NO this it NOT correct. The caching framework will check on every request ->has($key) if the cached content is "alive" :-( So this patch is even more important on production. Peter. -- docendo discimus _____________________________ uon GbR http://www.uon.li http://www.xing.com/profile/Peter_Russ From bjoern.pedersen at frm2.tum.de Fri Feb 18 10:50:03 2011 From: bjoern.pedersen at frm2.tum.de (Bjoern Pedersen) Date: Fri, 18 Feb 2011 10:50:03 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1298022540.16647.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298016451.6669.typo3-dev@lists.typo3.org> <mailman.1.1298022540.16647.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298022719.16696.typo3-dev@lists.typo3.org> Am 18.02.2011 10:47, schrieb Peter Russ: > --- Original Nachricht --- > Absender: Bjoern Pedersen > Datum: 18.02.2011 09:05: >> Am 17.02.2011 22:50, schrieb Christian Kuhn: >>> Hey, >>> >>> On 02/17/2011 05:11 PM, Bjoern Pedersen wrote: >>> >>>> SELECT identifier FROM cachingframework_cache_hash WHERE crdate + >>>> lifetime< 1297803600 AND lifetime> 0; >>> ... >>> >>> Those queries are only fired by the garbage collection task, they are no >>> usual production queries from frontend? >>> >>> Regards >>> Christian >> Yes, that is correct. For normal cache retrieval the indentifier serves >> as key. >> >> I will see wether I can create a patch. > > NO this it NOT correct. The caching framework will check on every > request ->has($key) if the cached content is "alive" :-( > So this patch is even more important on production. > > Peter. > Well, on production the key is used and normally will return just 1 or very few records where the scan for "is alive" has to be done. So there the impact is rather low. But of course I will consider this in my patch. Bj?rn From peter.russ at 4many.net Fri Feb 18 11:03:54 2011 From: peter.russ at 4many.net (Peter Russ) Date: Fri, 18 Feb 2011 11:03:54 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1298022719.16696.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298016451.6669.typo3-dev@lists.typo3.org> <mailman.1.1298022540.16647.typo3-dev@lists.typo3.org> <mailman.1.1298022719.16696.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298023551.18649.typo3-dev@lists.typo3.org> --- Original Nachricht --- Absender: Bjoern Pedersen Datum: 18.02.2011 10:50: > Am 18.02.2011 10:47, schrieb Peter Russ: >> --- Original Nachricht --- >> Absender: Bjoern Pedersen >> Datum: 18.02.2011 09:05: >>> Am 17.02.2011 22:50, schrieb Christian Kuhn: >>>> Hey, >>>> >>>> On 02/17/2011 05:11 PM, Bjoern Pedersen wrote: >>>> >>>>> SELECT identifier FROM cachingframework_cache_hash WHERE crdate + >>>>> lifetime< 1297803600 AND lifetime> 0; >>>> ... >>>> >>>> Those queries are only fired by the garbage collection task, they are no >>>> usual production queries from frontend? >>>> >>>> Regards >>>> Christian >>> Yes, that is correct. For normal cache retrieval the indentifier serves >>> as key. >>> >>> I will see wether I can create a patch. >> NO this it NOT correct. The caching framework will check on every >> request ->has($key) if the cached content is "alive" :-( >> So this patch is even more important on production. >> >> Peter. >> > Well, on production the key is used and normally will return just 1 or > very few records where the scan for "is alive" has to be done. So there > the impact is rather low. But of course I will consider this in my patch. > > Bj?rn Sorry but your answer is not correct. Please check the code HOW it is handled in the dbbackend. Even if only true or false is returned query will always take lifetime into account. Additionally there is an overhead as has and get are similar and always 2 queries are required to receive a cached item. So using dbbackend for caching might even increase the number of queries and slow down delivery on high load sites. If you would consider this in your patch it would help more ;-) Peter. -- docendo discimus _____________________________ uon GbR http://www.uon.li http://www.xing.com/profile/Peter_Russ From bjoern.pedersen at frm2.tum.de Fri Feb 18 11:27:03 2011 From: bjoern.pedersen at frm2.tum.de (Bjoern Pedersen) Date: Fri, 18 Feb 2011 11:27:03 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1298023551.18649.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298016451.6669.typo3-dev@lists.typo3.org> <mailman.1.1298022540.16647.typo3-dev@lists.typo3.org> <mailman.1.1298022719.16696.typo3-dev@lists.typo3.org> <mailman.1.1298023551.18649.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298024938.20796.typo3-dev@lists.typo3.org> Am 18.02.2011 11:03, schrieb Peter Russ: > > Sorry but your answer is not correct. Please check the code HOW it is > handled in the dbbackend. Even if only true or false is returned query > will always take lifetime into account. > > Additionally there is an overhead as has and get are similar and always > 2 queries are required to receive a cached item. So using dbbackend for > caching might even increase the number of queries and slow down delivery > on high load sites. > > If you would consider this in your patch it would help more ;-) > > Peter. > Peter, we are talking about two different things here. You are talking about the handling in php. I am only talking about handling by the database. And there is a key on identifier, so the number of records to check for expiry is low. mysql> explain select * from cachingframework_cache_pages where identifier='xxxx' and crdate+lifetime>=now(); +----+-------------+------------------------------+------+---------------+----------+---------+-------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------------------------+------+---------------+----------+---------+-------+------+-------------+ | 1 | SIMPLE | cachingframework_cache_pages | ref | cache_id | cache_id | 130 | const | 1 | Using where | +----+-------------+------------------------------+------+---------------+----------+---------+-------+------+-------------+ 1 row in set (0.03 sec) mysql> explain select * from cachingframework_cache_pages where crdate+lifetime>=now(); +----+-------------+------------------------------+------+---------------+------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------------------------+------+---------------+------+---------+------+------+-------------+ | 1 | SIMPLE | cachingframework_cache_pages | ALL | NULL | NULL | NULL | NULL | 1 | Using where | +----+-------------+------------------------------+------+---------------+------+---------+------+------+-------------+ 1 row in set (0.00 sec) Bj?rn From peter.russ at 4many.net Fri Feb 18 11:51:14 2011 From: peter.russ at 4many.net (Peter Russ) Date: Fri, 18 Feb 2011 11:51:14 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1298024938.20796.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298016451.6669.typo3-dev@lists.typo3.org> <mailman.1.1298022540.16647.typo3-dev@lists.typo3.org> <mailman.1.1298022719.16696.typo3-dev@lists.typo3.org> <mailman.1.1298023551.18649.typo3-dev@lists.typo3.org> <mailman.1.1298024938.20796.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298026390.23706.typo3-dev@lists.typo3.org> --- Original Nachricht --- Absender: Bjoern Pedersen Datum: 18.02.2011 11:27: > Am 18.02.2011 11:03, schrieb Peter Russ: >> Sorry but your answer is not correct. Please check the code HOW it is >> handled in the dbbackend. Even if only true or false is returned query >> will always take lifetime into account. >> >> Additionally there is an overhead as has and get are similar and always >> 2 queries are required to receive a cached item. So using dbbackend for >> caching might even increase the number of queries and slow down delivery >> on high load sites. >> >> If you would consider this in your patch it would help more ;-) >> >> Peter. >> > > Peter, > > we are talking about two different things here. You are talking about > the handling in php. I am only talking about handling by the database. > And there is a key on identifier, so the number of records to check for > expiry is low. > > mysql> explain select * from cachingframework_cache_pages where > identifier='xxxx' and crdate+lifetime>=now(); > +----+-------------+------------------------------+------+---------------+----------+---------+-------+------+-------------+ > | id | select_type | table | type | possible_keys > | key | key_len | ref | rows | Extra | > +----+-------------+------------------------------+------+---------------+----------+---------+-------+------+-------------+ > | 1 | SIMPLE | cachingframework_cache_pages | ref | cache_id > | cache_id | 130 | const | 1 | Using where | > +----+-------------+------------------------------+------+---------------+----------+---------+-------+------+-------------+ > 1 row in set (0.03 sec) > > mysql> explain select * from cachingframework_cache_pages where > crdate+lifetime>=now(); > +----+-------------+------------------------------+------+---------------+------+---------+------+------+-------------+ > | id | select_type | table | type | possible_keys > | key | key_len | ref | rows | Extra | > +----+-------------+------------------------------+------+---------------+------+---------+------+------+-------------+ > | 1 | SIMPLE | cachingframework_cache_pages | ALL | NULL > | NULL | NULL | NULL | 1 | Using where | > +----+-------------+------------------------------+------+---------------+------+---------+------+------+-------------+ > 1 row in set (0.00 sec) This assumption is correct on your machine. But on high load sites where values are cached for some secs or mins it looks totally different: There could be several 100s or 1000s of records with the same key before GB.... It would help a lot if developers would realize that TYPO3 claims to be an "Enterpise CMS" and this more than just "runs fine on my machine" ;-) Peter. -- docendo discimus _____________________________ uon GbR http://www.uon.li http://www.xing.com/profile/Peter_Russ From info at sk-typo3.de Fri Feb 18 12:46:32 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Fri, 18 Feb 2011 12:46:32 +0100 Subject: [TYPO3-dev] Override allow ed extension list of media element In-Reply-To: <mailman.1.1298016168.6367.typo3-dev@lists.typo3.org> References: <mailman.1.1297957382.6811.typo3-dev@lists.typo3.org> <mailman.1.1297961797.13044.typo3-dev@lists.typo3.org> <mailman.1.1298016168.6367.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298029710.29768.typo3-dev@lists.typo3.org> Hi, Am 18.02.2011 09:00, schrieb Bjoern Pedersen: > So that would be: > $TCEFORM['tt_content']['pi_flexform']['media']['sDef']['mmFile']['wizards']['links']['params']['allowedExtensions']='xxx' > > I will give it a try. > i'm not sure, i even expect that it doesn't work. I also never tried change sections this way. The problem is that flexforms were invited for a special purpose, having dynamic count of fields in one db field. There never was a real generic approach (also you see sections vs IRRE) I hope that these things will be solved with the TCEforms refactore, which might be finished in 4.6 vg Steffen From cristian at intera.it Fri Feb 18 13:09:21 2011 From: cristian at intera.it (Cristian Buja) Date: Fri, 18 Feb 2011 13:09:21 +0100 Subject: [TYPO3-dev] Problem with tt_board and sr_frecap from tslib_cObj->FORM Message-ID: <mailman.1.1298031070.31894.typo3-dev@lists.typo3.org> I have a question, whi in tslib_cObj->FORM function there is that? $confData['label'] = t3lib_div::removeXSS(trim($parts[0])); I don't think there is CROSS SITE SCRIPTS problem with label in a form but I would understand, because I think this genetare issues when I update to 3.4 my TYPO3 site that use tt_board with sr_frecap. Thank's Cristian From rupi at gmx.li Fri Feb 18 13:40:15 2011 From: rupi at gmx.li (Rupert Germann) Date: Fri, 18 Feb 2011 13:40:15 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1298026390.23706.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298016451.6669.typo3-dev@lists.typo3.org> <mailman.1.1298022540.16647.typo3-dev@lists.typo3.org> <mailman.1.1298022719.16696.typo3-dev@lists.typo3.org> <mailman.1.1298023551.18649.typo3-dev@lists.typo3.org> <mailman.1.1298024938.20796.typo3-dev@lists.typo3.org> <mailman.1.1298026390.23706.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298032935.2738.typo3-dev@lists.typo3.org> Am 18.02.2011 11:51, schrieb Peter Russ: .... > It would help a lot if developers would realize that TYPO3 claims to be > an "Enterpise CMS" and this more than just "runs fine on my machine" ;-) well said! +100 ;-) greets rupert From bjoern.pedersen at frm2.tum.de Fri Feb 18 17:15:20 2011 From: bjoern.pedersen at frm2.tum.de (Bjoern Pedersen) Date: Fri, 18 Feb 2011 17:15:20 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1298026390.23706.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298016451.6669.typo3-dev@lists.typo3.org> <mailman.1.1298022540.16647.typo3-dev@lists.typo3.org> <mailman.1.1298022719.16696.typo3-dev@lists.typo3.org> <mailman.1.1298023551.18649.typo3-dev@lists.typo3.org> <mailman.1.1298024938.20796.typo3-dev@lists.typo3.org> <mailman.1.1298026390.23706.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298045836.26489.typo3-dev@lists.typo3.org> Am 18.02.2011 11:51, schrieb Peter Russ: > --- Original Nachricht --- > > This assumption is correct on your machine. But on high load sites where > values are cached for some secs or mins it looks totally different: > There could be several 100s or 1000s of records with the same key before > GB.... > > It would help a lot if developers would realize that TYPO3 claims to be > an "Enterpise CMS" and this more than just "runs fine on my machine" ;-) > > Peter. > > Yes, that is valid point. A few more infos that I need from the cache specialists: is the has-function actually used anywhere except in some BE's internally? A grep on the core sources did not find anything. There were just hits in the tests and in swiftmailer (implementing it's own cache) and in extbase, also not using the normal cache. If it is not really used, i would suggest to deprecate it to avoid a usage pattern like: if(cache->has(id)) then cache->get(id). Bj?rn From peter.russ at 4many.net Fri Feb 18 18:32:17 2011 From: peter.russ at 4many.net (Peter Russ) Date: Fri, 18 Feb 2011 18:32:17 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1298045836.26489.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298016451.6669.typo3-dev@lists.typo3.org> <mailman.1.1298022540.16647.typo3-dev@lists.typo3.org> <mailman.1.1298022719.16696.typo3-dev@lists.typo3.org> <mailman.1.1298023551.18649.typo3-dev@lists.typo3.org> <mailman.1.1298024938.20796.typo3-dev@lists.typo3.org> <mailman.1.1298026390.23706.typo3-dev@lists.typo3.org> <mailman.1.1298045836.26489.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298050454.1154.typo3-dev@lists.typo3.org> --- Original Nachricht --- Absender: Bjoern Pedersen Datum: 18.02.2011 17:15: > Am 18.02.2011 11:51, schrieb Peter Russ: >> --- Original Nachricht --- >> >> This assumption is correct on your machine. But on high load sites where >> values are cached for some secs or mins it looks totally different: >> There could be several 100s or 1000s of records with the same key before >> GB.... >> >> It would help a lot if developers would realize that TYPO3 claims to be >> an "Enterpise CMS" and this more than just "runs fine on my machine" ;-) >> >> Peter. >> >> > Yes, that is valid point. > > A few more infos that I need from the cache specialists: > is the has-function actually used anywhere except in some BE's > internally? A grep on the core sources did not find anything. There were > just hits in the tests and in swiftmailer (implementing it's own cache) > and in extbase, also not using the normal cache. > > > If it is not really used, i would suggest to deprecate it to avoid a > usage pattern like: > if(cache->has(id)) then cache->get(id). > > Bj?rn :-) 1#: Caching Framework (CFW) is a backport from the "famous" FLOW3 foam-work*. Due to the fact that it has a nice architecture at the cost of performance this implementation of the CFW come up. 2nd: If you want to change something in the CFW you should talk to the MoDs* of FLOW3. To get some changes into CORE it takes 6 month to several years. No idea about FLOW3 with it's academical approach*. Enjoy your weekend. Peter. *Just my personal opinion. To get me right: FLOW3 has an excellent design/architecture. But it's slow by design. But may be I'm wrong ;-) -- docendo discimus _____________________________ uon GbR http://www.uon.li http://www.xing.com/profile/Peter_Russ From jbl at deweblop.de Fri Feb 18 19:19:09 2011 From: jbl at deweblop.de (J. Lingott) Date: Fri, 18 Feb 2011 19:19:09 +0100 Subject: [TYPO3-dev] TYPO3 cleanup cli for typo3temp Message-ID: <mailman.11196.1298053274.648.typo3-dev@lists.typo3.org> Hey list, wrote some small command line interface for running cronjob to cleanup typo3temp directory. Made it as subpart of install sysext as its kind of using the procedure provided there. Modified it a bit to fit the needs of a scheduled task and it currently just supports the cleanup of typo3temp and its sub-directories (as that is all what I needed at the moment). The options are basically the same as for the install tool, just added some more to have extended functionality. Like for instance running through multiple sub-directories of typo3temp, including typo3temp itself. Also its possible to set the number of repeated runs being processed, so larger amounts can be processed without pushing server performance down too much. Also fixed a small bug concerning the file hash check, which didn't take into account file extensions differing from three chars. If you are interested in providing the code, i'd need info on how to do so! :-) Greetings J?rg Lingott From lolli at schwarzbu.ch Fri Feb 18 20:34:39 2011 From: lolli at schwarzbu.ch (Christian Kuhn) Date: Fri, 18 Feb 2011 20:34:39 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1298012606.766.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298012606.766.typo3-dev@lists.typo3.org> Message-ID: <mailman.11208.1298057799.648.typo3-dev@lists.typo3.org> Hey. On 02/18/2011 08:01 AM, Peter Russ wrote: >> On 02/17/2011 05:11 PM, Bjoern Pedersen wrote: >>> SELECT identifier FROM cachingframework_cache_hash WHERE crdate + >>> lifetime< 1297803600 AND lifetime> 0; >> >> Those queries are only fired by the garbage collection task, they are >> no usual production queries from frontend? > > But there is no reason that GB is blocking the server ;-) > Production or not doesn't really matter. Sure. My question was only meant to get an idea of the impact. Taking a look at the code something like 'AND lifetime>0' is used pretty often. From db point of view its even more bad if 'OR lifetime=0' is done. Background is that an entry with infinite lifetime is set to 0 to indicate that. It would be better to change this from 0 to 'far in the future' to avoid these queries. BTW: starttime / endtime fields in usual tables suffer from the same problem, a long standing issue ... Furthermore, imho 'unlimited' lifetime for cache entries is a bad idea in the first place (pretty often done for entries in cf_cache_hash): Chances for cache pollution are good this way (entries written once, never used, but never invalidated). From my point of view we should take a look at all core cache entries with unlimited lifetime and set a lower lifetime by default (not more than 4 weeks for example). The db backend is not a backport of FLOW3, it is v4 only. Patches can go to v4 directly. I'll see if I can come up with patches for the above two things (1. remove lifetime=0 queries and 2. maximum lifetime for core cache entries). Regards Christian From typo3.lists at philippgampe.info Fri Feb 18 20:46:24 2011 From: typo3.lists at philippgampe.info (Philipp Gampe) Date: Fri, 18 Feb 2011 20:46:24 +0100 Subject: [TYPO3-dev] TYPO3 cleanup cli for typo3temp References: <mailman.11196.1298053274.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298058500.13265.typo3-dev@lists.typo3.org> J. Lingott wrote: > If you are interested in providing the code, i'd need info on how to do > so! :-) You could make an extension and put sources on forge.typo3.org or you create a patch and attach it to bugtracker (create a feature request). IMHO best would be, if you could develop it into a core-ready patch and post this to core list ;) Best regards -- Philipp Gampe From lolli at schwarzbu.ch Fri Feb 18 20:52:45 2011 From: lolli at schwarzbu.ch (Christian Kuhn) Date: Fri, 18 Feb 2011 20:52:45 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1298023551.18649.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298016451.6669.typo3-dev@lists.typo3.org> <mailman.1.1298022540.16647.typo3-dev@lists.typo3.org> <mailman.1.1298022719.16696.typo3-dev@lists.typo3.org> <mailman.1.1298023551.18649.typo3-dev@lists.typo3.org> Message-ID: <mailman.11209.1298058885.648.typo3-dev@lists.typo3.org> Hey, On 02/18/2011 11:03 AM, Peter Russ wrote: > Sorry but your answer is not correct. Please check the code HOW it is > handled in the dbbackend. Even if only true or false is returned query > will always take lifetime into account. As far as I can see, there is no call to has() in the get() method of the db backend. Regards Christian From peter.russ at 4many.net Sat Feb 19 01:56:07 2011 From: peter.russ at 4many.net (Peter Russ) Date: Sat, 19 Feb 2011 01:56:07 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.11209.1298058885.648.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298016451.6669.typo3-dev@lists.typo3.org> <mailman.1.1298022540.16647.typo3-dev@lists.typo3.org> <mailman.1.1298022719.16696.typo3-dev@lists.typo3.org> <mailman.1.1298023551.18649.typo3-dev@lists.typo3.org> <mailman.11209.1298058885.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298077084.5334.typo3-dev@lists.typo3.org> --- Original Nachricht --- Absender: Christian Kuhn Datum: 18.02.2011 20:52: > Hey, > > On 02/18/2011 11:03 AM, Peter Russ wrote: >> Sorry but your answer is not correct. Please check the code HOW it is >> handled in the dbbackend. Even if only true or false is returned query >> will always take lifetime into account. > > As far as I can see, there is no call to has() in the get() method of > the db backend. > > Regards > Christian You are right at this point if you only see the dbbackend. BUT check the caching framework ;-) There is always a has() query BEFORE a get due to the fact that this has to perform on filesystem or memcache or db ;-) IMHO it would be best to put result of has or set ;-) to globals and return value if get is queried for the same value. BUT only works for dbbackend. Peter -- docendo discimus _____________________________ uon GbR http://www.uon.li http://www.xing.com/profile/Peter_Russ From typo3 at perseguers.ch Sat Feb 19 08:18:19 2011 From: typo3 at perseguers.ch (Xavier Perseguers) Date: Sat, 19 Feb 2011 08:18:19 +0100 Subject: [TYPO3-dev] API module on Forge Message-ID: <mailman.1.1298100016.14233.typo3-dev@lists.typo3.org> Hi, Does someone already succeeded on using API module for one of your Forge extensions? Is there something to do? I get this: translation missing: en, label_plugin_api Hier kommt die API-Dokumentation hin. Thanks Xavier From typo3 at t3node.com Sat Feb 19 11:44:25 2011 From: typo3 at t3node.com (=?UTF-8?B?U3RlZmZlbiBNw7xsbGVy?=) Date: Sat, 19 Feb 2011 11:44:25 +0100 Subject: [TYPO3-dev] TYPO3 cleanup cli for typo3temp In-Reply-To: <mailman.11196.1298053274.648.typo3-dev@lists.typo3.org> References: <mailman.11196.1298053274.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298112348.28607.typo3-dev@lists.typo3.org> Hi. On 18.02.2011 19:19 J. Lingott wrote: > wrote some small command line interface for running cronjob to cleanup > typo3temp directory. > (...) > If you are interested in providing the code, i'd need info on how to do > so! :-) > Yes, please open a bug for core. -- cheers, Steffen TYPO3 Blog: http://www.t3node.com/ Twitter: http://twitter.com/t3node From soren.malling at gmail.com Sat Feb 19 17:43:36 2011 From: soren.malling at gmail.com (=?ISO-8859-1?Q?S=F8ren_Malling?=) Date: Sat, 19 Feb 2011 17:43:36 +0100 Subject: [TYPO3-dev] Introduction to FlexForm excludefields (RFC #16334) Message-ID: <mailman.1.1298133939.26832.typo3-dev@lists.typo3.org> Hi, While developing TYPO3 4.5, Kai Vogel came up with a great feature: Make FlexForms editable via TSConfig and group access lists http://bugs.typo3.org/view.php?id=16334 The documentation helped a lot, but I would like to give the community a good example on how to use this, and how you do use it :-) From that, I came up with my first post on buzz.typo3.org. I would like to share it with you through the mailliglist, since the frontpage of buzz is very "random" and I'm not shown in the february list (don't worry, the admins have been notified :-) ) http://buzz.typo3.org/people/soeren-malling/article/personal-flexforms-and-the-need-for-typoscript/ I hope that you can benefit from it, please share it so this great feature can be spread. It didn't get much attention at the release. Have a nice weekend! Regards, S?ren Malling From typo3 at ndh-websolutions.de Mon Feb 21 00:12:51 2011 From: typo3 at ndh-websolutions.de (Nico de Haen) Date: Mon, 21 Feb 2011 00:12:51 +0100 Subject: [TYPO3-dev] Icons for custom doktypes Message-ID: <mailman.1.1298243689.24383.typo3-dev@lists.typo3.org> Hi, I wonder if the t3lib_spritemanager and the pagetree extension support page icons for custom doktypes. t3lib_spritemanager::addTcaTypeIcon('pages','contains_myext',t3lib_extMgm::extRelPath($_EXTKEY) . 'Resources/Public/Icons/pagetype.png'); enables a custom icon in the doktype selector in the page properties, but not in the page tree... Does someone know how to configure it? Regards, Nico From bjoern.pedersen at frm2.tum.de Mon Feb 21 09:47:35 2011 From: bjoern.pedersen at frm2.tum.de (Bjoern Pedersen) Date: Mon, 21 Feb 2011 09:47:35 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.11208.1298057799.648.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298012606.766.typo3-dev@lists.typo3.org> <mailman.11208.1298057799.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298278173.17051.typo3-dev@lists.typo3.org> Am 18.02.2011 20:34, schrieb Christian Kuhn: > Hey. > > On 02/18/2011 08:01 AM, Peter Russ wrote: >>> On 02/17/2011 05:11 PM, Bjoern Pedersen wrote: >>>> SELECT identifier FROM cachingframework_cache_hash WHERE crdate + >>>> lifetime< 1297803600 AND lifetime> 0; >>> >>> Those queries are only fired by the garbage collection task, they are >>> no usual production queries from frontend? >> >> But there is no reason that GB is blocking the server ;-) >> Production or not doesn't really matter. > > Sure. My question was only meant to get an idea of the impact. > > Taking a look at the code something like 'AND lifetime>0' is used pretty > often. From db point of view its even more bad if 'OR lifetime=0' is done. > Background is that an entry with infinite lifetime is set to 0 to > indicate that. It would be better to change this from 0 to 'far in the > future' to avoid these queries. BTW: starttime / endtime fields in usual > tables suffer from the same problem, a long standing issue ... > > Furthermore, imho 'unlimited' lifetime for cache entries is a bad idea > in the first place (pretty often done for entries in cf_cache_hash): > Chances for cache pollution are good this way (entries written once, > never used, but never invalidated). From my point of view we should take > a look at all core cache entries with unlimited lifetime and set a lower > lifetime by default (not more than 4 weeks for example). > > The db backend is not a backport of FLOW3, it is v4 only. Patches can go > to v4 directly. > > I'll see if I can come up with patches for the above two things (1. > remove lifetime=0 queries and 2. maximum lifetime for core cache entries). > > > Regards > Christian I fully agree. So to summarize once again: a) we need an indexed expire column b) we want to get rid of lifetime=0 as flag for no expiry (actually we could set expire to int_max, that's anyway the longest lifetime before wrapround to negative values would occur. c) i would suggest to make "has()" protected, as it is only useful in some cache_be implementations. Bj?rn From info at sk-typo3.de Mon Feb 21 09:52:02 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 21 Feb 2011 09:52:02 +0100 Subject: [TYPO3-dev] Plugins for FF4 beta Message-ID: <mailman.1.1298278440.17252.typo3-dev@lists.typo3.org> Hi, if you decided to use FF4 beta you may miss your plugins that are not compatible. However, they mostly work. So here is the way to enable them: * go to about:config * right click to create a new value type boolean * enter name "extensions.checkCompatibility.4.0b" and set to false * restart browser vg Steffen From dmitry.dulepov at gmail.com Mon Feb 21 14:40:21 2011 From: dmitry.dulepov at gmail.com (Dmitry Dulepov) Date: Mon, 21 Feb 2011 15:40:21 +0200 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1298278173.17051.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298012606.766.typo3-dev@lists.typo3.org> <mailman.11208.1298057799.648.typo3-dev@lists.typo3.org> <mailman.1.1298278173.17051.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298295740.15033.typo3-dev@lists.typo3.org> Hi! Bjoern Pedersen wrote: > a) we need an indexed expire column Generally a single index column is not worth unless it is the only one used in WHERE. Everything depends on the query. It is best to see the query and field definitions to decide on indexes. -- Dmitry Dulepov TYPO3 core&security team member E-mail: dmitry.dulepov at typo3.org Web: http://dmitry-dulepov.com/ From info at sk-typo3.de Mon Feb 21 14:47:03 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 21 Feb 2011 14:47:03 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1298295740.15033.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298012606.766.typo3-dev@lists.typo3.org> <mailman.11208.1298057799.648.typo3-dev@lists.typo3.org> <mailman.1.1298278173.17051.typo3-dev@lists.typo3.org> <mailman.1.1298295740.15033.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298296142.15332.typo3-dev@lists.typo3.org> Hi, Am 21.02.2011 14:40, schrieb Dmitry Dulepov: > Hi! > > Bjoern Pedersen wrote: >> a) we need an indexed expire column > > Generally a single index column is not worth unless it is the only one > used in WHERE. Everything depends on the query. It is best to see the > query and field definitions to decide on indexes. > absolute correct. That makes it so difficult to find the best indexes for TYPO3 tables. vg Steffen From typo3 at perseguers.ch Mon Feb 21 15:02:41 2011 From: typo3 at perseguers.ch (Xavier Perseguers) Date: Mon, 21 Feb 2011 15:02:41 +0100 Subject: [TYPO3-dev] API Module on Forge Message-ID: <mailman.1.1298297081.17662.typo3-dev@lists.typo3.org> Hi, Was sure I posted this but seems that my message was delivered to limbs. Anyway, can someone tell me if s/he was successful at using module "API" on Forge? Don't get what I have to do to make it work and could not find this module in the list of modules of Redmine. All I get is: translation missing: en, label_plugin_api Hier kommt die API-Dokumentation hin. Xavier From bjoern.pedersen at frm2.tum.de Mon Feb 21 15:11:33 2011 From: bjoern.pedersen at frm2.tum.de (Bjoern Pedersen) Date: Mon, 21 Feb 2011 15:11:33 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1298296142.15332.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298012606.766.typo3-dev@lists.typo3.org> <mailman.11208.1298057799.648.typo3-dev@lists.typo3.org> <mailman.1.1298278173.17051.typo3-dev@lists.typo3.org> <mailman.1.1298295740.15033.typo3-dev@lists.typo3.org> <mailman.1.1298296142.15332.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298297611.18707.typo3-dev@lists.typo3.org> Am 21.02.2011 14:47, schrieb Steffen Kamper: > Hi, > > Am 21.02.2011 14:40, schrieb Dmitry Dulepov: >> Hi! >> >> Bjoern Pedersen wrote: >>> a) we need an indexed expire column >> >> Generally a single index column is not worth unless it is the only one >> used in WHERE. Everything depends on the query. It is best to see the >> query and field definitions to decide on indexes. >> > > absolute correct. That makes it so difficult to find the best indexes > for TYPO3 tables. > > vg Steffen I agree. Actually that's what I meant with indexed column. See also the thread start for a slowlog based analysis. Bj?rn From dmitry.dulepov at gmail.com Mon Feb 21 15:39:07 2011 From: dmitry.dulepov at gmail.com (Dmitry Dulepov) Date: Mon, 21 Feb 2011 16:39:07 +0200 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.1.1298296142.15332.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298012606.766.typo3-dev@lists.typo3.org> <mailman.11208.1298057799.648.typo3-dev@lists.typo3.org> <mailman.1.1298278173.17051.typo3-dev@lists.typo3.org> <mailman.1.1298295740.15033.typo3-dev@lists.typo3.org> <mailman.1.1298296142.15332.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298299266.21610.typo3-dev@lists.typo3.org> Hi! Steffen Kamper wrote: > absolute correct. That makes it so difficult to find the best indexes > for TYPO3 tables. There are too many different queries to optimize that. What we need is something like a "storage" object for each record type (like a "page storage"). That would return the record with the given query and cache it (at least by id) to avoid database queries to the same record from other parts of the core. I thought of doing that on t3lib_db level but that is too low level point. It would be a big architectural change if we do such layer but may be we should if we want to improve performance. -- Dmitry Dulepov TYPO3 core&security team member E-mail: dmitry.dulepov at typo3.org Web: http://dmitry-dulepov.com/ From bjoern.pedersen at frm2.tum.de Mon Feb 21 16:36:10 2011 From: bjoern.pedersen at frm2.tum.de (Bjoern Pedersen) Date: Mon, 21 Feb 2011 16:36:10 +0100 Subject: [TYPO3-dev] performace of cachingframework In-Reply-To: <mailman.11208.1298057799.648.typo3-dev@lists.typo3.org> References: <mailman.1.1297959200.9924.typo3-dev@lists.typo3.org> <mailman.11120.1297979565.648.typo3-dev@lists.typo3.org> <mailman.1.1298012606.766.typo3-dev@lists.typo3.org> <mailman.11208.1298057799.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298302689.28874.typo3-dev@lists.typo3.org> Am 18.02.2011 20:34, schrieb Christian Kuhn: > Hey. > > On 02/18/2011 08:01 AM, Peter Russ wrote: >>> On 02/17/2011 05:11 PM, Bjoern Pedersen wrote: >>>> SELECT identifier FROM cachingframework_cache_hash WHERE crdate + >>>> lifetime< 1297803600 AND lifetime> 0; >>> >>> Those queries are only fired by the garbage collection task, they are >>> no usual production queries from frontend? >> >> But there is no reason that GB is blocking the server ;-) >> Production or not doesn't really matter. > > Sure. My question was only meant to get an idea of the impact. > > Taking a look at the code something like 'AND lifetime>0' is used pretty > often. From db point of view its even more bad if 'OR lifetime=0' is done. > Background is that an entry with infinite lifetime is set to 0 to > indicate that. It would be better to change this from 0 to 'far in the > future' to avoid these queries. BTW: starttime / endtime fields in usual > tables suffer from the same problem, a long standing issue ... > > Furthermore, imho 'unlimited' lifetime for cache entries is a bad idea > in the first place (pretty often done for entries in cf_cache_hash): > Chances for cache pollution are good this way (entries written once, > never used, but never invalidated). From my point of view we should take > a look at all core cache entries with unlimited lifetime and set a lower > lifetime by default (not more than 4 weeks for example). > > The db backend is not a backport of FLOW3, it is v4 only. Patches can go > to v4 directly. > > I'll see if I can come up with patches for the above two things (1. > remove lifetime=0 queries and 2. maximum lifetime for core cache entries). > > > Regards > Christian I have created a bugtracker entry and a first patch. http://bugs.typo3.org/view.php?id=17693 Bj?rn From bau at netzwerkstatt.ch Mon Feb 21 17:13:39 2011 From: bau at netzwerkstatt.ch (bau at netzwerkstatt.ch) Date: Mon, 21 Feb 2011 17:13:39 +0100 Subject: [TYPO3-dev] Access Tab is not displayed within Content Types "Image" and "Text w/ Image" Message-ID: <mailman.11449.1298304940.648.typo3-dev@lists.typo3.org> ?Hello We encounter a strange issue currently after a T3-Upgrade to 4.4.6. The Access Tab where you can set the start and stop times is not displayed anymore in the BE after the upgrade. Strangely, this only happens with the content types "Image" and "Text w/ Image". We have checked the TCA and anything else that could make this happen. The compatibility wizzard did not help to resolve this as well. The Access Tab is displayed all correctly if we're working with Text or any other content type. I presume that the file tbl_tt_content.php is the script that controls the settings of the backend screen.. What else could we try to get our Access Tabs back for Image and Text w/ Image? Note: We did not change anything in the TYPO3-Core previously. Thanks in advance Netzwerkstatt, Florian Baumann From typo3 at ndh-websolutions.de Tue Feb 22 07:31:41 2011 From: typo3 at ndh-websolutions.de (Nicolas de Haen) Date: Tue, 22 Feb 2011 07:31:41 +0100 Subject: [TYPO3-dev] Icons for custom doktypes In-Reply-To: <mailman.1.1298243689.24383.typo3-dev@lists.typo3.org> References: <mailman.1.1298243689.24383.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298356420.8588.typo3-dev@lists.typo3.org> Hat keiner eine Idee? Ich bin doch sicher nicht der Einzige der custom icons f?r custom doktypes verwendet? Gru?, Nico From fsu-lists at cobweb.ch Tue Feb 22 11:39:18 2011 From: fsu-lists at cobweb.ch (=?ISO-8859-1?Q?Fran=E7ois_Suter?=) Date: Tue, 22 Feb 2011 11:39:18 +0100 Subject: [TYPO3-dev] ExtJs in the TYPO3 BE how-to questions? Message-ID: <mailman.1.1298371278.16876.typo3-dev@lists.typo3.org> Hi all, I have a few questions regarding proper usage of ExtJS-based scripts in the TYPO3 BE: 1) I know some mechanism was defined to store localized string read from locallang files. How is this done properly? 2) about MessageBoxes: is it ok to simple call Ext.MessageBox.show() or do we have a specific type of MessageBoxes for TYPO3 extending the original one? 3) about buttons in MessageBoxes: same question, do we have specific classes in TYPO3 for buttons? Additional question: if I want my button label to be translatable, I guess I have to define my own custom button and not use something like Ext.MessageBox.OK, right? 4) about name-spacing, what should really go into it and what is ok to just stuff inside an Ext.onReady() call? That's all for now, thanks in advance for the information. Cheers -- Francois Suter Cobweb Development Sarl - http://www.cobweb.ch From info at sk-typo3.de Tue Feb 22 11:57:46 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Tue, 22 Feb 2011 11:57:46 +0100 Subject: [TYPO3-dev] ExtJs in the TYPO3 BE how-to questions? In-Reply-To: <mailman.1.1298371278.16876.typo3-dev@lists.typo3.org> References: <mailman.1.1298371278.16876.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298372387.19023.typo3-dev@lists.typo3.org> Hi Francois, Am 22.02.2011 11:39, schrieb Fran?ois Suter: > Hi all, > > I have a few questions regarding proper usage of ExtJS-based scripts in > the TYPO3 BE: > fine - also good for all others to know what the best practise is. > 1) I know some mechanism was defined to store localized string read from > locallang files. How is this done properly? > 1) pagerenderer has a method to include a language file for javascript. This is simular to the inclusion via LANG you do for php. Example: $this->pageRenderer->addInlineLanguageLabelFile(t3lib_extMgm::extPath('em', 'language/locallang.xml')); 2) If you have some single labels to include, just define an array with these labels like $labels['yes'] = $GLOBALS['LANG']->sL('LLL:EXT:lang/locallang_common.xml:yes'); $labels['no'] = $GLOBALS['LANG']->sL('LLL:EXT:lang/locallang_common.xml:no'); $this->pageRenderer->addInlineLanguageLabelArray($labels); You can do that additional to step 1. > 2) about MessageBoxes: is it ok to simple call Ext.MessageBox.show() or > do we have a specific type of MessageBoxes for TYPO3 extending the > original one? > it's ok to do so, but we already have a file you should include: t3lib(js/extjs/notifications.js There you find some predefined message boxes and windows for easy usage, eg TYPO3.Dialog.InformationDialog(config) TYPO3.Dialog.QuestionDialog(config) a.s.o. But it's not mandantory to use these. In same file we have windows that have already the css classes for TYPO3, so that makes life bit easier. > 3) about buttons in MessageBoxes: same question, do we have specific > classes in TYPO3 for buttons? Additional question: if I want my button > label to be translatable, I guess I have to define my own custom button > and not use something like Ext.MessageBox.OK, right? > see above. ExtJs comes with translations for exact these labels, and they are included automatically by pagerenderer > 4) about name-spacing, what should really go into it and what is ok to > just stuff inside an Ext.onReady() call? > namespace is important to be independent from other scripts, so no problems if your function have same name. We take the TYPO3 prefix always to indicate that we are inside TYPO3. The BE already use some namespaces, best is to open BE and console and type "top.TYPO3" - press ctrl + return to execute. You'll find the TYPO3 object in console and can browse it to see all existing components. For extensions i suggest namespace TYPO3.[extkey].[classname] So you are save that the namespace is already given. Hope your questions are answered now. vg Steffen From info at sk-typo3.de Tue Feb 22 11:59:57 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Tue, 22 Feb 2011 11:59:57 +0100 Subject: [TYPO3-dev] ExtJs in the TYPO3 BE how-to questions? In-Reply-To: <mailman.1.1298372387.19023.typo3-dev@lists.typo3.org> References: <mailman.1.1298371278.16876.typo3-dev@lists.typo3.org> <mailman.1.1298372387.19023.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298372518.19023.typo3-dev@lists.typo3.org> Hi, Am 22.02.2011 11:57, schrieb Steffen Kamper: >> > > 1) > pagerenderer has a method to include a language file for javascript. > This is simular to the inclusion via LANG you do for php. > Example: > $this->pageRenderer->addInlineLanguageLabelFile(t3lib_extMgm::extPath('em', > 'language/locallang.xml')); > > 2) > If you have some single labels to include, just define an array with > these labels like > $labels['yes'] = > $GLOBALS['LANG']->sL('LLL:EXT:lang/locallang_common.xml:yes'); > $labels['no'] = > $GLOBALS['LANG']->sL('LLL:EXT:lang/locallang_common.xml:no'); > $this->pageRenderer->addInlineLanguageLabelArray($labels); > > You can do that additional to step 1. > forgot to mention: once this is done, labels are found with TYPO3.lang.[labelname] Try to avoid labelnames with dot (again), as this is an array seperator in javascript. vg Steffen From fsu-lists at cobweb.ch Tue Feb 22 12:08:43 2011 From: fsu-lists at cobweb.ch (=?ISO-8859-1?Q?Fran=E7ois_Suter?=) Date: Tue, 22 Feb 2011 12:08:43 +0100 Subject: [TYPO3-dev] ExtJs in the TYPO3 BE how-to questions? In-Reply-To: <mailman.1.1298372387.19023.typo3-dev@lists.typo3.org> References: <mailman.1.1298371278.16876.typo3-dev@lists.typo3.org> <mailman.1.1298372387.19023.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298373043.20081.typo3-dev@lists.typo3.org> Hi, > Hope your questions are answered now. Yep, thanks a lot, it certainly gives me more to experiment. I'll come back if I have more questions. Cheers -- Francois Suter Cobweb Development Sarl - http://www.cobweb.ch From vsbies at wp.pl Tue Feb 22 12:13:40 2011 From: vsbies at wp.pl (Marcus 'biesior' Biesioroff) Date: Tue, 22 Feb 2011 12:13:40 +0100 Subject: [TYPO3-dev] Values from 2 DB fields in TypoScript (hook conf) Message-ID: <mailman.1.1298373345.20904.typo3-dev@lists.typo3.org> ellou' Geeks! I'm creating new hook and need to pass a DB value to some configuration option, in example: 10 = TEXT 10.field = crdate 10.myHook = 1 10.myHook { someOption.field = tstamp } but in debug it returns just 'tstamp' how can I workaround this problem (in TS and/or my PHP)? -- Marcus 'biesior' Biesioroff http://www.typo3.pl | TYPO3 Polish Community T3CI From benni at typo3.org Tue Feb 22 17:41:26 2011 From: benni at typo3.org (Benjamin Mack) Date: Tue, 22 Feb 2011 17:41:26 +0100 Subject: [TYPO3-dev] Schedule info for all participants of next weeks' code sprint Message-ID: <mailman.1.1298393006.24498.typo3-dev@lists.typo3.org> To all TYPO3 Coders who are attending the Code Sprint next week :) As the Berlin Code Sprint 2011 is marching closer, I want to give you a quick overview of how we want to outline the week. The first two days will include some general discussions about certain team-wide hot topics like Git/Gerrit migration or the next steps on the migration path to TYPO3 v5. The major part of the week however should be marked by having small coding groups and projects we want to kickstart (or even finish). Inbetween, and especially in the evenings we considered "7 minutes of fame" where everybody can do small presentations about cool things like "Power using phpStorm for TYPO3 development" or such. However, this is only a rough idea of the actual topics we want to discuss, and there are a lot of places where we'd like to get your ideas, to fill the week with interesting bits and pieces for everybody. The schedule also already shows when we plan on having the breaks. Lunch is taken care of every day at a small caf? nearby. On wednesday we join in to have a coding night to revive the spirit from the last Code Sprint in Stuttgart. You will find the current schedule in the wiki, and we're happy to get your input, either via this list or directly next monday, when we meet in person and start the week with a kickoff meeting. Wiki page: http://wiki.typo3.org/Code_Sprint_Berlin_2011 Agenda PDF: http://wiki.typo3.org/wiki/images/d/d7/Calendar_t3bcs11.pdf All the best, Benni Mack From christian.lerrahn at cerebrum.com.au Wed Feb 23 07:22:11 2011 From: christian.lerrahn at cerebrum.com.au (Christian Lerrahn (Cerebrum)) Date: Wed, 23 Feb 2011 17:22:11 +1100 Subject: [TYPO3-dev] Implement password expiry in BE Message-ID: <mailman.1.1298442272.27711.typo3-dev@lists.typo3.org> Hi, I'm trying to implement a password expiry with blacklists for the BE. In principle that already exists as the extension cl_beuser_password but that extension (even when modified to work with current TYPO3 versions) has one major weakness. As the password update is performed AFTER successful login, it can easily be circumvented by just changing the URL in the browser. I have had several ideas how to go about this but ran into different kinds of problems with every single one of them. My first approach was to use a service. I could run this service before any other authentication service, pass through to the other services if the password is not expired or redirect to some password change form if it is expired. There is a major flaw in this design. Firstly, I reveal that the password is expired without knowing first if the entered password is valid. If I want to avoid that I have to duplicate the whole authentication routine into my service and then not pass on to other services. That seems rather inelegant. The other option would be to run the service late in the process. However, I cannot run it after successful login because it will never be used at that point. The service chain stops as soon as a service reports a successful login. The second approach I took was using hooks or XCLASSes, similar to cl_beuser_password. The XCLASS approach has two major flaws. There is, of course, the limitation of one XCLASS per class. Furthermore, I can't XCLASS e.g. dummy.php if I don't log in the user first because the start-up code in that file already exits if no user is logged it. However, once I keep the user logged in, he can just go to the BE manually and never change his password. The problem with hooks is that there are no hooks that really are in the right place. The one that rsaauth uses only works until it gets content from something that hooks in. The hooks in authentication class get called too often for the purpose here. Any suggestions how to go about that? Maybe another approach I haven't thought of? Cheers, Christian From ernst at cron-it.de Wed Feb 23 12:01:15 2011 From: ernst at cron-it.de (Ernesto Baschny [cron IT]) Date: Wed, 23 Feb 2011 12:01:15 +0100 Subject: [TYPO3-dev] Schedule info for all participants of next weeks' code sprint In-Reply-To: <mailman.1.1298393006.24498.typo3-dev@lists.typo3.org> References: <mailman.1.1298393006.24498.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298458995.4818.typo3-dev@lists.typo3.org> Benjamin Mack schrieb am 22.02.2011 17:41: > To all TYPO3 Coders who are attending the Code Sprint next week :) > > As the Berlin Code Sprint 2011 is marching closer, I want to give you a > quick overview of how we want to outline the week. The first two days > will include some general discussions about certain team-wide hot topics > like Git/Gerrit migration or the next steps on the migration path to > TYPO3 v5. The major part of the week however should be marked by having > small coding groups and projects we want to kickstart (or even finish). > Inbetween, and especially in the evenings we considered "7 minutes of > fame" where everybody can do small presentations about cool things like > "Power using phpStorm for TYPO3 development" or such. > > However, this is only a rough idea of the actual topics we want to > discuss, and there are a lot of places where we'd like to get your > ideas, to fill the week with interesting bits and pieces for everybody. > > The schedule also already shows when we plan on having the breaks. Lunch > is taken care of every day at a small caf? nearby. On wednesday we join > in to have a coding night to revive the spirit from the last Code Sprint > in Stuttgart. > > You will find the current schedule in the wiki, and we're happy to get > your input, either via this list or directly next monday, when we meet > in person and start the week with a kickoff meeting. > > Wiki page: http://wiki.typo3.org/Code_Sprint_Berlin_2011 > Agenda PDF: http://wiki.typo3.org/wiki/images/d/d7/Calendar_t3bcs11.pdf +1 on all that, it will be a *great week* for TYPO3!!! Sad that I can only join Monday + Tuesday, but at least I will share a little of the spirit. Cheers and see ya there, Ernesto From oliver.hader at typo3.org Wed Feb 23 15:48:01 2011 From: oliver.hader at typo3.org (Oliver Hader) Date: Wed, 23 Feb 2011 15:48:01 +0100 Subject: [TYPO3-dev] Announcing TYPO3 4.3.11 and 4.4.7 Message-ID: <mailman.1.1298472602.31113.typo3-dev@lists.typo3.org> Dear TYPO3 community, The TYPO3 core team has just released TYPO3 versions 4.3.11 and 4.4.7, which are now ready for you to download. All versions are maintenance releases and contain only bugfixes. The packages can be downloaded here: http://typo3.org/download/packages/ For details about the release, please see: http://news.typo3.org/news/article/typo3-4311-and-447-released/ MD5 checksums: 3294cd3937d6b09d7786d3596138a26e dummy-4.3.11.tar.gz 5e701f944065f73946e764a79ae0fb96 dummy-4.3.11.zip 44587ce69cd89b7ec8493c76f2888fc2 typo3_src-4.3.11.tar.gz 14f7a0ec5cd3cae9370c5e463f322aa9 typo3_src-4.3.11.zip be01675f4fd115b7e9d4ea2f4ae103e6 typo3_src+dummy-4.3.11.zip af88d6aeb97cd8a746d8a506c6faf561 dummy-4.4.7.tar.gz b447f7f9832348340081ba9a9930bf3a dummy-4.4.7.zip 77ec411f06cd16f0379958c09116ca90 typo3_src-4.4.7.tar.gz e97bd6c41e68d480c6c5dc760b71e2b2 typo3_src-4.4.7.zip 5d20fcf28bdd26ebced7fa7438bf5169 typo3_src+dummy-4.4.7.zip 9840334bf78a379f8cf348bf727a84ee introductionpackage-4.4.7.zip Rock on! Olly -- Oliver Hader TYPO3 v4 Core Team Leader TYPO3 .... inspiring people to share! Get involved: http://typo3.org From ernesto.baschny at typo3.org Wed Feb 23 18:41:17 2011 From: ernesto.baschny at typo3.org (Ernesto Baschny) Date: Wed, 23 Feb 2011 18:41:17 +0100 Subject: [TYPO3-dev] [TYPO3-v4] Announcing TYPO3 4.5.1 Message-ID: <mailman.11806.1298483102.648.typo3-dev@lists.typo3.org> Dear TYPO3 community, The TYPO3 core team has just released TYPO3 versions 4.5.1, which is now ready for you to download. This is a maintenance release and contain only bugfixes. Users of 4.5.0 are strongly advised to upgrade. The packages can be downloaded here: http://typo3.org/download/packages/ For details about the release, please see: http://news.typo3.org/news/article/typo3-451-released/ http://wiki.typo3.org/TYPO3_4.5.1 - Release Notes **MD5 checksums: b91e93d98e4f7bad0636788689eb179c dummy-4.5.1.tar.gz cb5e7afbd349d5d2b9a65b14ec577c68 dummy-4.5.1.zip 6b7012da6953010673d9990d9bf0ca9e typo3_src-4.5.1.tar.gz 884d832ae93023b9506df7eb67f91f05 typo3_src-4.5.1.zip 4b1cfd122125029827e99ec7ca3295cc typo3_src+dummy-4.5.1.zip 28027c7a6bb707ff006000b5912ab089 introductionpackage-4.5.1.tar.gz 632782f0d38298980cadb9f7445cbf3f introductionpackage-4.5.1.zip Cheers, Steffen Kamper (Technical Leader) and Ernesto Baschny (Release Manager) -- Ernesto Baschny Core Developer V4 Team Release Manager TYPO3 4.5 TYPO3 .... inspiring people to share! Get involved: typo3.org From tomasnorre at gmail.com Thu Feb 24 09:04:37 2011 From: tomasnorre at gmail.com (Tomas Norre Mikkelsen) Date: Thu, 24 Feb 2011 09:04:37 +0100 Subject: [TYPO3-dev] TS Newsgroup Message-ID: <mailman.1.1298534788.4189.typo3-dev@lists.typo3.org> Hi, Tried to find a TypoScript newsgroup but could not find any. If not exists, How about creating one ? -- Tomas Norre Mikkelsen twitter.com/tomasnorre Member of TYPO3: Documentation Teams & Skin Team. From mail at ringerge.org Thu Feb 24 09:12:17 2011 From: mail at ringerge.org (Georg Ringer) Date: Thu, 24 Feb 2011 09:12:17 +0100 Subject: [TYPO3-dev] TS Newsgroup In-Reply-To: <mailman.1.1298534788.4189.typo3-dev@lists.typo3.org> References: <mailman.1.1298534788.4189.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298535252.4977.typo3-dev@lists.typo3.org> Hi, Am 24.02.2011 09:04, schrieb Tomas Norre Mikkelsen: > If not exists, How about creating one ? for which reason? there is already english, german, and dev? I guess that nobody wants to read one list more Georg From tomasnorre at gmail.com Thu Feb 24 09:34:18 2011 From: tomasnorre at gmail.com (Tomas Norre Mikkelsen) Date: Thu, 24 Feb 2011 09:34:18 +0100 Subject: [TYPO3-dev] TS Newsgroup In-Reply-To: <mailman.1.1298535252.4977.typo3-dev@lists.typo3.org> References: <mailman.1.1298534788.4189.typo3-dev@lists.typo3.org> <mailman.1.1298535252.4977.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298536568.7484.typo3-dev@lists.typo3.org> On 24-02-2011 09:12, Georg Ringer wrote: > Hi, > > Am 24.02.2011 09:04, schrieb Tomas Norre Mikkelsen: >> If not exists, How about creating one ? > > for which reason? there is already english, german, and dev? I guess > that nobody wants to read one list more An English TS List? If not what you ment, my idea was the more specific, the easier to get help? -- Tomas Norre Mikkelsen twitter.com/tomasnorre Member of TYPO3: Documentation Teams & Skin Team. From christian.weiske at netresearch.de Thu Feb 24 12:15:25 2011 From: christian.weiske at netresearch.de (Christian Weiske) Date: Thu, 24 Feb 2011 12:15:25 +0100 Subject: [TYPO3-dev] Backend: Reloading flexform without saving Message-ID: <mailman.1.1298546247.24949.typo3-dev@lists.typo3.org> Hello, Fields in a flexform may be set to reload the form when changed by setting > <onChange>reload</onChange> because i.e. different fields will be shown when the field has a certain value. The same is possible by setting 'requestUpdate' in the TCA control array. Now my question: Is it possible to reload the form without causing it to save the current values? This is necessary when the fields that are visible after reloading are not valid yet. -- Mit freundlichen Gr??en Christian Weiske E-Mail: christian.weiske at netresearch.de Dipl.-Inf. Christian Weiske Netresearch GmbH & Co. KG ----------------------------------------------- Nonnenstra?e 11d - 04229 Leipzig Telefon: (0341) 47 842 - 16 Telefax: (0341) 47 842 - 29 ----------------------------------------------- http://www.netresearch.de - info at netresearch.de ++++++++++++++ Netresearch - Spezialagentur f?r TYPO3 und Magento ++++++++++++++ http://www.netresearch.de/blog http://twitter.com/netresearch ----------------------------------------------- Registergericht: Amtsgericht Leipzig HRA 15614 Komplement?r: Netresearch Beteiligungs GmbH, Amtsgericht Leipzig HRB 17018 Gesch?ftsf?hrer: Michael Ablass, Thomas Fleck From typo3 at perseguers.ch Thu Feb 24 12:35:39 2011 From: typo3 at perseguers.ch (Xavier Perseguers) Date: Thu, 24 Feb 2011 12:35:39 +0100 Subject: [TYPO3-dev] Backend: Reloading flexform without saving In-Reply-To: <mailman.1.1298546247.24949.typo3-dev@lists.typo3.org> References: <mailman.1.1298546247.24949.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298547461.27765.typo3-dev@lists.typo3.org> Hello, > Fields in a flexform may be set to reload the form when changed by > setting >> <onChange>reload</onChange> > because i.e. different fields will be shown when the field has a > certain value. The same is possible by setting 'requestUpdate' in the > TCA control array. > > Now my question: Is it possible to reload the form without causing it > to save the current values? This is necessary when the fields that > are visible after reloading are not valid yet. Short answer: no! Although I agree this would be very useful but this implies a complete rework of tceforms. Xavier From ernesto.baschny at typo3.org Thu Feb 24 15:43:16 2011 From: ernesto.baschny at typo3.org (Ernesto Baschny) Date: Thu, 24 Feb 2011 15:43:16 +0100 Subject: [TYPO3-dev] [TYPO3-v4] Tomorrow release TYPO3 4.5.2 Message-ID: <mailman.11969.1298559003.648.typo3-dev@lists.typo3.org> Hi, we are glad that almost everybody enjoyed our 4.5.1 release yesterday. It fixes almost all stuff that were reported since the release of 4.5.0. But unfortunately some of these fixes also included some regressions which affected specific installations. For this reason, we will be releasing a *4.5.2* by tomorrow, which will address these topics: 1) RFC #17732: Install Tool "Fatal error: Class 't3lib_div' not found" => This only happens when you have specific versions of PHP-APC running. 2) Fatal Error in the Linkvalidator => This affects all users that need or use the new Linkvalidator module 3) RFC #16788: Flexform inputfields remain empty due to JS error => Not a regression, but a "long standing" 4.5 bug which will be fixed 4) Warnings and other issues (Translations, ...) in the Extension Manager ... maybe more? To get more feedback, I would appreciate if you take a time to check the bug tracker and try to reproduce or give feedback on issues that have been found already: http://bit.ly/feqH96 If you have an issue not listed here before, don't be shy to report it. Since we need to be able to reproduce or at least understand the origin or a reported problem, please be so kind to give us more information about your setup (OS, Webserver Software, Versions of PHP, Installed modules, third party extensions that are installed, etc). If you get PHP errors, it helps to have XDEBUG Extension installed which will print out a whole stack trace of the error for you to copy&paste into the report. Thanks for your help! Cheers, Ernesto -- Ernesto Baschny Core Developer V4 Team Release Manager TYPO3 4.5 TYPO3 .... inspiring people to share! Get involved: typo3.org From ernesto.baschny at typo3.org Thu Feb 24 18:17:35 2011 From: ernesto.baschny at typo3.org (Ernesto Baschny) Date: Thu, 24 Feb 2011 18:17:35 +0100 Subject: [TYPO3-dev] [TYPO3-v4] Tomorrow release TYPO3 4.5.2 In-Reply-To: <mailman.1.1298558718.16860.typo3-project-v4@lists.typo3.org> References: <mailman.1.1298558718.16860.typo3-project-v4@lists.typo3.org> Message-ID: <mailman.11996.1298568002.648.typo3-dev@lists.typo3.org> Ernesto Baschny schrieb am 24.02.2011 15:43: > we are glad that almost everybody enjoyed our 4.5.1 release yesterday. > It fixes almost all stuff that were reported since the release of 4.5.0. > > But unfortunately some of these fixes also included some regressions > which affected specific installations. For this reason, we will be > releasing a *4.5.2* by tomorrow, which will address these topics: > (...) > ... maybe more? Some of the issues being reported seems to be related to PHP opcaches or stalled typo3conf/temp* files. These include stuff like: - "Extension key "lang" was NOT loaded" - PHP Fatal error: Class 't3lib_extjs_ExtDirectApi' not found - ... and maybe others To be sure, before reporting an error, please make sure you follow this routing after you switch the symlink from 4.5.0 to 4.5.1 source: 1) Restart the Webserver / PHP if you are using some PHP opcache (Xcache, APC, eAccelerator). Maybe you might need to delete old cache files before doing that, if the module stores cached files in the file system (check your php.ini settings or output of phpinfo() for this). 2) Delete old typo3conf/temp* files. 3) Clean up your browsers cache and make sure you connect to the backend using a new session (restart the browser). After doing that and still being able to reproduce the error, go ahead and report it in the bug tracker, *if* it hasn't been reported before. If its already there, just add a comment to it so that we know who exactly is affected. Thanks! Cheers, Ernesto -- Ernesto Baschny Core Developer V4 Team Release Manager TYPO3 4.5 TYPO3 .... inspiring people to share! Get involved: typo3.org From scecere at krur.com Thu Feb 24 19:31:44 2011 From: scecere at krur.com (Stefano Cecere) Date: Thu, 24 Feb 2011 19:31:44 +0100 Subject: [TYPO3-dev] Symmetric bidirectional MM ralations on the same table References: <mailman.1.1248700188.11126.typo3-dev@lists.netfielders.de> <mailman.1.1248722157.7907.typo3-dev@lists.netfielders.de> Message-ID: <mailman.1.1298572426.7659.typo3-dev@lists.typo3.org> any news on self symmetrical MM relations? now we have 4.5 .. and i was hoping they had come! maybe we could add a new special tca variable (like "self" enabled).. so that the relation can be searched in both ways? any idea? On Mon, 27 Jul 2009 21:15:57 +0200, Dmitry Dulepov <dmitry.dulepov at gmail.com> wrote: > Hi! > > Steffen M?ller wrote: >> My entity 'article' should be allowed to have references to records of >> the same entity (table). >> I tried to add a column 'related' of type 'select' which makes use of a >> MM-table. But I can only see the reference in one way (in the article >> where I added the reference). The article which was added as a reference >> does not show the reference to its origin. > > It is not supported by TYPO3 (for those who want to dig deeper: see > t3lib_loaddbgroup). > -- ____ ___ __ _ ______________________ Stefano Cecere krur.com multimedia From helmut.hummel at typo3.org Thu Feb 24 20:58:41 2011 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Thu, 24 Feb 2011 20:58:41 +0100 Subject: [TYPO3-dev] Symmetric bidirectional MM ralations on the same table In-Reply-To: <mailman.1.1298572426.7659.typo3-dev@lists.typo3.org> References: <mailman.1.1248700188.11126.typo3-dev@lists.netfielders.de> <mailman.1.1248722157.7907.typo3-dev@lists.netfielders.de> <mailman.1.1298572426.7659.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298577643.16039.typo3-dev@lists.typo3.org> Hi, On 24.02.11 19:31, Stefano Cecere wrote: > any news on self symmetrical MM relations? > > now we have 4.5 .. and i was hoping they had come! > > maybe we could add a new special tca variable (like "self" enabled).. so > that the relation can be searched in both ways? > > any idea? I would use a tcemain hook that adds the opposite relation to the mm table. Kind regards, Helmut -- Helmut Hummel TYPO3 Security Team Leader TYPO3 .... inspiring people to share! Get involved: typo3.org From info at sk-typo3.de Thu Feb 24 21:14:48 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Thu, 24 Feb 2011 21:14:48 +0100 Subject: [TYPO3-dev] Symmetric bidirectional MM ralations on the same table In-Reply-To: <mailman.1.1298577643.16039.typo3-dev@lists.typo3.org> References: <mailman.1.1248700188.11126.typo3-dev@lists.netfielders.de> <mailman.1.1248722157.7907.typo3-dev@lists.netfielders.de> <mailman.1.1298572426.7659.typo3-dev@lists.typo3.org> <mailman.1.1298577643.16039.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298578611.17226.typo3-dev@lists.typo3.org> Hi, Am 24.02.2011 20:58, schrieb Helmut Hummel: > Hi, > > On 24.02.11 19:31, Stefano Cecere wrote: >> any news on self symmetrical MM relations? >> >> now we have 4.5 .. and i was hoping they had come! >> >> maybe we could add a new special tca variable (like "self" enabled).. so >> that the relation can be searched in both ways? >> >> any idea? > > I would use a tcemain hook that adds the opposite relation to the mm table. > ... as proof of concept. At the end i would wish to have correct fixes in core, i kmow there are some issues where mm tables are not updated proper, or records not deleted if parent records are deleted. vg Steffen From scecere at krur.com Thu Feb 24 22:38:30 2011 From: scecere at krur.com (Stefano Cecere) Date: Thu, 24 Feb 2011 22:38:30 +0100 Subject: [TYPO3-dev] Symmetric bidirectional MM ralations on the same table References: <mailman.1.1248700188.11126.typo3-dev@lists.netfielders.de> <mailman.1.1248722157.7907.typo3-dev@lists.netfielders.de> <mailman.1.1298572426.7659.typo3-dev@lists.typo3.org> <mailman.1.1298577643.16039.typo3-dev@lists.typo3.org> <mailman.1.1298578611.17226.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298583632.24928.typo3-dev@lists.typo3.org> On Thu, 24 Feb 2011 21:14:48 +0100, Steffen Kamper <info at sk-typo3.de> wrote: > Hi, > > Am 24.02.2011 20:58, schrieb Helmut Hummel: >> Hi, >> >> On 24.02.11 19:31, Stefano Cecere wrote: >>> any news on self symmetrical MM relations? >>> >>> now we have 4.5 .. and i was hoping they had come! >>> >>> maybe we could add a new special tca variable (like "self" enabled).. >>> so >>> that the relation can be searched in both ways? >>> >>> any idea? >> >> I would use a tcemain hook that adds the opposite relation to the mm >> table. >> > > ... as proof of concept. At the end i would wish to have correct fixes > in core, i kmow there are some issues where mm tables are not updated > proper, or records not deleted if parent records are deleted. i'll do asap an experiment with the hook. i didn't think anyway about deleting the mm_relations whenever a parent gets deleted.. arg.. anybody knows how it is solved with FLOW3/Doctrine2 ? -- ____ ___ __ _ ______________________ Stefano Cecere krur.com multimedia From dmitry.dulepov at gmail.com Fri Feb 25 09:15:48 2011 From: dmitry.dulepov at gmail.com (Dmitry Dulepov) Date: Fri, 25 Feb 2011 10:15:48 +0200 Subject: [TYPO3-dev] Symmetric bidirectional MM ralations on the same table In-Reply-To: <mailman.1.1298583632.24928.typo3-dev@lists.typo3.org> References: <mailman.1.1248700188.11126.typo3-dev@lists.netfielders.de> <mailman.1.1248722157.7907.typo3-dev@lists.netfielders.de> <mailman.1.1298572426.7659.typo3-dev@lists.typo3.org> <mailman.1.1298577643.16039.typo3-dev@lists.typo3.org> <mailman.1.1298578611.17226.typo3-dev@lists.typo3.org> <mailman.1.1298583632.24928.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298621872.28565.typo3-dev@lists.typo3.org> Hi! Stefano Cecere wrote: > anybody knows how it is solved with FLOW3/Doctrine2 ? The problem with bidirectional relations is inside t3lib_loaddbgroup and only there. The proposed solution of using a hook to add another record to MM table is incorrect (and it does not work well, I tried ? it causes various side effects and data corruption for MM relations). Normally you have uid_local and uid_foreign. Assuming you have [3,5] there, adding [5,3] is not a good idea because it doubles the size of the table and slows down the whole thing. MM relations are slow because they use joins and doubling the size of the table makes it even slower. Instead t3lib_loaddbgroup should check if the relation is to the same table and use a special condition to fetch the data. Something like: (uid_local=3 and uid_foreign=5) or (uid_foreign=3 and uid_local=5) It sounds easy to implement but in fact it is not because of the way t3lib_loaddbgroup is coded. It needs a serious rewrite to support bidirectional MM relations on the same table. -- Dmitry Dulepov TYPO3 core&security team member E-mail: dmitry.dulepov at typo3.org Web: http://dmitry-dulepov.com/ From helmut.hummel at typo3.org Fri Feb 25 09:44:16 2011 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Fri, 25 Feb 2011 09:44:16 +0100 Subject: [TYPO3-dev] Symmetric bidirectional MM ralations on the same table In-Reply-To: <mailman.1.1298621872.28565.typo3-dev@lists.typo3.org> References: <mailman.1.1248700188.11126.typo3-dev@lists.netfielders.de> <mailman.1.1248722157.7907.typo3-dev@lists.netfielders.de> <mailman.1.1298572426.7659.typo3-dev@lists.typo3.org> <mailman.1.1298577643.16039.typo3-dev@lists.typo3.org> <mailman.1.1298578611.17226.typo3-dev@lists.typo3.org> <mailman.1.1298583632.24928.typo3-dev@lists.typo3.org> <mailman.1.1298621872.28565.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298623579.31148.typo3-dev@lists.typo3.org> Hi, On 25.02.11 09:15, Dmitry Dulepov wrote: > Stefano Cecere wrote: > The proposed solution of using a hook to add another record to MM table is > incorrect (and it does not work well, I tried ? it causes various side > effects and data corruption for MM relations). My proposal was not meant as a final solution, but as a workaround until TYPO3 can handle such relations correctly. Not as a solution for TYPO3 in general but for your current project, if you need it (I never did). Can you tell us what exactly will be corrupted when doing which actions? I can imagine that it would be neccessary to update the reference index in the hook, anything else? > Normally you have uid_local and uid_foreign. Assuming you have [3,5] there, > adding [5,3] is not a good idea because it doubles the size of the table > and slows down the whole thing. MM relations are slow because they use > joins and doubling the size of the table makes it even slower. Will there be a performance impact or data corruption? The first would be bearable in most situations, the latter not. > Instead > t3lib_loaddbgroup should check if the relation is to the same table and use > a special condition to fetch the data. Something like: > > (uid_local=3 and uid_foreign=5) or (uid_foreign=3 and uid_local=5) Yes of course. > It sounds easy to implement but in fact it is not because of the way > t3lib_loaddbgroup is coded. It needs a serious rewrite to support > bidirectional MM relations on the same table. That's the problem. "Not easy" == "no one does it" == "customer not happy" ;) Kind regards, Helmut -- Helmut Hummel TYPO3 Security Team Leader TYPO3 .... inspiring people to share! Get involved: typo3.org From scecere at krur.com Fri Feb 25 10:03:07 2011 From: scecere at krur.com (Stefano Cecere) Date: Fri, 25 Feb 2011 10:03:07 +0100 Subject: [TYPO3-dev] Symmetric bidirectional MM ralations on the same table References: <mailman.1.1248700188.11126.typo3-dev@lists.netfielders.de> <mailman.1.1248722157.7907.typo3-dev@lists.netfielders.de> <mailman.1.1298572426.7659.typo3-dev@lists.typo3.org> <mailman.1.1298577643.16039.typo3-dev@lists.typo3.org> <mailman.1.1298578611.17226.typo3-dev@lists.typo3.org> <mailman.1.1298583632.24928.typo3-dev@lists.typo3.org> <mailman.1.1298621872.28565.typo3-dev@lists.typo3.org> <mailman.1.1298623579.31148.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298624710.685.typo3-dev@lists.typo3.org> On Fri, 25 Feb 2011 09:44:16 +0100, Helmut Hummel <helmut.hummel at typo3.org> wrote: > That's the problem. > "Not easy" == "no one does it" == "customer not happy" ;) while i can easily solve this with the hook, i checked t3lib_loaddbgroup code.. too complex for me we are facing the same problem with the up to come "news2" extension (which has, as all news extesnions, relations self 2 self) i also checked tt_news and it suffers the same problem! (how can big news website live with this problem??) i'll ask anyway my current client if they're willing to sponsor in someway this refactoring ciao & thanks -- ____ ___ __ _ ______________________ Stefano Cecere krur.com multimedia From j.rieger at connecta.ag Fri Feb 25 13:56:53 2011 From: j.rieger at connecta.ag (Jochen Rieger) Date: Fri, 25 Feb 2011 13:56:53 +0100 Subject: [TYPO3-dev] Symmetric bidirectional MM ralations on the same table In-Reply-To: <mailman.1.1298624710.685.typo3-dev@lists.typo3.org> References: <mailman.1.1248700188.11126.typo3-dev@lists.netfielders.de> <mailman.1.1248722157.7907.typo3-dev@lists.netfielders.de> <mailman.1.1298572426.7659.typo3-dev@lists.typo3.org> <mailman.1.1298577643.16039.typo3-dev@lists.typo3.org> <mailman.1.1298578611.17226.typo3-dev@lists.typo3.org> <mailman.1.1298583632.24928.typo3-dev@lists.typo3.org> <mailman.1.1298621872.28565.typo3-dev@lists.typo3.org> <mailman.1.1298623579.31148.typo3-dev@lists.typo3.org> <mailman.1.1298624710.685.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298638736.25516.typo3-dev@lists.typo3.org> Hi all, > we are facing the same problem with the up to come "news2" extension > (which has, as all news extesnions, relations self 2 self) hmmm ... if I understood everything correctly this is a similar case that I worked on a year or two ago. We had to define relations of characters / people that had to be accessible from both sides. So we created one table for the charcter data and an MM-rel table. The important part of the character table's tca is: 'relations' => array ( 'exclude' => 0, 'label' => 'MyLabale', 'config' => array ( 'type' => 'inline', 'foreign_table' => 'tx_myext_characters_rel_mm', 'foreign_field' => 'character1', 'foreign_label' => 'character2', 'foreign_sortby' => 'sorting_char1', 'symmetric_field' => 'character2', 'symmetric_label' => 'character1', 'symmetric_sortby' => 'sorting_char2', 'minitems' => 0, 'maxitems' => 100, 'appearance' => array ( 'collapseAll' => 1, 'expandSingle' => 1, 'newRecordLinkAddTitle' => 1, ), ) ), So ... I just checked the old project and indeed the relations are accessible from both related records. The MM-table mainly consists of the fields configured above (no uid_local or uid_foreign). Isn't that what you were looking for? Regards, Jochen From scecere at krur.com Fri Feb 25 15:41:47 2011 From: scecere at krur.com (Stefano Cecere) Date: Fri, 25 Feb 2011 15:41:47 +0100 Subject: [TYPO3-dev] Symmetric bidirectional MM ralations on the same table References: <mailman.1.1248700188.11126.typo3-dev@lists.netfielders.de> <mailman.1.1248722157.7907.typo3-dev@lists.netfielders.de> <mailman.1.1298572426.7659.typo3-dev@lists.typo3.org> <mailman.1.1298577643.16039.typo3-dev@lists.typo3.org> <mailman.1.1298578611.17226.typo3-dev@lists.typo3.org> <mailman.1.1298583632.24928.typo3-dev@lists.typo3.org> <mailman.1.1298621872.28565.typo3-dev@lists.typo3.org> <mailman.1.1298623579.31148.typo3-dev@lists.typo3.org> <mailman.1.1298624710.685.typo3-dev@lists.typo3.org> <mailman.1.1298638736.25516.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298645030.4858.typo3-dev@lists.typo3.org> Hi Jochen! yes it seems you understood well the problem.. but i could not make your configuration work (i got empty form.. tried several configurations) what's the sql for your table tx_myext_characters_rel_mm ? has it a TCA definition? where do you have those 'character1' and 'character2' fields? thanks s On Fri, 25 Feb 2011 13:56:53 +0100, Jochen Rieger <j.rieger at connecta.ag> wrote: > Hi all, > >> we are facing the same problem with the up to come "news2" extension >> (which has, as all news extesnions, relations self 2 self) > > hmmm ... if I understood everything correctly this is a similar case > that I worked on a year or two ago. We had to define relations of > characters / people that had to be accessible from both sides. > > So we created one table for the charcter data and an MM-rel table. The > important part of the character table's tca is: > > 'relations' => array ( > 'exclude' => 0, > 'label' => 'MyLabale', > 'config' => array ( > 'type' => 'inline', > 'foreign_table' => 'tx_myext_characters_rel_mm', > 'foreign_field' => 'character1', > 'foreign_label' => 'character2', > 'foreign_sortby' => 'sorting_char1', > > 'symmetric_field' => 'character2', > 'symmetric_label' => 'character1', > 'symmetric_sortby' => 'sorting_char2', > > 'minitems' => 0, > 'maxitems' => 100, > 'appearance' => array ( > 'collapseAll' => 1, > 'expandSingle' => 1, > 'newRecordLinkAddTitle' => 1, > ), > ) > ), > > So ... I just checked the old project and indeed the relations are > accessible from both related records. The MM-table mainly consists of > the fields configured above (no uid_local or uid_foreign). > > Isn't that what you were looking for? > > Regards, > Jochen -- ____ ___ __ _ ______________________ Stefano Cecere krur.com multimedia From j.rieger at connecta.ag Fri Feb 25 15:58:28 2011 From: j.rieger at connecta.ag (Jochen Rieger) Date: Fri, 25 Feb 2011 15:58:28 +0100 Subject: [TYPO3-dev] Symmetric bidirectional MM ralations on the same table In-Reply-To: <mailman.1.1298645030.4858.typo3-dev@lists.typo3.org> References: <mailman.1.1248700188.11126.typo3-dev@lists.netfielders.de> <mailman.1.1248722157.7907.typo3-dev@lists.netfielders.de> <mailman.1.1298572426.7659.typo3-dev@lists.typo3.org> <mailman.1.1298577643.16039.typo3-dev@lists.typo3.org> <mailman.1.1298578611.17226.typo3-dev@lists.typo3.org> <mailman.1.1298583632.24928.typo3-dev@lists.typo3.org> <mailman.1.1298621872.28565.typo3-dev@lists.typo3.org> <mailman.1.1298623579.31148.typo3-dev@lists.typo3.org> <mailman.1.1298624710.685.typo3-dev@lists.typo3.org> <mailman.1.1298638736.25516.typo3-dev@lists.typo3.org> <mailman.1.1298645030.4858.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298646031.6516.typo3-dev@lists.typo3.org> Hi Stefano, > what's the sql for your table tx_myext_characters_rel_mm ? has it a TCA > definition? > where do you have those 'character1' and 'character2' fields? yes, the mm table has a TCA definition in this case: -- snip -- $TCA['tx_myext_characters_rel_mm'] = array ( 'ctrl' => $TCA['tx_myext_characters_rel_mm']['ctrl'], 'interface' => array ( 'showRecordFieldList' => 'hidden' ), 'feInterface' => $TCA['tx_myext_characters_rel_mm']['feInterface'], 'columns' => array ( 't3ver_label' => array ( 'label' => 'LLL:EXT:lang/locallang_general.xml:LGL.versionLabel', 'config' => array ( 'type' => 'input', 'size' => '30', 'max' => '30', ) ), 'hidden' => array ( 'exclude' => 0, 'label' => 'LLL:EXT:lang/locallang_general.xml:LGL.hidden', 'config' => array ( 'type' => 'check', 'default' => '0' ) ), 'character1' => array ( 'exclude' => 0, 'label' => 'LLL:EXT:myext/locallang_db.xml:tx_myext_characters_rel_mm.character1', 'config' => array ( 'type' => 'group', 'internal_type' => 'db', 'allowed' => 'tx_myext_characters', 'size' => 1, 'minitems' => 0, 'maxitems' => 1, ) ), 'character2' => array ( 'exclude' => 0, 'label' => 'LLL:EXT:myext/locallang_db.xml:tx_myext_characters_rel_mm.character2', 'config' => array ( 'type' => 'group', 'internal_type' => 'db', 'allowed' => 'tx_myext_characters', 'size' => 1, 'minitems' => 0, 'maxitems' => 1, ) ), 'sorting_char1' => Array ( 'config' => Array ( 'type' => 'passthrough', ) ), 'sorting_char2' => Array ( 'config' => Array ( 'type' => 'passthrough', ) ), ), 'types' => array ( '0' => array('showitem' => 'hidden;;1;;1-1-1, character1, character2) ), ); -- snap -- But of cause it's not edited as an own record. Just by editing the character records to be found in tx_myext_characters. Also, of cause you need the part to be found in ext_tables.php. But this one contains nothing special... just the standards. Maybe now you'll get it to work? :) Cheers, Jochen From scecere at krur.com Fri Feb 25 16:42:39 2011 From: scecere at krur.com (Stefano Cecere) Date: Fri, 25 Feb 2011 16:42:39 +0100 Subject: [TYPO3-dev] Symmetric bidirectional MM ralations on the same table References: <mailman.1.1248700188.11126.typo3-dev@lists.netfielders.de> <mailman.1.1248722157.7907.typo3-dev@lists.netfielders.de> <mailman.1.1298572426.7659.typo3-dev@lists.typo3.org> <mailman.1.1298577643.16039.typo3-dev@lists.typo3.org> <mailman.1.1298578611.17226.typo3-dev@lists.typo3.org> <mailman.1.1298583632.24928.typo3-dev@lists.typo3.org> <mailman.1.1298621872.28565.typo3-dev@lists.typo3.org> <mailman.1.1298623579.31148.typo3-dev@lists.typo3.org> <mailman.1.1298624710.685.typo3-dev@lists.typo3.org> <mailman.1.1298638736.25516.typo3-dev@lists.typo3.org> <mailman.1.1298645030.4858.typo3-dev@lists.typo3.org> <mailman.1.1298646031.6516.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298648682.11239.typo3-dev@lists.typo3.org> On Fri, 25 Feb 2011 15:58:28 +0100, Jochen Rieger <j.rieger at connecta.ag> wrote: >> Maybe now you'll get it to work? :) hi Jochen it's tarting to work.. and i agree i could be a nice solution for self2self relationship only oddity is that i see "Character2" (in the IRRE inline mm records) in both the character records (i linked uid 1 to uid 2.. and in both records the relation shows "2") uhm... am i missing some other config? s -- ____ ___ __ _ ______________________ Stefano Cecere krur.com multimedia From j.rieger at connecta.ag Fri Feb 25 17:47:40 2011 From: j.rieger at connecta.ag (Jochen Rieger) Date: Fri, 25 Feb 2011 17:47:40 +0100 Subject: [TYPO3-dev] Symmetric bidirectional MM ralations on the same table In-Reply-To: <mailman.1.1298648682.11239.typo3-dev@lists.typo3.org> References: <mailman.1.1248700188.11126.typo3-dev@lists.netfielders.de> <mailman.1.1248722157.7907.typo3-dev@lists.netfielders.de> <mailman.1.1298572426.7659.typo3-dev@lists.typo3.org> <mailman.1.1298577643.16039.typo3-dev@lists.typo3.org> <mailman.1.1298578611.17226.typo3-dev@lists.typo3.org> <mailman.1.1298583632.24928.typo3-dev@lists.typo3.org> <mailman.1.1298621872.28565.typo3-dev@lists.typo3.org> <mailman.1.1298623579.31148.typo3-dev@lists.typo3.org> <mailman.1.1298624710.685.typo3-dev@lists.typo3.org> <mailman.1.1298638736.25516.typo3-dev@lists.typo3.org> <mailman.1.1298645030.4858.typo3-dev@lists.typo3.org> <mailman.1.1298646031.6516.typo3-dev@lists.typo3.org> <mailman.1.1298648682.11239.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298652583.19216.typo3-dev@lists.typo3.org> Hi Stefano, > uhm... > am i missing some other config? I just tested it. And it works smoothly. I created two new characters (uid 223 and 224). Then I added the Relation via IRRE. And the mm table was filled with 223 in field "character1" and 224 in field "character2". Be sure to have this strange IRRE setup with foreign_label, symmetric_field, etc. vice versa (see previous post with the inline field config). If you won't get a long send me a PM. Then I can send you the full extension. So you can compare 1:1. Oops ... sorry. I think you are right. When I am editing the second record I created I get a reference to itself in the TCE form. But the database still entry looks fine (as described above). Seemingly just the tcemain gets a hickup caused by this config when rendering the form element. Regards, Jochen From scecere at krur.com Fri Feb 25 17:58:07 2011 From: scecere at krur.com (Stefano Cecere) Date: Fri, 25 Feb 2011 17:58:07 +0100 Subject: [TYPO3-dev] Symmetric bidirectional MM ralations on the same table References: <mailman.1.1248700188.11126.typo3-dev@lists.netfielders.de> <mailman.1.1248722157.7907.typo3-dev@lists.netfielders.de> <mailman.1.1298572426.7659.typo3-dev@lists.typo3.org> <mailman.1.1298577643.16039.typo3-dev@lists.typo3.org> <mailman.1.1298578611.17226.typo3-dev@lists.typo3.org> <mailman.1.1298583632.24928.typo3-dev@lists.typo3.org> <mailman.1.1298621872.28565.typo3-dev@lists.typo3.org> <mailman.1.1298623579.31148.typo3-dev@lists.typo3.org> <mailman.1.1298624710.685.typo3-dev@lists.typo3.org> <mailman.1.1298638736.25516.typo3-dev@lists.typo3.org> <mailman.1.1298645030.4858.typo3-dev@lists.typo3.org> <mailman.1.1298646031.6516.typo3-dev@lists.typo3.org> <mailman.1.1298648682.11239.typo3-dev@lists.typo3.org> <mailman.1.1298652583.19216.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298653210.20940.typo3-dev@lists.typo3.org> On Fri, 25 Feb 2011 17:47:40 +0100, Jochen Rieger <j.rieger at connecta.ag> wrote: > Oops ... sorry. I think you are right. When I am editing the second > record I created I get a reference to itself in the TCE form. But the > database still entry looks fine (as described above). Seemingly just the > tcemain gets a hickup caused by this config when rendering the form > element. yes, the db is ok. it's a TCE/IRRE form problem :( now i temporary solved the topic creating a "reversed" mm relation, with a new field to be shown belove the stadard relation selector so the editor can see if any other records already point to the current one. obvioulsy a better solution (and core integrated) would be better :) let me know if you are gonna study more the IRRE solution!! ciaooo -- ____ ___ __ _ ______________________ Stefano Cecere krur.com multimedia From ernesto.baschny at typo3.org Sat Feb 26 01:12:51 2011 From: ernesto.baschny at typo3.org (Ernesto Baschny) Date: Sat, 26 Feb 2011 01:12:51 +0100 Subject: [TYPO3-dev] [TYPO3-v4] Announcing TYPO3 4.5.2 Message-ID: <mailman.12167.1298679302.648.typo3-dev@lists.typo3.org> Dear TYPO3 community, The TYPO3 core team has just released TYPO3 versions 4.5.2, which is ready for you to download. This is a maintenance release and contain only bugfixes. It fixes important regressions which were introduced in 4.5.1. Users of 4.5.0 and 4.5.1 are strongly advised to upgrade. The packages can be downloaded here: http://typo3.org/download/packages/ For details about the release, please see: http://news.typo3.org/news/article/typo3-452-released/ http://wiki.typo3.org/TYPO3_4.5.2 - Release Notes MD5 checksums: cad7fa2b4a4169e25318ae7f9f1a3e31 dummy-4.5.2.tar.gz 88d81c968fd22020cc808c7283286b8e dummy-4.5.2.zip d9c8f325c9ad63437215792c17ac1676 typo3_src-4.5.2.tar.gz 8b4ebd7129ea35b7b9d68f5d57e5cad6 typo3_src-4.5.2.zip d348caf3cc1e2b08ba71779a438a1873 typo3_src+dummy-4.5.2.zip bfa5024524a28fd5570f5b13b12045f9 introductionpackage-4.5.2.tar.gz adcd504551721d1189f771c00bc4d378 introductionpackage-4.5.2.zip Cheers, Steffen Kamper (Technical Leader) and Ernesto Baschny (Release Manager) -- Ernesto Baschny Core Developer V4 Team Release Manager TYPO3 4.5 TYPO3 .... inspiring people to share! Get involved: typo3.org From typo3 at kay-strobach.de Sat Feb 26 11:16:14 2011 From: typo3 at kay-strobach.de (Kay Strobach) Date: Sat, 26 Feb 2011 11:16:14 +0100 Subject: [TYPO3-dev] [TYPO3-english] Idea to speed up Backend Message-ID: <mailman.12200.1298715604.648.typo3-dev@lists.typo3.org> (Hope it's ok to post my idea here, posted in the core list first - sry) Hello Core Devs, due i'm developing more and more ExtJS based Modules i have an idea how to speed up modules if correctly prepared. Currently there is a viewport which is like this one: +-----+-----+----------------+ | | +-----+-----+----------------+ | | | | | 1 | 2 | 3 | | | | | +-----+-----+----------------+ The area 2 (pagetree) is hidden if the module doesn't need it - good. But any module in 3 is loaded as normal html page. If we would implement 3 as an extjs cardlayout [1] the following could be possible: 1. classic modules load in card 0 as before (backwards compatibility) 2. every new JS module load in extra card (there must be an array to save the relation between module and cardnumber) A cardlayout is similar to tabs, but without a userinterface. Additionally type 2 modules (area 3) may listen to the following events to update their content: 1. page selected in area 2 2. page action applied (suply action name) 3. module visible 4. module hidden Using this method modules like the extMgm are accessable very fast and load only once. A new listmodule can be build using ajax with the effort of a very fast load. Some users in the german list a complaining about loading times :( Thanks a lot for all your great work. Regards Kay [1] http://dev.sencha.com/deploy/dev/docs/?class=Ext.layout.CardLayout -- http://www.kay-strobach.de - Open Source Rocks From robertwildling at gmail.com Sun Feb 27 10:14:54 2011 From: robertwildling at gmail.com (Robert Wildling) Date: Sun, 27 Feb 2011 10:14:54 +0100 Subject: [TYPO3-dev] ext manager Message-ID: <mailman.1.1298798218.32571.typo3-dev@lists.typo3.org> Just having begun to test TYPO? v4.5, I love the ext manager! But I realize that the "last update" date is only shown, when clicking on the the ext name and the "more info" box pops up. Would there be any chance to integrate this element in the list view, since it is a very important info? Furthermore, when I order the list view by author and activate a filter (like "Furrer"), the filter has no effect on the list whatsoever. I would expect that only ext by "Furrer" are shown, but maybe I am wrong and do not correctely grasp the idea of this feature...? Thank you! Robert From info at sk-typo3.de Sun Feb 27 12:57:42 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Sun, 27 Feb 2011 12:57:42 +0100 Subject: [TYPO3-dev] ext manager In-Reply-To: <mailman.1.1298798218.32571.typo3-dev@lists.typo3.org> References: <mailman.1.1298798218.32571.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298807990.13908.typo3-dev@lists.typo3.org> Hi, Am 27.02.2011 10:14, schrieb Robert Wildling: > Just having begun to test TYPO? v4.5, I love the ext manager! great :) > But I > realize that the "last update" date is only shown, when clicking on the > the ext name and the "more info" box pops up. Would there be any chance > to integrate this element in the list view, since it is a very important > info? > this could be done, just open a BT entry for this. > Furthermore, when I order the list view by author and activate a filter > (like "Furrer"), the filter has no effect on the list whatsoever. I > would expect that only ext by "Furrer" are shown, but maybe I am wrong > and do not correctely grasp the idea of this feature...? > i tested and there is a bug with filter with author, please open a seperate BT entry, i'll take care. Further it's important to mention which list you speak from, in your case the repository list (local list has also the filtering) vg Steffen From dmitry.dulepov at gmail.com Sun Feb 27 13:38:34 2011 From: dmitry.dulepov at gmail.com (Dmitry Dulepov) Date: Sun, 27 Feb 2011 14:38:34 +0200 Subject: [TYPO3-dev] Symmetric bidirectional MM ralations on the same table In-Reply-To: <mailman.1.1298623579.31148.typo3-dev@lists.typo3.org> References: <mailman.1.1248700188.11126.typo3-dev@lists.netfielders.de> <mailman.1.1248722157.7907.typo3-dev@lists.netfielders.de> <mailman.1.1298572426.7659.typo3-dev@lists.typo3.org> <mailman.1.1298577643.16039.typo3-dev@lists.typo3.org> <mailman.1.1298578611.17226.typo3-dev@lists.typo3.org> <mailman.1.1298583632.24928.typo3-dev@lists.typo3.org> <mailman.1.1298621872.28565.typo3-dev@lists.typo3.org> <mailman.1.1298623579.31148.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298810439.17580.typo3-dev@lists.typo3.org> Hi! Helmut Hummel wrote: > My proposal was not meant as a final solution, but as a workaround until > TYPO3 can handle such relations correctly. Not as a solution for TYPO3 > in general but for your current project, if you need it (I never did). If I remember correctly, MM relations handled by loaddbgroup, not by tcemain. So you cannot use a hook (nothing to hook to). I can be wrong because I investigated that long time ago. > Can you tell us what exactly will be corrupted when doing which actions? > I can imagine that it would be neccessary to update the reference index > in the hook, anything else? t3lib_loaddbgroup does not expect such relations. Therefore it does not handle them correctly. I do not remember exact details but I think only some of these relations were deleted and false once were displayed when I tried it. I ended up on handling that manually using my own field types. -- Dmitry Dulepov TYPO3 core&security team member E-mail: dmitry.dulepov at typo3.org Web: http://dmitry-dulepov.com/ From info at sk-typo3.de Sun Feb 27 13:51:05 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Sun, 27 Feb 2011 13:51:05 +0100 Subject: [TYPO3-dev] ext manager In-Reply-To: <mailman.1.1298807990.13908.typo3-dev@lists.typo3.org> References: <mailman.1.1298798218.32571.typo3-dev@lists.typo3.org> <mailman.1.1298807990.13908.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298811193.19173.typo3-dev@lists.typo3.org> Am 27.02.2011 12:57, schrieb Steffen Kamper: > > i tested and there is a bug with filter with author, please open a > seperate BT entry, i'll take care. > already done with fix attached in http://bugs.typo3.org/view.php?id=17786 vg Steffen From info at sk-typo3.de Sun Feb 27 14:42:39 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Sun, 27 Feb 2011 14:42:39 +0100 Subject: [TYPO3-dev] ext manager In-Reply-To: <mailman.1.1298811193.19173.typo3-dev@lists.typo3.org> References: <mailman.1.1298798218.32571.typo3-dev@lists.typo3.org> <mailman.1.1298807990.13908.typo3-dev@lists.typo3.org> <mailman.1.1298811193.19173.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298814288.23636.typo3-dev@lists.typo3.org> Am 27.02.2011 13:51, schrieb Steffen Kamper: > Am 27.02.2011 12:57, schrieb Steffen Kamper: >> >> i tested and there is a bug with filter with author, please open a >> seperate BT entry, i'll take care. >> > > already done with fix attached in > http://bugs.typo3.org/view.php?id=17786 > and fixed in 4_5 branch and trunk vg Steffen From robertwildling at gmail.com Sun Feb 27 15:36:45 2011 From: robertwildling at gmail.com (Robert Wildling) Date: Sun, 27 Feb 2011 15:36:45 +0100 Subject: [TYPO3-dev] ext manager In-Reply-To: <mailman.1.1298814288.23636.typo3-dev@lists.typo3.org> References: <mailman.1.1298798218.32571.typo3-dev@lists.typo3.org> <mailman.1.1298807990.13908.typo3-dev@lists.typo3.org> <mailman.1.1298811193.19173.typo3-dev@lists.typo3.org> <mailman.1.1298814288.23636.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298817529.28169.typo3-dev@lists.typo3.org> Hi, Steffen, Sunday is a work day for it seems! Great work! Thanks!!!! Greetings, Robert > Am 27.02.2011 13:51, schrieb Steffen Kamper: >> Am 27.02.2011 12:57, schrieb Steffen Kamper: >>> >>> i tested and there is a bug with filter with author, please open a >>> seperate BT entry, i'll take care. >>> >> >> already done with fix attached in >> http://bugs.typo3.org/view.php?id=17786 >> > > and fixed in 4_5 branch and trunk > > vg Steffen > From lists at mind2machine.com Mon Feb 28 10:44:25 2011 From: lists at mind2machine.com (=?iso-8859-1?Q?Alban_Cousini=E9?=) Date: Mon, 28 Feb 2011 10:44:25 +0100 Subject: [TYPO3-dev] Typo3 and persistent connexions Message-ID: <mailman.12316.1298886389.648.typo3-dev@lists.typo3.org> Hello, Do you guys know if Typo3 basically maintains persistent connexions to the database ? Or do permanent connexions occur only if Typo3 is expressively told to do so ? Our server administrator reports he always has 5 open mysql connexions on the Typo3 database right after restarting mysql, (and often 50 open connexions with 2 typo3 websites hosted (one of these making 800 visits per day). It seems ok to me, but the sys administrator beleives it is very abnormal and he is alerting me. What do you guys think of this ? Thanks for your time, Alban Cousini? -- MIND2MACHINE SARL http://www.mind2machine.com From typo3 at t3node.com Mon Feb 28 10:59:31 2011 From: typo3 at t3node.com (=?UTF-8?B?U3RlZmZlbiBNw7xsbGVy?=) Date: Mon, 28 Feb 2011 10:59:31 +0100 Subject: [TYPO3-dev] Typo3 and persistent connexions In-Reply-To: <mailman.12316.1298886389.648.typo3-dev@lists.typo3.org> References: <mailman.12316.1298886389.648.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298887258.7773.typo3-dev@lists.typo3.org> Hi. On 28.02.2011 10:44 Alban Cousini? wrote: > Do you guys know if Typo3 basically maintains persistent connexions to the > database ? > Or do permanent connexions occur only if Typo3 is expressively told to do so > ? Have a look into the install tool and change the following setting: [SYS][no_pconnect] I dunno why this is turned on by default. I always turn it off with MySQL. -- cheers, Steffen TYPO3 Blog: http://www.t3node.com/ Twitter: http://twitter.com/t3node From scecere at krur.com Mon Feb 28 11:32:45 2011 From: scecere at krur.com (Stefano Cecere) Date: Mon, 28 Feb 2011 11:32:45 +0100 Subject: [TYPO3-dev] Typo3 and persistent connexions References: <mailman.12316.1298886389.648.typo3-dev@lists.typo3.org> <mailman.1.1298887258.7773.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298889290.11536.typo3-dev@lists.typo3.org> On Mon, 28 Feb 2011 10:59:31 +0100, Steffen M?ller <typo3 at t3node.com> wrote: > Have a look into the install tool and change the following setting: > [SYS][no_pconnect] > > I dunno why this is turned on by default. I always turn it off with > MySQL. me too! it's in my default localconf -- ____ ___ __ _ ______________________ Stefano Cecere krur.com multimedia From lists at mind2machine.com Mon Feb 28 12:13:43 2011 From: lists at mind2machine.com (=?utf-8?Q?Alban_Cousini=C3=A9?=) Date: Mon, 28 Feb 2011 12:13:43 +0100 Subject: [TYPO3-dev] Typo3 and persistent connexions In-Reply-To: <mailman.1.1298887258.7773.typo3-dev@lists.typo3.org> References: <mailman.12316.1298886389.648.typo3-dev@lists.typo3.org> <mailman.1.1298887258.7773.typo3-dev@lists.typo3.org> Message-ID: <mailman.12336.1298891748.648.typo3-dev@lists.typo3.org> Thanks a lot !!! Alban. > -----Message d'origine----- > De : typo3-dev-bounces at lists.typo3.org [mailto:typo3-dev- > bounces at lists.typo3.org] De la part de Steffen M?ller > Envoy? : lundi 28 f?vrier 2011 11:00 > ? : typo3-dev at lists.typo3.org > Objet : Re: [TYPO3-dev] Typo3 and persistent connexions > > Hi. > > On 28.02.2011 10:44 Alban Cousini? wrote: > > Do you guys know if Typo3 basically maintains persistent connexions to > the > > database ? > > Or do permanent connexions occur only if Typo3 is expressively told to do > so > > ? > > Have a look into the install tool and change the following setting: > [SYS][no_pconnect] > > I dunno why this is turned on by default. I always turn it off with MySQL. > > > -- > cheers, > Steffen > > TYPO3 Blog: http://www.t3node.com/ > Twitter: http://twitter.com/t3node > > _______________________________________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev From info at sk-typo3.de Mon Feb 28 12:34:35 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 28 Feb 2011 12:34:35 +0100 Subject: [TYPO3-dev] Typo3 and persistent connexions In-Reply-To: <mailman.1.1298887258.7773.typo3-dev@lists.typo3.org> References: <mailman.12316.1298886389.648.typo3-dev@lists.typo3.org> <mailman.1.1298887258.7773.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298893001.17921.typo3-dev@lists.typo3.org> Hi, Am 28.02.2011 10:59, schrieb Steffen M?ller: > > Have a look into the install tool and change the following setting: > [SYS][no_pconnect] > > I dunno why this is turned on by default. I always turn it off with MySQL. > > 'no_pconnect' => FALSE is the default vg Steffen From scecere at krur.com Mon Feb 28 12:55:45 2011 From: scecere at krur.com (Stefano Cecere) Date: Mon, 28 Feb 2011 12:55:45 +0100 Subject: [TYPO3-dev] Typo3 and persistent connexions References: <mailman.12316.1298886389.648.typo3-dev@lists.typo3.org> <mailman.1.1298887258.7773.typo3-dev@lists.typo3.org> <mailman.1.1298893001.17921.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298894271.20683.typo3-dev@lists.typo3.org> On Mon, 28 Feb 2011 12:34:35 +0100, Steffen Kamper <info at sk-typo3.de> wrote: > Hi, > > Am 28.02.2011 10:59, schrieb Steffen M?ller: >> >> Have a look into the install tool and change the following setting: >> [SYS][no_pconnect] >> >> I dunno why this is turned on by default. I always turn it off with >> MySQL. >> >> > > 'no_pconnect' => FALSE > > is the default well.. actually to turn off permanent connection you have to put it to TRUE :) -- ____ ___ __ _ ______________________ Stefano Cecere krur.com multimedia From leenstrijk at tomaatnet.nl Mon Feb 28 14:24:15 2011 From: leenstrijk at tomaatnet.nl (Leen Strijk) Date: Mon, 28 Feb 2011 14:24:15 +0100 Subject: [TYPO3-dev] I can't read the values from ext_conf_template.txt Message-ID: <mailman.1.1298899584.29531.typo3-dev@lists.typo3.org> Hello all, I have made my (1st) extension, and all is working fine but I can't seem to te be able to read the values in ext_conf_template.txt The values are showing in the backend in template setup and in the constants part of the object browser and all but I can see them in my script. I have tried with : $this->configuration = unserialize($GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['my_ext']); and with debug I can't even get them to show up with: debug($GLOBALS['TYPO3_CONF_VARS']['EXT']) All the other values from other scripts are there but not my extension. kind regards Leen From info at sk-typo3.de Mon Feb 28 14:25:19 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 28 Feb 2011 14:25:19 +0100 Subject: [TYPO3-dev] Typo3 and persistent connexions In-Reply-To: <mailman.1.1298894271.20683.typo3-dev@lists.typo3.org> References: <mailman.12316.1298886389.648.typo3-dev@lists.typo3.org> <mailman.1.1298887258.7773.typo3-dev@lists.typo3.org> <mailman.1.1298893001.17921.typo3-dev@lists.typo3.org> <mailman.1.1298894271.20683.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298899645.29480.typo3-dev@lists.typo3.org> Hi, Am 28.02.2011 12:55, schrieb Stefano Cecere: >>> >>> >> >> 'no_pconnect' => FALSE >> >> is the default > > well.. actually to turn off permanent connection you have to put it to > TRUE :) > > :) i don't know if it's good to turn it off, i guess it's a performance lose with single connections. vg Steffen From info at sk-typo3.de Mon Feb 28 14:27:29 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 28 Feb 2011 14:27:29 +0100 Subject: [TYPO3-dev] I can't read the values from ext_conf_template.txt In-Reply-To: <mailman.1.1298899584.29531.typo3-dev@lists.typo3.org> References: <mailman.1.1298899584.29531.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298899775.29480.typo3-dev@lists.typo3.org> Hi, a) Does the value exist in localconf.php? b) Where do you read the var, in your class or in ext_tables/ext_localconf? If the latter this can fail because it's not known at this point. vg Steffen From typo3 at kay-strobach.de Mon Feb 28 14:39:34 2011 From: typo3 at kay-strobach.de (Kay Strobach) Date: Mon, 28 Feb 2011 14:39:34 +0100 Subject: [TYPO3-dev] Typo3 and persistent connexions In-Reply-To: <mailman.1.1298899645.29480.typo3-dev@lists.typo3.org> References: <mailman.12316.1298886389.648.typo3-dev@lists.typo3.org> <mailman.1.1298887258.7773.typo3-dev@lists.typo3.org> <mailman.1.1298893001.17921.typo3-dev@lists.typo3.org> <mailman.1.1298894271.20683.typo3-dev@lists.typo3.org> <mailman.1.1298899645.29480.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298900501.31117.typo3-dev@lists.typo3.org> Hello Steffen, my measurements show, that the performance is better with non persistent connections. There many discussions about that in the internet. Regards Kay Am 28.02.2011 14:25, schrieb Steffen Kamper: > Hi, > > Am 28.02.2011 12:55, schrieb Stefano Cecere: >>>> >>>> >>> >>> 'no_pconnect' => FALSE >>> >>> is the default >> >> well.. actually to turn off permanent connection you have to put it to >> TRUE :) >> >> > :) > > i don't know if it's good to turn it off, i guess it's a performance > lose with single connections. > > vg Steffen > > -- http://www.kay-strobach.de - Open Source Rocks From dmitry.dulepov at gmail.com Mon Feb 28 14:58:08 2011 From: dmitry.dulepov at gmail.com (Dmitry Dulepov) Date: Mon, 28 Feb 2011 14:58:08 +0100 Subject: [TYPO3-dev] Typo3 and persistent connexions In-Reply-To: <mailman.1.1298899645.29480.typo3-dev@lists.typo3.org> References: <mailman.12316.1298886389.648.typo3-dev@lists.typo3.org> <mailman.1.1298887258.7773.typo3-dev@lists.typo3.org> <mailman.1.1298893001.17921.typo3-dev@lists.typo3.org> <mailman.1.1298894271.20683.typo3-dev@lists.typo3.org> <mailman.1.1298899645.29480.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298901614.597.typo3-dev@lists.typo3.org> Hi! Steffen Kamper wrote: > i don't know if it's good to turn it off, i guess it's a performance > lose with single connections. Persistent connections are not good for TYPO3. TYPO3 does not always free resources. In case of persistent connections those resources continue to live after the current script is ended (I got that conclusion by looking at PHP "C" source code). So the more PHP scripts are processed, the more memory is leaked. The more memory is leaked, the slower the system becomes. So it is best not to use persistent connections, especially with such a database hungry script as TYPO3. If turning persistent connection is not possible (can't imagine why thought), one solution is to set a limit on a number of request that Apache process handles. But that is not good for high load web sites because spawning a new process is an expensive operation. -- Dmitry Dulepov TYPO3 core&security team member E-mail: dmitry.dulepov at typo3.org Web: http://dmitry-dulepov.com/ From dmitry.dulepov at gmail.com Mon Feb 28 15:00:18 2011 From: dmitry.dulepov at gmail.com (Dmitry Dulepov) Date: Mon, 28 Feb 2011 15:00:18 +0100 Subject: [TYPO3-dev] I can't read the values from ext_conf_template.txt In-Reply-To: <mailman.1.1298899584.29531.typo3-dev@lists.typo3.org> References: <mailman.1.1298899584.29531.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298901745.597.typo3-dev@lists.typo3.org> Hi! Leen Strijk wrote: > The values are showing in the backend in template setup and in the > constants part of the object browser and all but I can see them in my > script. ext_conf_template.txt is not what you can see in the TS object browser. Are you sure you are not confusing different things? ext_conf_template.txt is for the Extension Manager and is showing when extension is installed/confiured in EM. -- Dmitry Dulepov TYPO3 core&security team member E-mail: dmitry.dulepov at typo3.org Web: http://dmitry-dulepov.com/ From info at sk-typo3.de Mon Feb 28 15:11:53 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 28 Feb 2011 15:11:53 +0100 Subject: [TYPO3-dev] Typo3 and persistent connexions In-Reply-To: <mailman.1.1298901614.597.typo3-dev@lists.typo3.org> References: <mailman.12316.1298886389.648.typo3-dev@lists.typo3.org> <mailman.1.1298887258.7773.typo3-dev@lists.typo3.org> <mailman.1.1298893001.17921.typo3-dev@lists.typo3.org> <mailman.1.1298894271.20683.typo3-dev@lists.typo3.org> <mailman.1.1298899645.29480.typo3-dev@lists.typo3.org> <mailman.1.1298901614.597.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298902439.1662.typo3-dev@lists.typo3.org> Hi, Am 28.02.2011 14:58, schrieb Dmitry Dulepov: > Hi! > > Steffen Kamper wrote: >> i don't know if it's good to turn it off, i guess it's a performance >> lose with single connections. > > Persistent connections are not good for TYPO3. TYPO3 does not always > free resources. In case of persistent connections those resources > continue to live after the current script is ended (I got that > conclusion by looking at PHP "C" source code). So the more PHP scripts > are processed, the more memory is leaked. The more memory is leaked, the > slower the system becomes. So it is best not to use persistent > connections, especially with such a database hungry script as TYPO3. > > If turning persistent connection is not possible (can't imagine why > thought), one solution is to set a limit on a number of request that > Apache process handles. But that is not good for high load web sites > because spawning a new process is an expensive operation. > thanks for the info. It's maybe worth to think about changing the default, maybe you could talk about in Berlin? vg Steffen From robertwildling at gmail.com Mon Feb 28 16:15:07 2011 From: robertwildling at gmail.com (Robert Wildling) Date: Mon, 28 Feb 2011 16:15:07 +0100 Subject: [TYPO3-dev] ext manager In-Reply-To: <mailman.1.1298814288.23636.typo3-dev@lists.typo3.org> References: <mailman.1.1298798218.32571.typo3-dev@lists.typo3.org> <mailman.1.1298807990.13908.typo3-dev@lists.typo3.org> <mailman.1.1298811193.19173.typo3-dev@lists.typo3.org> <mailman.1.1298814288.23636.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298906236.8279.typo3-dev@lists.typo3.org> I am confused and have to ask for help to clarify how to understand the new ext manager: When the T3 installation is clean, the ext manager shows many possibilites, among them the 3 old menu entries "installed ext", "install ext" and "import ext". When using the new ext manager, after a while, the menu entries from the drop down lost for the old ext manager disappear. - Is this behaviour intended? - If so, is there any way to change back to the old ext manager entries later on? I also realize that when I copy&paste ext from another local T3 installation, the ext managers (old and new) just won't recognize them. The rights and chmods are set correctly though. (I am on a Mac 10.6.6, MAMP Pro 1.9.4, Firefox 3.6.13 (but similiar in latest Chrome and Opera), Typo3 4.5.2) Steffen - last time you said you made the changes, but you meant the filter features for TER ext, didn't you? The field to show the date of the latest update is not yet integrated, or am I missing sth? How about the bug report? The one you entered, http://bugs.typo3.org/view.php?id=17788, addresses another topic, not mine. I mean that there are columns for "Erweiterung", "Schl?ssel", "Kategorie" etc - and that there should be a column that shows the "last update" of the respective ext. It was requested quite often! And it really is such a valueable info that it shouldn't be hidden in the description. (It is quite a waste of time to click through all the ext and check their date) Furthermore: when updateing an ext, that won't work. The procedure is initialising the prozess and downloading the updated ext, but when going back to the list view, nothing changed. Another thing: I updated the list of ext with the button (that is shown in the above mentioned bug report). Since it every once in a while gets stuck, I have to remove the ext XML from the temp folder and repeat the procedure. T3 4.5 doesrepeat the procedure, it will also show how many ext there are in the TER, but when I then search for eg powermail, nothing is found! I am pretty desperate about this whole new AJAX stuff in T3. Instead of making the CMS faster, everything just gets slower and slower and more and more unstable. The search for errors gets even more difficult... I dont know if T3 is really going into the right direction... (It also should always grow that musch in file size... should ExtJS and the new sprite feature make everything smaller and faster? Why is it not happening???) I really respect your work, guys, but please don't forget usability! Best regards, Robert > Am 27.02.2011 13:51, schrieb Steffen Kamper: >> Am 27.02.2011 12:57, schrieb Steffen Kamper: >>> >>> i tested and there is a bug with filter with author, please open a >>> seperate BT entry, i'll take care. >>> >> >> already done with fix attached in >> http://bugs.typo3.org/view.php?id=17786 >> > > and fixed in 4_5 branch and trunk > > vg Steffen > From info at sk-typo3.de Mon Feb 28 16:31:35 2011 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 28 Feb 2011 16:31:35 +0100 Subject: [TYPO3-dev] ext manager In-Reply-To: <mailman.1.1298906236.8279.typo3-dev@lists.typo3.org> References: <mailman.1.1298798218.32571.typo3-dev@lists.typo3.org> <mailman.1.1298807990.13908.typo3-dev@lists.typo3.org> <mailman.1.1298811193.19173.typo3-dev@lists.typo3.org> <mailman.1.1298814288.23636.typo3-dev@lists.typo3.org> <mailman.1.1298906236.8279.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298907226.10188.typo3-dev@lists.typo3.org> Hi, Am 28.02.2011 16:15, schrieb Robert Wildling: > I am confused and have to ask for help to clarify how to understand the > new ext manager: > > When the T3 installation is clean, the ext manager shows many > possibilites, among them the 3 old menu entries "installed ext", > "install ext" and "import ext". > > When using the new ext manager, after a while, the menu entries from the > drop down lost for the old ext manager disappear. > > - Is this behaviour intended? > - If so, is there any way to change back to the old ext manager entries > later on? > no - it's not losing entries. In ext conf of em you can switch off old modules. > > I also realize that when I copy&paste ext from another local T3 > installation, the ext managers (old and new) just won't recognize them. > The rights and chmods are set correctly though. > > (I am on a Mac 10.6.6, MAMP Pro 1.9.4, Firefox 3.6.13 (but similiar in > latest Chrome and Opera), Typo3 4.5.2) > don't ever expirienced this. > > Steffen - last time you said you made the changes, but you meant the > filter features for TER ext, didn't you? The field to show the date of > the latest update is not yet integrated, or am I missing sth? How about > the bug report? The one you entered, > http://bugs.typo3.org/view.php?id=17788, addresses another topic, not mine. > i fixed the sql error with filtering, not the extra field for the list. I said that this is a different issue, please open a BT entry. > I mean that there are columns for "Erweiterung", "Schl?ssel", > "Kategorie" etc - and that there should be a column that shows the "last > update" of the respective ext. It was requested quite often! And it > really is such a valueable info that it shouldn't be hidden in the > description. (It is quite a waste of time to click through all the ext > and check their date) > see above. > > Furthermore: when updateing an ext, that won't work. The procedure is > initialising the prozess and downloading the updated ext, but when going > back to the list view, nothing changed. > can't confirm this behaviour. The update icon in rep list is hidden after successful update. > Another thing: I updated the list of ext with the button (that is shown > in the above mentioned bug report). Since it every once in a while gets > stuck, I have to remove the ext XML from the temp folder and repeat the > procedure. T3 4.5 doesrepeat the procedure, it will also show how many > ext there are in the TER, but when I then search for eg powermail, > nothing is found! > what? i find each ext i search for, no problems. > > I am pretty desperate about this whole new AJAX stuff in T3. Instead of > making the CMS faster, everything just gets slower and slower and more > and more unstable. The search for errors gets even more difficult... I > dont know if T3 is really going into the right direction... (It also > should always grow that musch in file size... should ExtJS and the new > sprite feature make everything smaller and faster? Why is it not > happening???) > > that's not true. Especially the extmanager is slow, you can compare a complete module load in old module to the new ext manager, it's much much faster! > I really respect your work, guys, but please don't forget usability! > everything is done with cooperation of the HCI team. If you find an issue which is not that usable, please do as usual and file a bug. vg Steffen From jigal at xs4all.nl Mon Feb 28 16:39:54 2011 From: jigal at xs4all.nl (Jigal van Hemert) Date: Mon, 28 Feb 2011 16:39:54 +0100 Subject: [TYPO3-dev] Typo3 and persistent connexions In-Reply-To: <mailman.1.1298901614.597.typo3-dev@lists.typo3.org> References: <mailman.12316.1298886389.648.typo3-dev@lists.typo3.org> <mailman.1.1298887258.7773.typo3-dev@lists.typo3.org> <mailman.1.1298893001.17921.typo3-dev@lists.typo3.org> <mailman.1.1298894271.20683.typo3-dev@lists.typo3.org> <mailman.1.1298899645.29480.typo3-dev@lists.typo3.org> <mailman.1.1298901614.597.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298907722.10906.typo3-dev@lists.typo3.org> Hi, On 28-2-2011 14:58, Dmitry Dulepov wrote: > Persistent connections are not good for TYPO3. TYPO3 does not always > free resources. In case of persistent connections those resources > continue to live after the current script is ended (I got that Persistent connections were nice in the "old days" when making a connection cost a lot of time. It is now only useful for connecting a database over a slow connection. +1 for changing the default. -- Kind regards / met vriendelijke groet, Jigal van Hemert skype:jigal.van.hemert msn: jigal at xs4all.nl http://twitter.com/jigalvh From robertwildling at gmail.com Mon Feb 28 17:55:28 2011 From: robertwildling at gmail.com (Robert Wildling) Date: Mon, 28 Feb 2011 17:55:28 +0100 Subject: [TYPO3-dev] ext manager In-Reply-To: <mailman.1.1298907226.10188.typo3-dev@lists.typo3.org> References: <mailman.1.1298798218.32571.typo3-dev@lists.typo3.org> <mailman.1.1298807990.13908.typo3-dev@lists.typo3.org> <mailman.1.1298811193.19173.typo3-dev@lists.typo3.org> <mailman.1.1298814288.23636.typo3-dev@lists.typo3.org> <mailman.1.1298906236.8279.typo3-dev@lists.typo3.org> <mailman.1.1298907226.10188.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298912254.18822.typo3-dev@lists.typo3.org> Thank you, Steffen, for your quick response! >> - Is this behaviour intended? >> - If so, is there any way to change back to the old ext manager entries >> later on? > no - it's not losing entries. In ext conf of em you can switch off old > modules. Ok, this might be a "read the manual" thing, that I missed. But here is another usability proposal from my side: Since there is so much place for additional flexform tabs, why not introduce another one that has a quick "How to use" or "New Features" or "Read me!" integrated? It would just add to usability. All those many little popups that suddenly come with T3 4.5 don't really grasp the potential of an extension (and seem to be quite useless, in my opinion; they evenutally just get in the way... can they be turned off?) But - to be honest: where is it mentioned that after calling the new EM for the first time the old functions get hidden? I consider this behaviour as so important, that it should be mentioned somewhere in the EM interface! (Like tt_news 3 instructs to hit the update button...) >> I also realize that when I copy&paste ext from another local T3 >> installation, the ext managers (old and new) just won't recognize them. >> The rights and chmods are set correctly though. >> >> (I am on a Mac 10.6.6, MAMP Pro 1.9.4, Firefox 3.6.13 (but similiar in >> latest Chrome and Opera), Typo3 4.5.2) > don't ever expirienced this. After maybe 10 or even more clean installations and experiencing with "use curl" and "don't check referer" and other stuff, it just keeps the way it is: not recognizing any TER ext. (BTW, this is a clean install, not the one with your corrections from last time) This only happens on local T3 installations on MAMP. But T3 4.4.6 is working fine... > i fixed the sql error with filtering, not the extra field for the list. > I said that this is a different issue, please open a BT entry. Done. I hope I did it correctly. >> Furthermore: when updateing an ext, that won't work. The procedure is >> initialising the prozess and downloading the updated ext, but when going >> back to the list view, nothing changed. > can't confirm this behaviour. The update icon in rep list is hidden > after successful update. On my local installations with MAMP this behaviour is endlessly reproducable. The remote installations are working fine, though! >> Another thing: I updated the list of ext with the button (that is shown >> in the above mentioned bug report). Since it every once in a while gets >> stuck, I have to remove the ext XML from the temp folder and repeat the >> procedure. T3 4.5 doesrepeat the procedure, it will also show how many >> ext there are in the TER, but when I then search for eg powermail, >> nothing is found! > what? i find each ext i search for, no problems. Same as above: MAMP -> reproduceable; remote: everything is fine. >> I am pretty desperate about this whole new AJAX stuff in T3. Instead of >> making the CMS faster, everything just gets slower and slower and more >> and more unstable. The search for errors gets even more difficult... I >> dont know if T3 is really going into the right direction... (It also >> should always grow that musch in file size... should ExtJS and the new >> sprite feature make everything smaller and faster? Why is it not >> happening???) > that's not true. Especially the extmanager is slow, you can compare a > complete module load in old module to the new ext manager, it's much > much faster! That might be true - but I never need the complete module load. (Instead, I would need a last-update order functionallity...) But the EM in general does actually feel faster than the old one (just not, when it is not finding anything). But here is another suggestion, and since T3 is so full of adjustments that a user can make, why not add this one, too; In my workflow, I need the EM mostly when I setup a new T3, afterwards I rarley need it. So I go to the EM, search the ext I need and install them. The thing that slows this workflow down, is that every time after an ext is installed, the interface jumps back to the local installation page (where the ext could be installed, so it makes perfectly sense). But I would actually expect to stay in the TER page, because I want to download some more ext and install them later all at once. powermail needs more than one ext, and tt_news, too. Of yourse, other situations and other users will contradict my workflow, and that would be perfectly fine. But the new EM handles everything very elegantly anyway, and I think there would be the place to throw in a new button next to the "close window" that says "back to TER list" (or sth like that) without reloading its actual content (and maybe changing the "close the window" to "install ext"?). That way every user would have a considerable important choice over what to do next with exactly the same amount of clicks - which is and remains 1. But the resulting consequences might save quite some time! *************** Other than that, I keep comparing the speed of T3 on my local enviroment, where the goal would be to get a real look&feel of an installed software. Here T3 v4.2 and v4.3 are faster than 4.4 and 4.5, and 4.4 is still a bit faster than 4.5... If anyone is out there who has a similar will to test, please join this discussion! I don't know if it is ExtJS or the evergrowing complexity of T3 - but to me it makes very strong the impression that everything gets slower and slower, even though you developers are working against it... I winer if there will be feedback... Regards, Robert From leenstrijk at tomaatnet.nl Mon Feb 28 20:03:39 2011 From: leenstrijk at tomaatnet.nl (Leen Strijk) Date: Mon, 28 Feb 2011 20:03:39 +0100 Subject: [TYPO3-dev] I can't read the values from ext_conf_template.txt In-Reply-To: <mailman.1.1298901745.597.typo3-dev@lists.typo3.org> References: <mailman.1.1298899584.29531.typo3-dev@lists.typo3.org> <mailman.1.1298901745.597.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298919949.29435.typo3-dev@lists.typo3.org> Hi, I put the values in ext_conf_template.txt example: plugin.myExtension { # cat=tx_myExtension_pi1/file; type=string; label= Upload Path : The upload path for the templatefiles uploadPath = uploads/tx_jobboard # cat=myExtension/links; type=int+; label= adminPid: Declare the pid for the admin page. adminPid = 88 and so on I tried getting the values from the class.extension.pi1 file with: $this->configuration = unserialize($GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['myExtension']); I tried it also in localconf.php from the ext folder. I can see the values in the constant editor, and in the constants part of the typoscript object browser. I can't see them in the ext manager. Because i lack experience I have been doing alot of trial and error so i tried things with myExtension and pi_myExtension_pi1 So far I have got things working with setup typoscript, and with flexforms. Then I wanted to practice with the constant editor, and they showed up perfectly even seperated with category's and all, but i just can't call them in the extension script. Somhow i feel it needs to be declared somewhere. On 28-2-2011 15:00, Dmitry Dulepov wrote: > Hi! > > Leen Strijk wrote: >> The values are showing in the backend in template setup and in the >> constants part of the object browser and all but I can see them in my >> script. > > ext_conf_template.txt is not what you can see in the TS object browser. > Are you sure you are not confusing different things? > ext_conf_template.txt is for the Extension Manager and is showing when > extension is installed/confiured in EM. > From leenstrijk at tomaatnet.nl Mon Feb 28 20:54:13 2011 From: leenstrijk at tomaatnet.nl (Leen Strijk) Date: Mon, 28 Feb 2011 20:54:13 +0100 Subject: [TYPO3-dev] I can't read the values from ext_conf_template.txt In-Reply-To: <mailman.1.1298899584.29531.typo3-dev@lists.typo3.org> References: <mailman.1.1298899584.29531.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298922984.1366.typo3-dev@lists.typo3.org> Hi again, I'm sorry it was confusing. But i wrote down ext_conf_template.txt but was meaning ext_typoscript_constants.txt So what I did was remove ext_typoscript_constants.txt and the ext_conf_template.txt does show the values in the ext manager. I still can't get the values though. with unserialize($GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['myExtension'] From leenstrijk at tomaatnet.nl Mon Feb 28 21:39:26 2011 From: leenstrijk at tomaatnet.nl (Leen Strijk) Date: Mon, 28 Feb 2011 21:39:26 +0100 Subject: [TYPO3-dev] I can't read the values from ext_conf_template.txt In-Reply-To: <mailman.1.1298899584.29531.typo3-dev@lists.typo3.org> References: <mailman.1.1298899584.29531.typo3-dev@lists.typo3.org> Message-ID: <mailman.1.1298925695.5168.typo3-dev@lists.typo3.org> I can get the values now. My previous post was premature cause i forgot to clear the cache. During my search i see that using ext_typoscript_constants.txt is deprecated Preset TypoScript constants Deprecated (use static template files instead, see extMgm API description) Such a file will be included in the constants section of all TypoScript templates. So i used static/constants.txt. I can see the values in the constant editor but still can't read them On 28-2-2011 14:24, Leen Strijk wrote: > Hello all, > > I have made my (1st) extension, and all is working fine but I can't seem > to te be able to read the values in ext_conf_template.txt > > The values are showing in the backend in template setup and in the > constants part of the object browser and all but I can see them in my > script. > > I have tried with : > $this->configuration = > unserialize($GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['my_ext']); > > and with debug I can't even get them to show up with: > debug($GLOBALS['TYPO3_CONF_VARS']['EXT']) > All the other values from other scripts are there but not my extension. > > kind regards > Leen