TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692010-04-07T12:14:23ZTYPO3 Forge
Redmine TYPO3 Core - Bug #22392 (Closed): Simplify the code to get nested GET Parameters with TShttp://forge.typo3.org/issues/223922010-04-07T12:14:23ZSebastian Michaelsenmichaelsen@t3seo.de
<p>The functionality to retrieve GET Parameters with statements like tt_news|uid can be simplified</p>
<p>The code resolves the first level itself and passes the rest to tslib_cObj::getGlobal().<br />But getGlobal() can do all the work (also the first level).<br />(issue imported from #M14021)</p> TYPO3 Core - Bug #22340 (Closed): Automatically hiding Option Checkboxes and search fields on "em...http://forge.typo3.org/issues/223402010-03-29T13:54:44ZSebastian Michaelsenmichaelsen@t3seo.de
<p>When you open a page in list view which has no records to display, it still shows up Checkboxes for "Extended View" and "Localization view" and a search form.<br />The functionality to hide these automatically is implemented but does not work anymore.</p>
<p>After computing the list of tables the list module checks if it has any output. If it's empty Checkboxes and searchform are hidden.</p>
<p>The problem ist that the "list of tables" output is never empty because t3lib_recordlist::writeBottom adds some Hardcoded HTML to the bottom of the table list.</p>
<p>Additionally note that rendering of the clipboard is inside the mentioned condition, so when no records are there the clipboard would also be hidden (you don't want that because you may want to paste records into an empty page). So the Clipboard rendering needs to be moved outside the if-statement<br />(issue imported from #M13942)</p> TYPO3 Core - Feature #22318 (Closed): Define a central whitelist for allowed tables for cObjects ...http://forge.typo3.org/issues/223182010-03-23T15:56:00ZSebastian Michaelsenmichaelsen@t3seo.de
<p>With the cObjects CONTENT and RECORDS you can get records out of database tables and render them.<br />However CONTENT is restricted to work only with the tables pages, fe_*, static_*, fe_*, tt_*, ttx_', tx_* and user_* (that means, not allowed are be_*, cache_*, index_*, sys_* and a few others). RECORDS has no restritctions regarding tables.<br />The reason for the restriction seems to be security as Dmitry pointed out: <a class="external" href="http://lists.typo3.org/pipermail/typo3-dev/2007-May/023736.html">http://lists.typo3.org/pipermail/typo3-dev/2007-May/023736.html</a></p>
<p>To have a consistent behaviour among CONTENT and RECORDS and for configurability of allowed tables I suggest to have a whitelist of allowed tables in the install tool (to be honest, Benjamin suggested this: <a class="external" href="http://lists.typo3.org/pipermail/typo3-dev/2010-February/039116.html">http://lists.typo3.org/pipermail/typo3-dev/2010-February/039116.html</a>)</p>
<p>I think, when a TYPO3 Admin knows what he does he should be allowed to access all tables (even be_users). Because <del>as Georg pointed out</del> when TS does not allow him the functionality he wants, he'll write an Extension or UserScript to achieve it, which can again introduce security holes.</p>
<p>This would break compatiblity when someone used a table with RECORDS, which is not allowed for CONTENT. The admin would need to add the tables he needs to the whitelist in the install tool.<br />(issue imported from #M13898)</p> TYPO3 Core - Feature #22300 (Closed): Possibility to configure another link paramter for jumpurl ...http://forge.typo3.org/issues/223002010-03-19T11:32:34ZSebastian Michaelsenmichaelsen@t3seo.de
<p>When you produce a filelink with stdWrap.filelink and jumpurl.secure you will be linked to the current PageId and type again with appenden jumpurl GET-Params.<br />Most times it doesn't matter which pid or type is used by the link, because tslib_fe will redirect the request to the jumpurl anyway.<br />But there are usecases where the pid and type can be important.<br />Example: you want to log file downloads using config.stat, but don't want to log every page hit. So you can set con.stat_typeNumList to 1119, so that only hits with this typeNum are logged. But currently you can not use that custom type for your filelink.</p>
<p>This patch introduces a property jumpurl.parameter to stdWrap.filelink.<br />It's straight forward applied to typolink.parameter so it has the same datatype/usage/syntax.<br />Also it has stdWrap properties of course.<br />When no parameter is set, the default behavior (current pid and typeNum) is applied.<br />(issue imported from #M13865)</p> TYPO3 Core - Feature #22279 (Closed): Add .numberFormat function to stdWraphttp://forge.typo3.org/issues/222792010-03-15T11:49:49ZSebastian Michaelsenmichaelsen@t3seo.de
<p>When handling prices or other special formated Numbers in TypoScript there's no reasonable way to format it properly. When there's a price like 0.8 in your Database you can't transform it to 0,80 easily.</p>
<p>There's already an extension adding this functionality by XCLASSing (am_stdwrap_number_format) and requests for such a feature (<a class="external" href="http://www.typo3.net/forum/list/list_post//89143/">http://www.typo3.net/forum/list/list_post//89143/</a> [german]), so I think a general interest for this functionality is given.<br />(issue imported from #M13815)</p> TYPO3 Core - Bug #22227 (Closed): t3lib_div CGL Cleanup: Missing spaces around string concatenatorhttp://forge.typo3.org/issues/222272010-03-03T14:21:16ZSebastian Michaelsenmichaelsen@t3seo.de
<p>t3lib_div does absolutely not match the current CGL. This issue is intended be focused on one particular rule of CGL: "String concatenation operator must be surrounded by spaces".</p>
<p>This issue/RFC/patch intentionally ignores other violations of the CGL, because this would be too much for one RFC. So the modified lines still contain violations like missing spaces after comma and so on.<br />(issue imported from #M13729)</p> TYPO3 Core - Bug #22162 (Closed): Deprecation log for IMAGE.alttext does not workhttp://forge.typo3.org/issues/221622010-02-23T11:11:33ZSebastian Michaelsenmichaelsen@t3seo.de
<p>Due to a typo no entry in the deprecation log is done when using the deprected IMAGE.alttext property.</p>
<p>if ($conf['altText'] || $conf['altText.']) {<br /> $GLOBALS['TSFE']->logDeprecatedTyposcript('IMAGE.alttext');<br />}</p>
<p>Obviously does not make sense. I corrected the property names in the IF-Condition to lowercase. Additionally I merged the two nested IF-Clauses to one. This also solves the little issue that $conf['altText'] = $conf['alttext']; was assigned even if there is no $conf['alttext'] - an IF-Check is done anyway, so why not include the assignement in there. This should tweak performance a little bit.<br />(issue imported from #M13623)</p> TYPO3 Core - Feature #22107 (Closed): Add a Hook to add Sub Categories to the Constant Editorhttp://forge.typo3.org/issues/221072010-02-11T10:42:37ZSebastian Michaelsenmichaelsen@t3seo.de
<p>Currently the Sub Categories of the Constant Editor are hardcoded (Enable Features, Dimensions, etc).<br />Especially when you develop a flexible TypoScript Library which should be configurable with the Constant Editor it would be great if you could add custom Sub Categories.</p>
<p>I added a constructor to t3lib_tsparser_ext, which can also be used for other hooks or initialization stuff. Currently it only includes my Hook (callUserFunction) to add Sub Categories.<br />(issue imported from #M13510)</p> TYPO3 Core - Feature #22086 (Closed): Give headTag stdWrap propertieshttp://forge.typo3.org/issues/220862010-02-09T08:52:15ZSebastian Michaelsenmichaelsen@t3seo.de
<p>PAGE.headTag does not have stdWrap properties but I have a usecase for it.</p>
<p>It should be implemented into core, stdWrap never hurts<br />(issue imported from #M13472)</p> TYPO3 Core - Feature #21928 (Accepted): Enable/Disable Control Icons in the List Module via Page...http://forge.typo3.org/issues/219282010-01-08T14:14:52ZSebastian Michaelsenmichaelsen@t3seo.de
<p>For each record in the databse the List module offers a variety of funtions. Depending on the Database Table, User Rights and other circumstances you can Edit, Move, Delete, Preview etc records.<br />But especially for editors with low technical skills the "wall of icons" in the extended view can be confusing.<br />Yes, you can disable the extended view, but then you might take away features the editor needs to perform his tasks.<br />Until now it's not possible to disable single Control Icons.</p>
<p>Solution is to introduce some properties to mod.web_list (which is avaiable in PageTS and UserTS).<br />My patch introduces the following properties:</p>
<p>mod.web_list.tableControls.[table].delete.disabled<br />mod.web_list.tableControls.[table].edit.disabled<br />mod.web_list.tableControls.[table].hideUnhide.disabled<br />mod.web_list.tableControls.[table].history.disabled<br />mod.web_list.tableControls.[table].info.disabled<br />mod.web_list.tableControls.[table].move.disabled<br />mod.web_list.tableControls.[table].moveLevels.disabled<br />mod.web_list.tableControls.[table].newRecordAfter.disabled<br />mod.web_list.tableControls.[table].permissions.disabled <br />mod.web_list.tableControls.[table].show.disabled<br />mod.web_list.tableControls.[table].upDown.disabled<br />mod.web_list.tableControls.[table].versions.disabled</p>
<p>Obviously all of them are boolean and "1" disables the certain icon.</p>
<p>Now you can disable Icons depending on Be-User, Page and Database Table.</p>
<p>Mind that some of the Controls are only available for certain tables. Eg. "moveLevels" is only for pages.</p>
<p>Though most Icons should be uite clear I attached a screenshot, showing which property belongs to which icon.<br />(issue imported from #M13183)</p> TYPO3 Core - Bug #21700 (Closed): Save the previous selected type of login in a cookiehttp://forge.typo3.org/issues/217002009-11-26T16:42:22ZSebastian Michaelsenmichaelsen@t3seo.de
<p>If a user likes to login via OpenID, he has to click "Switch to OpenID" first, to get the the right login form. He needs to do this every time he wants to log in, which is avoidable pain.<br />My suggestion is to save the user's choice in a cookie.</p>
<p>Steffen Kamper pointed out that nobody needs to click on "Switch to OpenID", because you can also just paste your OpenID Identifier to the username field.<br />This might be right, but then the divisiion between conventional und openid login does not make any sense.<br />(issue imported from #M12779)</p> TYPO3 Core - Feature #20933 (Closed): Enable working with SysFolders in CONTENThttp://forge.typo3.org/issues/209332009-08-26T23:47:56ZSebastian Michaelsenmichaelsen@t3seo.de
<p>When using the pages table in CONTENT, only pages with doktype below 200 will be queried, but it should be possible also to fetch SysFolders.</p>
<p>The patch adds a new TS property CONTENT.select.dontCheckDoktype to enable all pages no matter what doktype.<br />(issue imported from #M11797)</p> TYPO3 Core - Feature #20930 (Closed): Give CONTENT.table stdWrap propertieshttp://forge.typo3.org/issues/209302009-08-26T22:19:03ZSebastian Michaelsenmichaelsen@t3seo.de
<p>The table of a CONTENT object has to be hardcoded by now. It should be stdWrap to gain more flexibility.</p>
<p>See patch<br />(issue imported from #M11793)</p> TYPO3 Core - Bug #19632 (Closed): Enable <del> instead of <strike> in lib.parseFunc_RTE.allowTags...http://forge.typo3.org/issues/196322008-11-22T20:54:28ZSebastian Michaelsenmichaelsen@t3seo.de
<p>lib.parseFunc_RTE.allowTags by default allows the strike HTML tag which is deprecated because it's a physical element with a logical equivalent.<br />I think the del HTML tag should be enabled by default.<br />I'd also add a patch but I don't know where this is defined. If I find it, I will add one.</p>
<p>(issue imported from #M9818)</p> TYPO3 Core - Feature #19142 (Closed): Be-User should be redirected to Login-Page if Login has exp...http://forge.typo3.org/issues/191422008-07-23T14:30:57ZSebastian Michaelsenmichaelsen@t3seo.de
<p>Instead of displaying the annoying "Login-error or session timed-out" error message the BE-User should be redirected to the Login-Page automatically.</p>
<p>I added the modified backendCheckLogin method that I created.</p>
<pre><code>function backendCheckLogin() {<br /> if (!$this->user['uid']) {<br /> if (!defined('TYPO3_PROCEED_IF_NO_USER') || !TYPO3_PROCEED_IF_NO_USER) {<br /> $url = t3lib_div::locationHeaderUrl(t3lib_div::getIndpEnv('TYPO3_SITE_URL').TYPO3_mainDir.'index.php');<br /> t3lib_BEfunc::typo3PrintError ('Redirecting to Login-Page', '&lt;script type=&quot;text/javascript&quot;&gt;function redirect_with_framebreaker(){var frames=parent.frames.length;if(frames==0)window.location.href="'.$url.'";}else{parent.location.href="'.$url.'";}}redirect_with_framebreaker();&lt;/script&gt;',0));<br /> exit;<br /> }<br /> } else { // ...and if that's the case, call these functions<br /> /* ... */<br /> }<br /> }<br />(issue imported from #M9032)</code></pre>