From Kohorst at citeq.de Mon Sep 2 09:24:45 2013 From: Kohorst at citeq.de (Britta Kohorst) Date: Mon, 02 Sep 2013 09:24:45 +0200 Subject: [TYPO3-dev] Compat Layer in LTS 6.2 ? Message-ID: Hello, we would like to know if we can rely on the information given in the file typo3/sysext/core/Migrations/Code/LegacyClassesForIde.php inside typo3src 6.0.8.? It says that functions and classes deprecated since 6.0 will be removed in 7.0 - which would mean that those classes and functions will still be available in LTS 6.2! This is of vital importance for us since we have to migrate a lot of extensions - that will be replaced by extbase- and fluid-based versions in the future - but that will have to run with 6.2 to bridge the gap until the new versions are in a stable production state. To put it in a nutshell: will we be able to run pibased extensions without namespaces under LTS 6.2 ? Will the compat layer still be in place? Kind regards, Britta From m.howells-mead at frappant.ch Mon Sep 2 09:24:51 2013 From: m.howells-mead at frappant.ch (m.howells-mead at frappant.ch) Date: 2 Sep 2013 09:24:51 +0200 Subject: [TYPO3-dev] =?utf-8?q?Compat_Layer_in_LTS_6=2E2_=3F?= Message-ID: Besten Dank f?r Ihre Nachricht. Unser B?ro ist am Nachmittag des 30. August aufgrund eines Firmenevents geschlossen. Ihre E-Mail wird nicht weitergeleitet. http://www.frappant.ch/ Wir sind am Montag, den. 2 September, gerne wieder f?r Sie da! Mit freundlichen Gr?ssen Mark Howells-Mead Technische Leitung, !frappant Webfactory From m.howells-mead at frappant.ch Mon Sep 2 09:24:54 2013 From: m.howells-mead at frappant.ch (m.howells-mead at frappant.ch) Date: 2 Sep 2013 09:24:54 +0200 Subject: [TYPO3-dev] =?utf-8?q?Compat_Layer_in_LTS_6=2E2_=3F?= Message-ID: Besten Dank f?r Ihre Nachricht. Unser B?ro ist am Nachmittag des 30. August aufgrund eines Firmenevents geschlossen. Ihre E-Mail wird nicht weitergeleitet. http://www.frappant.ch/ Wir sind am Montag, den. 2 September, gerne wieder f?r Sie da! Mit freundlichen Gr?ssen Mark Howells-Mead Technische Leitung, !frappant Webfactory From cbuchli at snowflake.ch Mon Sep 2 11:34:12 2013 From: cbuchli at snowflake.ch (Christoph Buchli) Date: Mon, 02 Sep 2013 11:34:12 +0200 Subject: [TYPO3-dev] Compat Layer in LTS 6.2 ? In-Reply-To: References: Message-ID: Hy Britta On 02.09.2013 09:24, Britta Kohorst wrote: > To put it in a nutshell: will we be able to run pibased extensions without namespaces under LTS 6.2 ? Will the compat layer still be in place? In a Nutshell: Yes. This will work as is in 6.2 and you won't have to namespace all your extensions to get them to work. What you have to do is to remove all require_once calls to the corresponting t3lib-files since they'll be gone in 6.2. See this Project for some more details: > https://github.com/nxpthx/typo3-upgradereport/ regards, -- Christoph Buchli From jainishsenjaliya at gmail.com Mon Sep 2 15:16:10 2013 From: jainishsenjaliya at gmail.com (Jainish Senjaliya) Date: Mon, 02 Sep 2013 15:16:10 +0200 Subject: [TYPO3-dev] =?utf-8?q?__kerberos_With_eu=5Fldap?= Message-ID: Can you please guide me... What i have to do for integrate SSO with kerberos and eu_ldap From mueller at cyperfection.de Mon Sep 2 15:41:59 2013 From: mueller at cyperfection.de (=?ISO-8859-15?Q?Chris_M=FCller?=) Date: Mon, 02 Sep 2013 15:41:59 +0200 Subject: [TYPO3-dev] TYPO3 and requireJs Message-ID: Hello, since TYPO3 6.1 it should be possible to use requireJs for the frontend. Does someone has an example for activating this feature and use it in own extensions? Regards, Chris. From philippwrann at gmx.at Mon Sep 2 17:10:16 2013 From: philippwrann at gmx.at (Philipp) Date: Mon, 02 Sep 2013 17:10:16 +0200 Subject: [TYPO3-dev] =?utf-8?q?_Hook_into_pagesRepository?= Message-ID: Is there a possibility to hook into the selection of a page record? I want the layout-field of a page record to hold strings instead of integer values. So hook into the SELECT process to transform 0 to default or 2 to yellow for example... Is that possible? In one point of my template i want to set the layout as class in a section tag. There i managed to do it with a CASE based on a levelfield of the layout. So i do a simple switch. But in elsewhere i need that class in a TMENU.wrapItemAndSub WRAP, i managed to add the layout-field to the css-classes but not that switch... so on one position it is
  • but on the other position it is
    now of course i have to write many css rules 2 times.... Instead of that id like TYPO3 to select my page record and save the field "layout" processed as string.... Is there some point i could hook in? From typo3 at ringerge.org Tue Sep 3 05:57:24 2013 From: typo3 at ringerge.org (Georg Ringer) Date: Tue, 03 Sep 2013 05:57:24 +0200 Subject: [TYPO3-dev] Hook into pagesRepository In-Reply-To: References: Message-ID: Hi, you could check out gridelements which imo changes that. however just for that, implementig a simple cObj CASE or USER would be by far easier! georg From philippwrann at gmx.at Tue Sep 3 09:29:22 2013 From: philippwrann at gmx.at (Philipp) Date: Tue, 03 Sep 2013 09:29:22 +0200 Subject: [TYPO3-dev] =?utf-8?q?Hook_into_pagesRepository?= References: Message-ID: But how can i do something like that: wrapItemAndSub =
  • |
    • i will never become a typoscript-expert.... If i hook into the page selection (seems there is one hook \TYPO3\CMS\Frontend\Page\PageRepositoryGetPageHookInterface) i could just exchange the layout key with my string and do it like
  • |
    • From j.rieger at connecta.ag Tue Sep 3 11:59:43 2013 From: j.rieger at connecta.ag (Jochen Rieger) Date: Tue, 3 Sep 2013 11:59:43 +0200 Subject: [TYPO3-dev] FAL: problem with "link" wizard and browse_links.php in TCA Message-ID: Hi folks, using TYPO3 6.0.8 we have a (fairly aged) extension that has the following input field (indeed just tca type "input") with a link wizard configured via TCA (I left out the unimportant parts): 'link' => array ( // ... 'config' => array ( 'type' => 'input', // ... 'softref' => 'typolink', 'wizards' => array( // ... 'link' => array( //... 'type' => 'popup', 'title' => 'Link', 'script' => 'browse_links.php?mode=wizard&act=file', 'params' => array( 'blindLinkOptions' => 'page,url,mail,spec,folder', ), ) ) ) ), The field was supposed to contain a link to a PDF file located somewhere in the fileadmin/user_upload section. Of course, this worked fine in 4.x versions, after chosing a file in the browse_links popup the full path was inserted (eg "fileadmin/user_upload/my_pdf/a_very_nice_file.pdf"). Now, with 6.0.x the browse_links script will insert something like "file: 5229" into the input field. My question: Is there any way to configure the TCA to make use of the old behaviour in this case? Regards, Jochen From philipp.gampe at typo3.org Tue Sep 3 19:08:37 2013 From: philipp.gampe at typo3.org (Philipp Gampe) Date: Tue, 03 Sep 2013 19:08:37 +0200 Subject: [TYPO3-dev] FAL: problem with "link" wizard and browse_links.php in TCA References: Message-ID: Hi Jochen, Jochen Rieger wrote: > Now, with 6.0.x the browse_links script will insert something like > "file: 5229" into the input field. > > My question: Is there any way to configure the TCA to make use of the > old behaviour in this case? You can insert the file link as external link. Anyway, whay do you do with the link? Do you just render a link on the frontend? Best regards -- Philipp Gampe ? PGP-Key 0AD96065 ? TYPO3 UG Bonn/K?ln Documentation ? Active contributor TYPO3 CMS TYPO3 .... inspiring people to share! From typo3 at kay-strobach.de Tue Sep 3 20:19:30 2013 From: typo3 at kay-strobach.de (Kay Strobach) Date: Tue, 03 Sep 2013 20:19:30 +0200 Subject: [TYPO3-dev] Hook into pagesRepository In-Reply-To: References: Message-ID: wrapItemAndSub.stdWrap.dataWrap = ...{field:layout}|... should do it untested Regards Kay Am 03.09.13 09:29, schrieb Philipp: > But how can i do something like that: > wrapItemAndSub =
  • |
    • > i will never become a typoscript-expert.... > > If i hook into the page selection (seems there is one hook > \TYPO3\CMS\Frontend\Page\PageRepositoryGetPageHookInterface) i could > just exchange the layout key with my string and do it like
  • class="navitem layout-{field:layout}">|
    • -- http://www.kay-strobach.de - Open Source Rocks TYPO3 .... inspiring people to share! Get involved: http://typo3.org Answer was useful - feel free to donate: - https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=KPM9NAV73VDF2 - https://flattr.com/profile/kaystrobach From ernesto.baschny at typo3.org Wed Sep 4 09:50:16 2013 From: ernesto.baschny at typo3.org (Ernesto Baschny) Date: Wed, 04 Sep 2013 09:50:16 +0200 Subject: [TYPO3-dev] Compat Layer in LTS 6.2 ? In-Reply-To: References: Message-ID: Britta Kohorst schrieb am 02.09.2013 09:24: > we would like to know if we can rely on the information given in the file typo3/sysext/core/Migrations/Code/LegacyClassesForIde.php inside typo3src 6.0.8.? > > It says that functions and classes deprecated since 6.0 will be removed in 7.0 - which would mean that those classes and functions will still be available in LTS 6.2! > > This is of vital importance for us since we have to migrate a lot of extensions - that will be replaced by extbase- and fluid-based versions in the future - but that will have to run with 6.2 to bridge the gap until the new versions are in a stable production state. > > To put it in a nutshell: will we be able to run pibased extensions without namespaces under LTS 6.2 ? Will the compat layer still be in place? Yes, all the old classnames and the "old way" of extensions to work (pibase, no namespaces etc) will still be working as usual in TYPO3 6.2. One difference that might affect your extension is that in 6.2 we removed the whole t3lib/ directory which actually contained the old class-files. In order to use the "old class names" you simply have to remove all "require_once" in your extension code and let the autoloader resolve the names for you. The file you are mentioning (LegacyClassForIde) are just there for the sake of IDE's like PhpStorm and Eclipse to understand the old class names and be able to autocomplete method names etc. At PHP execution time the compatibility is done through so called "Class Aliases", which are set up in files like these: typo3/sysext//Migrations/Code/ClassAliasMap.php We have an initiative working on an extension that will check your current environment and report you stuff that you need to do while migrating from 4.5 to 6.2: https://github.com/nxpthx/typo3-upgradereport (EXT:smoothmigration) This is still a work in progress, but one of the thing it checks is exactly extensions that are using "require_once's" that need to be removed. Kind regards, Ernesto -- Ernesto Baschny TYPO3 CMS Core Developer Release Manager TYPO3 4.5 & 6.2 LTS TYPO3 .... inspiring people to share! Get involved: typo3.org From ernesto.baschny at typo3.org Wed Sep 4 09:50:31 2013 From: ernesto.baschny at typo3.org (Ernesto Baschny) Date: Wed, 04 Sep 2013 09:50:31 +0200 Subject: [TYPO3-dev] [TYPO3-core] More time for 6.2 LTS to mature Message-ID: Hello friends, We will be postponing the release of 6.2 LTS. Read more about it here: http://typo3.org/news/article/more-time-for-62-lts-to-mature/ And while you are at it, consider yourself as part of the team working on making TYPO3 better, and join the effort around the release! You *can* help out if you aren't yet. By testing, writing issues, reviewing patches, commenting on changes, suggesting improvements, fixes, working on documentation etc. You certainly *will* find some area that you have fun working on and at the end you can be proud to say "I helped making TYPO3 a better product for myself and for others". This is your chance! Kind regards, Ernesto -- Ernesto Baschny TYPO3 CMS Core Developer Release Manager TYPO3 4.5 & 6.2 LTS TYPO3 .... inspiring people to share! Get involved: typo3.org From philippwrann at gmx.at Wed Sep 4 09:57:10 2013 From: philippwrann at gmx.at (Philipp) Date: Wed, 04 Sep 2013 09:57:10 +0200 Subject: [TYPO3-dev] =?utf-8?q?Hook_into_pagesRepository?= References: Message-ID: Did it now using: wrapItemAndSub.stdWrap.cObject = CASE wrapItemAndSub.stdWrap.cObject { key.field = layout default = TEXT default.value =
  • |
    • 1 = TEXT 1.value =
  • |
    • and so on... } From info at cybercraft.de Wed Sep 4 10:06:29 2013 From: info at cybercraft.de (JoH asenau) Date: Wed, 04 Sep 2013 10:06:29 +0200 Subject: [TYPO3-dev] Invitation to the Gridelements weekend from Sep. 13th to 15th Message-ID: Hi folks! Save the date: http://typo3.org/events/code-sprints/gridelements-weekend/ CU there :-) 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 philippwrann at gmx.at Wed Sep 4 12:02:50 2013 From: philippwrann at gmx.at (Philipp) Date: Wed, 04 Sep 2013 12:02:50 +0200 Subject: [TYPO3-dev] =?utf-8?q?_place_og=3Aimage_in_header?= Message-ID: Any of you got an example to get a processed image from FAL as path in a meta tag in your header? Do i have to write a userfunction for that purpose or can i handle it using Typoscript? From philippwrann at gmx.at Wed Sep 4 12:07:16 2013 From: philippwrann at gmx.at (Philipp) Date: Wed, 04 Sep 2013 12:07:16 +0200 Subject: [TYPO3-dev] =?utf-8?q?_Re=3A_place_og=3Aimage_in_header?= References: Message-ID: Quote: Philipp (majpay) wrote on Wed, 04 September 2013 12:02 ---------------------------------------------------- > Any of you got an example to get a processed image from FAL as path in a meta tag in your header? > > Do i have to write a userfunction for that purpose or can i handle it using Typoscript? ---------------------------------------------------- Ahhhh 1 min after posting i managed it 40 = TEXT 40.value = From philippwrann at gmx.at Wed Sep 4 13:37:01 2013 From: philippwrann at gmx.at (Philipp) Date: Wed, 04 Sep 2013 13:37:01 +0200 Subject: [TYPO3-dev] =?utf-8?q?_Determine_if_ext=5Ftables_is_cached?= Message-ID: Hi i wrote i function that merges flexforms for plugins, background is, that i have many plugins using the same fields (because working with same base-models etc). So i wrote a service, that merges flexforms (i only have to write the additions to the new flexform, everything else is inherited). Now i realized that the cached ext_tables.php does all of this live request by request. So i wonder if i can determine the ext_tables mode. Is there a constant or mode defined that i could request? When the cache is empty and the ext_tables is being generated i want the function to parse, else just return the cached XML file.... Or how can i use the cachingframework for this purpose (i did not work with the caching framework so far), so it deletes my cache-files on clear configuration cache. From popy.dev at gmail.com Wed Sep 4 14:25:29 2013 From: popy.dev at gmail.com (Popy) Date: Wed, 4 Sep 2013 14:25:29 +0200 Subject: [TYPO3-dev] Determine if ext_tables is cached In-Reply-To: References: Message-ID: Basicly, ext_tables.php are always included in backend, but cached in frontend. If you want your code to know if ext_tables is included or not, simply put some code in your ext_tables : it won't be executed if ext_tables is not included. And, of course you can use caching for your function. You'll have to find which Class/Method of caching framework you'll have to use, but basicly it's somthink like : $cache = $framework->getFromCache($key); if (!$cache) { $cache = generate(); $framework->storeInCache($key, $cache); ) where $key is the md5 of something built with your function name, the merged file names, the mtime of the files Cordialement, Pierre Dudoret 2013/9/4 Philipp > Hi > > i wrote i function that merges flexforms for plugins, background is, that > i have many plugins using the same fields (because working with same > base-models etc). So i wrote a service, that merges flexforms (i only have > to write the additions to the new flexform, everything else is inherited). > Now i realized that the cached ext_tables.php does all of this live request > by request. So i wonder if i can determine the ext_tables mode. > > Is there a constant or mode defined that i could request? When the cache > is empty and the ext_tables is being generated i want the function to > parse, else just return the cached XML file.... > > Or how can i use the cachingframework for this purpose (i did not work > with the caching framework so far), so it deletes my cache-files on clear > configuration cache. > ______________________________**_________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-dev > From philippwrann at gmx.at Wed Sep 4 15:05:58 2013 From: philippwrann at gmx.at (Philipp) Date: Wed, 04 Sep 2013 15:05:58 +0200 Subject: [TYPO3-dev] =?utf-8?q?Determine_if_ext=5Ftables_is_cached?= References: Message-ID: Yep thanks allready done it with the cachingFramework, really easy/intuitive like everything should be.... From oliver.hader at typo3.org Wed Sep 4 16:35:58 2013 From: oliver.hader at typo3.org (Oliver Hader) Date: Wed, 04 Sep 2013 16:35:58 +0200 Subject: [TYPO3-dev] [TYPO3-core] Announcing TYPO3 CMS 6.0.9 and 6.1.4 Message-ID: Dear TYPO3 World, the TYPO3 Community has just released TYPO3 CMS versions 6.0.9 and 6.1.4 which are now ready for you to download. All versions are maintenance releases and contain bug fixes and security fixes. *IMPORTANT* These versions include important security fixes to the TYPO3 CMS Core. A security announcement has just been released: http://typo3.org/teams/security/security-bulletins/typo3-core/typo3-core-sa-2013-003/ The packages can be downloaded here: http://typo3.org/download/ For details about the releases, please see: http://typo3.org/news/article/typo3-cms-609-and-614-released/ MD5 checksums: 5b31a48d6e4ed45adb2e1cc568b9f515 blankpackage-6.0.9.tar.gz 3f4fa1ea8358247037c0fdceb52abf9a blankpackage-6.0.9.zip dbf0d6a5a9c2311fecc4eee4398a44ff dummy-6.0.9.tar.gz 6c180f33d82aa07db519f58df61e85da dummy-6.0.9.zip 0f67f152eec9baf074f77d31547ba7b6 typo3_src+dummy-6.0.9.zip 022feeab17de3b9bbc1c92dd5b75d0f6 typo3_src-6.0.9.tar.gz f7b3943ad7bbc51c8ee07315655526f6 typo3_src-6.0.9.zip ee2c0e027380d0a5299ebcb06e744294 blankpackage-6.1.4.tar.gz 7efb74aedb2508121d35b4b63de73063 blankpackage-6.1.4.zip fe200790796ab40b538c6180dcfe9f0a dummy-6.1.4.tar.gz d87f29f758ab4c9fcad42291603512c1 dummy-6.1.4.zip 4f02fd88f9f33d0fe3a2476e59237029 governmentpackage-6.1.4.tar.gz 0a8c746b0db4c72db617652b6ec207c6 governmentpackage-6.1.4.zip 762b8fe3ff5fcd503c3acf5f15d44239 introductionpackage-6.1.4.tar.gz 33f144752324740fcf772d42c7964cb0 introductionpackage-6.1.4.zip 431afff51ea649c59a3e3bc97c2bb442 typo3_src+dummy-6.1.4.zip 9a6394fa3640abe5f0bffd49cb3974cf typo3_src-6.1.4.tar.gz 4bcca10d941070543db5399c3a58b7a7 typo3_src-6.1.4.zip Best regards Oliver -- Oliver Hader TYPO3 CMS Core Team Leader TYPO3 .... inspiring people to share! Get involved: http://typo3.org From philippwrann at gmx.at Wed Sep 4 17:19:40 2013 From: philippwrann at gmx.at (Philipp) Date: Wed, 04 Sep 2013 17:19:40 +0200 Subject: [TYPO3-dev] =?utf-8?q?_change_behaviour_of_FAL_inline_field?= Message-ID: Hey, i configured a TCA input field using \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::getFileFieldTCAConfig('images',.....) When i now add a new Reference for a file TYPO3 checks those checkboxes - as if i wanted to overwwrite the title/alt attributes. But if i save it without unchecking those boxes my reference says i entered an alt text and it is "" (empty) What i want: I want those checkboxes to be unchecked by default. Can i configure that behaviour in getFileFieldTCAConfig()? Do i have to overwwrite the TCA for sys_file_reference? Do i have to hook some javascript snippet between to uncheck those boxes? begin 644 screen.png MB5!.1PT*&@H````-24A$4@```H4```$+"`(````@&6NV````&71%6'13;V9T M=V%R90!!9&]B92!);6%G95)E861Y<'!A8VME="!B96=I;CTB[[N_(B!I9#TB5S5-,$UP0V5H M:4AZDY48WIK8SED(C\^(#QX.GAM<&UE=&$@>&UL;G,Z>#TB861O8F4Z M;G,Z;65T82\B('@Z>&UP=&L](D%D;V)E(%A-4"!#;W)E(#4N,"UC,#8Q(#8T M+C$T,#DT.2P@,C`Q,"\Q,B\P-RTQ,#HU-SHP,2`@("`@("`@(CX@/')D9CI2 M1$8@>&UL;G,Z&UL;G,Z>&UP/2)H='1P.B\O;G,N861O8F4N8V]M+WAA<"\Q+C`O(B!X;6QN M&UL M;G,Z&%P+S$N,"]S5'EP92]2 M97-O=7)C95)E9B,B('AM<#I#&UP34TZ1&5R:79E9$9R;VT@&UP+FEI M9#HU-S`R-45%-C$U-S0Q,44S.44Y.$1%1#`U.3=&-3E#0B(@&UP+F1I9#HU-S`R-45%-S$U-S0Q,44S.44Y.$1%1#`U.3=& M-3E#0B(O/B`\+W)D9CI$97-C&UP M;65T83X@/#]X<&%C:V5T(&5N9#TB?Q^2/(%5;%W7Q7=UB`7M=(:02Z7)OW(6][FVT?5 at 2<=&&FYMBY0:__G4$``!F M50P``'D,``#(8P``R&,``$`>`P!`'@,``/(8 M``#R&```D,<``)#'``"`/`8`@#P&``#D,0``Y#$``""/QZ2OO5YJ[V-+``!J M)8]--CFSFE%N5=Q*#'1MUE]O[AH8]54C3S/AE9GRV0(`R..*6KN+Q=XV]:BM MMUCL;JV!]>W9HU.P[[&.0_SP``"71AY7+0W;NVQYJHI$5ZKZXC5[HK2$S1?< M050QV-]`UU[>N3#ZK6\GH-/+95ZM[HF6)_9XL.I?OD8U-&V^*U<>?!HJ6FD9/HW+5!IDIM M5W;[*-W6T]+97_J"AOJ.J^^HK).598 ML8K3CWFV``!,T.P?1XTWA>6JKQB;@F;E@:/J<=OVTF;OOGT] MKMKT+SARK$J-V?JP. at MHZ7RX=4)S&->*59M^PI,!`#"E>3PB6:Q6+C='9*M; MZZ#*^(IT,5KQVZ/.H?D;&=ML`0"8HCQ68Z3,V*6>;6._ MWJFU6Q6)ZA7U]??M#2O;9TSO:NFPJ=9NW>]J7E'RO;$NLO(<3-2Z at 5?C7;%J MTX]QM@``C)DH%HNSL%@]`$NU,%=OF`8`X-)1-X/+LN.8G;9>PA@`@-FLCP$` M0(#[5P,`0!X#``#R&```\A@``)#'``"0QP``@#P&`(`\!@``D\CCBK_N8=R_ M`P*8 at V9X/^=C!9#']EA09G/7@/KE#=WZ=QEU;59?`O,X?>LK_R*5Z=OYR&4[?X5]7E>7 M7:9&E1.I3TU[>_DT6>VJYU0R9]M>K:8+/F7R63N'B7W6REZEGV@/?GNX?+ZO MZ@<<0,WDL:%_:7!+9[\\ZWZR?-)Z0G,E_U=T8=C_69^1PLNM=U'MDF[$/FL57B770RU?A;.,YFU1KRRD6ZM\P`'47!Y7KRFBGFWV MY+M)GF`?)8\Q%^/XQ;W1CJVZ=;?UX>[+8-NFZ=4?+D6,# MOA9UKQMI=;*3`G^>,,'/6I57R4CN;9;5<-/>'?WD+S`KIN'W'[?U1G&JA8MMMHO]HT4R`]W[FEZK&_G]GT=T8[^ MQDDMM\JK&F]JD34]/WM@;M;'Y6?DZCQ^F^]O&NC:3-\3YIZ^QSHBW53K6Y-= M$W.%G7\R^[RKF7796OUC%;DVZW;75CWAY59[55^[*HU5"W93-A^:MX"Y41^K M`T3]MOH>?;J=?=R[^SLW-]779Z?B;&3,M3A6J5=L+-G7]_5E565NYY_H/M_: MW;NOWKZLK:UMI(^53=)MVWK:>KLG]UFK\"J9RDT=S;U%%?0[#_:J\5R=_0=W MYMXC>P4PW80\^6SY MN#3W?-1N'M?7+VF^I?E/'U],DD1H!2>.8_V$G$K^3>7_TM2]3. at _]H&5NK_9 M9'9B-X_:Q)`]))T^>-WDL,]@=@VH:'32_T39(W( MHD78H[0P?U.7=KE)P]BIYW'8+DO-.]=0B7,+(6>C/B]()[@SZYUEV M&F%^KKDP%D)43V+Y;?,CCD1:OC/D=HFQ[7NS>%0BC#&+^QYY3!Y7-C0TY/-8 M'DN3.)9?ZH=!(93Z+`@.V-E!W!SHLPE=3,G#=FJGJA at Y)36H\+,8+85%KB(5 M)@+56J1:DJ0V0T44NPHYRV3_KLKB*8B3W`K;\P5A7V/^"RKQ+%5%,%EBUL:\ M(QM99D7RFU*,%,-9S&>A/-HF"HIU(>R)1Y)$9LNXM=:+CRO_)"K.,JW8H"`R M(^7Y&/WUCW\\ELD>^O:W^81C/F'/)X^59%B1!U+32"W_T9$LS+'55859@:03 M-FC(MN67B\(T2[C4SR!?8V7IE;H0S]7':?X,("IK#-95FHBR at C<-5B31]%-J MDC at RY7XJLJC0\2W_2U1B9E5N6K%(%2(*3S12G;*)B]KLC<99U*=V/=R_-I#- M*LM54G]D$MJ5,A6[2,.EE3RL7K!6SLXT3-:L[L?^IR[_A^W+3"S$X$_1,3]<#]]U?8F^OJY*SECBK?P9-//37YC\?%"Q?-J5NV MT_K3HVQO#/=\>[Z5?X^5]_S<28H(FO++NR?&N>?GYQVL3*5]=\&"!1P'YY"9 MV?-1TWD\;/)8B at OA9SPMI.H(&T6ES;\E!P+?=^L/;OYX[P_1Y4>-W&$[UT?K MCT?EC<[N9<*T^<:F\3I7VL)71ZS\KFKP%UD<._GMH3)0_4FR@!:B9(N(7"MP4-/[%N>T_+"= MKUC=*8LOY&_#!L` M)NP??WD at _/+J-:M?>V/P]=^=N?_K?[9F5TKLC[3:!+6VYT?Y?4/$ M4](P at 9HP4WL^:K8^UD=I<9J76-A>Y"S+!X:'DI4Z.C`20L%?RA-T]@G M=SJC(DY$8F.L MI)57E,6P7Z?P4!MLW[)&:U$A.$1^XPP-J74RZ6,"U(SOWM2/B!3>Z8%#;DZM!T1XO$B*TI*\R8>EB8\X+J2% M.+4-OC9P$AW'NFU']9K*:#Z#G[K/9#`:,_&"!*2+7;$7#E;]YY<3[ M at Q7C8I*QNL8Y,([6JDM7[B]6A-G%O.'63E>:Q7:^@ M4"H]7+HV8]T`+OR1-S9;P-7?69.X33^38F5'32$J]@D*WWH>=D$&2X^"/O/< MBH9;J)":]?N)"#.GPJ8,`\Z at R-7`F:]ST+'<<&T/<2YOG0;#Y.V M:-'"19WY\J>:=3?$N;810GD>F($]'S667&F:M*DP1%4RK6VYTD3MZRZET MKZ,]XMB&O21HL at N.)R(_(L753_F1Q16KA/S`YZQX,V5?7/"U2VQ&=+GA2K86 M3.SX'&'72R6R#A+S.#$=JFDP]$OW at Z:Y/CU?JJ2Y*WCM&#![/5@<-N;J46K^ M>B>_Z;+KL/P;S`[YX=$V/PPHJZR"PW?6?1P%8^#=RD7^J*V;!E+3LVW*0/O6 M[;MV*Y>X(WGN="=. at LX`_?IAE\B1R6,7QLE(M?K$K%ZU\L)'T:O];__%GU__ M\JLGSYR[N&YMP^V?WWC\^(DI#..L[B_+Y+*.XQK:\W6+1*Q/@_1.[:[&(XSG M at 1G8\U'3>>R/"EEK:*(:KZ/\6%EWL%:')#,.R(SC2=)@L$^2YMK;S-6Z4>E0 M85'2OI96/RREY4KV MU)Y0^?YLN=B"W])Q$EZZ)L(D<"<%_OIR83LG[2HEMJW>IGD2M+V;ZZC2:,JC M6%NS>N7C/?]T[/CIFZ]?^_P_')$;YVM?O54NNW[APBE?5K:[)?Z-YH9WU=R> MKZ^!T&=5OCN?))XG9G+/QXQV0(QQ.MLD&MLJ(/+5F0B;P?(MJ:/,*S_M:*?M M91>TECT.QD@%HY9S5^^X$L1%CO"WW(C\X]*6/U]QQ*:_U3;1QJ7O5627.0?M MCK[U4L1Q]AH]Q,SUWII[G=69OW5U=>;.9WX0512,]*ET&4LV-CI+[S1KE_9O MS`WI3LN'=;L#NR^Q_%MV*YZMB.^Z%E%INWG6G!U5[V6>0A]\,+CK6W?(67_O MAR^<>G=PU8JE7]A\G7Q+"Q;43<^'Q?=ZES5,U.">'PS:3_T%=N$=]#!GS?B> MCQJKC^W`''T(*N@(B0OZF>SJX=R1IF0(K1__Y:O(X*P_K7#T&?&^$?EFX31W MP:N_'87-GZ"`$*8GUZ>-Z]MUP5,2'O:*9%5J"%OGA=U[:=A`G1\_E=4B(@NX M[!ZC;OR4+H^$J:'"@;?^R&HVH[EO210&I;N`)>BXS6[%$=Y#*QOAJ\HYW5#@ MMU84!K=]UXGM3TX+:L\8-EL@=S,S>YF./4TIN+71M;>[(XFYT$S]3^TE;E>) M_1"G*5(L%I9'-`(J M'=5+&2=!)V[D*FISKY!LBX5_H]Q0WV##JCF*83-^.TU=SW_)@.E"=L,N-0PH MZ",MN\8V&)PMS#W6],K&:L7]CZ"@\KW.5/^NM5VXZ[LG.Z2KKA`/OG_F[J\V MR_VCKJ[PQ*[!6R]AV9A#&W M\335JRBYPB4JN9U8V9$Q.\Z5#O?VA;@.,'5^D,9!EZ*MCLW;B&V#N^VFS(WF MBF.1N^`YU]%<C86'S.`Z:I:Z3NBNE"K$-9'L:$ERLGHK)]FA^YJ8;S=I\YR_OD&]H>'AX87W] M--3%P4W;51(G2=G%9+6XY_OQ[_;N[79 at A,AN=$<>CMO-X at 3LHQ?[7 M.YEFRY*;5(C\;:-+1OBFE9KH*GT=W'(HNS]C/@9SEV(&=Y[T]^Z(8U?(^Y0U M16^=FE=L!E5'67.RZS`5]HX at JN76-O'&451U5%+8@!@V1XI\?W30\^SN!5;A MMTZH9:DDC-V0H21_U(_])48B^-T/I8.F at DEL=F9L"+EDRAZX> M.?M__JKS?YXRCV_[5N?=-W)XFX^X'>8\)HK%XLA3O'?Z_+IK/A6%%^0`,VC@ MS7?6KUTQ\\OU>SYP2>WYF"UC&E]]^MSY$_27#K8\T%]G//'/W[R M87&(+879LK2^[O+++YOYY;+GX]+<\S%;1N\_ECL$^P0N0>SY`&92S"8``(`\ M!@``Y#$``.0Q```@CP$`((\!``!Y#```>0P``,AC``#(8P``0!X#`#"'\[BO MO;Z]K^IW![HV;^X:8*L"D_PH36S*$>=1/TV?S0FLGEJ;2;\EX-+*X_)/6FMW ML;N5S89Y3IY9U@>F(\E&_"CESFPG_Z'K:]]VI+/_X,[&*N]OO.$XV=63+^F- MMI'(P*3J8^`2T=+97W1V'VVJG[LM/P-=>WK:=F=A+$^SF_;NR-Y=L;_SR)Z9 M?G>M#\_"0H%YE<>^8E8/VMNKEP_Z!)S&:\P+JIYK[KC/[LY!<>GW\+[VLF*Z M=#)=5':UNWITA(_20-=]'8<.=339PC5HI at H6$SPUXB*RO)(R;CNXN%G,? M>F`N1_+VMD-'!W3`Z'W;[/H[]NJ0EAD7]=KG>IO=9+X&M4]%T:&.H^8S4]+` MZSY*-O4;=S[3V6+J\W!"^;%246JGC+;Y=*O^2=0O.QK&\<"Q(RT[ME;^7,I< M#DKFK#UY>E:O\8;F0T?)8V!*\MA]R.6);LN18_Z#]6)[O3I at TTVR3E21TGA3BWI.!UAKM]KUY619$[%Y*E)MX`^WCO11TJE?M6A4P9K- MTYT?5/\D3N3=M6?OK`97#R"/QT-6`%%;U+./H1J8;SGLZ-LO'YE_=S5SL[]0UH*J8]V2=RV/],,C4;[G)Y%UY6VXX3S5& MRTTY6 at ++EP7GQZT/=T8=3?F.YKYV^[6OA%4SP#2OGFHYOXEL![RZT2;HV5;O M/YBR+M@^MMFJ\2^JY:NE9.`(,%>H`4L=_BRSO]CM&Y_[.S;W1SDI)^76W#[SX>``>*)8++(5 M@%DMOO=MG][Q%G(1>VZ:X*GQ-*W>#+QK8+[5QP#FNE95^39MCFJEM_OV;)T\- M#IYG8V'F77GELD]?>\WZ=5?/_*(???11MC]JQR.//,)&N-3SN+Y^2?,MS:M6 M+&-C8>:=/G?^#Q]^-%M+W[-G#S\"U(+=NW>S$)TGRTDLO M'3ERI*&AX=RY4''WS0W-Q\^^VWQ_%D^V(>>NBA=]]] M5SX00L3JK_K',!/(_Z7A"U+]E.6GLM]+TY*'P00ETT:C/:_F4?K$.%X\?LN6 M<00`:B./@=HA<^:G/_WIAQ]^^(UO?./BQ8NG3IWZV<]^MFC1HKONNJM0*+SS MSCO_[^C?G3S]/PI+-ET\^^OU__:AQ1LF?%O&5"_._"=L*HLX$C;KLCRV">MB M6O at XE/_8Z-0I;*(XR',]59:<%3,T>#)-TW%NJNE*:,RZO_[QC\=T6OGM;[.M MR&- at 6AP\>/#X\>/?_.8W?_*3GQPX<."JJZ[:M&G3B1,G7GGE%5G.?F/KJCNN M7WGYRGN7;?CLX.]N./Z_G]OT'R>?57/_KR MO__^<=?'@B_O'K-ZM?>&'S] M=V?N__J?K5G5P/8ACX%IM&;-FI=??GEH:.@'/_B!+`+DOS*>Y?,;/W7F>]_Y MPK)/?ZGXSG.7+1(G#_]KDE[V;^[Z+Y->8!H$;B)2&WGYRMB5QS[_#-]47/6CW_?'5\VM&#)M0N'3J[>^J-XTE<1K&<13YQNS8 M_(VR_F/Y^B1109SX.,Y26TX;E?6M8WK^:K1;.JO2`NFQJ_6 M*H[Y(H[%BH8K?_/*B?<'+VY8MZ+YQJOD+L=F(8^!:73MM==^][O?_?[WOW_T MZ-$%"Q;(@\[V.];>M/ZR98W_X>/?/Q$O&/KD#QO.'OCG-7=U%I:MFW1EK(,O ML9F;VO9F7YUF[=19PIHPCH-.9E<4VT at NJ8]%25]S%/1"Y]NOT^R/3F7U)]]= M;%N!`5Y+=B(5Q+."7R_+1HT<)%ER_\Z*,_+F^XXN]__ at MY'K;CSL]> MN'AAZ=(E;!SR&)A&P\/#Z]>O[^[N-E^^?^(7 at V__9E73G9^\^W3ALO3C\]>> M/?C/Z^]Y.EVX8DH69Y+/9&H2_.MB-5^EFBR,&59=]_/ZZP4/_NG[' MDU,2QJEO'-:/$EW@:FF2YBK=+%@3]3?)KE2.LK;EH#@."N0@(GVOM*MC;7V< M#1ZK4"#[:ZMQ&4TV%>/%4%O6K%[Y>,\_'3M^^N;KUS[_ M#T?DKO>UK]XJ]]'ZA0O9.',.]Z_&'/8O+SW]F=L?J'_[I==[#QS^^?NO__)? MUM[UP_3R3TW-W+/&:)NB4=;PK`PG/J!50MND-M&;E#&)GH99;J/=S&IX6/ZG M+U(Q_R;F:_6T>:R7-VS_F._:*92A(?=_^\BLGIR[;6IG;YF7/OA@<->W[I"G M7M_[X0NGWAU>_B980[K'SC]^%-/ M?/[' M=E2IIS<_JUS_M1L''DZ;$L.7PA&\$`^^?^;NKS;+&*ZK*WQQ\W4?7K@@3\4* M!8[MY#$P at WK^U\GIG+TP=^TP5_*:[%/]LWZD=)3=DRNHC5W1ZVZGF5TSE>5I MA3A.1XKBDF!.?;AG/=*NI]N-Z++WV]9K+B*&<4&ROM"]"LR;K"54IIEL=1=L5RA=HX';DX+LEC M/]3,-56;L=MFX'8<%R1US9.]\,J<'HB(\5SS"[?#)(^!2R60W9!E6W)FP5EZ M"^DLC[,L#:?)/2Y_5-8C/'(@^]MN^DNH3!ZK?^VXZH).9)W*N6NO,&_PBR(N MT3P^?>X\OW(1LT+N>[,6QZK/.(K-%42FU*SZ.QQS=ZR,1L[C,9X(5,SE;#ZN M`]DUGF<7847VHJ="H4[%<1R[AFO*8V".Y_$52R__L#ATZO0@&PNSXE,-2V>M M/C;WURB8/X78#=G*QVOU6TZG%7]/<5HY_<=<(@>WL#9_W656;HR77FE[%A$' MW<@`YG8>7W[Y9?(_MA0N-2*[&W7L56_\S3^=3OZ"W^J-S'[FMDB.2V]/$MRH M*Q:^"YE(!N9X'@.7;B+[2YA&SV-3W+HKG*:LQ[9T1J9!6H3!+/^-@]\S$=3V MP4 at TNI`!\AB8VY&0P``,AC``#(8P``0!X#`$`>`P``\A@``/(8 M``"0QP``D,<``(`\!@"`/`8``.0Q``#D,0``((\!`""/`0``>0P``'D,``#( M8P``R&,``$`>`P!`'@,``/(8``#R&```D,<``)#'``"`/`8`@#P&``#D,0`` M((\!`""/`0``>0P``'D,``#(8P``R&,``$`>`P!`'@,``/(8``#R&```D,<` M`)#'``"`/`8`@#P&``#D,0``Y#$``""/`0`@CP$``'D,``!Y#```R&,``,AC M``!`'@,`0!X#``#R&```\A@``)#'``"0QP``@#P&`*"VU;$)@&IV[][-1@`P M,T2Q6&0K```PNVBO!@"`/`8``.0Q``#D,0``((\!`""/`0``>0P``'D,``#( M8P``R&,``$`>`P!`'@,``/(8``#R&```D,<``)#'``"`/`8`@#P&``#D,0`` MY#$``""/`0`@CP$``'D,``!Y#```R&,``&I7W5MOO<56``!@EO.XH:&!K0`` MP.RBO1H``/(8``"0QP``D,<``$"I>^VUU]@*``#,/^N>YZ-HGN?.WOV M[/X'-YH$'6<$FMS,C/D<8()1.ZD7`P!04=U4SW#+XV?//JX?R0>C9ND;ZN;9 MM]ZP<1*!?MLCAZ-;'WU%QKD)RWL>N6W7=6<*6IFS9L(@[K2/MXRY9<#6NR-(H./W*;?&K7KBVJ5K9?VF9F MWYI=I2;=_X)ZR;W_^4&;Z%ONO%?^^^P+02/U&R4K6:&!?+2E9.]=ON/QKR0` M`*/F\:.WJFP)>ED//_+(L^6%K,DA68<&E>>SST=/GCW[W+WJ-7\UEF[:K\G) MS[ZBE_B`C*TMCZO'D6FOWO_XX_O5K,Q"]%)4L?NL_LJ]ZK:2WN#R^GKC#6J. MK[UQ(K^2V4)5<6P7Z[-VY*6$[_W!!\>_D@``C)['ND(-`\QFR]G]#_J4>_Z! M7*.PDY6EN1E4=?-U:O*-UZE?*'7X^9^/]@)3^^I"=.7*V\K6IW8E`0"7NKJS62]OM10Y+/-(%GZJOOQ*Y52:`!W.8\BMJDD8N6P_?/B8 MG(^=Y,2QPR/,W)P1C&TI)\;QWD=<20``1J^/(]WD.F(3ZZV//KG_2=7$:UM\ M1S-R?6 at JRHICN$QCLV/Z at H.F\`KK:?N+_ZM;+=N??.>6,2]TE*64O_?QKR0` M`*/F\V13P````!)14Y$KD)@@@`` ` end From info at bednarik.org Wed Sep 4 21:11:55 2013 From: info at bednarik.org (Jan Bednarik) Date: Wed, 04 Sep 2013 21:11:55 +0200 Subject: [TYPO3-dev] BE module _DISPATCH - BACK_PATH doesn't work with symlinked core In-Reply-To: References: Message-ID: Hi Helmut, I can confirm that require_once t3lib_extMgm::extPath('cooluri') . 'class.tx_cooluri.php'; works. Thanks Jan Dne 30.8.2013 13:32, Helmut Hummel napsal(a): > Hi Jan, > > On 28.08.13 12:56, Jan Bednarik wrote: >> I have changed CoolUri's BE modules to be _DISPATCH and I use this code >> to include necessary classes: > > This is a good thing. > >> require_once $BACK_PATH . t3lib_extMgm::extRelPath('cooluri') . >> 'cooluri/manager/linkmanager.Main.php'; > > $BACK_PATH contains the *relative* path to the typo3 directory of the > TYPO3 sources. > > If you use _DISPATCH then, your module is called from mod.php which is > inside the mod.php directory, so $BACK_PATH is always an empty string. > > If you want to require own classes, never use $BACK_PATH but > t3lib_extMgm::extPath('cooluri') which returns the absolute path to your > extension. Thus the require statement should always look like this: > > require_once t3lib_extMgm::extPath('cooluri') . > 'manager/linkmanager.Main.php'; > > A better (future proof) approach would be to include all your classes in > a ext_autoload.php file, which the extension extdeveval can > automatically create for you. Then you do not need any requires at all. > >> So what is the correct approach? For required I could use >> dirname(__FILE__), but this won't work when I e.g. include CSS: >> >> $this->pageRenderer->addCssFile($BACK_PATH . >> t3lib_extMgm::extRelPath('cooluri') . 'mod1/style.css'); > > As said above, $BACK_PATH is empty if you use the module dispatcher and > if not includes the relative path tho the typo3 directory of the TYPO3 > sources. $BACK_PATH is of no use, if you want to add your extension > resources for rendering. You can just use > > $this->pageRenderer->addCssFile('' . t3lib_extMgm::extRelPath('cooluri') > . 'mod1/style.css'); > > because the page renderer accepts paths relative to document root. > > HTH > > Kind regards, > Helmut > From steffen.ritter at typo3.org Thu Sep 5 09:23:13 2013 From: steffen.ritter at typo3.org (Steffen Ritter) Date: Thu, 05 Sep 2013 09:23:13 +0200 Subject: [TYPO3-dev] Invitation to the Gridelements weekend from Sep. 13th to 15th In-Reply-To: References: Message-ID: Am 04.09.13 10:06, schrieb JoH asenau: > Hi folks! > > Save the date: http://typo3.org/events/code-sprints/gridelements-weekend/ You don't think that inviting people ten days afront is way to short-handed? regards Steffen From philippwrann at gmx.at Thu Sep 5 10:38:43 2013 From: philippwrann at gmx.at (Philipp) Date: Thu, 05 Sep 2013 10:38:43 +0200 Subject: [TYPO3-dev] =?utf-8?q?_Re=3A_Cleaner_URL_=28Form_submit=29?= References: Message-ID: ANYONE? Please... From soren.malling at gmail.com Thu Sep 5 12:17:55 2013 From: soren.malling at gmail.com (=?ISO-8859-1?Q?S=F8ren_Malling?=) Date: Thu, 5 Sep 2013 12:17:55 +0200 Subject: [TYPO3-dev] Cleaner URL (Form submit) In-Reply-To: References: Message-ID: Submit as post, and use $this->redirect to redirect them to the correct URL? On Thu, Sep 5, 2013 at 10:38 AM, Philipp wrote: > ANYONE? Please... > > ______________________________**_________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-dev > From info at cybercraft.de Thu Sep 5 12:36:11 2013 From: info at cybercraft.de (JoH asenau) Date: Thu, 05 Sep 2013 12:36:11 +0200 Subject: [TYPO3-dev] Invitation to the Gridelements weekend from Sep. 13th to 15th In-Reply-To: References: Message-ID: Am 05.09.2013 09:23, schrieb Steffen Ritter: > Am 04.09.13 10:06, schrieb JoH asenau: >> Hi folks! >> >> Save the date: http://typo3.org/events/code-sprints/gridelements-weekend/ > > You don't think that inviting people ten days afront is way to > short-handed? We already announced the sprint a few months ago. So this is just a reminder and a kind of "extension", since we asked for a code sprint in the first place, which has now changed to become a kind of workshop with some coding. So if people find the time to join us for a weekend, this would be nice. And even if you don't have the time yourself, maybe you can spread the word so that others might join us. 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 philippwrann at gmx.at Thu Sep 5 15:03:55 2013 From: philippwrann at gmx.at (Philipp) Date: Thu, 05 Sep 2013 15:03:55 +0200 Subject: [TYPO3-dev] =?utf-8?q?Cleaner_URL_=28Form_submit=29?= References: Message-ID: To complicated, i need all of that to work smooth with the absolute same behaviour in all circumstances, for example the pageinate viewhelper, ajax situations, etc etc i'd like to simply tell the form viewhelper NOT to render all those tags, because i really dont need them here.... I can see their use in CRUD actions but not in here.... Should i simply write my own form-viewHelper for those scenarios? Dont like to do that either. From info at wendisch-media.de Thu Sep 5 15:30:07 2013 From: info at wendisch-media.de (Tim Wendisch) Date: Thu, 05 Sep 2013 15:30:07 +0200 Subject: [TYPO3-dev] kerberos With eu_ldap In-Reply-To: References: Message-ID: Am 02.09.2013 15:16, schrieb Jainish Senjaliya: > Can you please guide me... What i have to do for integrate SSO with > kerberos and eu_ldap Hi Jainish, I found a nice Whitepaper / Concept related to this topic, created by a company from Switzerland. Unfortunately it is in German but maybe it helps you to get a first impression. http://www.internezzo.ch/fileadmin/user_upload/Kontakt_Service/Downloads/Konzept_TYPO3_Single_Sign-On_mit_Kerberos_und_LDAP.pdf Tim Wendisch From rakeshdodda.rd at gmail.com Thu Sep 5 19:05:18 2013 From: rakeshdodda.rd at gmail.com (Rakesh Dodda) Date: Thu, 5 Sep 2013 22:35:18 +0530 Subject: [TYPO3-dev] Cleaner URL (Form submit) In-Reply-To: References: Message-ID: Hi Philipp, I guess RealUrl is what you should be looking at. I personally haven't used it (yet), but it might solve the ugly long url issue. Here is the documentation : http://docs.typo3.org/typo3cms/extensions/realurl/1.12.6/ and here is the extension : http://typo3.org/extensions/repository/view/realurl Thanks On Thu, Sep 5, 2013 at 6:33 PM, Philipp wrote: > To complicated, i need all of that to work smooth with the absolute same > behaviour in all circumstances, for example the pageinate viewhelper, ajax > situations, etc etc > > i'd like to simply tell the form viewhelper NOT to render all those tags, > because i really dont need them here.... I can see their use in CRUD > actions but not in here.... > > Should i simply write my own form-viewHelper for those scenarios? Dont > like to do that either. > > ______________________________**_________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-dev > -- Regards, Rakesh Dodda From philippwrann at gmx.at Fri Sep 6 09:17:48 2013 From: philippwrann at gmx.at (Philipp) Date: Fri, 06 Sep 2013 09:17:48 +0200 Subject: [TYPO3-dev] =?utf-8?q?Cleaner_URL_=28Form_submit=29?= References: Message-ID: I rewrote the viewhelper, seems to be the best way for non-crud actions http://pastebin.com/DXy1EEWC From kontakt at mb-neuemedien.de Fri Sep 6 10:40:30 2013 From: kontakt at mb-neuemedien.de (Michael Bakonyi) Date: Fri, 06 Sep 2013 10:40:30 +0200 Subject: [TYPO3-dev] Voting + sponsoring of bug-fixing in Forge Message-ID: Hi, before I aks my questions beyond I'd like to point out, that I don't want to offend anybody of you devs investing a lot of (often unpayed) time in bringing TYPO3 forward. Although I work with TYPO3 for some years know as an integrator I'd just like know the inner processes of the TYPO3-community regarding development. Until now I didn't find any docs about them. So: First I wonder if the voting-feature within forge is taken into account regarding the priority of bug-fixing issues. How do you (core-)deveolpers decide which bugs are worth fixing and why? As example there's a bug posted 6 months ago with 21 votes: http://forge.typo3.org/issues/45859 which didn't get fixed until now. To strengthen the spirit of community I think it would make sense to take the votings into account to a greater extent. Then (as a non-developer) one has the feeling that my voice is heared. Second I wonder if it's worth thinking about implementing a bug-sponsoring-feature within forge. Maybe there's a functionality within forge already, which could get activated. If you think it's worth it, I could research that. We had that kind of "feature" within the old bugtracker in Mantis. In Forge regarding some bugs I offered sponsoring of bugfixings within the comments of an issue but never got asked to sponsor it and I always wondered why. Maybe it's against the spirit of TYPO3 paying for development but I don't think so. Everyone has to live with ugly money ... But maybe sponsoring would be accepted to a greater extent, if there was a feature where several people could "throw together" some money if one dev says "I'll do it but I need X EUR for it")? Would be glad to hear some thoughts from you. Cheers, Michael From typo3 at ringerge.org Fri Sep 6 10:55:16 2013 From: typo3 at ringerge.org (Georg Ringer) Date: Fri, 06 Sep 2013 10:55:16 +0200 Subject: [TYPO3-dev] Voting + sponsoring of bug-fixing in Forge In-Reply-To: References: Message-ID: Hi Micheal, Am 06.09.2013 10:40, schrieb Michael Bakonyi: > First I wonder if the voting-feature within forge is taken into account > regarding the priority of bug-fixing issues. How do you > (core-)deveolpers decide which bugs are worth fixing and why? there are many strategies how to find the issue you want to solve: - because it bugs you/your company - because you got e.g. 2h time and wanna finish the work with a working patch - because you know this area well - ... > As example there's a bug posted 6 months ago with 21 votes: > http://forge.typo3.org/issues/45859 the vote is certainly helpful to identify bugs which are highly welcomed by the users but there is no strict rule that this issue must be fixed as next one. So the answer could be something like: It certainly helps if people vote but it is still not a guarantee. > Second I wonder if it's worth thinking about implementing a > bug-sponsoring-feature within forge. This was in mantis available but not often used because just because someone says with an anonymous user "I will pay 100?" won't mean that the developer get its money. If you got money for fixing something, just announce it in the mailinglist, and make a deal with a developer yourself. This is the best way! If you can't afford the fix alone, collect the money first and then approach a dev. This makes it easier for everybody. At least I handle it that way (both ways as getting paid and paying others). > Maybe it's against the spirit of > TYPO3 paying for development certainly not ;) Georg From jigal.van.hemert at typo3.org Fri Sep 6 11:17:53 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Fri, 06 Sep 2013 11:17:53 +0200 Subject: [TYPO3-dev] Voting + sponsoring of bug-fixing in Forge In-Reply-To: References: Message-ID: Hi, On 6-9-2013 10:40, Michael Bakonyi wrote: > First I wonder if the voting-feature within forge is taken into account > regarding the priority of bug-fixing issues. How do you > (core-)deveolpers decide which bugs are worth fixing and why? Yes, some take the votes into account (looking at the most votes bugs and features from time to time). Most developers fix bugs in areas of the core they are familiar with, bugs which get some attention somewhere (lists, forum, twitter, etc.), bugs marked by a Release Manager, bugs in areas they are working on, bugs they pick up when they are friendly ghost, bugs which the friendly ghost brings to their attention, etc. > As example there's a bug posted 6 months ago with 21 votes: > > http://forge.typo3.org/issues/45859 > > which didn't get fixed until now. The problem with this particular bug is that Benni assigned it to himself. This is a sign that he is working on it and other devs will not likely work on the same issue (there are plenty of bugs/features which are not yet assigned). In this particular case it's best to contact Benni and ask him if he has a solution or wants to unassign himself. If this doesn't work out, there is a typo3.teams.bugs list to ask for an issue to be updated (remove assignment, close, etc.) > Second I wonder if it's worth thinking about implementing a > bug-sponsoring-feature within forge. It's not about money for all devs. Some are free-lancers and for them it might work, but others work for a company/organisation and work on TYPO3 in their spare time. We've had such a feature in the old bugtracker, but there were plenty of problems with people actually getting paid if they fixed an issue which had a sponsoring amount attached to it. -- Jigal van Hemert TYPO3 CMS Active Contributor TYPO3 .... inspiring people to share! Get involved: typo3.org From j.rieger at connecta.ag Fri Sep 6 17:25:12 2013 From: j.rieger at connecta.ag (Jochen Rieger) Date: Fri, 6 Sep 2013 17:25:12 +0200 Subject: [TYPO3-dev] FAL: problem with "link" wizard and browse_links.php in TCA References: Message-ID: Hi Philipp, > You can insert the file link as external link. Anyway, whay do you do with > the link? > Do you just render a link on the frontend? yes, it's rendered as a file link to the PDF. At the time the developers did not want to use the group / file TCA type because the linked PDFs were updated (aka overwritten) by editors frequetly. So a direct link to the fileadmin/user_upload section was more comfy than the copied versions in uploads/tx_myext/. But ? now of course chosing a file in the popup will fill the file:1234 relation syntax into the input field. So ? I'm afraid, my question of the initial post remains. The other option would be to use FAL relations and make use of the API in the Plugin. But? the we would need to convert all the old file path values to file id strings. Regards, Jochen From philipp.gampe at typo3.org Fri Sep 6 17:37:26 2013 From: philipp.gampe at typo3.org (Philipp Gampe) Date: Fri, 06 Sep 2013 17:37:26 +0200 Subject: [TYPO3-dev] FAL: problem with "link" wizard and browse_links.php in TCA References: Message-ID: Hi Jochen Rieger, Jochen Rieger wrote: > But ? now of course chosing a file in the popup will fill the file:1234 > relation syntax into the input field. So ? I'm afraid, my question of > the initial post remains. You have to add treatIdAsReference = 1 to the FILE object. Best regards -- Philipp Gampe ? PGP-Key 0AD96065 ? TYPO3 UG Bonn/K?ln Documentation ? Active contributor TYPO3 CMS TYPO3 .... inspiring people to share! From ernesto.baschny at typo3.org Fri Sep 6 22:04:36 2013 From: ernesto.baschny at typo3.org (Ernesto Baschny) Date: Fri, 06 Sep 2013 22:04:36 +0200 Subject: [TYPO3-dev] Voting + sponsoring of bug-fixing in Forge In-Reply-To: References: Message-ID: Hi Michael, thanks for bringing that into our attention. Georg and Jigal already gave you good answers. Just one more ideas thrown in: There are no strict rules and the voting is just an indicator but not a guarantee that someone will actually take a look at it - as you have noted. What you can always do is to bring certain bugs into a more broader attention by writing to: a) the core list (typo3.teams.core) b) the current release manager (myself) or the core team leader (Olly Hader) We usually know what the priorities are at the moment and who could or should work on that. If you are interested in sponsoring "someone" to actually fix a bug (or add a feature), just mention that in your mail to us and we can then see how we can make a match (i.e. by asking the active contributors if there is interest). After all, fixing a bug is more than a "one-man-thing", because it requires one person to fix the bug and at least two others to review the changes. Meaning that if you are sponsoring, it might be handy to gather a "3-man-team" around it (which is not so easy depending on the context of the change). Another added complexity that by looking at a bug report its usually not easy (and usually even impossible) to estimate the amount time that will be required to fix it. So getting ?100 sponsored but having then to work for two weeks on it doesn't make sense. Which is also why "sponsoring bug fixes" usually doesn't work so easily. :) Please be aware that this particular bug is very important and I personally want also that it gets fixed for at least the release of 6.2 LTS (see http://forge.typo3.org/projects/typo3cms-v62/wiki/Issues for a list of other "important issues"). Kind regards, Ernesto Michael Bakonyi schrieb am 06.09.2013 10:40: > Hi, > > before I aks my questions beyond I'd like to point out, that I don't > want to offend anybody of you devs investing a lot of (often unpayed) > time in bringing TYPO3 forward. Although I work with TYPO3 for some > years know as an integrator I'd just like know the inner processes of > the TYPO3-community regarding development. Until now I didn't find any > docs about them. So: > > First I wonder if the voting-feature within forge is taken into account > regarding the priority of bug-fixing issues. How do you > (core-)deveolpers decide which bugs are worth fixing and why? > > As example there's a bug posted 6 months ago with 21 votes: > > http://forge.typo3.org/issues/45859 > > which didn't get fixed until now. To strengthen the spirit of community > I think it would make sense to take the votings into account to a > greater extent. Then (as a non-developer) one has the feeling that my > voice is heared. > > Second I wonder if it's worth thinking about implementing a > bug-sponsoring-feature within forge. Maybe there's a functionality > within forge already, which could get activated. If you think it's worth > it, I could research that. We had that kind of "feature" within the old > bugtracker in Mantis. In Forge regarding some bugs I offered sponsoring > of bugfixings within the comments of an issue but never got asked to > sponsor it and I always wondered why. Maybe it's against the spirit of > TYPO3 paying for development but I don't think so. Everyone has to live > with ugly money ... But maybe sponsoring would be accepted to a greater > extent, if there was a feature where several people could "throw > together" some money if one dev says "I'll do it but I need X EUR for it")? > > Would be glad to hear some thoughts from you. > > Cheers, > Michael -- Ernesto Baschny TYPO3 CMS Core Developer Release Manager TYPO3 4.5 & 6.2 LTS TYPO3 .... inspiring people to share! Get involved: typo3.org From helmut.hummel at typo3.org Sat Sep 7 11:08:54 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Sat, 07 Sep 2013 11:08:54 +0200 Subject: [TYPO3-dev] Voting + sponsoring of bug-fixing in Forge In-Reply-To: References: Message-ID: Hi Michael, not answering your question, but tackling the bug you mention yourself. On 06.09.13 10:40, Michael Bakonyi wrote: > http://forge.typo3.org/issues/45859 > > which didn't get fixed until now. It is really a shame that a bug like this is not fixed yet. I encountered this right after release of 6.0 but simply had no time to tackle it myself. At least I managed to get this on topic again during the FAL code sprint some weeks ago and Oliver Hader picked up on that and made a preliminary patch, you can try out: https://review.typo3.org/22934 We did not find an existing ticket at this time, that is why Oliver opened a new one, which I now closed as duplicate. Kind regards, Helmut -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From helmut.hummel at typo3.org Sat Sep 7 11:12:36 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Sat, 07 Sep 2013 11:12:36 +0200 Subject: [TYPO3-dev] FAL: problem with "link" wizard and browse_links.php in TCA In-Reply-To: References: Message-ID: Hi Jochen, On 03.09.13 11:59, Jochen Rieger wrote: > My question: Is there any way to configure the TCA to make use of the > old behaviour in this case? No, there isn't. Kind regards, Helmut -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From helmut.hummel at typo3.org Sat Sep 7 11:35:48 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Sat, 07 Sep 2013 11:35:48 +0200 Subject: [TYPO3-dev] FAL: problem with "link" wizard and browse_links.php in TCA In-Reply-To: References: Message-ID: Hi Jochen, On 06.09.13 17:25, Jochen Rieger wrote: > But ? now of course chosing a file in the popup will fill the file:1234 > relation syntax into the input field. So ? I'm afraid, my question of > the initial post remains. > > The other option would be to use FAL relations and make use of the API > in the Plugin. But? the we would need to convert all the old file path > values to file id strings. You have a field with a link wizard configured in TCA. The link wizard is able to generate strings like this: "308 _blank css title foo=3" So a link string can consist of 5 parts: 1. Link (can be integer for link to internal page, ...) 2. HTML target attribute value 3. CSS class value 4. title attribute value 5. additional parameter(s) for the link This is like that since TYPO3 4.0 (or prior to that). So using the string directly in a without parsing has been wrong since then. However it worked before FAL, because links to files were just relative paths and now with FAL they are identified by the "file:" prefix followed by an integer id (as you pointed out). Long story short, if you use the proper typolink API, then the string properly gets converted to an "" tag taking all editorial features and FAL into account while being backwards compatible. You can use the PHP API like this: $databaseFieldString = '308 _blank css title foo=3'; $textToBeLinked = 'click me'; $html = $cObj->getTypoLink($textToBeLinked, $databaseFieldString); $html will contain sth. this: "click me Or you can render this with TypoScript lib.foo = TEXT lib.foo.field = label_field lib.foo.htmlSpecialChars = 1 lib.foo.typolink.parameter.field = link_field HTH Kind regards, Helmut -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From helmut.hummel at typo3.org Sat Sep 7 11:38:34 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Sat, 07 Sep 2013 11:38:34 +0200 Subject: [TYPO3-dev] FAL: problem with "link" wizard and browse_links.php in TCA In-Reply-To: References: Message-ID: On 06.09.13 17:37, Philipp Gampe wrote: > You have to add treatIdAsReference = 1 to the FILE object. I don't think so. There are no file reference (sys_file_reference) records in this case. The id inserted by the link wizard is the id of the original file record (in sys_file). Thus "treatIdAsReference = 1" (triggering a lookup in sys_file_reference) would be wrong. Kind regards, Helmut -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From philipp.gampe at typo3.org Sat Sep 7 12:40:39 2013 From: philipp.gampe at typo3.org (Philipp Gampe) Date: Sat, 07 Sep 2013 12:40:39 +0200 Subject: [TYPO3-dev] FAL: problem with "link" wizard and browse_links.php in TCA References: Message-ID: Hi Helmut, Helmut Hummel wrote: > There are no file reference (sys_file_reference) records in this case. > The id inserted by the link wizard is the id of the original file record > (in sys_file). > > Thus "treatIdAsReference = 1" (triggering a lookup in > sys_file_reference) would be wrong. You are right. Thanks for pointing this out. Best regards -- Philipp Gampe ? PGP-Key 0AD96065 ? TYPO3 UG Bonn/K?ln Documentation ? Active contributor TYPO3 CMS TYPO3 .... inspiring people to share! From g4-lisz at tonarchiv.ch Sun Sep 8 05:46:20 2013 From: g4-lisz at tonarchiv.ch (g4-lisz at tonarchiv.ch) Date: Sun, 08 Sep 2013 05:46:20 +0200 Subject: [TYPO3-dev] Subparts not substituted inT3 6.2? Message-ID: Hi there, i have an issue with simply substituting marked subparts in my template file:
    ###LOGO###

    Welcome

    Dummy content to be replaced.

    ###FOOTER###
    page.10.workOnSubpart=DOCUMENT_BODY page.10.subparts{ CONTENT References: Message-ID: On 09/08/2013 05:46 AM, g4-lisz at tonarchiv.ch wrote: > Hi there, > > i have an issue with simply substituting marked subparts in my template > file: > > >
    >
    ###LOGO###
    >
    > >
    > >

    Welcome

    >

    Dummy content to be replaced.

    > >
    >
    >
    ###FOOTER###
    >
    > > > page.10.workOnSubpart=DOCUMENT_BODY > > page.10.subparts{ > CONTENT MENU SUBMENU } Same issue on 6.1.4 - what am I missing here?! From Kohorst at citeq.de Mon Sep 9 10:59:20 2013 From: Kohorst at citeq.de (Britta Kohorst) Date: Mon, 09 Sep 2013 10:59:20 +0200 Subject: [TYPO3-dev] Antw: Re: Compat Layer in LTS 6.2 ? In-Reply-To: References: Message-ID: Hi Christop and Ernesto, thank you for your answers. That is very reassuring for us, it means we don't have to spend days mending extensions that are in the process of being re-coded all over anyhow. So, we will remove all include_once statements and let the autoloader do the job. But what about code parts like the following: reset($SOBE->include_once); while(list(,$INC_FILE)=each($SOBE->include_once)) {include_once($INC_FILE);} I must admit I don't know exactly what that code part does, but it can be found in TYPO3 back end modules (of the old kind) like dam, tt_news, cal or direct_mail - so seems to have been a standard behaviour. Can I delete those lines and will the autoloader do the work? And one more question: I assume the 'require_once' statements in backend modules must also be deleted for the extension to be runnable with TYPO3 6.2? Kind regards britta >>> Ernesto Baschny schrieb am Mittwoch, 4. September 2013 um 09:50 in Nachricht : > Britta Kohorst schrieb am 02.09.2013 09:24: > >> we would like to know if we can rely on the information given in the file > typo3/sysext/core/Migrations/Code/LegacyClassesForIde.php inside typo3src > 6.0.8.? >> >> It says that functions and classes deprecated since 6.0 will be removed in > 7.0 - which would mean that those classes and functions will still be > available in LTS 6.2! >> >> This is of vital importance for us since we have to migrate a lot of > extensions - that will be replaced by extbase- and fluid-based versions in the > future - but that will have to run with 6.2 to bridge the gap until the new > versions are in a stable production state. >> >> To put it in a nutshell: will we be able to run pibased extensions without > namespaces under LTS 6.2 ? Will the compat layer still be in place? > > Yes, all the old classnames and the "old way" of extensions to work > (pibase, no namespaces etc) will still be working as usual in TYPO3 6.2. > > One difference that might affect your extension is that in 6.2 we > removed the whole t3lib/ directory which actually contained the old > class-files. In order to use the "old class names" you simply have to > remove all "require_once" in your extension code and let the autoloader > resolve the names for you. > > The file you are mentioning (LegacyClassForIde) are just there for the > sake of IDE's like PhpStorm and Eclipse to understand the old class > names and be able to autocomplete method names etc. > > At PHP execution time the compatibility is done through so called "Class > Aliases", which are set up in files like these: > > typo3/sysext//Migrations/Code/ClassAliasMap.php > > We have an initiative working on an extension that will check your > current environment and report you stuff that you need to do while > migrating from 4.5 to 6.2: > > https://github.com/nxpthx/typo3-upgradereport (EXT:smoothmigration) > > This is still a work in progress, but one of the thing it checks is > exactly extensions that are using "require_once's" that need to be removed. > > Kind regards, > Ernesto From helmut.hummel at typo3.org Mon Sep 9 10:58:57 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Mon, 09 Sep 2013 10:58:57 +0200 Subject: [TYPO3-dev] Subparts not substituted inT3 6.2? In-Reply-To: References: Message-ID: On 08.09.13 16:39, g4-lisz at tonarchiv.ch wrote: > Same issue on 6.1.4 - what am I missing here?! This TypoScript works perfectly on master for me: page.30 = TEMPLATE page.30.template = TEXT page.30.template.value (
    ###LOGO###

    Welcome

    Dummy content to be replaced.

    ###FOOTER###
    ) page.30.workOnSubpart = DOCUMENT_BODY page.30.subparts { CONTENT < styles.content.get MENU = TEXT MENU.value = bar } Subparts are not replaced, if the object you assign is invalid (empty) CONTENT < not.existant.path So I guess that in your case the objects "styles.content.get" (maybe css_styled_content template not assigned), "lib.mainnav" and "lib.sidenav" (maybe ordering problem) are empty at the place you assign them to the subparts. Kind regards, Helmut -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From helmut.hummel at typo3.org Mon Sep 9 11:23:32 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Mon, 09 Sep 2013 11:23:32 +0200 Subject: [TYPO3-dev] Antw: Re: Compat Layer in LTS 6.2 ? In-Reply-To: References: Message-ID: Hi Britta, On 09.09.13 10:59, Britta Kohorst wrote: > thank you for your answers. That is very reassuring for us, it means we don't have to spend days mending extensions that are in the process of being re-coded all over anyhow. > So, we will remove all include_once statements and let the autoloader do the job. Great. > But what about code parts like the following: > > reset($SOBE->include_once); > while(list(,$INC_FILE)=each($SOBE->include_once)) {include_once($INC_FILE);} This includes files that must be loaded for the backend module to work. Since this is a loop over a property of the module object, it might be that core classes are included in this place, but it also might be that only extension classes are included, which would be no problem. So in this case you have to check the code where values are assigned to the include_once propety and remove core files from there. But since this is an include statement and not a require statement, it does not harm to not change anything because PHP just proceeds if the file is not found (in contrast to the require statements where you get a PHP fatal error). > And one more question: I assume the 'require_once' statements in backend modules must also be deleted for the extension to be runnable with TYPO3 6.2? Just to explain why it is needed to remove the require_once. Prior to the autoloading mechanism for classes, you had to maually needed to require the files where a class is defined before being able to use this class in your code. With autoloading you do not have to do a manual require any more, because the autoloader is triggered if PHP does not find a class and the autoloader then does require the requested class for you. But it does not harm, if you use a require_once on the class file, because then the autoloader is not triggered any more by PHP as the class is already defined. In TYPO3 many class files used to reside in the t3lib/ folder. For the namespace change all classes have been renamed and moved to new locations. For backwards compatibility we kept dummy files in the old location which did nothing else than requiring the file in the new location. By that, extensions that still did a manual require on the old class files in t3lib/ still worked because a file still existed in the old location. As of TYPO3 6.2 the old location does not exist any more and all extensions using require on files in the old location will cause a fatal error. So extension authors either have to adapt the require to include the new file, or (as sugessted) remove the require as the autoloader does the job anyway. For your own extensions I would recommend to use the autoloader mechanism as it makes the life easier. But it does not harm if you keep the require calls in your own code, as long as you do not move files around ;) HTH Kind regards, Helmut -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From stefan.franke at gmx.co.uk Mon Sep 9 14:03:38 2013 From: stefan.franke at gmx.co.uk (Stefan Franke) Date: Mon, 9 Sep 2013 14:03:38 +0200 (CEST) Subject: [TYPO3-dev] cObj in scheduler task (Extbase) Message-ID: Hello, is there a way to access $this->cObj in a scheduler task (Extbase!)? Thanks for your help! Kind regards, Stefan From patrick.schriner at diemedialen.de Mon Sep 9 15:30:44 2013 From: patrick.schriner at diemedialen.de (Patrick Schriner) Date: Mon, 09 Sep 2013 15:30:44 +0200 Subject: [TYPO3-dev] cObj in scheduler task (Extbase) References: Message-ID: Hello, the scheduler system runs in a backend context. You can create your cObj by simplying calling t3lib_div::makeInstance('tslib_cObj').* While you can do that some of the most used functions in tslib_cObj rely on being called from a frontend context. You can fake that too (e.g. using the extension oelib, or using some hand-crafted calls), but even then you will sometimes have "odd" behavior that you have to work around (e.g.: conditions in typoscript don't work as expected - because there is no frontend user, no groups...). As all those effects are hard to predict I'd recommend writing a scheduler task that calls an URL on your system (e.g. as an eid/ajax call), and write the real scheduler as a frontend extension. You'd have to take care of access restrictions and secure you eid extension script against being called from elsewhere, but that is manageable. Regards, Patrick * ContentObjectRenderer for TYPO3 > 6.0 On Mon, 09 Sep 2013 14:03:38 +0200, Stefan Franke wrote: > Hello, > is there a way to access $this->cObj in a scheduler task (Extbase!)? > > Thanks for your help! > > Kind regards, > Stefan From ernesto.baschny at typo3.org Mon Sep 9 15:50:32 2013 From: ernesto.baschny at typo3.org (Ernesto Baschny) Date: Mon, 09 Sep 2013 15:50:32 +0200 Subject: [TYPO3-dev] [TYPO3-core] TYPO3 6.0 and 6.1 patchlevel releases tomorrow Message-ID: Hi, we will release fixed patchlevel versions of the 6.0 and 6.1 branches *tomorrow* (September 10th). The goal is to fix the issues that came with 6.0.9 and 6.1.4, mainly related to the File Abstraction Layer new security policies. If you can, please test the current GIT versions of both branches (6.0-dev and 6.1-dev), which already contain the patches to solve the most urgent issues already. If you find other still unsolved regressions (things that worked in 6.1.3 and 6.0.8 and broke with the security releases from last week) please first check if they haven't been reported before and then open up new issues in the issue tracker [1]. Hopefully the releases tomorrow will be again rocket stable. Thanks for your help! Kind regards, Ernesto [1] http://forge.typo3.org/projects/typo3v4-core/issues -- Ernesto Baschny TYPO3 CMS Core Developer Release Manager TYPO3 4.5 & 6.2 LTS TYPO3 .... inspiring people to share! Get involved: typo3.org From stefan.franke at gmx.co.uk Mon Sep 9 16:29:55 2013 From: stefan.franke at gmx.co.uk (Stefan Franke) Date: Mon, 9 Sep 2013 16:29:55 +0200 (CEST) Subject: [TYPO3-dev] cObj in scheduler task (Extbase) In-Reply-To: References: , Message-ID: > the scheduler system runs in a backend context. You can create your cObj > by simplying calling t3lib_div::makeInstance('tslib_cObj').* > * ContentObjectRenderer for TYPO3 > 6.0 The keyword "ContentObjectRenderer" lead me to this page: http://pastebin.com/znXm9EhM It's working now, thanks! :) Kind regards, Stefan From stefan.franke at gmx.co.uk Mon Sep 9 17:59:49 2013 From: stefan.franke at gmx.co.uk (Stefan Franke) Date: Mon, 9 Sep 2013 17:59:49 +0200 (CEST) Subject: [TYPO3-dev] accessing plugin configuration in scheduler task (Extbase) Message-ID: Hello, is it possible to access the plugin configuration setup from within a scheduler task (Extbase, TYPO3 >= 6.0)? Thanks for your help! Kind regards, Stefan From lorenz-typo3 at visol.ch Mon Sep 9 18:56:56 2013 From: lorenz-typo3 at visol.ch (Lorenz Ulrich) Date: Mon, 09 Sep 2013 18:56:56 +0200 Subject: [TYPO3-dev] accessing plugin configuration in scheduler task (Extbase) In-Reply-To: References: Message-ID: Hi Stefan Are you using an Extbase CommandController? There it is quite easy: $settings = $this->configurationManager->getConfiguration(Tx_Extbase_Configuration_ConfigurationManagerInterface::CONFIGURATION_TYPE_SETTINGS, 'myExt', 'myExt'); If you didn't have already, you need to have an instance of the configurationManager: /** * @var Tx_Extbase_Configuration_ConfigurationManagerInterface * @inject */ protected $configurationManager; Best regards, Lorenz Am 09.09.2013 17:59, schrieb Stefan Franke: > Hello, > is it possible to access the plugin configuration setup from within a scheduler task (Extbase, TYPO3 >= 6.0)? > > Thanks for your help! > > Kind regards, > Stefan > From g4-lisz at tonarchiv.ch Mon Sep 9 19:13:05 2013 From: g4-lisz at tonarchiv.ch (g4-lisz at tonarchiv.ch) Date: Mon, 09 Sep 2013 19:13:05 +0200 Subject: [TYPO3-dev] Subparts not substituted inT3 6.2? In-Reply-To: References: Message-ID: On 09/09/2013 10:58 AM, Helmut Hummel wrote: > On 08.09.13 16:39, g4-lisz at tonarchiv.ch wrote: > >> Same issue on 6.1.4 - what am I missing here?! > > This TypoScript works perfectly on master for me: > > page.30 = TEMPLATE > page.30.template = TEXT > page.30.template.value ( > >
    >
    ###LOGO###
    >
    > >
    > >

    Welcome

    >

    Dummy content to be replaced.

    > >
    >
    >
    ###FOOTER###
    >
    > > ) > page.30.workOnSubpart = DOCUMENT_BODY > page.30.subparts { > CONTENT < styles.content.get > MENU = TEXT > MENU.value = bar > } > > Subparts are not replaced, if the object you assign is invalid (empty) > > CONTENT < not.existant.path > > So I guess that in your case the objects "styles.content.get" (maybe > css_styled_content template not assigned), "lib.mainnav" and > "lib.sidenav" (maybe ordering problem) are empty at the place you > assign them to the subparts. > > > Kind regards, > Helmut > Hi Helmut Thank you very much. With your help i was able to isolate the problem... page.30.workOnSubpart = DOCUMENT_BODY page.30.subparts { CONTENT = TEXT CONTENT.value = foo MENU = TEXT MENU.value = bar } This replaced the tags as expected. Now i wonder why styles.content.get returns nothing. There IS content in the "normal" column of the page! Maye there is something wrong with some extension? Best wishes, Till From dmitry.dulepov at gmail.com Tue Sep 10 08:32:20 2013 From: dmitry.dulepov at gmail.com (Dmitry Dulepov) Date: Tue, 10 Sep 2013 10:32:20 +0400 Subject: [TYPO3-dev] cObj in scheduler task (Extbase) In-Reply-To: References: Message-ID: Hi! Stefan Franke wrote: > is there a way to access $this->cObj in a scheduler task (Extbase!)? If you write what the original problem is, may be we can tell you how to solve it without using cObj :) -- Dmitry Dulepov Today is a good day to have a good day. From stefan.franke at gmx.co.uk Tue Sep 10 09:57:22 2013 From: stefan.franke at gmx.co.uk (Stefan Franke) Date: Tue, 10 Sep 2013 09:57:22 +0200 (CEST) Subject: [TYPO3-dev] cObj in scheduler task (Extbase) In-Reply-To: References: , Message-ID: Hi Dmitry, I need $cObj->enablefields in an SQL-statement in the scheduler. I guess using an eID-mechanism would be the way to go regarding the use of ressources, wouldn't it? Kind regards, Stefan > Gesendet: Dienstag, 10. September 2013 um 08:32 Uhr > Von: "Dmitry Dulepov" > An: typo3-dev at lists.typo3.org > Betreff: Re: [TYPO3-dev] cObj in scheduler task (Extbase) > > Hi! > > Stefan Franke wrote: > > is there a way to access $this->cObj in a scheduler task (Extbase!)? > > If you write what the original problem is, may be we can tell you how to > solve it without using cObj :) > > -- > Dmitry Dulepov > > Today is a good day to have a good day. > _______________________________________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev > From invisible.kinder at gmail.com Tue Sep 10 11:31:45 2013 From: invisible.kinder at gmail.com (Viktor Livakivskyi) Date: Tue, 10 Sep 2013 11:31:45 +0200 Subject: [TYPO3-dev] =?utf-8?q?cObj_in_scheduler_task_=28Extbase=29?= References: Message-ID: Hi, Stefan. > I need $cObj->enablefields in an SQL-statement in the scheduler. I guess using an eID-mechanism would be the way to go regarding the use of ressources, wouldn't it? Take a look at class BackendUtility. Ut has BEenableFields() method, which server perfect for this case. Also I recommend to go through all of it's methods to learn, what you can do in BE without TSFE or cObj creation. From jigal.van.hemert at typo3.org Tue Sep 10 11:36:07 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Tue, 10 Sep 2013 11:36:07 +0200 Subject: [TYPO3-dev] cObj in scheduler task (Extbase) In-Reply-To: References: , Message-ID: Hi, On 10-9-2013 9:57, Stefan Franke wrote: > I need $cObj->enablefields in an SQL-statement in the scheduler. I > guess using an eID-mechanism would be the way to go regarding the use > of ressources, wouldn't it? \TYPO3\CMS\Backend\Utility\BackendUtility::BEenableFields($table) (t3lib_BEfunc::BEenableFields($table) in TYPO3 4.x) \TYPO3\CMS\Backend\Utility\BackendUtility::deleteClause($table) (t3lib_BEfunc::deleteClause($table) in TYPO3 4.x) as a combination will have the same functionality. -- Jigal van Hemert TYPO3 CMS Active Contributor TYPO3 .... inspiring people to share! Get involved: typo3.org From stefan.franke at gmx.co.uk Tue Sep 10 11:48:04 2013 From: stefan.franke at gmx.co.uk (Stefan Franke) Date: Tue, 10 Sep 2013 11:48:04 +0200 (CEST) Subject: [TYPO3-dev] cObj in scheduler task (Extbase) In-Reply-To: References: , , Message-ID: Hi guys! > \TYPO3\CMS\Backend\Utility\BackendUtility can't test the suggested solutions right now, but they do indeed look very promising! :) Thanks very much, Stefan From daniel.kluhs at gmx.net Tue Sep 10 12:03:38 2013 From: daniel.kluhs at gmx.net (Daniel Kluhs) Date: Tue, 10 Sep 2013 12:03:38 +0200 (CEST) Subject: [TYPO3-dev] Label and tooltip attributes of own page doctypes Message-ID: Hi, I hope im in the right mailing list. I have a problem if i add an custom page doctype it is not possible to modify the title and the tooltip of the toolbar button. (It is not very important but nice to have) The Problem is it seems that this attributes are mapped with an hardcoded array. ExtdirectTreeDataProvider.php: 115 public function getNodeTypes() { 116 $map = array( 117 1 => 'LLL:EXT:lang/locallang_tca.xlf:doktype.I.0', 118 3 => 'LLL:EXT:cms/locallang_tca.xlf:pages.doktype.I.8', 119 4 => 'LLL:EXT:cms/locallang_tca.xlf:pages.doktype.I.2', 120 6 => 'LLL:EXT:cms/locallang_tca.xlf:pages.doktype.I.4', 121 7 => 'LLL:EXT:cms/locallang_tca.xlf:pages.doktype.I.5', 122 199 => 'LLL:EXT:cms/locallang_tca.xlf:pages.doktype.I.7', 123 254 => 'LLL:EXT:lang/locallang_tca.xlf:doktype.I.folder', 124 255 => 'LLL:EXT:lang/locallang_tca.xlf:doktype.I.2' 125 ); 126 $doktypes = \TYPO3\CMS\Core\Utility\GeneralUtility::trimExplode(',', $GLOBALS['BE_USER']->getTSConfigVal('options.pageTree.doktypesToShowInNewPageDragArea')); 127 $output = array(); 128 $allowedDoktypes = \TYPO3\CMS\Core\Utility\GeneralUtility::trimExplode(',', $GLOBALS['BE_USER']->groupData['pagetypes_select']); 129 $isAdmin = $GLOBALS['BE_USER']->isAdmin(); 130 foreach ($doktypes as $doktype) { 131 if (!$isAdmin && !in_array($doktype, $allowedDoktypes)) { 132 continue; 133 } 134 $label = $GLOBALS['LANG']->sL($map[$doktype], TRUE); 135 $spriteIcon = \TYPO3\CMS\Backend\Utility\IconUtility::getSpriteIconClasses($GLOBALS['TCA']['pages']['ctrl']['typeicon_classes'][$doktype]); 136 $output[] = array( 137 'nodeType' => $doktype, 138 'cls' => 'typo3-pagetree-topPanel-button', 139 'iconCls' => $spriteIcon, 140 'title' => $label, 141 'tooltip' => $label 142 ); 143 } 144 return $output; 145 } Maybe someone has an idee how to make this editable. Or maybe if $map[$doktype] is empty it's possible to use the "doctype name" as fallback. ($TCA['pages_language_overlay']['columns']['doktype']['config']['items'][$foo][0]) mfg Daniel Kluhs From gmohrmann at gmx.de Tue Sep 10 15:53:10 2013 From: gmohrmann at gmx.de (Gerrit Mohrmann) Date: Tue, 10 Sep 2013 15:53:10 +0200 Subject: [TYPO3-dev] =?utf-8?q?_Re=3A_=5BTYPO3-core=5D_TYPO3_6=2E0_and_6?= =?utf-8?q?=2E1_patchlevel_releases_tomorrow?= References: Message-ID: For Webdav I initialize an BackendUser with $GLOBALS['BE_USER'] = t3lib_div::makeInstance('t3lib_tsfeBeUserAuth') <...> //Get the fileMounts: $GLOBALS['BE_USER']->fetchGroupData(); $storages = $GLOBALS['BE_USER']->getFileStorages(); foreach ($storages as $storageObject) { $storageMounts = $storageObject->getFileMounts(); if (count($storageMounts)) { foreach ($storageMounts as $storageMountInfo) { $fileMounts[] = array( 'path' => $storageMountInfo['folder']->getPublicUrl(), 'name' => $storageMountInfo['title'], ); } } } It's fine bevor the security fix, after it is broken. When debuging I can see the Storage but not the Filemounts. Permissions are set in UserGroupTS and for testing in UserTS too: permissions.file.default { addFile = 1 .. } permissions.file.storage.1 { addFile = 1 .. } Or have I todo more to see the Filemounts again? Issue: http://forge.typo3.org/issues/51831 From helmut.hummel at typo3.org Tue Sep 10 19:20:54 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Tue, 10 Sep 2013 19:20:54 +0200 Subject: [TYPO3-dev] [TYPO3-core] TYPO3 6.0 and 6.1 patchlevel releases tomorrow In-Reply-To: References: Message-ID: On 10.09.13 15:53, Gerrit Mohrmann wrote: > For Webdav I initialize an BackendUser with Can you explain what you are doing exactly? In what context do you initialize the backend user? And for what purpose do you need the mount points? Thanks. Kind regards, Helmut -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From gmohrmann at gmx.de Wed Sep 11 01:12:24 2013 From: gmohrmann at gmx.de (Gerrit Mohrmann) Date: Wed, 11 Sep 2013 01:12:24 +0200 Subject: [TYPO3-dev] =?utf-8?q?=5BTYPO3-core=5D_TYPO3_6=2E0_and_6=2E1_patc?= =?utf-8?q?hlevel_releases_tomorrow?= References: Message-ID: > Can you explain what you are doing exactly? > In what context do you initialize the backend user? > And for what purpose do you need the mount points? Hi Helmut, I have posted the answer in the forge issue. http://forge.typo3.org/issues/51831 best regards Gerrit From robert.gonda at gmail.com Wed Sep 11 10:41:38 2013 From: robert.gonda at gmail.com (Robert Gonda) Date: Wed, 11 Sep 2013 10:41:38 +0200 Subject: [TYPO3-dev] =?utf-8?q?_EXT_Extension_uploader_=28extension=5Fuplo?= =?utf-8?q?ader=29_-_no_upload_to_TER?= Message-ID: Typo3 6.1.4 Extension Uploader, extension_uploader 1.0.9 PHP SOAP is installed Extension Uploader can not upload to TER, still return message: Connection error when trying to contact the repository. Where is problem? From typo3ml at schams.net Wed Sep 11 11:53:01 2013 From: typo3ml at schams.net (Michael Schams) Date: Wed, 11 Sep 2013 19:53:01 +1000 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: On 11/09/13 18:41, Robert Gonda wrote: > Extension Uploader can not upload to TER, still return message: > Connection error when trying to contact the repository. Two possibilities: (1) Did you set a valid TYPO3 dependency (min and max version) in the extension you try to upload? http://typo3.org/news/article/announcing-ter-cleanup-process/ http://typo3.org/news/article/ter-new-requirement-for-extension-upload/ (2) The new version of TER breaks uploads by Extension Uploader If the new version of TER [1] has been installed on typo3.org recently, it is possible that EXT:extension_uploader [2] does not work any more. I reported this on forge: http://forge.typo3.org/issues/51645 As I see it, this is caused by TER's behaviour how to deal with SOAP requests and in particular, the TYPO3 dependency settings. If dependencies were passed as an object rather than an array (which is the case when you use EXT:extension_uploader), TER can not extract the information and rejects the upload. I also created a patch, but it has to be processed, reviewed, merged and installed on typo3.org by someone :-) Cheers Michael From jigal.van.hemert at typo3.org Wed Sep 11 12:24:10 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Wed, 11 Sep 2013 12:24:10 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi, On 11-9-2013 11:53, Michael Schams wrote: > On 11/09/13 18:41, Robert Gonda wrote: > >> Extension Uploader can not upload to TER, still return message: >> Connection error when trying to contact the repository. > > Two possibilities: > > (1) Did you set a valid TYPO3 dependency (min and max version) in the > extension you try to upload? > > http://typo3.org/news/article/announcing-ter-cleanup-process/ > http://typo3.org/news/article/ter-new-requirement-for-extension-upload/ > > (2) The new version of TER breaks uploads by Extension Uploader > > If the new version of TER [1] has been installed on typo3.org recently, > it is possible that EXT:extension_uploader [2] does not work any more. I > reported this on forge: > > http://forge.typo3.org/issues/51645 > > As I see it, this is caused by TER's behaviour how to deal with SOAP > requests and in particular, the TYPO3 dependency settings. If > dependencies were passed as an object rather than an array (which is the > case when you use EXT:extension_uploader), TER can not extract the > information and rejects the upload. Can you explain why this should be a bug in TER and not in Extension Uploader? The EM in 4.5-4.7 works with dependencies set in the extension when doing an upload. If the handling in Extension Uploader is different it looks like a problem in Extension Uploader. Furthermore, TER returns an error description. This is shown in the EM, but apparently not in Extension Uploader. This seems also a bug to me in that tool. What do you think? -- Jigal van Hemert TYPO3 CMS Active Contributor TYPO3 .... inspiring people to share! Get involved: typo3.org From dmitry.dulepov at gmail.com Wed Sep 11 12:40:20 2013 From: dmitry.dulepov at gmail.com (Dmitry Dulepov) Date: Wed, 11 Sep 2013 14:40:20 +0400 Subject: [TYPO3-dev] cObj in scheduler task (Extbase) In-Reply-To: References: , , Message-ID: Hi! Stefan Franke wrote: >> \TYPO3\CMS\Backend\Utility\BackendUtility > > can't test the suggested solutions right now, but they do indeed look very promising! :) They are the way to go in BE. So you just do: 'your where here...' . BackendUtility::deleteClause(...) . BackendUtility::BEenableField(...) -- Dmitry Dulepov Today is a good day to have a good day. From typo3ml at schams.net Wed Sep 11 13:42:48 2013 From: typo3ml at schams.net (Michael Schams) Date: Wed, 11 Sep 2013 21:42:48 +1000 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: On 11/09/13 20:24, Jigal van Hemert wrote: [...] >> If the new version of TER [1] has been installed on typo3.org recently, >> it is possible that EXT:extension_uploader [2] does not work any more. I >> reported this on forge: http://forge.typo3.org/issues/51645 [...] > Can you explain why this should be a bug in TER and not in Extension > Uploader? I expected this question ;-) ...and it's quite legitimate. It took me a while to dig into the code, before I decided, I create a patch for TER and not for EXT:extension_uploader. When EU (Extension Uploader) creates $data for the SOAP request, which includes the TYPO3 dependency, it sends the dependencies as an object, which I think is legitimate (the WSDL file does not specify this due to the cascading). See file "Classes/Upload/ExtensionDataCollector.php" Methods getDataForExtension() and getDependenciesArray() So, from TER's view, it receives a SOAP call such as: uploadExtension ($accountData, $extensionInfoData, $filesData) Where $extensionInfoData can be something like: $extensionInfoData->technicalData->dependencies ...and type: stdClass (not array only). My patch allows both data types: array and stdClass. If the SOAP request contains a dependency of type stdClass (object), it converts it to an array and then processes it as usual. > Furthermore, TER returns an error description. This is shown in the EM, > but apparently not in Extension Uploader. This seems also a bug to me in > that tool. That's right and very annoying. However, not relevant to this discussion :-) > What do you think? I think, I am not a hard-core developer and not the author of EXT:extension_uploader. I am happy to be proven wrong if my approach is not ideal. But I would also like to enable the TYPO3 community to publish their extensions at TER (again) as soon as possible - given the fact TYPO3 version 6.0 and 6.1 does not offer such a function out-of-the-box, which means, we rely on CLI tools, the TER frontend and external extensions such as EXT:extension_uploader. Cheers Michael From pet at biba.uni-bremen.de Wed Sep 11 13:49:47 2013 From: pet at biba.uni-bremen.de (Tom Peters) Date: Wed, 11 Sep 2013 11:49:47 +0000 Subject: [TYPO3-dev] Replacement for loadTCA Message-ID: Hello, I'm trying to build a new Content Extension in Typo3 6.2. I got trouble to update the TCA[tt_content][types][pluginname][showitem] without using the deprecated "loadTCA". If the item TCA[tt_content][types][pluginname] is set I'm able to use "addToAllTCAtypes('tt_content', $showitemtext, 'pluginname')". Is there a good way to set TCA[tt_content][types][pluginname] without using "loadTCA"? Yours sincerely Tom Peters From jigal.van.hemert at typo3.org Wed Sep 11 14:33:02 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Wed, 11 Sep 2013 14:33:02 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi, On 11-9-2013 13:42, Michael Schams wrote: > On 11/09/13 20:24, Jigal van Hemert wrote: >> Can you explain why this should be a bug in TER and not in Extension >> Uploader? > > I expected this question ;-) ...and it's quite legitimate. It took me a > while to dig into the code, before I decided, I create a patch for TER > and not for EXT:extension_uploader. > > When EU (Extension Uploader) creates $data for the SOAP request, which > includes the TYPO3 dependency, it sends the dependencies as an object, > which I think is legitimate (the WSDL file does not specify this due to > the cascading). > > See file "Classes/Upload/ExtensionDataCollector.php" > Methods getDataForExtension() and getDependenciesArray() Take a look in the EM of 4.7 and you'll find in sysext/em/classes/connection/tx_em_Connection_Ter::uploadToTER that the entire data block is an array. I've only taken a quick look, but I couldn't see a single object in the extension data. Of course EU can do as it pleases, but if it sends data as an object while TER expects an array (even thought the WSDL is inconclusive about it) and the old EM code clearly sends it as an array, the conclusion is simple IMO. >> Furthermore, TER returns an error description. This is shown in the EM, >> but apparently not in Extension Uploader. This seems also a bug to me in >> that tool. > > That's right and very annoying. However, not relevant to this discussion > :-) Well, it shows that EU doesn't seem to follow the situation in the old EMs in more than one aspect. If the functionality was the same (or better) than the code in the old EM both problems would not have occured. -- Jigal van Hemert TYPO3 CMS Active Contributor TYPO3 .... inspiring people to share! Get involved: typo3.org From info at cybercraft.de Wed Sep 11 15:26:00 2013 From: info at cybercraft.de (JoH asenau) Date: Wed, 11 Sep 2013 15:26:00 +0200 Subject: [TYPO3-dev] Invitation to the Gridelements weekend from Sep. 13th to 15th In-Reply-To: References: Message-ID: Am 04.09.2013 10:06, schrieb JoH asenau: > Hi folks! > > Save the date: http://typo3.org/events/code-sprints/gridelements-weekend/ > > CU there :-) > > Joey > Everybody who did not manage to join the #TYPO3 #Gridelements Workshop next weekend, feel free to vote for part III. http://t.co/QNQi0o4kpx 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 lolli at schwarzbu.ch Wed Sep 11 20:45:03 2013 From: lolli at schwarzbu.ch (Christian Kuhn) Date: Wed, 11 Sep 2013 20:45:03 +0200 Subject: [TYPO3-dev] Replacement for loadTCA In-Reply-To: References: Message-ID: Hey, On 09/11/2013 01:49 PM, Tom Peters wrote: > I'm trying to build a new Content Extension in Typo3 6.2. > I got trouble to update the TCA[tt_content][types][pluginname][showitem] without using the deprecated "loadTCA". > If the item TCA[tt_content][types][pluginname] is set I'm able to use "addToAllTCAtypes('tt_content', $showitemtext, 'pluginname')". > Is there a good way to set TCA[tt_content][types][pluginname] without using "loadTCA"? addToAllTCAtypes() works exactly as before. You can just remove all loadTCA() calls, there is no substitution. With 6.1, TCA is always fully loaded, the need to call loadTCA() is gone. Beside the removal of loadTCA(), there is another neat improvement: If defining TCA for a new table, the whole TCA array is in one file now, so 'ctrl' section and 'columns' are now combined. See [1] for documentation and see core extensions for examples [2] [3]. This way, you don't need this weird "dynamicConfigFile" construct anymore. Adding a file named like your db-table to Configuration/TCA in your extension that returns the full TCA array of this table does the job, it will be automatically loaded by the system. You only need to call API methods of \TYPO3\CMS\Core\Utility\ExtensionManagementUtility like addToAllTCAtypes() if you add fields or need to mangle TCA of existing tables in ext_tables.php, just like before. If changing TCA of a table that a different extension defines in the first place, you only need to take care that the extension defining the main table is registered in LocalConfiguration extListArray() *before* your extending extension. This is also identical to the previous behaviour. As usual, this stuff is fully backwards compatible, you could still use the old scheme with ctrl section in ext_tables and the rest in some tca.php file or something, if you need to stay compatible with older core versions. You can also still call loadTCA(), it is just deprecated and the method itself is empty (it does nothing) because the TCA loading is always done during bootstrap. Regards Christian [1] http://docs.typo3.org/typo3cms/TCAReference/WhatIsTca/Index.html [2] system extension sys_note: typo3/sysext/sys_note/Configuration/TCA/sys_note.php [3] system extension core: typo3/sysext/core/Configuration/TCA/ From ernesto.baschny at typo3.org Wed Sep 11 22:15:05 2013 From: ernesto.baschny at typo3.org (Ernesto Baschny) Date: Wed, 11 Sep 2013 22:15:05 +0200 Subject: [TYPO3-dev] [TYPO3-core] TYPO3 6.0 and 6.1 patchlevel releases tomorrow In-Reply-To: References: Message-ID: Hi, yes, tomorrow means *tomorrow* (as of today). :) We discovered some more trouble yesterday, and had to fix some last standing issues with the 6.0 and 6.1 today. We've packages a snapshot for you to try out what we will release tomorrow. Check if it fixes most prominent regressions (in the file abstraction layer area) if you have been affected: 6.0 Snapshot: https://sourceforge.net/projects/typo3/files/TYPO3%20Source%20and%20Dummy/TYPO3%206.0-snapshot-20130911/ 6.1 Snapshot: https://sourceforge.net/projects/typo3/files/TYPO3%20Source%20and%20Dummy/TYPO3%206.1-snapshot-20130911/ Or, if you prefer to check it out directly from git: $ git clone -b TYPO3_6-0 git://git.typo3.org/Packages/TYPO3.CMS.git typo3_src $ git clone -b TYPO3_6-1 git://git.typo3.org/Packages/TYPO3.CMS.git typo3_src So now the final and definitive plan is to release 6.0.10 and 6.1.5 tomorrow (if nothing notable pops up in the way). Kind regards, Ernesto Am 2013-09-09 15:50, schrieb Ernesto Baschny: > Hi, > > we will release fixed patchlevel versions of the 6.0 and 6.1 branches > *tomorrow* (September 10th). The goal is to fix the issues that came > with 6.0.9 and 6.1.4, mainly related to the File Abstraction Layer new > security policies. > > If you can, please test the current GIT versions of both branches > (6.0-dev and 6.1-dev), which already contain the patches to solve the > most urgent issues already. > > If you find other still unsolved regressions (things that worked in > 6.1.3 and 6.0.8 and broke with the security releases from last week) > please first check if they haven't been reported before and then open up > new issues in the issue tracker [1]. > > Hopefully the releases tomorrow will be again rocket stable. > > Thanks for your help! > > Kind regards, > Ernesto > > [1] http://forge.typo3.org/projects/typo3v4-core/issues > > -- Ernesto Baschny TYPO3 CMS Core Developer Release Manager TYPO3 4.5 & 6.2 LTS TYPO3 .... inspiring people to share! Get involved: typo3.org From typo3ml at schams.net Thu Sep 12 03:20:36 2013 From: typo3ml at schams.net (Michael) Date: Thu, 12 Sep 2013 11:20:36 +1000 Subject: [TYPO3-dev] =?utf-8?q?EXT_Extension_uploader_=28extension=5Fuploa?= =?utf-8?q?der=29_-_no_upload_to_TER?= In-Reply-To: References: Message-ID: On 2013-09-11 22:33, Jigal van Hemert wrote: [...] > Take a look in the EM of 4.7 and you'll find in > sysext/em/classes/connection/tx_em_Connection_Ter::uploadToTER that > the entire data block is an array. I've only taken a quick look, but I > couldn't see a single object in the extension data. Ok, so the bottom line is: the author of EXT:extension_uploader has to update his extension. As long as this is not done, the extension can not be used for publishing extensions at TER. Besides CLI tools such Typo3ExtensionUtils, are there any other (working) solutions to upload extensions to TER with a TYPO3 CMS 6.x system available? Cheers Michael From franz at ttproducts.de Thu Sep 12 07:42:10 2013 From: franz at ttproducts.de (Franz Holzinger) Date: Thu, 12 Sep 2013 07:42:10 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Le 11. 09. 13 10:41, Robert Gonda a ?crit : > Typo3 6.1.4 > Extension Uploader, extension_uploader 1.0.9 PHP SOAP is installed > > Extension Uploader can not upload to TER, still return message: > Connection error when trying to contact the repository. > > Where is problem? I have the same problem with the ext1 extension upload tool and t3xutils. This did work fine until August 2013. ---------------------------------------------- php /var/www/web50/web/typo3conf/ext/ext1/Cool/Modules/Ext/Services/../../Typo3ExtensionUtils/bin/t3xutils.php upload mytypo3useraccount mysecretpassword myextensionkey ' My Upload Comment ' /var/www/web50/web/trunk/typo3/ext/myextensionkey ---------------------------------------------- The words mytypo3useraccount, mysecretpassword and myextensionkey are not real and must be replaced by your TYPO3 user account, password and extension key. This results in an error message: ---------------------------------------------- SOAP-Error: Internal Server Error ---------------------------------------------- Yesterday I got this error message: ---------------------------------------------- SOAP-Error: Could not connect to host ---------------------------------------------- - Franz From gregor at a-mazing.de Thu Sep 12 08:18:11 2013 From: gregor at a-mazing.de (Gregor Hermens) Date: Thu, 12 Sep 2013 08:18:11 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER References: Message-ID: Hi Michael, Michael wrote: > Besides CLI tools such Typo3ExtensionUtils, are there any other > (working) solutions to upload extensions to TER with a TYPO3 CMS 6.x > system available? you can upload your extensions on http://typo3.org/extensions/extension-keys/ You have to login first, of course... hth Gregor -- http://www.a-mazing.de/ | Certified TYPO3 Integrator From tomita.militaru at gmail.com Thu Sep 12 09:14:03 2013 From: tomita.militaru at gmail.com (=?UTF-8?B?VG9tacWjxIMgTUlMSVRBUlU=?=) Date: Thu, 12 Sep 2013 10:14:03 +0300 Subject: [TYPO3-dev] Typo3QuerySettings - limits to the query result by cruser_id Message-ID: Hello, I want to limit the query by cruser_id = $someUserId in frontend from the query settings, but I don't know if that is possible. Is there a way to extend Typo3QuerySettings so that I could use something like $querySettings->setCruserId($someUserId )? Thanks, Tomita From robert.gonda at gmail.com Thu Sep 12 11:22:53 2013 From: robert.gonda at gmail.com (Robert Gonda) Date: Thu, 12 Sep 2013 11:22:53 +0200 Subject: [TYPO3-dev] =?utf-8?q?EXT_Extension_uploader_=28extension=5Fuploa?= =?utf-8?q?der=29_-_no_upload_to_TER?= References: Message-ID: This works - (1) Did you set a valid TYPO3 dependency... http://typo3.org/news/article/ter-new-requirement-for-extension-upload/ Thank You! From ernesto.baschny at typo3.org Thu Sep 12 11:58:16 2013 From: ernesto.baschny at typo3.org (Ernesto Baschny) Date: Thu, 12 Sep 2013 11:58:16 +0200 Subject: [TYPO3-dev] [TYPO3-core] Announcing TYPO3 CMS 6.1.5, 6.0.10, 4.7.15 and 4.5.30 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear TYPO3 Enthusiasts, the TYPO3 Community has just released TYPO3 CMS versions 6.1.5, 6.0.10, 4.7.15 and 4.5.30 which are now ready for you to download. All versions are maintenance releases and contain only bug fixes. Thanks to all involved in fixing these bugs! Your help is highly appreciated. Note: * Releases 6.1.5 and 6.0.10 contain important fixes to regression which were introduced in the latest security releases (6.1.4 and 6.0.9), so upgrading is highly recommended. * Releases 4.7.15 and 4.5.30 are merely bug fix releases, and increased compatibility with browsers and MySQL 5.5. The packages can be downloaded here: http://typo3.org/download/ For details about the releases, please see: http://typo3.org/news/article/typo3-cms-615-6010-4715-and-4530-released/ MD5 checksums: 8f82cb74a965c1c290dde53779193f8b blankpackage-6.1.5.tar.gz bfcc6b6e063abcac9f290cac14c6e20e blankpackage-6.1.5.zip 3fbcaa8acc55fe48a1266c7feb1ee5f6 dummy-6.1.5.tar.gz f0d36c82207a5f5d2cecd96d4e63488e dummy-6.1.5.zip b9dbbb832e4c05ef4c36cbdf717a36d2 governmentpackage-6.1.5.tar.gz 5a3bd1f0ec66b2e0dc41d6e6ad5d460e governmentpackage-6.1.5.zip 918dbd1e82e1223e1d6b34cf4cca8cdc introductionpackage-6.1.5.tar.gz 34e97ad90124de1b63efcd4e2c5b5425 introductionpackage-6.1.5.zip a042bf28abf2f4078be2b67c7e76dc2a typo3_src+dummy-6.1.5.zip fa124e639e91ecade837f209488de5d2 typo3_src-6.1.5.tar.gz 98c6b08e1ab3e94a4e9aafe06323ab03 typo3_src-6.1.5.zip c1f9c8f49a6876fe6803da7ab0d264bc blankpackage-6.0.10.tar.gz 663ce4dec08a9d95004d67097e7d26f2 blankpackage-6.0.10.zip a5d2eda7d6868f404cc1db8983711b26 dummy-6.0.10.tar.gz f851231ddb9f447800cd6ca25ddf5517 dummy-6.0.10.zip 97f2219eab4b5d70134d014a6991d84a typo3_src+dummy-6.0.10.zip a026fff3b4713f331767ae780a94e3c2 typo3_src-6.0.10.tar.gz 2228126a7ad47c247915b31509c9decb typo3_src-6.0.10.zip 67812b6a9c4379096fa96e902fd61123 blankpackage-4.7.15.tar.gz 6c2a4c0f7f8591b4d5ce8a5ebccc3225 blankpackage-4.7.15.zip d862b37fbaf81f066aa94f5f8748dfbd dummy-4.7.15.tar.gz f9f0158da38e13340029229ccf0dacc7 dummy-4.7.15.zip 658da63205cc83f1232b0db4d416573e typo3_src+dummy-4.7.15.zip 7c79e4c20308e3c780d228483c833cb3 typo3_src-4.7.15.tar.gz 6ff214be69c91eaf3a9c1997311f3aa0 typo3_src-4.7.15.zip 3f97c578e8701ae1bbcd546e021668c5 blankpackage-4.5.30.tar.gz 1a39d28ad0b2a16f43f5f3c699255d36 blankpackage-4.5.30.zip 7a5d905713d1f5115c47f35d54e973c8 dummy-4.5.30.tar.gz db975ea6016a8f69b2b5483b3d13d90c dummy-4.5.30.zip ee8af6ff3375bbffa6071c062545e0f8 introductionpackage-4.5.30.tar.gz 0ab7ef2680a2d3244975b04b345697cd introductionpackage-4.5.30.zip af93220f0d84f2ab29469dea432b647e typo3_src+dummy-4.5.30.zip 7cee9cec79f17015fce178ea18bff0c4 typo3_src-4.5.30.tar.gz cd1efb804d82c879fa034e5ca35b4b59 typo3_src-4.5.30.zip Cheers, Ernesto - -- Ernesto Baschny TYPO3 CMS Core Developer Release Manager TYPO3 4.5 & 6.2 LTS TYPO3 .... inspiring people to share! Get involved: typo3.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlIxkDgACgkQHHDui5FfZDhO/gCfRuJXx3Ck60n/FdaD/hWDlctg ys4AoL2czz+TAUbhrL70llFX4q530mLr =nlwm -----END PGP SIGNATURE----- From cl at viazenetti.de Thu Sep 12 22:46:50 2013 From: cl at viazenetti.de (Christian Ludwig) Date: Thu, 12 Sep 2013 22:46:50 +0200 Subject: [TYPO3-dev] [TYPO3-performance] Scaling TYPO3 horizontally In-Reply-To: References: Message-ID: Hi Ernesto, I just found your post. We are using Varnish for all http requests what does its job really well without any other optimizations needed. To handle SSL, we have an NginX that passes the "page" https requests straight to the TYPO3 Server (because these are the only real "dynamic" contents) and the static content requests like images, css and js to Varnish by http. Christian -----Original Message----- From: typo3-dev-bounces at lists.typo3.org [mailto:typo3-dev-bounces at lists.typo3.org] On Behalf Of Ernesto Baschny [cron IT] Sent: Friday, June 28, 2013 10:17 PM To: typo3-dev at lists.typo3.org Subject: [TYPO3-dev] [TYPO3-performance] Scaling TYPO3 horizontally Hi, I've got some questions for the "performance-freaks" amongst us. What techniques are you using for scaling TYPO3 in a "Cloudy" scenario (or in a scenario where you need horizontal scaling)? Using some Load-Balancer in front of multiple frontend servers? Which? Varnish? Nginx? Pound? If only Varnish, how are you handling SSL? Where is your PHP running? Apache with mod_php? Nginx with FastCGI? PHP-FPM with either Apache or Nginx? Or some other method? What PHP opcode cache are you using? APC? Zend? eAccelerator? How are you synchronizing the file storage amongst the multiple frontend webservers (typo3temp, fileadmin, ...)? NFS? DRBD with OCFS2 or GFS2? rsync "from time to time"? iSCSI How are you scaling MySQL? Master and multiple slaves? How are you ensuring TYPO3 writes only to the Master and reads from "some" slave? MySQL-Proxy? Some TYPO3 Extension? Where are you letting TYPO3 cache your data? Redis? Memcache? File-Based? A mix? If you are using Redis, how are you scaling this? Also Master-slave's? Sharding? Are you separating the editors (Backend) on a separate frontend server? Are they working on the "live database" or on some copy? If on some copy of it, how are you synchronizing it to the live server(s)? Well, many questions, but I expect many interesting answers. :) Maybe this could serve as a base for some documentation on this topic in future... Kind regards, Ernesto _______________________________________________ TYPO3-dev mailing list TYPO3-dev at lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev From email at spikx.net Fri Sep 13 12:44:23 2013 From: email at spikx.net (Fritz-Michael Gschwantner) Date: Fri, 13 Sep 2013 12:44:23 +0200 Subject: [TYPO3-dev] =?utf-8?q?4=2E5=2E19=3A_loadTCA_infinity_loop/recursi?= =?utf-8?q?on?= References: Message-ID: We haven't got around yet to properly reproduce this issue with a "naked" extension. The only thing we also noticed is, that the problem does not occur anymore, if we change Page ID (`pid`) of each and every entry to something non-sensical (i.e. a Page ID that doesn't exist, or -1). For the functionality of our extension, the Page ID does not matter (for the most part), since the entries are loaded and edited via a custom backend extension that reads all the articles from the table, regardless of the Page ID. From typo3.neufeind at speedpartner.de Fri Sep 13 17:32:10 2013 From: typo3.neufeind at speedpartner.de (Stefan Neufeind) Date: Fri, 13 Sep 2013 17:32:10 +0200 Subject: [TYPO3-dev] [TYPO3-performance] Scaling TYPO3 horizontally In-Reply-To: References: Message-ID: Hi, but then why don't you use nginx directly for the caching of images etc., or even with it's integrated webserver to also fetch the static files from disk. Furthermore, if you pass dynamic requests straight through, you don't take advantage of caching pages as well. That would be possible with "aggressive" caching in Varnish and then using something like the varnish-TYPO3-module to actively inform varnish which pages were purged from the cache/became invalid. Kind regards, Stefan On 09/12/2013 10:46 PM, Christian Ludwig wrote: > Hi Ernesto, > > I just found your post. > > We are using Varnish for all http requests what does its job really well > without any other optimizations needed. > To handle SSL, we have an NginX that passes the "page" https requests > straight to the TYPO3 Server (because these are the only real "dynamic" > contents) and the static content requests like images, css and js to > Varnish by http. > > Christian > > -----Original Message----- > From: typo3-dev-bounces at lists.typo3.org > [mailto:typo3-dev-bounces at lists.typo3.org] On Behalf Of Ernesto Baschny > [cron IT] > Sent: Friday, June 28, 2013 10:17 PM > To: typo3-dev at lists.typo3.org > Subject: [TYPO3-dev] [TYPO3-performance] Scaling TYPO3 horizontally > > Hi, > > I've got some questions for the "performance-freaks" amongst us. > > What techniques are you using for scaling TYPO3 in a "Cloudy" scenario > (or in a scenario where you need horizontal scaling)? > > Using some Load-Balancer in front of multiple frontend servers? Which? > Varnish? Nginx? Pound? > > If only Varnish, how are you handling SSL? > > Where is your PHP running? Apache with mod_php? Nginx with FastCGI? > PHP-FPM with either Apache or Nginx? Or some other method? > > What PHP opcode cache are you using? APC? Zend? eAccelerator? > > How are you synchronizing the file storage amongst the multiple frontend > webservers (typo3temp, fileadmin, ...)? NFS? DRBD with OCFS2 or GFS2? > rsync "from time to time"? iSCSI > > How are you scaling MySQL? Master and multiple slaves? How are you > ensuring TYPO3 writes only to the Master and reads from "some" slave? > MySQL-Proxy? Some TYPO3 Extension? > > Where are you letting TYPO3 cache your data? Redis? Memcache? > File-Based? A mix? > > If you are using Redis, how are you scaling this? Also Master-slave's? > Sharding? > > Are you separating the editors (Backend) on a separate frontend server? > Are they working on the "live database" or on some copy? If on some copy > of it, how are you synchronizing it to the live server(s)? > > Well, many questions, but I expect many interesting answers. :) Maybe > this could serve as a base for some documentation on this topic in > future... > > Kind regards, > Ernesto From franz at ttproducts.de Fri Sep 13 21:30:27 2013 From: franz at ttproducts.de (Franz Holzinger) Date: Fri, 13 Sep 2013 21:30:27 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Any idea when this issue will be fixed? Or must I report this on the bugtracker? Le 12. 09. 13 07:42, Franz Holzinger a ?crit : > I have the same problem with the ext1 extension upload tool and > t3xutils. This did work fine until August 2013. > > ---------------------------------------------- > SOAP-Error: Internal Server Error > ---------------------------------------------- From olivier.dobberkau at dkd.de Fri Sep 13 22:06:22 2013 From: olivier.dobberkau at dkd.de (Olivier Dobberkau) Date: Fri, 13 Sep 2013 22:06:22 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Am 13.09.13 21:30, schrieb Franz Holzinger: > Any idea when this issue will be fixed? Or must I report this on the > bugtracker? Are you trying to override a released version, Franz? Olivier From franz at ttproducts.de Fri Sep 13 23:10:17 2013 From: franz at ttproducts.de (Franz Holzinger) Date: Fri, 13 Sep 2013 23:10:17 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Le 13. 09. 13 22:06, Olivier Dobberkau a ?crit : > Am 13.09.13 21:30, schrieb Franz Holzinger: > >> Any idea when this issue will be fixed? Or must I report this on the >> bugtracker? > > Are you trying to override a released version, Franz? > > Olivier Does "SOAP-Error: Internal Server Error" mean: "You have uploaded the extension under an already existing version number!" ? - Franz From xavier at typo3.org Sat Sep 14 12:27:28 2013 From: xavier at typo3.org (Xavier Perseguers) Date: Sat, 14 Sep 2013 12:27:28 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi Franz, >>> Any idea when this issue will be fixed? Or must I report this on the >>> bugtracker? >> >> Are you trying to override a released version, Franz? >> >> Olivier > > Does "SOAP-Error: Internal Server Error" mean: > > "You have uploaded the extension under an already existing version > number!" ? A bit hard to tell :) I would say that centralizing such knowledge within the bug tracker of the corresponding extension would make more sense that here, so if I were you, I would open a ticket for the extension to let the author tell me the real cause. You might debug this yourself as well, and answer the ticket as well, still publishing the info where it may be easily found by others. And if it makes sense and the extension is simply throwing a generic error, the author may then consider changing its error message. Kind regards -- Xavier Perseguers Release Manager TYPO3 4.6 TYPO3 .... inspiring people to share! Get involved: http://typo3.org From olivier.dobberkau at dkd.de Sat Sep 14 18:57:39 2013 From: olivier.dobberkau at dkd.de (Olivier Dobberkau) Date: Sat, 14 Sep 2013 18:57:39 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Am 13.09.13 23:10, schrieb Franz Holzinger: > "You have uploaded the extension under an already existing version > number!" ? Why do you want to overide an existing released version? That aint very trustworthy. Olivier From wenzel at webfox03.de Sat Sep 14 22:52:54 2013 From: wenzel at webfox03.de (Dirk Wenzel) Date: Sat, 14 Sep 2013 22:52:54 +0200 Subject: [TYPO3-dev] Extbase relation to tt_content - TCA overwritten Message-ID: Hi, I'm building an extension where a model should have an m:n relation to tt_content records. When setting up this relation in extension builder the TCA for tt_content is overwritten. Content elements can not be edited in BE anymore since the edit window is empty. Also the wizard for creating content elements doesn't show the icon for tt_content anymore. Instead there is the standard icon for extbase entities without a label. I followed the instructions under [1]. The above case is mentioned there. But I don't understand how to avoid it. (see below for details) Thanks in advance Dirk Model: ========== Option Object Type: entity Is Aggregat Root: yes Enable Sorting: yes ========== Properties [...] ========== Relations ========= Name: ContentElements TtContent---------------Type: m:n Object Type: entity ========== Is Aggregat Root: yes Enable Sorting: yes ========= Properties -Points ========= Generated ext_typoscript_setup.txt: config.tx_extbase{ persistence{ classes{ webfox\T3rating\Domain\Model\TtContent { mapping { tableName = tt_content recordType = Tx_T3rating_TtContent } } } } } Generated [...]TCA/TtContent.php: empty [1] http://wiki.typo3.org/T3Doc/Extension_Builder/Mapping_to_tables_and_extending_classes From xavier at typo3.org Sat Sep 14 23:30:01 2013 From: xavier at typo3.org (Xavier Perseguers) Date: Sat, 14 Sep 2013 23:30:01 +0200 Subject: [TYPO3-dev] Rendering on docs.typo3.org Message-ID: Hi, I just automatically rendered Sphinx-based manuals from extensions uploaded to TER in the last 45 days. This is now running regularly for new uploads. Martin started a few scripts in Python, Fabien kickstarted a Flow-based app, but none of these ways were actually able to render Sphinx-based documentation. Nobody to blame, it's just due to lack of time. As in the mean time I largely rewrote the rendering internals for a few special projects and official manuals, I could took over this task and quickly come with some pragmatic PHP-based approach to automate the rendering. I created a repository with my work on github: https://github.com/xperseguers/TYPO3.docs.ter-automation This is raw but does what it should and can now serve as a base for a cleaner "future-proof" Flow-based app. What I did not do: properly render OOo-based manuals as it involves multiple Python-based scripts which I never used myself and they are still rendered on typo3.org anyway so this part will wait! I hope you finally see your extension's manual properly rendered on docs.typo3.org. If that's not the case, please ping me on Twitter. I've seen that a few extensions seemed to fail to compile properly, most probably because they never were compiled locally before. I invite you to locally compile your manuals prior to any upload to TER using my extension "sphinx" available in TER. For anyone interested into testing the upcoming release of EXT:sphinx, please do so by cloning the master branch from git://git.typo3.org/TYPO3CMS/Extensions/sphinx.git I've included quite some cool stuff but I will test them for some time before releasing this new version 1.2.0. Kind regards and happy documenting -- Xavier Perseguers Release Manager TYPO3 4.6 TYPO3 .... inspiring people to share! Get involved: http://typo3.org From xavier at typo3.org Sun Sep 15 18:24:49 2013 From: xavier at typo3.org (Xavier Perseguers) Date: Sun, 15 Sep 2013 18:24:49 +0200 Subject: [TYPO3-dev] Rendering on docs.typo3.org In-Reply-To: References: Message-ID: Hi again, > What I did not do: properly render OOo-based manuals as it involves > multiple Python-based scripts which I never used myself and they are > still rendered on typo3.org anyway so this part will wait! This is now done, I could not stand anymore seeing TER linking to awful rendering on docs.typo3.org. OOo-based manuals are now converted to Sphinx project using latest version of conversion script from RestTools repository and then build as standard Sphinx-based projects. I converted back OOo-based manuals for extensions uploaded to TER within the last 15 days. Kind regards -- Xavier Perseguers Release Manager TYPO3 4.6 TYPO3 .... inspiring people to share! Get involved: http://typo3.org From fsu-lists at cobweb.ch Sun Sep 15 21:07:24 2013 From: fsu-lists at cobweb.ch (=?ISO-8859-1?Q?Fran=E7ois_Suter?=) Date: Sun, 15 Sep 2013 21:07:24 +0200 Subject: [TYPO3-dev] Rendering on docs.typo3.org In-Reply-To: References: Message-ID: Hi Xavier, >> What I did not do: properly render OOo-based manuals as it involves >> > multiple Python-based scripts which I never used myself and they are >> > still rendered on typo3.org anyway so this part will wait! > > This is now done, I could not stand anymore seeing TER linking to awful > rendering on docs.typo3.org. Woohoo! Thanks for everything! -- Francois Suter Work: Cobweb Development Sarl - http://www.cobweb.ch TYPO3: Help the project! - http://typo3.org/contribute/ Appreciate my work? Support me - http://www.monpetitcoin.com/en/francois/support-me/ From xavier at typo3.org Mon Sep 16 08:24:11 2013 From: xavier at typo3.org (Xavier Perseguers) Date: Mon, 16 Sep 2013 08:24:11 +0200 Subject: [TYPO3-dev] Rendering on docs.typo3.org In-Reply-To: References: Message-ID: Hi Francois, >>> What I did not do: properly render OOo-based manuals as it involves >>> > multiple Python-based scripts which I never used myself and they are >>> > still rendered on typo3.org anyway so this part will wait! >> >> This is now done, I could not stand anymore seeing TER linking to awful >> rendering on docs.typo3.org. > > Woohoo! Thanks for everything! You're welcome :) A few info for everyone: - OOo-based manual may be converted to Sphinx project using either EXT:sphinx (dashboard in Help > Sphinx Documentation Viewer) or online service from Documentation Team: http://docs.typo3.org/getthedocs/service-convert.html (this is exactly the same!) 1) After the conversion, please first convert every .gif image to either .png or .jpg (and adapt inclusion) because .gif is not compatible with PDF rendering 2) Adapt the Index.rst start page using this template: http://docs.typo3.org/typo3cms/extensions/sphinx/_sources/Index.txt 3) Test the rendering locally, it's so damn easy with EXT:sphinx - Many "recent" extensions have been kickstarted with the Extension Builder which automatically created an example documentation (based on the official template back then). It was meant as a base to be updated or deleted if you did not want to have a Documentation at that time but many authors just left this dumb documentation in place. This is now fixed in recent version of EB. In order to prevent us for cluttering docs.typo3.org with those actually invalid manuals, I detect if this is the case (or seems to be!) and if so, I simply skip its rendering! - You *must* have a Settings.yml file in your Documentation/ folder (EXT:bib currently does not for instance, don't know why, probably because it was manually kickstarted) otherwise it will be as if you would not have any documentation for your extension - You /should/ update the version (upcoming one) of your extension in Settings.yml prior to uploading it to TER because it is used on docs.typo3.org to show the manual's version. However, as it is easily forgotten I override it anyway when rendering, based on the actual extension's version - As Sphinx-based documentation are now automatically rendered, it would be good if the Documentation module from TYPO3 6.2 would be largely put under stress. It has been developed a while ago, we did not change much and hopefully kept compatibility but it is time to adjust it if needed: 1) fetch of official documentation 2) fetch of offline copy of installed extension's manual - only if Sphinx-based - another excellent reason to switch today to Sphinx for your extension manuals 3) behaviour of this fetch when a multilingual documentation is found according to the Backend user language (fix or enhance UX if needed) 4) Known multilingual extensions: EXT:in_gallery_flickr, EXT:socialshareprivacy, EXT:sphinx I really encourage you to read chapter of EXT:sphinx's manual regarding what to know about rendering on docs.typo3.org: http://docs.typo3.org/typo3cms/extensions/sphinx/UsersManual/DocsTypo3Org/Index.html Just so that you get the most out of it! Cheers Xavier -- Xavier Perseguers Release Manager TYPO3 4.6 TYPO3 .... inspiring people to share! Get involved: http://typo3.org From gcopin at inouit.com Mon Sep 16 09:30:46 2013 From: gcopin at inouit.com (Grégory Copin) Date: Mon, 16 Sep 2013 09:30:46 +0200 Subject: [TYPO3-dev] =?utf-8?q?_=5Bin=5Fgallery=5Fflickr=5D_need_feedback?= Message-ID: Hi. We've just made a extension to make FlickR gallery in typo3 content based on extbase/fluid. We need some help for the feedback, ideas or issues. There's two versions of the extension : - 1.x : for typo3 4.5.x - 2.x : for typo3 6.x Thanks a lot for you time. I hope you'll enjoy it. Almost forgot the link ;) : http://typo3.org/extensions/repository/view/in_gallery_flickr From gianluca.strafella at webformat.com Mon Sep 16 10:46:03 2013 From: gianluca.strafella at webformat.com (Gianluca Strafella) Date: Mon, 16 Sep 2013 10:46:03 +0200 Subject: [TYPO3-dev] Typo3QuerySettings - limits to the query result by cruser_id In-Reply-To: References: Message-ID: Hi Tomita, Typo3QuerySettings is not related to field cruser_id in some way. So, you could extend rather method createQuery of the class Tx_Extbase_Persistence_Repository to limit each repository query to specific cruser_id value. For example, in your Repository, you could override method createQuery with a similar code: public function createQuery() { $query = parent::createQuery(); //99 is a cruser_id $query = $query->matching( $query->equals("cruserId", 99) ); return $query; } In this way, each query in your repository will contain the clause "and cruser_id=99" Regards, Gianluca P.s. I think that you support request is most specific of list typo3.projects.typo3v4mvc :) Gianluca Strafella Software Developer gianluca.strafella at webformat.com Tel. +39-0427-926.389 WEBFORMAT srl ? www.webformat.com Via S. Francesco d'Assisi, 6 ? 20122 MILANO Corte Europa, 12 - 33097 SPILIMBERGO (PN) Il 12/09/2013 09:14, Tomi?? MILITARU ha scritto: > Hello, > > I want to limit the query by cruser_id = $someUserId in frontend from the > query settings, but I don't know if that is possible. > Is there a way to extend Typo3QuerySettings so that I could use something > like $querySettings->setCruserId($someUserId )? > > Thanks, > Tomita > From mueller at cyperfection.de Mon Sep 16 13:32:57 2013 From: mueller at cyperfection.de (=?ISO-8859-15?Q?Chris_M=FCller?=) Date: Mon, 16 Sep 2013 13:32:57 +0200 Subject: [TYPO3-dev] TYPO3 and requireJs In-Reply-To: References: Message-ID: Okay, now I found in the forge issue #39622 an example extension, but it doesn't work. It seems that it uses an earlier implementation of that feature. I also found no implementation in the core. So it seems, this feature was introduced in TYPO3 6.1 with no reference of usage. No one who has implemented it and can help me with an example or can push me to the right direction? Regards, Chris. Am 02.09.2013 15:41, schrieb Chris M?ller: > Hello, > > since TYPO3 6.1 it should be possible to use requireJs for the frontend. > Does someone has an example for activating this feature and use it in > own extensions? > > Regards, > Chris. From franz at ttproducts.de Mon Sep 16 13:47:15 2013 From: franz at ttproducts.de (Franz Holzinger) Date: Mon, 16 Sep 2013 13:47:15 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hello Olivier, Le 14. 09. 13 18:57, Olivier Dobberkau a ?crit : > Am 13.09.13 23:10, schrieb Franz Holzinger: > >> "You have uploaded the extension under an already existing version >> number!" ? > > Why do you want to overide an existing released version? > That aint very trustworthy. > Sorry, I cannot follow you. Maybe my English is too bad? - Franz From franz at ttproducts.de Mon Sep 16 13:50:28 2013 From: franz at ttproducts.de (Franz Holzinger) Date: Mon, 16 Sep 2013 13:50:28 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hello Xavier, Le 14. 09. 13 12:27, Xavier Perseguers a ?crit : > Hi Franz, > >>>> Any idea when this issue will be fixed? Or must I report this on the >>>> bugtracker? >>> >> Does "SOAP-Error: Internal Server Error" mean: >> >> "You have uploaded the extension under an already existing version >> number!" ? > > A bit hard to tell :) I would say that centralizing such knowledge > within the bug tracker of the corresponding extension would make more > sense that here, so if I were you, I would open a ticket for the > extension to let the author tell me the real cause. > > You might debug this yourself as well, and answer the ticket as well, > still publishing the info where it may be easily found by others. And if > it makes sense and the extension is simply throwing a generic error, the > author may then consider changing its error message. to which extension must I report this TER upload bug? Is is extension ext1 or another one? I have used this upload script: ---------------------------------------------- php /var/www/web50/web/typo3conf/ext/ext1/Cool/Modules/Ext/Services/../../Typo3ExtensionUtils/bin/t3xutils.php upload mytypo3useraccount mysecretpassword myextensionkey ' My Upload Comment ' /var/www/web50/web/trunk/typo3/ext/myextensionkey ---------------------------------------------- - Franz From xavier at typo3.org Mon Sep 16 15:18:32 2013 From: xavier at typo3.org (Xavier Perseguers) Date: Mon, 16 Sep 2013 15:18:32 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hello Franz, >> A bit hard to tell :) I would say that centralizing such knowledge >> within the bug tracker of the corresponding extension would make more >> sense that here, so if I were you, I would open a ticket for the >> extension to let the author tell me the real cause. >> >> You might debug this yourself as well, and answer the ticket as well, >> still publishing the info where it may be easily found by others. And if >> it makes sense and the extension is simply throwing a generic error, the >> author may then consider changing its error message. > > to which extension must I report this TER upload bug? > Is is extension ext1 or another one? > > I have used this upload script: > > ---------------------------------------------- > php > /var/www/web50/web/typo3conf/ext/ext1/Cool/Modules/Ext/Services/../../Typo3ExtensionUtils/bin/t3xutils.php > upload mytypo3useraccount mysecretpassword myextensionkey ' > My Upload Comment > ' /var/www/web50/web/trunk/typo3/ext/myextensionkey > ---------------------------------------------- You are using t3xutils and you have a problem using it, right? So the project is hosted on github: https://github.com/etobi/Typo3ExtensionUtils There's a bug tracker, open a ticket there and wish @etobi will give you feedback quickly. Kind regards Xavier -- Xavier Perseguers Release Manager TYPO3 4.6 TYPO3 .... inspiring people to share! Get involved: http://typo3.org From tp at codem.dk Mon Sep 16 17:23:32 2013 From: tp at codem.dk (Thomas Petersen) Date: Mon, 16 Sep 2013 17:23:32 +0200 Subject: [TYPO3-dev] =?utf-8?q?_Fluid_menu_span-tag_problem=2E?= Message-ID: Hi all. Its my first time with TYPO3 and Fluid, but im allready love it. I have a little problem, i have a menu thats in RAW HTML looks like this. I need a SPAN-tag inside the A-tag, but i cant see how im doing this in TS.. My TS code is. lib.mainNavi = HMENU lib.mainNavi.entryLevel=0 lib.mainNavi.1 = TMENU lib.mainNavi.1 { wrap = expAll = 0 NO.allWrap =
  • |
    • RO < .NO RO = 1 CUR < .NO CUR = 1 CUR.allWrap =
  • |
    • ACT < .CUR } If i add the SPAN-tag like
  • |
  • |
    • I get the A-tag inside the SPAN, and its make some funny things with my CSS layout, so i need the SPAN inside the A-tag, how and where do i fix this ? Thx for reading this post. From ernst at cron-it.de Mon Sep 16 17:58:13 2013 From: ernst at cron-it.de (Ernesto Baschny [cron IT]) Date: Mon, 16 Sep 2013 17:58:13 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Olivier Dobberkau schrieb am 14.09.2013 18:57: > Am 13.09.13 23:10, schrieb Franz Holzinger: > >> "You have uploaded the extension under an already existing version >> number!" ? > > Why do you want to overide an existing released version? > That aint very trustworthy. Olivier, I guess you are speculating and spreading rumors based on some assumption. Not very polite. Especially quoting Franz out of context. The new SOAP error might also come from the fact that you now need to specify typo3 dependency on a released TYPO3 version if you want to upload to TER. Only that TER currently has some error handling bug, AFAIK. See also http://forge.typo3.org/issues/51654 Cheers, Ernesto From soren.malling at gmail.com Mon Sep 16 20:22:10 2013 From: soren.malling at gmail.com (=?ISO-8859-1?Q?S=F8ren_Malling?=) Date: Mon, 16 Sep 2013 20:22:10 +0200 Subject: [TYPO3-dev] Fluid menu span-tag problem. In-Reply-To: References: Message-ID: Hi Thomas, Welcome to the cool world of Fluid. Try this in your TMENU NO { allWrap = | stdWrap.wrap = | ATagParams = class="some-css-class-for-your-a-tag" } Regards S?ren On Mon, Sep 16, 2013 at 5:23 PM, Thomas Petersen wrote: > Hi all. > > Its my first time with TYPO3 and Fluid, but im allready love it. > I have a little problem, i have a menu thats in RAW HTML looks like this. > > > > I need a SPAN-tag inside the A-tag, but i cant see how im doing this in > TS.. > My TS code is. > > lib.mainNavi = HMENU > lib.mainNavi.entryLevel=0 > lib.mainNavi.1 = TMENU > lib.mainNavi.1 { > wrap = > expAll = 0 > NO.allWrap =
  • |
    • > RO < .NO > RO = 1 > CUR < .NO > CUR = 1 > CUR.allWrap =
  • | > ACT < .CUR > } > > If i add the SPAN-tag like
  • | >
  • <**span>|
    • > > I get the A-tag inside the SPAN, and its make some funny things with my > CSS layout, so i need the SPAN inside the A-tag, how and where do i fix > this ? > > Thx for reading this post. > ______________________________**_________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-dev > From jigal.van.hemert at typo3.org Mon Sep 16 20:50:05 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Mon, 16 Sep 2013 20:50:05 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi, On 16-9-2013 17:58, Ernesto Baschny [cron IT] wrote: > The new SOAP error might also come from the fact that you now need to > specify typo3 dependency on a released TYPO3 version if you want to > upload to TER. Only that TER currently has some error handling bug, > AFAIK. See also http://forge.typo3.org/issues/51654 I'm not convinced it's a problem in the TER on the server part. When testing the patches for the dependency check on a dev copy of TER the actual messages from TER were displayed in the EM. The last check was with the EM of 4.7. Each correct and incorrect combination of dependencies was followed with a flash message that showed the problem (or a test-message that the dependency was correct). I'll try to do some tests with the current trunk of TER on my test server. -- Jigal van Hemert TYPO3 CMS Active Contributor TYPO3 .... inspiring people to share! Get involved: typo3.org From tp at codem.dk Mon Sep 16 21:09:21 2013 From: tp at codem.dk (Thomas Petersen) Date: Mon, 16 Sep 2013 21:09:21 +0200 Subject: [TYPO3-dev] =?utf-8?q?Fluid_menu_span-tag_problem=2E?= References: Message-ID: Quote: Soren Malling (sorenmalling) wrote on Mon, 16 September 2013 20:22 ---------------------------------------------------- > Hi Thomas, > > Welcome to the cool world of Fluid. > > Try this in your TMENU > > NO { > allWrap = | > stdWrap.wrap = | > ATagParams = class="some-css-class-for-your-a-tag" > } > > Regards > > S??ren Hi S??ren Do u mean like this lib.mainNavi = HMENU lib.mainNavi.entryLevel=0 lib.mainNavi.1 = TMENU lib.mainNavi.1 { wrap = expAll = 0 NO.allWrap =
  • |
    • NO.allWrap = |*| | ?| |*| | NO.ATagParams = class="some-css-class-for-your-a-tag" RO < .NO RO = 1 CUR < .NO CUR = 1 CUR.allWrap =
  • |
    • CUR.allWrap = |*| | ?| |*| | CUR.ATagParams = class="some-css-class-for-your-a-tag" ACT < .CUR } From philipp.gampe at typo3.org Mon Sep 16 22:27:59 2013 From: philipp.gampe at typo3.org (Philipp Gampe) Date: Mon, 16 Sep 2013 22:27:59 +0200 Subject: [TYPO3-dev] Fluid menu span-tag problem. References: Message-ID: Hi Thomas Petersen, Thomas Petersen wrote: > NO.allWrap =
  • |
    • > NO.allWrap = |*| | ?| |*| | The second line overrides the first line completely. Best regards -- Philipp Gampe ? PGP-Key 0AD96065 ? TYPO3 UG Bonn/K?ln Documentation ? Active contributor TYPO3 CMS TYPO3 .... inspiring people to share! From tp at codem.dk Mon Sep 16 22:40:02 2013 From: tp at codem.dk (Thomas Petersen) Date: Mon, 16 Sep 2013 22:40:02 +0200 Subject: [TYPO3-dev] =?utf-8?q?Fluid_menu_span-tag_problem=2E?= References: Message-ID: Hvis code did the job. Thx anyway :-) lib.mainNavi = HMENU lib.mainNavi.entryLevel=0 lib.mainNavi.1 = TMENU lib.mainNavi.1 { wrap = expAll = 0 NO.allWrap =
  • |
    • NO.stdWrap.wrap = | RO < .NO RO = 1 CUR < .NO CUR = 1 CUR.allWrap =
  • |
    • CUR.stdWrap.wrap = | ACT < .CUR } Quote: Thomas Petersen (tpbillund) wrote on Mon, 16 September 2013 21:09 ---------------------------------------------------- > Quote: Soren Malling (sorenmalling) wrote on Mon, 16 September 2013 20:22 > ---------------------------------------------------- > > Hi Thomas, > > > > Welcome to the cool world of Fluid. > > > > Try this in your TMENU > > > > NO { > > allWrap = | > > stdWrap.wrap = | > > ATagParams = class="some-css-class-for-your-a-tag" > > } > > > > Regards > > > > S??ren > > Hi S??ren > Do u mean like this > > lib.mainNavi = HMENU > lib.mainNavi.entryLevel=0 > lib.mainNavi.1 = TMENU > lib.mainNavi.1 { > wrap = > expAll = 0 > NO.allWrap =
  • |
    • > NO.allWrap = |*| | ?| |*| | > NO.ATagParams = class="some-css-class-for-your-a-tag" > RO < .NO > RO = 1 > CUR < .NO > CUR = 1 > CUR.allWrap =
  • |
    • > CUR.allWrap = |*| | ?| |*| | > CUR.ATagParams = class="some-css-class-for-your-a-tag" > ACT < .CUR > } > > ---------------------------------------------------- From helmut.hummel at typo3.org Mon Sep 16 23:45:00 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Mon, 16 Sep 2013 23:45:00 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi! On 16.09.13 20:50, Jigal van Hemert wrote: > I'm not convinced it's a problem in the TER on the server part. But it is! The problem is not only the TER Serverpart but also the webserver configuration and the fact, that PHP sends a 500 status code for SoapFaults by default. There was a hack in TER Server to circumvent this PHP behaviour but this obviously did not work. In combination with a special default (HTML) error page configured in the webserver when status code is 500, this lead to the meaningless error messages in (all) SoapClients. A workaround (looks ugly but works) for that is now commited and deployed on typo3.org http://forge.typo3.org/attachments/24980/51654_v2.diff Please test uploads again... Kind regards, Helmut -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From jigal.van.hemert at typo3.org Tue Sep 17 12:12:50 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Tue, 17 Sep 2013 12:12:50 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi, On 16-9-2013 23:45, Helmut Hummel wrote: > On 16.09.13 20:50, Jigal van Hemert wrote: > >> I'm not convinced it's a problem in the TER on the server part. > But it is! The problem is not only the TER Serverpart but also the > webserver configuration and the fact, that PHP sends a 500 status code > for SoapFaults by default. > > There was a hack in TER Server to circumvent this PHP behaviour but > this obviously did not work. > > In combination with a special default (HTML) error page configured in > the webserver when status code is 500, this lead to the meaningless > error messages in (all) SoapClients. From what I now understand the problem is the fact that the web server (the Nginx part) catches the 500 status and outputs a special error page instead of what PHP sent. This also explains why the message from TER worked fine on my test TER server. I tested with uploading extensions with incorrect and correct dependencies from the 4.5 and 4.7 Extension Manager and saw the exact messages from (my) TER. > A workaround (looks ugly but works) for that is now commited and > deployed on typo3.org > http://forge.typo3.org/attachments/24980/51654_v2.diff Yes, it's quite ugly that it abuses the status 424 (which is for WebDAV to indicate that a requested action failed because it depends on another action which failed). The behaviour of the Nginx server should be changed to not serve that document when status 500 occurs. -- Jigal van Hemert TYPO3 CMS Active Contributor TYPO3 .... inspiring people to share! Get involved: typo3.org From steffen.gebert at typo3.org Tue Sep 17 13:03:41 2013 From: steffen.gebert at typo3.org (Steffen Gebert) Date: Tue, 17 Sep 2013 18:03:41 +0700 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, sorry, I haven't monitored this topic until now. Indeed, we are running "proxy_intercept_errors on", which will catch errors 500-504 in our configuration. I could deactivate this globally, but I found this feature pretty nice. So maybe we just disable it for the that one URL? (which is /wsdl/tx_ter_wsdl.php or index.php?id=ter ?) > location /wsdl/tx_ter_wsdl.php { > proxy_pass http://backend_srv107; > > # disable the interception of error pages sent by the backend server for TER SOAP > # otherwise uploaders cannot see correct error messages (e.g. that no version constraint is set) > proxy_intercept_errors off; > } Please note that there's a RewriteRule in place on the web server (not that some get confused): > RewriteRule ^wsdl/tx_ter_wsdl.php$ typo3conf/ext/ter/tx_ter_wsdl.php [L] What do you think? Kind regards Steffen - -- Steffen Gebert TYPO3 Server Administration Team Member TYPO3 .... inspiring people to share! Get involved: http://typo3.org My wish list: https://www.amazon.de/registry/wishlist/922E3JYSQ7CV/ref=cm_wl_sb_v?sort=priority On 9/17/13 5:12 PM, Jigal van Hemert wrote: > Hi, > > On 16-9-2013 23:45, Helmut Hummel wrote: >> On 16.09.13 20:50, Jigal van Hemert wrote: >> >>> I'm not convinced it's a problem in the TER on the server part. >> But it is! The problem is not only the TER Serverpart but also the >> webserver configuration and the fact, that PHP sends a 500 status code >> for SoapFaults by default. >> >> There was a hack in TER Server to circumvent this PHP behaviour but >> this obviously did not work. >> >> In combination with a special default (HTML) error page configured in >> the webserver when status code is 500, this lead to the meaningless >> error messages in (all) SoapClients. > > From what I now understand the problem is the fact that the web server > (the Nginx part) catches the 500 status and outputs a special error page > instead of what PHP sent. > > This also explains why the message from TER worked fine on my test TER > server. I tested with uploading extensions with incorrect and correct > dependencies from the 4.5 and 4.7 Extension Manager and saw the exact > messages from (my) TER. > >> A workaround (looks ugly but works) for that is now commited and >> deployed on typo3.org >> http://forge.typo3.org/attachments/24980/51654_v2.diff > > Yes, it's quite ugly that it abuses the status 424 (which is for WebDAV > to indicate that a requested action failed because it depends on another > action which failed). > > The behaviour of the Nginx server should be changed to not serve that > document when status 500 occurs. > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJSODcNAAoJEIskG/rSlyw4oO4H/005ahhKqu+/Q8vCs20UFHLi If8gw0tBBLqUpI/Of7/e4+3aE9R/qkH2J8ecwsLIb+ZytuzpU0e/JBNFqOJcf5h/ eBDASIQM0CdYZcwCVdm2t5nxCQaDP2861gBNgkHYvQO5kVLgvJOyr8RwX41kvMFd p6RxNgHHnBzwPGu9cwfdKT+fVQG8AaG5ouyM6osfdDGzMZC+MiKu529VT4s3EoLz eL2UOJ8NBy/M09h7FIq0LdbZXvvAzzi8jT3hxcoRKCqlspIZPsFYWCPNjrkE6nAp PDNbjAWGdogpA4Ar9HXbmS4mjVRBoeHIltCANg9mZd9Vit2a3xqGPlYIPmLrbR8= =uHI6 -----END PGP SIGNATURE----- From helmut.hummel at typo3.org Tue Sep 17 13:50:22 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Tue, 17 Sep 2013 13:50:22 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi! On 17.09.13 12:12, Jigal van Hemert wrote: > From what I now understand the problem is the fact that the web server > (the Nginx part) catches the 500 status and outputs a special error page > instead of what PHP sent. Two problems. First of all overwriting the HTTP does not work (like it is intended in the code) Secondly, yes the 500 status "outputs a special error page instead of what PHP sent" > This also explains why the message from TER worked fine on my test TER > server. Yes. Both problems seems to not have existed on your side. > Yes, it's quite ugly that it abuses the status 424 (which is for WebDAV > to indicate that a requested action failed because it depends on another > action which failed). Well, 404 code is also abused. The only code that would fit soehow is 401 (see http://forge.typo3.org/issues/44135), but this still seems to violate the SOAP protocol, but at least the PHP implementation of it (500 is sent by intention in case of a SOAP Fault). > The behaviour of the Nginx server should be changed to not serve that > document when status 500 occurs. We have a solution. It is committed and deployed. It robust because it is independend form webserver configuration. We can easily change the desired http status header (to anything besides 500). One can invest more time to make it more pretty. It would probably worth it, as code 500 is sent for quite some different server error and a proper error message would be nice to have and in such cases still a 500 code is sent triggering the webserver to deliver the default page. I personally would like to be pragmatic and invest my time in other areas. Kind regards, Helmut -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From helmut.hummel at typo3.org Tue Sep 17 14:00:33 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Tue, 17 Sep 2013 14:00:33 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi Steffen, On 17.09.13 13:03, Steffen Gebert wrote: > Indeed, we are running "proxy_intercept_errors on", which will catch > errors 500-504 in our configuration. > > I could deactivate this globally, but I found this feature pretty nice. It definetly makes sense. I would not disable it completely. > So maybe we just disable it for the that one URL? (which is > /wsdl/tx_ter_wsdl.php or index.php?id=ter ?) > >> location /wsdl/tx_ter_wsdl.php { >> proxy_pass http://backend_srv107; >> >> # disable the interception of error pages sent by the backend server for TER SOAP >> # otherwise uploaders cannot see correct error messages (e.g. that no version constraint is set) >> proxy_intercept_errors off; >> } http://typo3.org/wsdl/tx_ter_wsdl.php only outputs a static file (with a URL replacement) no SOAP action is done here. http://typo3.org/index.php?id=ter is where the soap action happens and the URL which would need to be excluded. > What do you think? Would be nice to have, if it is not much work. Kind regards, Helmut -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From helmut.hummel at typo3.org Tue Sep 17 14:03:16 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Tue, 17 Sep 2013 14:03:16 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi! On 17.09.13 13:50, Helmut Hummel wrote: > I personally would like to be pragmatic and invest my time in other areas. To be clear. Disabling the 500 interception for the SOAP URL would be good, but beautifying the TER code (that actually works) is not on my priority list. Kind regards, Helmut -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From steffen.gebert at typo3.org Tue Sep 17 14:21:26 2013 From: steffen.gebert at typo3.org (Steffen Gebert) Date: Tue, 17 Sep 2013 19:21:26 +0700 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Helmut, > http://typo3.org/index.php?id=ter is where the soap action happens and > the URL which would need to be excluded. Ah.. then indeed it's not possible. Query strings can only be matched using an "if", not directly in the "location" declaration - but then I cannot disable the interception. So if nobody comes up with a better idea, I would leave it globally enabled. If help / input from us (Server Team) is required, just ping us. Kind regards Steffen - -- Steffen Gebert TYPO3 Server Administration Team Member TYPO3 .... inspiring people to share! Get involved: http://typo3.org My wish list: https://www.amazon.de/registry/wishlist/922E3JYSQ7CV/ref=cm_wl_sb_v?sort=priority On 9/17/13 7:00 PM, Helmut Hummel wrote: > Hi Steffen, > > On 17.09.13 13:03, Steffen Gebert wrote: > >> Indeed, we are running "proxy_intercept_errors on", which will catch >> errors 500-504 in our configuration. >> >> I could deactivate this globally, but I found this feature pretty nice. > > It definetly makes sense. I would not disable it completely. > >> So maybe we just disable it for the that one URL? (which is >> /wsdl/tx_ter_wsdl.php or index.php?id=ter ?) >> >>> location /wsdl/tx_ter_wsdl.php { >>> proxy_pass http://backend_srv107; >>> >>> # disable the interception of error pages sent by >>> the backend server for TER SOAP >>> # otherwise uploaders cannot see correct error >>> messages (e.g. that no version constraint is set) >>> proxy_intercept_errors off; >>> } > > http://typo3.org/wsdl/tx_ter_wsdl.php only outputs a static file (with a > URL replacement) no SOAP action is done here. > > http://typo3.org/index.php?id=ter is where the soap action happens and > the URL which would need to be excluded. > >> What do you think? > > Would be nice to have, if it is not much work. > > Kind regards, > Helmut > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJSOElGAAoJEIskG/rSlyw48ZAH/ArC1UWDvueVolXjgMqTsUOY /BI2qExwucwbE+W0OTub7H8POw5goo1Q+mUL1J2P8wNb3RQRJOFW91/xv/pePhrB 7KgaB2Cv1ZQJCQBwGhZPV01dLtSzmOMFL0ztWhkd2rOPbQeG2QIMgdaMl8gDyqS6 LjO+ykmSkrfiylVi5JnqzWMOdc5QAe9Zr1EgFDW5sR2ME3KzkVVFUKVDzO+LRxaw gvaSyJzogLq55Dbhaitpo7XYao/H6nkPhVd0Al5Bitxatbg6wjFYXRkAqyJ7gOpP RV+uw+LypifuQdFGvIOEZcOnxPsMidh9eMi9kUvQckZN+KiM5816Hl2RPI/MclQ= =kxAA -----END PGP SIGNATURE----- From jigal.van.hemert at typo3.org Tue Sep 17 15:33:02 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Tue, 17 Sep 2013 15:33:02 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi, On 17-9-2013 14:21, Steffen Gebert wrote: > Ah.. then indeed it's not possible. Query strings can only be matched > using an "if", not directly in the "location" declaration - but then I > cannot disable the interception. Seems we have to adjust the behaviour of TER slightly. Perhaps it's better to (ab)use a different status for errors which have a traceable cause to be able to display the message in EM/uploader and leave 500 for the cases where something unknown goes horribly wrong. How can someone work on patches for TER without these nginx surprises? -- Jigal van Hemert TYPO3 CMS Active Contributor TYPO3 .... inspiring people to share! Get involved: typo3.org From helmut.hummel at typo3.org Tue Sep 17 16:35:59 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Tue, 17 Sep 2013 16:35:59 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi! On 17.09.13 15:33, Jigal van Hemert wrote: > On 17-9-2013 14:21, Steffen Gebert wrote: >> Ah.. then indeed it's not possible. Query strings can only be matched >> using an "if", not directly in the "location" declaration - but then I >> cannot disable the interception. OK, no worries. > Seems we have to adjust the behaviour of TER slightly. Perhaps it's > better to (ab)use a different status for errors which have a traceable > cause to be able to display the message in EM/uploader and leave 500 for > the cases where something unknown goes horribly wrong. That is exactly the case now. Only if DB connection is not possible or directories do not exist or any other technical problem on the typo3.org side exists a 500 status code is forced. The only "problem" there is, that we do not know what kind of error occured, as the message is not sent, but the Nginx HTML is delivered. We could change the status header in this case to sth. different than 500 and users would see the details of the failure. But we could also log such cases to the PHP error log instead, as the action to be taken needs to be done by the server team anyway which has access to the logs. All "user errors" wrong auth, wrong deps etc. send different staus headers > How can someone work on patches for TER without these nginx surprises? There are also Varnish surprises and server load surprises. We cannot prevent such issues to occur but can only debug and fix them. That is what I did. Case closed or are there open topics still? Kind regards, Helmut -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From helmut.hummel at typo3.org Tue Sep 17 16:41:32 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Tue, 17 Sep 2013 16:41:32 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi! On 17.09.13 16:35, Helmut Hummel wrote: > But we could also log such cases to the PHP error log instead [x] done Kind regards, Helmut -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From cl at viazenetti.de Tue Sep 17 17:57:21 2013 From: cl at viazenetti.de (Christian Ludwig) Date: Tue, 17 Sep 2013 17:57:21 +0200 Subject: [TYPO3-dev] [TYPO3-performance] Scaling TYPO3 horizontally In-Reply-To: References: Message-ID: Hi Stefan, Due to the small amount of hits on these pages there was no need in caching the dynamic pages. We are using a patched version of moc_varnish (or is there an other extension for TYPO3?) and tried out the "ESI Features", but unfortunately they did not work out of the box. Because of the lack of budget and time and enough performance, we could not digg further into ESI. We prefered using NginX as a https proxy only (without caching) because we wanted all caching to be managed and configured in one central application. In addition Varnish holds its cache in memory what is much faster than fetching static files from disk. Greetings Christian -----Original Message----- From: typo3-dev-bounces at lists.typo3.org [mailto:typo3-dev-bounces at lists.typo3.org] On Behalf Of Stefan Neufeind Sent: Friday, September 13, 2013 5:32 PM To: List for Core-/Extension development Subject: Re: [TYPO3-dev] [TYPO3-performance] Scaling TYPO3 horizontally Hi, but then why don't you use nginx directly for the caching of images etc., or even with it's integrated webserver to also fetch the static files from disk. Furthermore, if you pass dynamic requests straight through, you don't take advantage of caching pages as well. That would be possible with "aggressive" caching in Varnish and then using something like the varnish-TYPO3-module to actively inform varnish which pages were purged from the cache/became invalid. Kind regards, Stefan From franz at ttproducts.de Tue Sep 17 19:25:57 2013 From: franz at ttproducts.de (Franz Holzinger) Date: Tue, 17 Sep 2013 19:25:57 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hello Xavier, Le 16. 09. 13 15:18, Xavier Perseguers a ?crit : > Hello Franz, > >>> A bit hard to tell :) I would say that centralizing such knowledge >>> within the bug tracker of the corresponding extension would make more >>> sense that here, so if I were you, I would open a ticket for the >>> extension to let the author tell me the real cause. >>> >>> You might debug this yourself as well, and answer the ticket as well, >>> still publishing the info where it may be easily found by others. And if >>> it makes sense and the extension is simply throwing a generic error, the >>> author may then consider changing its error message. >> >> to which extension must I report this TER upload bug? >> Is is extension ext1 or another one? >> >> I have used this upload script: >> >> ---------------------------------------------- >> php >> /var/www/web50/web/typo3conf/ext/ext1/Cool/Modules/Ext/Services/../../Typo3ExtensionUtils/bin/t3xutils.php >> upload mytypo3useraccount mysecretpassword myextensionkey ' >> My Upload Comment >> ' /var/www/web50/web/trunk/typo3/ext/myextensionkey >> ---------------------------------------------- > > You are using t3xutils and you have a problem using it, right? So the > project is hosted on github: > > https://github.com/etobi/Typo3ExtensionUtils > > There's a bug tracker, open a ticket there and wish @etobi will give you > feedback quickly. Thank you to have this information here. At the moment it seems that the bug is inside the SOAP system of typo3.org. So I look for the solution from there. - Franz From franz at ttproducts.de Tue Sep 17 19:32:24 2013 From: franz at ttproducts.de (Franz Holzinger) Date: Tue, 17 Sep 2013 19:32:24 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hello Le 17. 09. 13 12:12, Jigal van Hemert a ?crit : >>> I'm not convinced it's a problem in the TER on the server part. >> But it is! The problem is not only the TER Serverpart but also the >> webserver configuration and the fact, that PHP sends a 500 status code >> for SoapFaults by default. >> >> There was a hack in TER Server to circumvent this PHP behaviour but >> this obviously did not work. >> >> In combination with a special default (HTML) error page configured in >> the webserver when status code is 500, this lead to the meaningless >> error messages in (all) SoapClients. > > From what I now understand the problem is the fact that the web server > (the Nginx part) catches the 500 status and outputs a special error page > instead of what PHP sent. > > This also explains why the message from TER worked fine on my test TER > server. I tested with uploading extensions with incorrect and correct > dependencies from the 4.5 and 4.7 Extension Manager and saw the exact > messages from (my) TER. > thank you for your efforts. Now I get this error message after trying to upload a new version 1.0.0 of extension div2007: SOAP-Error: Extension does not have a dependency for a supported version of TYPO3. See http://typo3.org/news/article/announcing-ter-cleanup-process/ for how to fix this. However I have set the dependancy on TYPO3. I do not know what is wrong. I have attached the file ext_emconf.php of div2007. I hope you can tell me the bug. - Franz From typo3 at wouterwolters.nl Tue Sep 17 22:27:05 2013 From: typo3 at wouterwolters.nl (Wouter Wolters) Date: Tue, 17 Sep 2013 22:27:05 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi Franz, I checked your ext_emconf.php and it looks like the following line is not OK. 'typo3' => '4.5.0-6.2.99', 6.2.99 is not a supported version. From the news item: "You can set the minimum for a version of TYPO3 which is not supported anymore, but then the maximum must be within the supported range. You cannot set a maximum outside the range of supported versions." Greetz Wouter Op 17-9-2013 19:32, Franz Holzinger schreef: > Hello > > Le 17. 09. 13 12:12, Jigal van Hemert a ?crit : >>>> I'm not convinced it's a problem in the TER on the server part. >>> But it is! The problem is not only the TER Serverpart but also the >>> webserver configuration and the fact, that PHP sends a 500 status code >>> for SoapFaults by default. >>> >>> There was a hack in TER Server to circumvent this PHP behaviour but >>> this obviously did not work. >>> >>> In combination with a special default (HTML) error page configured in >>> the webserver when status code is 500, this lead to the meaningless >>> error messages in (all) SoapClients. >> >> From what I now understand the problem is the fact that the web server >> (the Nginx part) catches the 500 status and outputs a special error page >> instead of what PHP sent. >> >> This also explains why the message from TER worked fine on my test TER >> server. I tested with uploading extensions with incorrect and correct >> dependencies from the 4.5 and 4.7 Extension Manager and saw the exact >> messages from (my) TER. >> > > thank you for your efforts. > > Now I get this error message after trying to upload a new version 1.0.0 > of extension div2007: > > > SOAP-Error: > Extension does not have a dependency > for a supported version of TYPO3. See > http://typo3.org/news/article/announcing-ter-cleanup-process/ for how to > fix this. > > However I have set the dependancy on TYPO3. I do not know what is wrong. > I have attached the file ext_emconf.php of div2007. I hope you can tell > me the bug. > > - Franz > > > > > From xavier at typo3.org Wed Sep 18 06:59:41 2013 From: xavier at typo3.org (Xavier Perseguers) Date: Wed, 18 Sep 2013 06:59:41 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi Franz, > I checked your ext_emconf.php and it looks like the following line is > not OK. 'typo3' => '4.5.0-6.2.99', > > 6.2.99 is not a supported version. > > From the news item: "You can set the minimum for a version of TYPO3 > which is not supported anymore, but then the maximum must be within the > supported range. You cannot set a maximum outside the range of supported > versions." Exactly, and from the related news [1] you will learn additionally: -------- You cannot set a maximum outside the range of supported versions. Currently and until the release of TYPO3 6.2 beta1 ? that is, "feature freeze" ? in September this year, the upper bound of allowed range is 6.1.99. -------- Feature freeze did not happen yet since we are still at alpha phase. Just for the fun, I was one of those to actively contribute to enforce this new policy and for one of my main extensions, namely EXT:sphinx I would have been tempted to tell it was officially compatible with 6.2 because I'm of course developing it with 6.2 and testing it before release on older versions. So I know it works in 6.2. However, at some time recently, the skins (CSS) were moved in 6.2 meaning my already uploaded version would not have been compatible anymore with 6.2. This is not a problem since I didn't mark it as compatible (I could have before the strict enforcement from TER). This is exactly the reason why although you know that your extension is already compatible with upcoming version, you cannot upload it to TER and tell everyone this is the case because at any point until feature freeze (aka beta1) your extension is likely to break due to changes in upcoming TYPO3 Core (even minor such as moving some CSS along). But once beta1 is out, this is real feature freeze and you should expect the Core to be "ready" (not bug free of course) and test again your extension and upload it with a new dependency so that when rc1 or the .0 version is out, many extensions are already "there". [1] http://typo3.org/news/article/ter-new-requirement-for-extension-upload/ -- Xavier Perseguers Release Manager TYPO3 4.6 TYPO3 .... inspiring people to share! Get involved: http://typo3.org From helmut.hummel at typo3.org Wed Sep 18 09:57:32 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Wed, 18 Sep 2013 09:57:32 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi! On 18.09.13 06:59, Xavier Perseguers wrote: > -------- > You cannot set a maximum outside the range of supported versions. > Currently and until the release of TYPO3 6.2 beta1 ? that is, "feature > freeze" ? in September this year, the upper bound of allowed range is > 6.1.99. > -------- Should we output the enforced version range in the error message along with the provided range? Kind regards, Helmut -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From typo3 at ringerge.org Wed Sep 18 09:59:44 2013 From: typo3 at ringerge.org (Georg Ringer) Date: Wed, 18 Sep 2013 09:59:44 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Am 18.09.2013 09:57, schrieb Helmut Hummel: > Hi! > > On 18.09.13 06:59, Xavier Perseguers wrote: > >> -------- >> You cannot set a maximum outside the range of supported versions. >> Currently and until the release of TYPO3 6.2 beta1 ? that is, "feature >> freeze" ? in September this year, the upper bound of allowed range is >> 6.1.99. >> -------- > > Should we output the enforced version range in the error message along > with the provided range? +1 Georg From xavier at typo3.org Wed Sep 18 10:04:37 2013 From: xavier at typo3.org (Xavier Perseguers) Date: Wed, 18 Sep 2013 10:04:37 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi, >> On 18.09.13 06:59, Xavier Perseguers wrote: >> >>> -------- >>> You cannot set a maximum outside the range of supported versions. >>> Currently and until the release of TYPO3 6.2 beta1 ? that is, "feature >>> freeze" ? in September this year, the upper bound of allowed range is >>> 6.1.99. >>> -------- >> Should we output the enforced version range in the error message along >> with the provided range? > > +1 This could help, for sure. -- Xavier Perseguers Release Manager TYPO3 4.6 TYPO3 .... inspiring people to share! Get involved: http://typo3.org From jigal.van.hemert at typo3.org Wed Sep 18 10:13:00 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Wed, 18 Sep 2013 10:13:00 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi, On 18-9-2013 9:57, Helmut Hummel wrote: > Should we output the enforced version range in the error message along > with the provided range? Could be done, but the enforced range can have multiple sub-ranges. The logic in TER does the opposite and checks if at least one of the current versions of the supported branches is within the provided range. (and checks the provided range) -- Jigal van Hemert TYPO3 CMS Active Contributor TYPO3 .... inspiring people to share! Get involved: typo3.org From tp at codem.dk Wed Sep 18 11:23:22 2013 From: tp at codem.dk (Thomas Petersen) Date: Wed, 18 Sep 2013 11:23:22 +0200 Subject: [TYPO3-dev] =?utf-8?q?_sublink_is_not_showed__IFSUB_problem?= Message-ID: Hi. I have this menu code, its working fine for the main menu, but the SUBlinks is not generated. I have made some pages under one of my mainlinks, so the pages is there. So its must be the IFSUB code thats something wrong with. Can someone maybe help ? lib.mainNavi.entryLevel=0 lib.mainNavi.1 = TMENU lib.mainNavi.1 { wrap = expAll = 0 NO.allWrap =
  • |
    • NO.stdWrap.wrap = | RO < .NO RO = 1 CUR < .NO CUR = 1 CUR.allWrap =
  • |
    • CUR.stdWrap.wrap = | ACT < .CUR #Sub menu links IFSUB = 1 IFSUB.wrapItemAndSub=
  • |
    • IFSUB.stdWrap.wrap = | ACTIFSUB < .IFSUB CURIFSUB < .IFSUB } From soren.malling at gmail.com Wed Sep 18 11:31:33 2013 From: soren.malling at gmail.com (=?ISO-8859-1?Q?S=F8ren_Malling?=) Date: Wed, 18 Sep 2013 11:31:33 +0200 Subject: [TYPO3-dev] sublink is not showed IFSUB problem In-Reply-To: References: Message-ID: Hi Thomas, Try and add a lib.mainMenu.2 < lib.mainMenu.1 to the bottom of the configuration On Wed, Sep 18, 2013 at 11:23 AM, Thomas Petersen wrote: > Hi. > > I have this menu code, its working fine for the main menu, but the > SUBlinks is not generated. > I have made some pages under one of my mainlinks, so the pages is there. > > So its must be the IFSUB code thats something wrong with. > Can someone maybe help ? > > lib.mainNavi.entryLevel=0 > lib.mainNavi.1 = TMENU > lib.mainNavi.1 { > wrap = > expAll = 0 > NO.allWrap =
  • |
    • > NO.stdWrap.wrap = | > RO < .NO RO = 1 > CUR < .NO CUR = 1 > CUR.allWrap =
  • | > CUR.stdWrap.wrap = | > ACT < .CUR #Sub menu links > IFSUB = 1 > IFSUB.wrapItemAndSub=
  • |
    • > IFSUB.stdWrap.wrap = | > ACTIFSUB < .IFSUB > CURIFSUB < .IFSUB > } > ______________________________**_________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-dev > From typo3 at xopn.de Wed Sep 18 11:40:35 2013 From: typo3 at xopn.de (Christian Zenker) Date: Wed, 18 Sep 2013 11:40:35 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER References: Message-ID: Am 17.09.2013, 22:27 Uhr, schrieb Wouter Wolters : > From the news item: "You can set the minimum for a version of TYPO3 > which is not supported anymore, but then the maximum must be within the > supported range. You cannot set a maximum outside the range of supported > versions." Just FYI: This is not entirely true anymore. Your upper limit might also be below the "oldest" officially supported version. We expect people would still like to upload bugfixes for their TYPO3 4.x extensions even if the core is no longer officially supported next year. That's why we took that decision during the last typo3org-Sprint a few weeks ago. Christian. From typo3 at xopn.de Wed Sep 18 11:43:41 2013 From: typo3 at xopn.de (Christian Zenker) Date: Wed, 18 Sep 2013 11:43:41 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER References: Message-ID: Am 17.09.2013, 14:21 Uhr, schrieb Steffen Gebert : > Ah.. then indeed it's not possible. Query strings can only be matched > using an "if", not directly in the "location" declaration - but then I > cannot disable the interception. > > So if nobody comes up with a better idea, I would leave it globally > enabled. Is it possible to check if the Status Code is 500 and the Content-Type HTML? It would not make sense to deliver HTML if something else was delivered by the Apache. Christian. From tp at codem.dk Wed Sep 18 11:55:00 2013 From: tp at codem.dk (Thomas Petersen) Date: Wed, 18 Sep 2013 11:55:00 +0200 Subject: [TYPO3-dev] =?utf-8?q?sublink_is_not_showed_IFSUB_problem?= References: Message-ID: No sry. i still only get the mainNavi link lib.mainNavi = HMENU lib.mainNavi.entryLevel=0 lib.mainNavi.1 = TMENU lib.mainNavi.1 { wrap = expAll = 0 NO.allWrap =
  • |
    • NO.stdWrap.wrap = | RO < .NO RO = 1 CUR < .NO CUR = 1 CUR.allWrap =
  • |
    • CUR.stdWrap.wrap = | ACT < .CUR #Sub menu links IFSUB = 1 IFSUB.wrapItemAndSub=
  • |
    • IFSUB.stdWrap.wrap = | ACTIFSUB < .IFSUB CURIFSUB < .IFSUB } lib.mainNavi.2 < lib.mainNavi.1 Quote: Soren Malling (sorenmalling) wrote on Wed, 18 September 2013 11:31 ---------------------------------------------------- > Hi Thomas, > > Try and add a > > lib.mainMenu.2 < lib.mainMenu.1 > > to the bottom of the configuration > > > On Wed, Sep 18, 2013 at 11:23 AM, Thomas Petersen wrote: > > > Hi. > > > > I have this menu code, its working fine for the main menu, but the > > SUBlinks is not generated. > > I have made some pages under one of my mainlinks, so the pages is there. > > > > So its must be the IFSUB code thats something wrong with. > > Can someone maybe help ? > > > > lib.mainNavi.entryLevel=0 > > lib.mainNavi.1 = TMENU > > lib.mainNavi.1 { > > wrap = > > expAll = 0 > > NO.allWrap =
  • |
    • > > NO.stdWrap.wrap = | > > RO < .NO RO = 1 > > CUR < .NO CUR = 1 > > CUR.allWrap =
  • | > > CUR.stdWrap.wrap = | > > ACT < .CUR #Sub menu links > > IFSUB = 1 > > IFSUB.wrapItemAndSub=
  • |
    • > > IFSUB.stdWrap.wrap = | > > ACTIFSUB < .IFSUB > > CURIFSUB < .IFSUB > > } > > ______________________________**_________________ > > TYPO3-dev mailing list > > TYPO3-dev at lists.typo3.org > > http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-dev > > ---------------------------------------------------- From steffen.gebert at typo3.org Wed Sep 18 12:50:14 2013 From: steffen.gebert at typo3.org (Steffen Gebert) Date: Wed, 18 Sep 2013 17:50:14 +0700 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 But what else than HTML will be sent from Apache? The question is if want to show the TYPO3 errors to the end user or the nicer error site (which will otherwise only be shown, if the backend server is not reachable). Kind regards Steffen - -- Steffen Gebert TYPO3 Server Administration Team Member TYPO3 .... inspiring people to share! Get involved: http://typo3.org My wish list: https://www.amazon.de/registry/wishlist/922E3JYSQ7CV/ref=cm_wl_sb_v?sort=priority On 9/18/13 4:43 PM, Christian Zenker wrote: > Am 17.09.2013, 14:21 Uhr, schrieb Steffen Gebert > : > >> Ah.. then indeed it's not possible. Query strings can only be matched >> using an "if", not directly in the "location" declaration - but then I >> cannot disable the interception. >> >> So if nobody comes up with a better idea, I would leave it globally >> enabled. > > Is it possible to check if the Status Code is 500 and the Content-Type > HTML? It would not make sense to deliver HTML if something else was > delivered by the Apache. > > Christian. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJSOYVmAAoJEIskG/rSlyw4VH8H/2sLCnFaPTZ2VfQSbUWmQqiw kY0tmm2Cs86qP0wwJWg8DMszp/oG5LcRH1Nmgf6jXCaK+mFVeBOX44Clj5Z3ZKkr 48NWyfwqAlxrj9rwMKtCk/i532jIRu6mY19YakYDINNU6Oa/PESw+Y2KTCCr9wIu 9vPzl6KvdGtV3PLmWLmKI27MzuGc4H7cBOXNKRMpk6uqXg9oYZDWUbwtRzehrzbj GxAbBdeqDExO28b8CEfPmIbIIjGEQI+/j9LR5N5B30P23FK8lxOET6o1uRe3uBom fcjJN+fMW5HCzVxYveaMjbQYCVnyM0sxpZG9QFjPD5LveqoWWe51ZOKXNHURfCI= =VIiZ -----END PGP SIGNATURE----- From info at cybercraft.de Wed Sep 18 13:03:03 2013 From: info at cybercraft.de (JoH asenau) Date: Wed, 18 Sep 2013 13:03:03 +0200 Subject: [TYPO3-dev] sublink is not showed IFSUB problem In-Reply-To: References: Message-ID: Am 18.09.2013 11:23, schrieb Thomas Petersen: > Hi. > > I have this menu code, its working fine for the main menu, but the > SUBlinks is not generated. > I have made some pages under one of my mainlinks, so the pages is there. > > So its must be the IFSUB code thats something wrong with. > Can someone maybe help ? expAll = 0 should be your problem. Set it to 1 to always get the submenus rendered, otherwise they will only render for the "active" and "current" pages, in other words the "rootline" of the page you are currently on. 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 tp at codem.dk Wed Sep 18 14:06:14 2013 From: tp at codem.dk (Thomas Petersen) Date: Wed, 18 Sep 2013 14:06:14 +0200 Subject: [TYPO3-dev] =?utf-8?q?sublink_is_not_showed__IFSUB_problem?= References: Message-ID: Thx. it work now, but have another problem now, but im making a new question for that. From tp at codem.dk Wed Sep 18 14:12:06 2013 From: tp at codem.dk (Thomas Petersen) Date: Wed, 18 Sep 2013 14:12:06 +0200 Subject: [TYPO3-dev] =?utf-8?q?_Navi__HMENU_dropdown_issue?= Message-ID: Hi http://www.codem.dk Im new to TYPO3 TS but i have a menu, thats almost is working. But i have some issues with it. - If i select the 2. menu link, a drop down is showed, if i click the link, and try to get the mouseover again, the dropdown is not showed again. - If i select a link inside the dropmenu in 2. menu link, i get to the page, but now the 2. menu link is black, and is not showed as current/activ link. Can someone guide me here ? lib.mainNavi = HMENU lib.mainNavi.entryLevel=0 lib.mainNavi { 1 = TMENU 1 { wrap = #Expane All - 0=NO, 1=YES expAll = 1 NO.wrapItemAndSub =
  • |
    • NO.stdWrap.wrap = | RO < .NO #RO = 1 CUR < .NO CUR = 1 CUR.allWrap =
  • |
    • CUR.stdWrap.wrap = | IFSUB = 1 IFSUB { wrapItemAndSub =
  • |
    • stdWrap.wrap = | } ACT < .NO ACT = 1 ACTIFSUB < .IFSUB } 2 = TMENU 2 { wrap =
      |
    expAll = 1 NO.wrapItemAndSub =
  • |
    • IFSUB = 1 IFSUB { wrapItemAndSub =
  • |
    • } } From info at cybercraft.de Wed Sep 18 14:14:40 2013 From: info at cybercraft.de (JoH asenau) Date: Wed, 18 Sep 2013 14:14:40 +0200 Subject: [TYPO3-dev] sublink is not showed IFSUB problem In-Reply-To: References: Message-ID: Am 18.09.2013 14:06, schrieb Thomas Petersen: > Thx. it work now, but have another problem now, but im making a new > question for that. Maybe you can switch to another list then, since this one is for development _for_ TYPO3 which means modules, extensions and core development. Your question is more related to development _with_ TYPO3, which is integrating stuff with TypoScript and the like. So you should go to english list or maybe a list that fits your preferred language. 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 jigal.van.hemert at typo3.org Wed Sep 18 14:20:40 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Wed, 18 Sep 2013 14:20:40 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi, On 18-9-2013 11:40, Christian Zenker wrote: > Just FYI: This is not entirely true anymore. Your upper limit might also > be below the "oldest" officially supported version. We expect people > would still like to upload bugfixes for their TYPO3 4.x extensions even > if the core is no longer officially supported next year. That's why we > took that decision during the last typo3org-Sprint a few weeks ago. -1. When the job to mark extensions as outdated is up and running these extensions will be marked as "outdated" and the Extension Manager will show them as such and hide them in the Import extension screen. Part of the goal of the clean up is to "remove" (in not show directly on t3o and not show at all in EM) extensions which are not suitable for maintained versions of the core. -- Jigal van Hemert TYPO3 CMS Active Contributor TYPO3 .... inspiring people to share! Get involved: typo3.org From typo3 at xopn.de Wed Sep 18 14:39:59 2013 From: typo3 at xopn.de (Christian Zenker) Date: Wed, 18 Sep 2013 14:39:59 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER References: Message-ID: Am 18.09.2013, 14:20 Uhr, schrieb Jigal van Hemert : > Hi, > > On 18-9-2013 11:40, Christian Zenker wrote: >> Just FYI: This is not entirely true anymore. Your upper limit might also >> be below the "oldest" officially supported version. We expect people >> would still like to upload bugfixes for their TYPO3 4.x extensions even >> if the core is no longer officially supported next year. That's why we >> took that decision during the last typo3org-Sprint a few weeks ago. > > -1. When the job to mark extensions as outdated is up and running these > extensions will be marked as "outdated" and the Extension Manager will > show them as such and hide them in the Import extension screen. > > Part of the goal of the clean up is to "remove" (in not show directly on > t3o and not show at all in EM) extensions which are not suitable for > maintained versions of the core. > I think we are on the same side here. Outdated extension won't show up per default in the extension listing on typo3.org! But the extension author should still be able to upload a new extension - to fix a known bug or to state that it is outdated. People can still download them if they run such an old version of TYPO3 or if they visit the extension details view. I don't see any reason why anyone would want to prevent that...(?) Best regards, Christian. From xavier at typo3.org Wed Sep 18 14:43:29 2013 From: xavier at typo3.org (Xavier Perseguers) Date: Wed, 18 Sep 2013 14:43:29 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi, > On 18-9-2013 11:40, Christian Zenker wrote: >> Just FYI: This is not entirely true anymore. Your upper limit might also >> be below the "oldest" officially supported version. We expect people >> would still like to upload bugfixes for their TYPO3 4.x extensions even >> if the core is no longer officially supported next year. That's why we >> took that decision during the last typo3org-Sprint a few weeks ago. > > -1. When the job to mark extensions as outdated is up and running these > extensions will be marked as "outdated" and the Extension Manager will > show them as such and hide them in the Import extension screen. This is indeed something that is not documented and we wait since months for the TER cleanup. Now that the hard check is done, we all want the next part to be done. I asked many time who is responsible because it's just a matter of going through the list and mark entries. TER is cluttered with unmaintained extensions. From a first look it's great to see so many extensions but once you start using them, you wish there would be much less but usable and maintained, so please run the cleanup script and stick to what was agreed and publicly announced regarding the hard check. Kind regards -- Xavier Perseguers Release Manager TYPO3 4.6 TYPO3 .... inspiring people to share! Get involved: http://typo3.org From xavier at typo3.org Wed Sep 18 14:45:53 2013 From: xavier at typo3.org (Xavier Perseguers) Date: Wed, 18 Sep 2013 14:45:53 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi, > I think we are on the same side here. Outdated extension won't show up > per default in the extension listing on typo3.org! But the extension > author should still be able to upload a new extension - to fix a known > bug or to state that it is outdated. People can still download them if > they run such an old version of TYPO3 or if they visit the extension > details view. I don't see any reason why anyone would want to prevent > that...(?) We don't want extension authors to upload new versions that are still deprecated, they should take the opportunity to publish a fix for an official version of TYPO3, that's the deal with TER to get visibility, nothing more. We are really relax with the hard-check, the LTS is supported so why would you allow people to allow a fix for, say TYPO3 4.2? -- Xavier Perseguers Release Manager TYPO3 4.6 TYPO3 .... inspiring people to share! Get involved: http://typo3.org From eichelt at web.de Wed Sep 18 15:01:50 2013 From: eichelt at web.de (Stefan Reichelt) Date: Wed, 18 Sep 2013 15:01:50 +0200 Subject: [TYPO3-dev] Navi HMENU dropdown issue In-Reply-To: References: Message-ID: Hello Thomas, On 18/09/2013 14:12, Thomas Petersen wrote: > Can someone guide me here ? I think we'd need to see the output in the frontend to get a better understanding of what goes wrong. Anyway, this might be one (second one probably) of the problems, not sure. You've written: CUR.allWrap =
  • |
    • Since you copied .NO into .CUR then .CUR already has wrapItemAndSub set with the
  • -tag in it. So with the allWrap you add it a second time. You could change it to: CUR.wrapItemAndSub=
  • |
    • To have both classes in the LI-Tag. And little bit of cleaning up: 1. You can remove all the items which have no difference to .NO. This includes .ACT .RO and all .IFSUB types. Only add them if you truly need them to do something different than .NO. If they are not defined, .NO will be used anyway. 2. You can avoid all the '.ACT = 1' & '.CUR = 1' and so forth by setting '.NO = 1' and when you copy .NO, it copies the activation too. Kind regards Stefan From typo3 at xopn.de Wed Sep 18 15:32:29 2013 From: typo3 at xopn.de (Christian Zenker) Date: Wed, 18 Sep 2013 15:32:29 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER References: Message-ID: Hi Xavier. > so why would you allow people to allow a fix for, say TYPO3 4.2? It's not about that - I have to admit this is not an issue *yet*. But once the TYPO3 4 branch will officially be no longer supported in a year the cut will be a lot larger. > [extension authors] should take the opportunity to publish a fix for an > official version of TYPO3. Well in an ideal world this might work. Then everyone would have migrated their TYPO3 4.x projects to 6.2. But reality shows that this is usually not the case. Let's take an example: In one year, why would you expect anyone to make DAM compatible with TYPO3 6.0 just so that a small bugfix for an officially(!) no longer supported TYPO3 version can be delivered? An extension author would either complain and annoy some people or - even worse - just set the supported TYPO3 version to 6.2 without testing just that he is able to ship a bugfixed version. Just to emphasize: This is not about what extensions are displayed. This is only about what extensions can be uploaded! Still, you would not see extensions in TER that only work on the version 4 branch after TYPO3 6.2 has been released. And still the Extension Manager will only show extensions that are supposed to run with your installation. > We don't want extension authors to upload new versions that are still > deprecated The extensions are not deprecated. The TYPO3 Core version is. And this is an important difference. You can't decide that an extension author is no longer "allowed" to support his own extension just because the CMS isn't. Best regards. Christian. From tp at codem.dk Wed Sep 18 15:57:33 2013 From: tp at codem.dk (Thomas Petersen) Date: Wed, 18 Sep 2013 15:57:33 +0200 Subject: [TYPO3-dev] =?utf-8?q?Navi__HMENU_dropdown_issue?= References: Message-ID: Hi Stefan Im new to TS...But thx.. U have fix the 1. issue, and its also fixed with colors THX :-) Now i only gat the 2. issue, if i select a link in the dropdown, the top link is getting black, and not yellow, if we select the toplink. How much can i clean it up, if i # something out, them im getting some errors. Hope U or another can help with the 2. issue. Code right now at www.codem.dk lib.mainNavi = HMENU lib.mainNavi.entryLevel=0 lib.mainNavi { 1 = TMENU 1 { wrap = #Expane All - 0=NO, 1=YES expAll = 1 NO = 1 NO.wrapItemAndSub =
  • |
    • NO.stdWrap.wrap = | RO < .NO CUR < .NO CUR.wrapItemAndSub =
  • |
    • CUR.stdWrap.wrap = | IFSUB = 1 IFSUB { wrapItemAndSub =
  • |
    • stdWrap.wrap = | } ACT < .NO ACTIFSUB < .IFSUB } 2 = TMENU 2 { wrap =
      |
    expAll = 1 NO.wrapItemAndSub =
  • |
    • IFSUB = 1 IFSUB { wrapItemAndSub =
  • |
    • } } Quote: Stefan Reichelt (Songyu) wrote on Wed, 18 September 2013 15:01 ---------------------------------------------------- > Hello Thomas, > > On 18/09/2013 14:12, Thomas Petersen wrote: > > Can someone guide me here ? > > I think we'd need to see the output in the frontend to get a better > understanding of what goes wrong. > > > Anyway, this might be one (second one probably) of the problems, not > sure. You've written: > CUR.allWrap =
  • |
    • > > Since you copied .NO into .CUR then .CUR already has wrapItemAndSub set > with the
  • -tag in it. So with the allWrap you add it a second time. > You could change it to: > CUR.wrapItemAndSub=
  • |
    • > > To have both classes in the LI-Tag. > > And little bit of cleaning up: > 1. You can remove all the items which have no difference to .NO. This > includes .ACT .RO and all .IFSUB types. Only add them if you truly need > them to do something different than .NO. If they are not defined, .NO > will be used anyway. > > 2. You can avoid all the '.ACT = 1' & '.CUR = 1' and so forth by setting > '.NO = 1' and when you copy .NO, it copies the activation too. > > > Kind regards > Stefan ---------------------------------------------------- From jigal.van.hemert at typo3.org Wed Sep 18 16:22:06 2013 From: jigal.van.hemert at typo3.org (Jigal van Hemert) Date: Wed, 18 Sep 2013 16:22:06 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi, On 18-9-2013 15:32, Christian Zenker wrote: >> so why would you allow people to allow a fix for, say TYPO3 4.2? > > It's not about that - I have to admit this is not an issue *yet*. But > once the TYPO3 4 branch will officially be no longer supported in a year > the cut will be a lot larger. So, you (or someone else) are afraid of the number of extensions in TER? It was actually a complaint from the community that there are so many extensions and most of them do not work with any supported version of TYPO3. >> [extension authors] should take the opportunity to publish a fix for an >> official version of TYPO3. > > Well in an ideal world this might work. Then everyone would have > migrated their TYPO3 4.x projects to 6.2. But reality shows that this is > usually not the case. They have a year to do that. If an installation is not migrated by then the owner certainly isn't too interested in keeping anything up-to-date. Why should TER offer extensions for that installation? > Let's take an example: > In one year, why would you expect anyone to make DAM compatible with > TYPO3 6.0 just so that a small bugfix for an officially(!) no longer > supported TYPO3 version can be delivered? I don't expect any bugfixes for DAM to appear by then. > An extension author would either complain and annoy some people or - > even worse - just set the supported TYPO3 version to 6.2 without testing > just that he is able to ship a bugfixed version. Someone could do that, but should expect a lot of bug reports and if feedback is implemented by then that will show a lot of people who report problems. > Just to emphasize: This is not about what extensions are displayed. This > is only about what extensions can be uploaded! Exactly! And that is what should be prevented in the first place. > Still, you would not see extensions in TER that only work on the version > 4 branch after TYPO3 6.2 has been released. And still the Extension > Manager will only show extensions that are supposed to run with your > installation. That doesn't work (yet) in the EM, simply because there isn't enough data yet. And the extensions that don't work with any maintained branch will be marked as "outdated" and not show up in the Extension Manager at all. >> We don't want extension authors to upload new versions that are still >> deprecated > > The extensions are not deprecated. The TYPO3 Core version is. And this > is an important difference. You can't decide that an extension author is > no longer "allowed" to support his own extension just because the CMS > isn't. The extension is in that case "outdated" and will be labelled as such for that reason. -- Jigal van Hemert TYPO3 CMS Active Contributor TYPO3 .... inspiring people to share! Get involved: typo3.org From eichelt at web.de Wed Sep 18 16:53:53 2013 From: eichelt at web.de (Stefan Reichelt) Date: Wed, 18 Sep 2013 16:53:53 +0200 Subject: [TYPO3-dev] Navi HMENU dropdown issue In-Reply-To: References: Message-ID: On 18/09/2013 15:57, Thomas Petersen wrote: > Now i only gat the 2. issue, if i select a link in the dropdown, the top link is getting black, and not yellow, if we select the toplink. On your first level copy .CUR into .ACT, so both states get the '.current-page-item' class added ie.: ACT < .CUR .CUR stands for the currently selected page. .ACT stands for all pages which are in the rootline (parents) of the currently selected page. Kind regards Stefan PS: Nice, pleasant coloring on each menu item. :) From helmut.hummel at typo3.org Wed Sep 18 20:00:32 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Wed, 18 Sep 2013 20:00:32 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi Christian, On 18.09.13 11:40, Christian Zenker wrote: > Just FYI: This is not entirely true anymore. Your upper limit might also > be below the "oldest" officially supported version. We expect people would > still like to upload bugfixes for their TYPO3 4.x extensions even if the > core is no longer officially supported next year. That's why we took that > decision during the last typo3org-Sprint a few weeks ago. "Just FYI"? These things have been discussed, decided and communicated[1] months ago. I did not hear any complaints about that so far. Now reading a "FYI" in a unrelated thread that something (not entirely but still) different has been decided "during the last typo3org-Sprint a few weeks ago" is kind of surprising. Kind regards, Helmut [1]http://typo3.org/news/article/announcing-ter-cleanup-process/ -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From helmut.hummel at typo3.org Wed Sep 18 20:32:30 2013 From: helmut.hummel at typo3.org (Helmut Hummel) Date: Wed, 18 Sep 2013 20:32:30 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi Christian, On 18.09.13 15:32, Christian Zenker wrote: > The extensions are not deprecated. The TYPO3 Core version is. The whole idea of the TER cleanup is, that extensions are by definition deprecated (outdated) when they are not suppored by a current TYPO3 version. In fact by deprecating certain TYPO3 Core versions, how can an extension not be deprecated by definition as it requires a TYPO3 Core version we suggest not to use any more? Extensions are not standalone, but in fact extending the core. > And this is an important difference. I don't think so. > You can't decide that an extension author is no > longer "allowed" to support his own extension just because the CMS isn't. We can't decide anything for anybody. There are (and there will always be) people that are still using TYPO3 4.2 and according extensions. But we can set up rules which we think make sense for the platform (which is the TYPO3 Core and the TER) in total. There is a broad consensus which TYPO3 versions are supported for what amount of time. It has been decided that this support policy should be reflected in the TER as it belongs to the platform. So, if there is a need for extension authors to upload extensions for deprecated TYPO3 versions in one year, we need to acknoledge that there is still a need for these TYPO3 versions which should result in longer support for these versions. Am I missing something? Kind regards, Helmut -- Helmut Hummel Release Manager TYPO3 6.0 TYPO3 Core Developer, TYPO3 Security Team Member TYPO3 .... inspiring people to share! Get involved: typo3.org From tp at codem.dk Wed Sep 18 21:35:15 2013 From: tp at codem.dk (Thomas Petersen) Date: Wed, 18 Sep 2013 21:35:15 +0200 Subject: [TYPO3-dev] =?utf-8?q?Navi__HMENU_dropdown_issue?= References: Message-ID: Hi Stefan Thx, i think its nice too. Im sry if i dont get this, but now i have added the current-page-item to ACT part, and i have changed ACT < .NO to ACT < .CUR and if i select a sublink in mainlink 2 i get a "black" mainlink, its not selected as Current-page-link. My code is. lib.mainNavi = HMENU lib.mainNavi.entryLevel=0 lib.mainNavi { 1 = TMENU 1 { wrap = #Expane All - 0=NO, 1=YES expAll = 1 NO = 1 NO.wrapItemAndSub =
  • |
    • NO.stdWrap.wrap = | RO < .NO CUR < .NO CUR.wrapItemAndSub =
  • |
    • CUR.stdWrap.wrap = | IFSUB = 1 IFSUB { wrapItemAndSub =
  • |
    • stdWrap.wrap = | } ACT < .CUR ACT.wrapItemAndSub =
  • |
    • ACT.stdWrap.wrap = | ACTIFSUB < .IFSUB } 2 = TMENU 2 { wrap =
      |
    expAll = 1 NO.wrapItemAndSub =
  • |
    • IFSUB = 1 IFSUB { wrapItemAndSub =
  • |
    • } } Quote: Stefan Reichelt (Songyu) wrote on Wed, 18 September 2013 16:53 ---------------------------------------------------- > On 18/09/2013 15:57, Thomas Petersen wrote: > > Now i only gat the 2. issue, if i select a link in the dropdown, the top link is getting black, and not yellow, if we select the toplink. > > On your first level copy .CUR into .ACT, so both states get the > '.current-page-item' class added ie.: > ACT < .CUR > > ..CUR stands for the currently selected page. > ..ACT stands for all pages which are in the rootline (parents) of the > currently selected page. > > > Kind regards > Stefan > > PS: Nice, pleasant coloring on each menu item. :) ---------------------------------------------------- From eichelt at web.de Wed Sep 18 22:15:56 2013 From: eichelt at web.de (Stefan Reichelt) Date: Wed, 18 Sep 2013 22:15:56 +0200 Subject: [TYPO3-dev] Navi HMENU dropdown issue In-Reply-To: References: Message-ID: Hi Thomas, On 18/09/2013 21:35, Thomas Petersen wrote: > ACT.wrapItemAndSub =
  • |
    • > ACT.stdWrap.wrap = | Remove those two lines. By copying it from .CUR, you already add the correct '.wrapItemAndSub' & '.stdWrap.wrap' to .ACT, so no need to do it again. > ACTIFSUB < .IFSUB Also, I think you might need to change this into 'ACTIFSUB < .ACT', so that both states will have the same effect. Kind regards Stefan From tp at codem.dk Wed Sep 18 23:10:03 2013 From: tp at codem.dk (Thomas Petersen) Date: Wed, 18 Sep 2013 23:10:03 +0200 Subject: [TYPO3-dev] =?utf-8?q?Navi__HMENU_dropdown_issue?= References: Message-ID: Hi Stefan. THX alot, its working now (Y) :-) If someone need the ex. code its under this text, feel free to clean up the code, but plz. leave a post here with the code, if someone clean it up.. Working code. lib.mainNavi = HMENU lib.mainNavi.entryLevel=0 lib.mainNavi { 1 = TMENU 1 { wrap = #Expane All - 0=NO, 1=YES expAll = 1 NO = 1 NO.wrapItemAndSub =
  • |
    • NO.stdWrap.wrap = | RO < .NO CUR < .NO CUR.wrapItemAndSub =
  • |
    • CUR.stdWrap.wrap = | IFSUB = 1 IFSUB { wrapItemAndSub =
  • |
    • stdWrap.wrap = | } ACT < .CUR ACTIFSUB < .ACT } 2 = TMENU 2 { wrap =
      |
    expAll = 1 NO.wrapItemAndSub =
  • |
    • IFSUB = 1 IFSUB { wrapItemAndSub =
  • |
    • } } From xavier at typo3.org Thu Sep 19 08:33:02 2013 From: xavier at typo3.org (Xavier Perseguers) Date: Thu, 19 Sep 2013 08:33:02 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: >> Just FYI: This is not entirely true anymore. Your upper limit might also >> be below the "oldest" officially supported version. We expect people >> would >> still like to upload bugfixes for their TYPO3 4.x extensions even if the >> core is no longer officially supported next year. That's why we took that >> decision during the last typo3org-Sprint a few weeks ago. > > "Just FYI"? > > These things have been discussed, decided and communicated[1] months > ago. I did not hear any complaints about that so far. > > Now reading a "FYI" in a unrelated thread that something (not entirely > but still) different has been decided "during the last typo3org-Sprint a > few weeks ago" is kind of surprising. +1 We discover by chance an important conceptual change which has not been communicated nor discussed. -- Xavier Perseguers Release Manager TYPO3 4.6 TYPO3 .... inspiring people to share! Get involved: http://typo3.org From xavier at typo3.org Thu Sep 19 08:36:51 2013 From: xavier at typo3.org (Xavier Perseguers) Date: Thu, 19 Sep 2013 08:36:51 +0200 Subject: [TYPO3-dev] EXT Extension uploader (extension_uploader) - no upload to TER In-Reply-To: References: Message-ID: Hi, > But we can set up rules which we think make sense for the platform > (which is the TYPO3 Core and the TER) in total. > > There is a broad consensus which TYPO3 versions are supported for what > amount of time. It has been decided that this support policy should be > reflected in the TER as it belongs to the platform. Exactly. TER is hosted on typo3.org, this is something official that to some extent is endorsed by the community. Just as an app store has rules to have the privilege to be hosted and listed there, the TER does. We don't ask much from extension authors, just that they show they are still willing to support an extension by checking it at least from time to time (that is when a new version is rolled out), adapt it if needed and upload a new version stating that it is "still" compatible. This is not to bother anyone but to help end users to wisely choose which extension is likely to be "better suited" than another. Kind regards -- Xavier Perseguers Release Manager TYPO3 4.6 TYPO3 .... inspiring people to share! Get involved: http://typo3.org From mueller at cyperfection.de Thu Sep 19 14:30:26 2013 From: mueller at cyperfection.de (=?ISO-8859-15?Q?Chris_M=FCller?=) Date: Thu, 19 Sep 2013 14:30:26 +0200 Subject: [TYPO3-dev] eID script and admin panel properties Message-ID: Hello, I have a web page with an ajax request. On the web page has a logged in backend user the possibility to use the admin panel to show hidden records. So far so good. On this page there as an ajax request to get more data. Now I am trying to get also hidden records in the eID script of the ajax request. I tried the following: $GLOBALS['TSFE'] = GeneralUtility::makeInstance( 'TYPO3\\CMS\\Frontend\\Controller\\TypoScriptFrontendController', $GLOBALS['TYPO3_CONF_VARS'], $pid, 0 ); $GLOBALS['TSFE']->connectToDB(); $GLOBALS['TSFE']->initFEuser(); $GLOBALS['TSFE']->determineId(); $GLOBALS['TSFE']->initTemplate(); $GLOBALS['TSFE']->getConfigArray(); $BE_USER = $GLOBALS['TSFE']->initializeBackendUser(); $BE_USER->initializeAdminPanel(); if ($BE_USER->adminPanel instanceof \TYPO3\CMS\Frontend\View\AdminPanelView) { \TYPO3\CMS\Core\Core\Bootstrap::getInstance() ->initializeLanguageObject(); } $BE_USER->displayAdminPanel(); $preview = $BE_USER->adminPanel->extGetFeAdminValue('preview'); But $preview is always null. Can someone give me a hint. Perhaps the properties of the admin panel are stored in some session? Regards, Chris. From gianluca.strafella at webformat.com Fri Sep 20 09:03:40 2013 From: gianluca.strafella at webformat.com (Gianluca Strafella) Date: Fri, 20 Sep 2013 09:03:40 +0200 Subject: [TYPO3-dev] Extbase relation to tt_content - TCA overwritten In-Reply-To: References: Message-ID: Hi Dirk, this seem be caused by some code in the file ext_tables.php (after you save extention by extention builder), can you post this file ? Gianluca Strafella Software Developer gianluca.strafella at webformat.com Tel. +39-0427-926.389 WEBFORMAT srl ? www.webformat.com Via S. Francesco d'Assisi, 6 ? 20122 MILANO Corte Europa, 12 - 33097 SPILIMBERGO (PN) Il 14/09/2013 22:52, Dirk Wenzel ha scritto: > Hi, > I'm building an extension where a model should have an m:n relation to > tt_content records. > > When setting up this relation in extension builder the TCA for > tt_content is overwritten. Content elements can not be edited in BE > anymore since the edit window is empty. Also the wizard for creating > content elements doesn't show the icon for tt_content anymore. Instead > there is the standard icon for extbase entities without a label. > > > I followed the instructions under [1]. The above case is mentioned > there. But I don't understand how to avoid it. (see below for details) > > Thanks in advance > Dirk > > Model: > > ========== > Option > Object Type: entity > Is Aggregat Root: yes > Enable Sorting: yes > ========== > Properties > [...] > ========== > Relations > ========= Name: ContentElements > TtContent---------------Type: m:n > Object Type: entity ========== > Is Aggregat Root: yes > Enable Sorting: yes > ========= > Properties > -Points > ========= > > Generated ext_typoscript_setup.txt: > config.tx_extbase{ > persistence{ > classes{ > > webfox\T3rating\Domain\Model\TtContent { > mapping { > tableName = tt_content > recordType = Tx_T3rating_TtContent > } > } > > } > } > } > > Generated [...]TCA/TtContent.php: empty > > [1] > http://wiki.typo3.org/T3Doc/Extension_Builder/Mapping_to_tables_and_extending_classes > From kmdpls at egmont.com Fri Sep 20 14:55:36 2013 From: kmdpls at egmont.com (Peter Lund-Sørensen) Date: Fri, 20 Sep 2013 14:55:36 +0200 Subject: [TYPO3-dev] =?utf-8?q?_TYPO3_and_DIBS?= Message-ID: We're using DIBS with our TYPO3. We need to get this work with instant capture/capturenow. DIBS says this must be indicated in TYPO3, but I can't find this setting. From soren.malling at gmail.com Fri Sep 20 15:08:52 2013 From: soren.malling at gmail.com (=?ISO-8859-1?Q?S=F8ren_Malling?=) Date: Fri, 20 Sep 2013 15:08:52 +0200 Subject: [TYPO3-dev] TYPO3 and DIBS In-Reply-To: References: Message-ID: Hi Peter, What payment extension are you using to handle your payments? Cheers, S?ren On Fri, Sep 20, 2013 at 2:55 PM, Peter Lund-S?rensen wrote: > We're using DIBS with our TYPO3. We need to get this work with instant > capture/capturenow. DIBS says this must be indicated in TYPO3, but I can't > find this setting. > ______________________________**_________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-dev > From m.howells-mead at frappant.ch Fri Sep 20 15:09:23 2013 From: m.howells-mead at frappant.ch (m.howells-mead at frappant.ch) Date: 20 Sep 2013 15:09:23 +0200 Subject: [TYPO3-dev] =?utf-8?q?TYPO3_and_DIBS?= Message-ID: Besten Dank f?r Ihre Nachricht. Ich bin zurzeit abwesend. Ist Ihre E_Mail dringend, nehmen Sie bitte Kontakt mit meinen Kollegen unter support at frappant.ch auf. Ihre E-Mail wird nicht weitergeleitet. Ich bin am Dienstag, den. 24 September, gerne f?r Sie wieder da! Mit freundlichen Gr?ssen Mark Howells-Mead Technische Leitung, !frappant Webfactory From m.howells-mead at frappant.ch Fri Sep 20 15:09:27 2013 From: m.howells-mead at frappant.ch (m.howells-mead at frappant.ch) Date: 20 Sep 2013 15:09:27 +0200 Subject: [TYPO3-dev] =?utf-8?q?TYPO3_and_DIBS?= Message-ID: Besten Dank f?r Ihre Nachricht. Ich bin zurzeit abwesend. Ist Ihre E_Mail dringend, nehmen Sie bitte Kontakt mit meinen Kollegen unter support at frappant.ch auf. Ihre E-Mail wird nicht weitergeleitet. Ich bin am Dienstag, den. 24 September, gerne f?r Sie wieder da! Mit freundlichen Gr?ssen Mark Howells-Mead Technische Leitung, !frappant Webfactory From tp at codem.dk Fri Sep 20 15:22:48 2013 From: tp at codem.dk (Thomas Petersen) Date: Fri, 20 Sep 2013 15:22:48 +0200 Subject: [TYPO3-dev] =?utf-8?q?_Page_404_=28500=29_error_handler?= Message-ID: Hi. Im new to the TYPO3 univers. Can see that if i add this to localconf file, then i can make 2 pages (realURL) that can show me the Page 404(500) errors. $TYPO3_CONF_VARS["FE"]["pageNotFound_handling"] = 'http://www.my-domain.com/not-found.html'; $TYPO3_CONF_VARS["FE"]["pageNotFound_handling_statheader"] = 'HTTP/1.1 404 Not Found'; $TYPO3_CONF_VARS["FE"]["pageNotAvailable_handling "] = 'http://www.my-domain.com/not-available.html'; $TYPO3_CONF_VARS["FE"]["pageNotAvailable_handling_statheader"] = 'HTTP/1.1 500 Not Available'; But i have the TYPO3 v.6 and here i can find the FE section like. 'FE' => array( 'loginSecurityLevel' => 'rsa', ), How do i add the TYPO3_CONF_VARS to the new localconf layout ? From soren.malling at gmail.com Fri Sep 20 15:26:52 2013 From: soren.malling at gmail.com (=?ISO-8859-1?Q?S=F8ren_Malling?=) Date: Fri, 20 Sep 2013 15:26:52 +0200 Subject: [TYPO3-dev] Page 404 (500) error handler In-Reply-To: References: Message-ID: Hi Thomas, Just add like 'loginSecurityLevel' so it will look like this 'FE' => array( 'loginSecurityLevel' => 'rsa', 'pageNotFound_handling' => 'your URL', 'pageNotFound_handling_statheader' => 'The header' ), On Fri, Sep 20, 2013 at 3:22 PM, Thomas Petersen wrote: > Hi. > Im new to the TYPO3 univers. > Can see that if i add this to localconf file, then i can make 2 pages > (realURL) that can show me the Page 404(500) errors. > > $TYPO3_CONF_VARS["FE"]["**pageNotFound_handling"] = ' > http://www.my-domain.com/not-**found.html > '; > $TYPO3_CONF_VARS["FE"]["**pageNotFound_handling_**statheader"] = > 'HTTP/1.1 404 Not Found'; > $TYPO3_CONF_VARS["FE"]["**pageNotAvailable_handling "] = ' > http://www.my-domain.com/not-**available.html > '; > $TYPO3_CONF_VARS["FE"]["**pageNotAvailable_handling_**statheader"] = > 'HTTP/1.1 500 Not Available'; > > But i have the TYPO3 v.6 and here i can find the FE section like. > 'FE' => array( > 'loginSecurityLevel' => 'rsa', > ), > > How do i add the TYPO3_CONF_VARS to the new localconf layout ? > ______________________________**_________________ > TYPO3-dev mailing list > TYPO3-dev at lists.typo3.org > http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-dev > From christian at futterlieb.ch Fri Sep 20 16:55:33 2013 From: christian at futterlieb.ch (Christian Futterlieb) Date: Fri, 20 Sep 2013 16:55:33 +0200 Subject: [TYPO3-dev] Page 404 (500) error handler In-Reply-To: References: Message-ID: Hi > Just add like 'loginSecurityLevel' so it will look like this > > 'FE' => array( > 'loginSecurityLevel' => 'rsa', > 'pageNotFound_handling' => 'your URL', > 'pageNotFound_handling_statheader' => 'The header' > > ), Or (imho) better: create a file typo3conf/AdditionalConfiguration.php and put your configurations there. And: write the configuration like this: $GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFound_handling'] ... ^^^^^^^^^^^^^^^^^^^^^^^^^^^ See also: http://wiki.typo3.org/Upgrade#Upgrading_to_6.0 Regards, Chrisitian From tp at codem.dk Fri Sep 20 23:24:01 2013 From: tp at codem.dk (Thomas Petersen) Date: Fri, 20 Sep 2013 23:24:01 +0200 Subject: [TYPO3-dev] =?utf-8?q?Page_404_=28500=29_error_handler?= References: Message-ID: Hi U2 Thx. i just have one question whats the ....code... for 400 Bad Request, if we look at the code layout for the 404 $TYPO3_CONF_VARS["FE"]["pageNotFound_handling_statheader"] = 'HTTP/1.1 404 Not Found'; From christian at futterlieb.ch Mon Sep 23 10:30:35 2013 From: christian at futterlieb.ch (Christian Futterlieb) Date: Mon, 23 Sep 2013 10:30:35 +0200 Subject: [TYPO3-dev] Page 404 (500) error handler In-Reply-To: References: Message-ID: Hi Thomas > whats the ....code... for 400 Bad Request, if we look at the code layout > for the 404 > $TYPO3_CONF_VARS["FE"]["pageNotFound_handling_statheader"] = 'HTTP/1.1 > 404 Not Found'; Maybe you mean 'HTTP/1.1 400 Bad Request'. But: be sure to send the correct headers, see https://tools.ietf.org/html/rfc2616#section-10.4 Regards, Christian From Robert.Williams at stimme-der-hoffnung.de Tue Sep 24 09:33:36 2013 From: Robert.Williams at stimme-der-hoffnung.de (Robert Williams) Date: Tue, 24 Sep 2013 07:33:36 +0000 Subject: [TYPO3-dev] File Collection - Type = Folder from Storage Message-ID: Hello, We would like to use File Collection (TYPO3 6). What is the concept of Type = "Folder from Storage"? How can we work with the files when there are no reference records stored for each file in the database? Gru? Robert Robert Williams B.S. Web-Development STIMME DER HOFFNUNG Adventist Media Center Sandwiesenstr. 35 D - 64665 Alsbach-Haehnlein Tel: +49 (0) 62 57 - 5 06 53-18 Fax: +49 (0) 62 57 - 5 06 53-70 E-Mail: robert.williams at stimme-der-hoffnung.de STIMME DER HOFFNUNG e.V. VR 1293, Amtsgericht Darmstadt Steuer-Nr. 007 250 80653 Ust-ID: DE111671780 www.bibelstudien-institut.de www.bibelinfo.de www.hope-channel.de www.ichwillleben.eu www.stimme-der-hoffnung.de From philipp.gampe at typo3.org Tue Sep 24 09:44:09 2013 From: philipp.gampe at typo3.org (Philipp Gampe) Date: Tue, 24 Sep 2013 09:44:09 +0200 Subject: [TYPO3-dev] File Collection - Type = Folder from Storage References: Message-ID: Hi Robert Williams, Robert Williams wrote: > We would like to use File Collection (TYPO3 6). What is the concept of > Type = "Folder from Storage"? How can we work with the files when there > are no reference records stored for each file in the database? FAL can also work with references to folders. In this case, all files in the folder reference are returned. Best regards -- Philipp Gampe ? PGP-Key 0AD96065 ? TYPO3 UG Bonn/K?ln Documentation ? Active contributor TYPO3 CMS TYPO3 .... inspiring people to share! From Robert.Williams at stimme-der-hoffnung.de Tue Sep 24 09:52:12 2013 From: Robert.Williams at stimme-der-hoffnung.de (Robert Williams) Date: Tue, 24 Sep 2013 07:52:12 +0000 Subject: [TYPO3-dev] File Collection - Type = Folder from Storage In-Reply-To: References: Message-ID: Hello Philipp, We would like to display every image of the file collection, but for this we need the file reference ID to display the image with TypoScript. How would we go about doing this with the below information? Additional question is would this be multi-lingual? Best Regards Robert -----Urspr?ngliche Nachricht----- Von: typo3-dev-bounces at lists.typo3.org [mailto:typo3-dev-bounces at lists.typo3.org] Im Auftrag von Philipp Gampe Gesendet: Dienstag, 24. September 2013 09:44 An: typo3-dev at lists.typo3.org Betreff: Re: [TYPO3-dev] File Collection - Type = Folder from Storage Hi Robert Williams, Robert Williams wrote: > We would like to use File Collection (TYPO3 6). What is the concept of > Type = "Folder from Storage"? How can we work with the files when > there are no reference records stored for each file in the database? FAL can also work with references to folders. In this case, all files in the folder reference are returned. Best regards -- Philipp Gampe ? PGP-Key 0AD96065 ? TYPO3 UG Bonn/K?ln Documentation ? Active contributor TYPO3 CMS TYPO3 .... inspiring people to share! _______________________________________________ TYPO3-dev mailing list TYPO3-dev at lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev From philipp.gampe at typo3.org Tue Sep 24 10:59:12 2013 From: philipp.gampe at typo3.org (Philipp Gampe) Date: Tue, 24 Sep 2013 10:59:12 +0200 Subject: [TYPO3-dev] File Collection - Type = Folder from Storage References: Message-ID: Hi Robert, Robert Williams wrote: > We would like to display every image of the file collection, but for this > we need the file reference ID to display the image with TypoScript. How > would we go about doing this with the below information? Additional > question is would this be multi-lingual? I do not know for sure, please have a look how the file element from tt_content does this. Best regards -- Philipp Gampe ? PGP-Key 0AD96065 ? TYPO3 UG Bonn/K?ln Documentation ? Active contributor TYPO3 CMS TYPO3 .... inspiring people to share! From fsu-lists at cobweb.ch Tue Sep 24 13:59:53 2013 From: fsu-lists at cobweb.ch (=?UTF-8?B?RnJhbsOnb2lzIFN1dGVy?=) Date: Tue, 24 Sep 2013 13:59:53 +0200 Subject: [TYPO3-dev] File Collection - Type = Folder from Storage In-Reply-To: References: Message-ID: Hi Robert, > We would like to display every image of the file collection, but for > this we need the file reference ID to display the image with > TypoScript. How would we go about doing this with the below > information? Additional question is would this be multi-lingual? The documentation of the FILES object should help you: http://docs.typo3.org/typo3cms/TyposcriptReference/ContentObjects/Files/Index.html Cheers -- Francois Suter Work: Cobweb Development Sarl - http://www.cobweb.ch TYPO3: Help the project! - http://typo3.org/contribute/ Appreciate my work? Support me - http://www.monpetitcoin.com/en/francois/support-me/ From Robert.Williams at stimme-der-hoffnung.de Tue Sep 24 17:21:21 2013 From: Robert.Williams at stimme-der-hoffnung.de (Robert Williams) Date: Tue, 24 Sep 2013 15:21:21 +0000 Subject: [TYPO3-dev] File Collection - Type = Folder from Storage In-Reply-To: References: Message-ID: Francois, Thank you, Robert -----Urspr?ngliche Nachricht----- Von: typo3-dev-bounces at lists.typo3.org [mailto:typo3-dev-bounces at lists.typo3.org] Im Auftrag von Fran?ois Suter Gesendet: Dienstag, 24. September 2013 14:00 An: typo3-dev at lists.typo3.org Betreff: Re: [TYPO3-dev] File Collection - Type = Folder from Storage Hi Robert, > We would like to display every image of the file collection, but for > this we need the file reference ID to display the image with > TypoScript. How would we go about doing this with the below > information? Additional question is would this be multi-lingual? The documentation of the FILES object should help you: http://docs.typo3.org/typo3cms/TyposcriptReference/ContentObjects/Files/Index.html Cheers -- Francois Suter Work: Cobweb Development Sarl - http://www.cobweb.ch TYPO3: Help the project! - http://typo3.org/contribute/ Appreciate my work? Support me - http://www.monpetitcoin.com/en/francois/support-me/ _______________________________________________ TYPO3-dev mailing list TYPO3-dev at lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev From i-litovan at yandex.ru Wed Sep 25 13:37:26 2013 From: i-litovan at yandex.ru (Иван) Date: Wed, 25 Sep 2013 13:37:26 +0200 Subject: [TYPO3-dev] =?utf-8?q?_GSEXY_-_UNIVERCAL_CATECORIZATOR_ALL_IN_BE?= Message-ID: ????? ????? ????? ???????... ????????? ????????????... Soon it will be possible to download ... Prepares documentation ... http://www.youtube.com/watch?v=I4aGNcQuiMA -- Ivan i-litovan at yandex.ru http://ivan-web-blog.ru/ From shanmugarajan.k at tcs.com Thu Sep 26 08:18:33 2013 From: shanmugarajan.k at tcs.com (shanmugarajan.k at tcs.com) Date: Thu, 26 Sep 2013 11:48:33 +0530 Subject: [TYPO3-dev] TYPO3 : RealURL Version History in extension repository Message-ID: Dear All Currently, it seems the version history is not available in TYPO3 Extension repository. For example : RealURL, direct_mail http://typo3.org/extensions/repository/view/realurl Hope this could help to check the overview on the extension compatibilty of TYPO3 Versions and security fixes details. Thanks & regards Shan =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you From typo3 at ringerge.org Thu Sep 26 08:26:40 2013 From: typo3 at ringerge.org (Georg Ringer) Date: Thu, 26 Sep 2013 08:26:40 +0200 Subject: [TYPO3-dev] TYPO3 : RealURL Version History in extension repository In-Reply-To: References: Message-ID: Hi, Am 26.09.2013 08:18, schrieb shanmugarajan.k at tcs.com: > Currently, it seems the version history is not available in TYPO3 > Extension repository. For example : RealURL, direct_mail This is because insecure versions are not listed. Georg From dmitry.dulepov at gmail.com Thu Sep 26 08:43:07 2013 From: dmitry.dulepov at gmail.com (Dmitry Dulepov) Date: Thu, 26 Sep 2013 10:43:07 +0400 Subject: [TYPO3-dev] [TYPO3-english] WARNING! RealURL 1.12.7 Message-ID: Hi all! Please, do not download or install that versions. Details will follow. -- Dmitry Dulepov Today is a good day to have a good day. From typo3 at ringerge.org Thu Sep 26 09:14:15 2013 From: typo3 at ringerge.org (Georg Ringer) Date: Thu, 26 Sep 2013 09:14:15 +0200 Subject: [TYPO3-dev] Re: [TYPO3-english] WARNING! RealURL 1.12.7 In-Reply-To: References: Message-ID: Am 26.09.2013 08:43, schrieb Dmitry Dulepov: > Hi all! > > Please, do not download or install that versions. Details will follow. sorry for the misunderstanding, everything is absolutly fine and secure with the version in TER. Georg Ringer, current Leader of the Security Team From typo3 at thomasnu.ch Thu Sep 26 09:24:44 2013 From: typo3 at thomasnu.ch (Thomas Nussbaumer) Date: Thu, 26 Sep 2013 09:24:44 +0200 Subject: [TYPO3-dev] [TYPO3-english] WARNING! RealURL 1.12.7 In-Reply-To: References: Message-ID: Why the comical view in http://typo3.org/extensions/repository/view/realurl ? Am 26.09.2013 09:14, schrieb Georg Ringer: > Am 26.09.2013 08:43, schrieb Dmitry Dulepov: >> Hi all! >> >> Please, do not download or install that versions. Details will follow. > > sorry for the misunderstanding, everything is absolutly fine and secure > with the version in TER. > > Georg Ringer, current Leader of the Security Team > > From xavier at typo3.org Thu Sep 26 09:29:07 2013 From: xavier at typo3.org (Xavier Perseguers) Date: Thu, 26 Sep 2013 09:29:07 +0200 Subject: [TYPO3-dev] [TYPO3-english] WARNING! RealURL 1.12.7 In-Reply-To: References: Message-ID: > Why the comical view in > http://typo3.org/extensions/repository/view/realurl ? Every other version has been marked as insecure and is as such automatically "hidden"... -- Xavier Perseguers Release Manager TYPO3 4.6 TYPO3 .... inspiring people to share! Get involved: http://typo3.org From ralf.rene at online.de Thu Sep 26 10:39:21 2013 From: ralf.rene at online.de (=?UTF-8?B?UmFsZi1SZW5lIFNjaHLDtmRlcg==?=) Date: Thu, 26 Sep 2013 10:39:21 +0200 Subject: [TYPO3-dev] [TYPO3-english] WARNING! RealURL 1.12.7 In-Reply-To: References: Message-ID: Am 26.09.2013 09:29, schrieb Xavier Perseguers: >> Why the comical view in >> http://typo3.org/extensions/repository/view/realurl ? > > Every other version has been marked as insecure and is as such > automatically "hidden"... > but for the graph this seems very confusing... could not download they is OK, but not showing the history is imho not the right solution... -- image[FORMAT] - Ralf-Ren? Schr?der http://www.image-format.eu ... Wir geben Ihrem Image das richtige Format From t3ng at bernd-wilke.net Thu Sep 26 16:56:06 2013 From: t3ng at bernd-wilke.net (bernd wilke) Date: Thu, 26 Sep 2013 16:56:06 +0200 Subject: [TYPO3-dev] [TYPO3-english] WARNING! RealURL 1.12.7 In-Reply-To: References: Message-ID: Am 26.09.13 10:39, schrieb Ralf-Rene Schr?der: > Am 26.09.2013 09:29, schrieb Xavier Perseguers: >>> Why the comical view in >>> http://typo3.org/extensions/repository/view/realurl ? >> >> Every other version has been marked as insecure and is as such >> automatically "hidden"... >> > but for the graph this seems very confusing... > could not download they is OK, but not showing the history is imho not > the right solution... > the graph may be damaged, more problematic is the loose of all history/ manual information of earlier versions. So you can't see what to do if you still have an older version: Were there changes in an extension which need big reconfiguration in case of an update? what changes are neccessary? bernd -- http://www.pi-phi.de/cheatsheet.html From dmitry.dulepov at gmail.com Thu Sep 26 19:31:13 2013 From: dmitry.dulepov at gmail.com (Dmitry Dulepov) Date: Thu, 26 Sep 2013 21:31:13 +0400 Subject: [TYPO3-dev] [TYPO3-english] WARNING! RealURL 1.12.7 In-Reply-To: References: Message-ID: Hi! bernd wilke wrote: > the graph may be damaged, more problematic is the loose of all history/ > manual information of earlier versions. > So you can't see what to do if you still have an older version: > Were there changes in an extension which need big reconfiguration in > case of an update? what changes are neccessary? Changes are available in the ChangeLog file in the extension. Manual can be found in Git. There are tags for each released version. -- Dmitry Dulepov Today is a good day to have a good day. From typo3 at ringerge.org Fri Sep 27 05:57:02 2013 From: typo3 at ringerge.org (Georg Ringer) Date: Fri, 27 Sep 2013 05:57:02 +0200 Subject: [TYPO3-dev] [TYPO3-english] WARNING! RealURL 1.12.7 In-Reply-To: References: Message-ID: Hi, Am 26.09.2013 16:56, schrieb bernd wilke: > the graph may be damaged, more problematic is the loose of all history/ > manual information of earlier versions. > So you can't see what to do if you still have an older version: > Were there changes in an extension which need big reconfiguration in > case of an update? what changes are neccessary? IMO you shouldn't trust a textarea which is quite limited alone. Georg From t3ng at bernd-wilke.net Fri Sep 27 09:11:06 2013 From: t3ng at bernd-wilke.net (bernd wilke) Date: Fri, 27 Sep 2013 09:11:06 +0200 Subject: [TYPO3-dev] [TYPO3-english] WARNING! RealURL 1.12.7 In-Reply-To: References: Message-ID: Am 26.09.13 19:31, schrieb Dmitry Dulepov: > Hi! > > bernd wilke wrote: >> the graph may be damaged, more problematic is the loose of all history/ >> manual information of earlier versions. >> So you can't see what to do if you still have an older version: >> Were there changes in an extension which need big reconfiguration in >> case of an update? what changes are neccessary? > > Changes are available in the ChangeLog file in the extension. Manual can > be found in Git. There are tags for each released version. > my remark was not targeted to realurl. it is a problem of TER and extensions which do not have an own changelog outside the TER upload-messages. bernd -- http://www.pi-phi.de/cheatsheet.html From Robert.Williams at stimme-der-hoffnung.de Mon Sep 30 14:20:01 2013 From: Robert.Williams at stimme-der-hoffnung.de (Robert Williams) Date: Mon, 30 Sep 2013 12:20:01 +0000 Subject: [TYPO3-dev] Gallery plug-in localization issues Message-ID: Hello We have a Gallery plug-in constructed using a FAL Reference in a Flex form configuration. When we attempt to localize a page using this plugin, say to Spanish, we have the following problems: 1.) The first gallery image is replaced by another image out of the system. This replacement image is active, or can be accessed. 2.) All the remaining images are the original images, copied from the default (English) content element, but are disabled. We are not able to make them visible. 3. ) On the disabled images, in the location where the "light bulb" (hide image) is located, is a text balloon which states "Record can be localized". When the balloon is clicked on, nothing happens, the image remains grayed out (disabled). It appears to us that the image references are not copied during the process of translation. Has anyone seen this issue before? Gru? Robert Robert Williams B.S. Web-Development STIMME DER HOFFNUNG Adventist Media Center Sandwiesenstr. 35 D - 64665 Alsbach-Haehnlein Tel: +49 (0) 62 57 - 5 06 53-18 Fax: +49 (0) 62 57 - 5 06 53-70 E-Mail: robert.williams at stimme-der-hoffnung.de STIMME DER HOFFNUNG e.V. VR 1293, Amtsgericht Darmstadt Steuer-Nr. 007 250 80653 Ust-ID: DE111671780 www.bibelstudien-institut.de www.bibelinfo.de www.hope-channel.de www.ichwillleben.eu www.stimme-der-hoffnung.de