TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692015-11-02T18:17:01ZTYPO3 Forge
Redmine TYPO3 Core - Bug #71253 (Closed): Folder Creation Fails If Same Folder Exists at File Storage Roothttp://forge.typo3.org/issues/712532015-11-02T18:17:01ZJeff Segarsjsegars@alumni.rice.edu
<p>Creating a new folder in Filelist fails if a folder of the same name exists in the file storage root. This is due to the $this->driver->folderExists() check in \TYPO3\CMS\Core\Resource\ResourceStorage->createFolder() that only considers the new folder name and not the parent folder. I'd assume this should actually be a call to $this->driver->folderExistsInFolder() instead.</p>
<p>Steps to Reproduce:<br />1) Create "folder1" in the file storage root.<br />2) Create "folder2" in the file storage root.<br />3) Attempt to create "folder1" inside "folder2"</p> TYPO3 Core - Bug #27099 (Closed): HMENU.excludeUidList is not accounted for when determining if a...http://forge.typo3.org/issues/270992011-05-27T21:10:25ZJeff Segarsjsegars@alumni.rice.edu
<p>HMENU.excludeUidList is used to exclude certain pages from menus and is read by tslib_menu->getBannedUids(). This getBannedUids() method is called when actually generating a menu, but is not accounted for when determining menu item states such as IFSUB, ACTIFSUB, and CURIFSUB. This means that IFSUB will trigger even if a page has no visible submenu because its subpages are part of HMENU.excludeUidList.</p>
<p>The solution is to add a check for getBannedUids() inside tslib_menu->isSubMenu().</p> TYPO3 Core - Bug #24810 (Closed): CSH popup windows for FlexForm fields do not show field labelhttp://forge.typo3.org/issues/248102011-01-25T19:01:44ZJeff Segarsjsegars@alumni.rice.edu
<p>When using CSH for FlexForms, the popup window does not show the field label in the header like it does for normal fields. Instead, a path such as tt_content.pi_flexform.myext_pi1.list: myField is shown.</p>
<p>(issue imported from #M17310)</p> TYPO3 Core - Bug #24688 (Closed): Pagetree cannot be initialized with a specific page IDhttp://forge.typo3.org/issues/246882011-01-20T17:16:22ZJeff Segarsjsegars@alumni.rice.edu
<p>In the backend live search, when someone clicks on a record we would like to select its page in the pagetree so that the editor has a clear picture of where they are. Currently, this does not work for the first load of the tree, but does work after the pagetree is loaded. The following JavaScript has been used for testing...</p>
<p>top.fsMod.recentIds['web'] = ###PID###<br />top.TYPO3.ModuleMenu.App.showModule('web_list');<br />top.TYPO3.Backend.NavigationContainer.PageTree.refresh();</p>
<p>(issue imported from #M17172)</p> TYPO3 Core - Bug #24666 (Closed): Update plugin layout to match other content elementshttp://forge.typo3.org/issues/246662011-01-19T18:11:52ZJeff Segarsjsegars@alumni.rice.edu
<p>In TYPO3 4.5, we have a new layout for built in content elements and plugins. FE Login is a bit of a hybrid since it is a frontend plugin but replacing the old built in content element. To achieve this, it overrides the TCA showitem definition of the old login content element. This showitem definition should be updated to the 4.5 layout.</p>
<p>(issue imported from #M17147)</p> TYPO3 Core - Bug #24534 (Closed): Update page and tt_content labels to use title casehttp://forge.typo3.org/issues/245342011-01-13T00:04:30ZJeff Segarsjsegars@alumni.rice.edu
<p>According to <a class="external" href="http://wiki.typo3.org/TCEformsRecommendedLayout">http://wiki.typo3.org/TCEformsRecommendedLayout</a>, form labels should use title case. This is mostly the case already in the backend but there are several exceptions in pages and tt_content the should be fixed.</p>
<p>This is not a change of meaning in the labels, since the wording doesn't change and it just follow different capitalization/punctuation rules so the existing labels are changed but do not need to be re-translated.</p>
<p>(issue imported from #M16989)</p> TYPO3 Core - Bug #24533 (Closed): Update Context Sensitive Help for pages and tt_content to match...http://forge.typo3.org/issues/245332011-01-12T22:27:36ZJeff Segarsjsegars@alumni.rice.edu
<p>With the recent label updates from JoH, Ingo, and others, the CSH doesn't match the actual labels for pages and tt_content very well.</p>
<p>In addition, a lot of the CSH descriptions are outdated and could use a little tweaking for their grammar. This hasn't been a complete rewrite of the CSH but more of a cleanup while fixing the label issues.</p>
<p>Additionally, we want to make these changes as easy as possible on the translators so that the existing CSH continues to work if new translations are not available.</p>
<p>1) Create new CSH files (inside a 4.5 folder) for pages and tt_content so that old TYPO3 versions are not affected.<br />2) Register these new CSH files using $TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']</p>
<p>When CSH is requested, the hierarchy will look like this....<br />1) Check for new 4.5 label in the current language<br />2) Check for old label in the current language<br />3) Check for new 4.5 label in the default language<br />4) Check for old label in the default language</p>
<p>In addition to tt_content and pages, there are 2 updates for CSH files that use SysFolder rather than the new Folder label.</p>
<p>(issue imported from #M16988)</p> TYPO3 Core - Bug #23401 (Closed): Flexform sections cannot be deleted in frontend editinghttp://forge.typo3.org/issues/234012010-08-18T22:10:12ZJeff Segarsjsegars@alumni.rice.edu
<p>When using feedit or feeditadvanced, flexform sections cannot be deleted.</p>
<p>In t3lib_tceforms->getSingleField_typeFlex_draw(), a special hidden form field is created to pass along the name of the element being deleted. In a backend context, itemFormElName is data. In a frontend context, its TSFE_EDIT[data].</p>
<p>$actionFieldName = '_ACTION_FLEX_FORM'.$PA['itemFormElName'].$s<sup><a href="#fn0">0</a></sup>.'][_ACTION]['.$s<sup><a href="#fn1">1</a></sup>;</p>
<p>In t3lib_tcemain->checkValueFlex(), the check is hardcoded to rely on the backend version.</p>
<p>$actionCMDs = t3lib_div::_GP('_ACTION_FLEX_FORMdata');</p>
<p>The "data" portion should not be hardcoded and the t3lib_tcemain should not read directly from the GET/POST data.</p>
<p>(issue imported from #M15496)</p> TYPO3 Core - Bug #23359 (Closed): pageRenderer doesn't take frontend editing into account when co...http://forge.typo3.org/issues/233592010-08-06T00:55:33ZJeff Segarsjsegars@alumni.rice.edu
<p>Currently the pageRenderer uses t3lib_compressor only when the TYPO3_MODE == 'BE'. This means that during frontend editing, individual stylesheets are loaded and are not combined. The number of stylesheets exceeds what IE can handle and results in an unstyled editing form.</p>
<p>The obvious solution would be for the page renderer to check for frontend editing also but we may need to look for an feeditadvanced solution until it can be handled properly in the core.</p>
<p>Cross-posted to the feeditadvanced bugtracker at <a class="external" href="http://forge.typo3.org/issues/9173">http://forge.typo3.org/issues/9173</a> also.</p>
<p>(issue imported from #M15368)</p> TYPO3 Core - Bug #23272 (Closed): Incorrect backpath used when including default and skin stylesh...http://forge.typo3.org/issues/232722010-07-26T22:50:15ZJeff Segarsjsegars@alumni.rice.edu
<p>CSS paths in typo3/template.php are currently calculated using $GLOBALS['BACK_PATH']. Elsewhere in t3lib_tceforms, $this->backPath is used instead of $GLOBALS['BACK_PATH]. $GLOBALS['BACK_PATH'] may not be available in all contexts, leading to missing styles.</p>
<p>The issue can easily be seen in frontend editing, where the CSS for sprite images is not loaded due to the incorrect path. In this instance $this->backPath is set properly and used elsewhere in t3lib_tceforms but $GLOBALS['BACK_PATH'] is not.</p>
<p>In previous versions of TYPO3, $this->backPath was not set at all in the backend context because all of the views were directly inside /typo3/ and no back path was needed. After moving list view and other modules to extensions, a back path is needed so the first hunk in this patch sets $this->backPath to $GLOBALS['BACK_PATH'] in the normal backend context. While its related to this patch, it could also be a followup to RFCs 15149-15155.</p>
<p>(issue imported from #M15242)</p> TYPO3 Core - Bug #25657 (Rejected): Task Object State Is Not Savedhttp://forge.typo3.org/issues/256572010-04-29T16:07:38ZJeff Segarsjsegars@alumni.rice.edu
<p>I've just started using the scheduler in 4.3 for the first time and overall its been a very pleasant experience. There is one area where I'm getting stuck, however.</p>
<p>In my task, I need to track a couple small variables that may change from one run to the next (ie. the last time an update was actually pulled from a remote server with changed data). I expected these would be saved when the task was serialized and available again on the next run, but instead I always have the default values.</p>
<p>This appears to be due to tx_scheduler->executeTask() which runs $task->save() prior to $task->execute. Is this the intended behavior? If so, I guess the best option is to just write my data somewhere else for saving rather than expecting my task to be persistent.</p>
<p>(issue imported from #M14251)</p> TYPO3 Core - Bug #20844 (Closed): TYPO3 Javascript object missing in alt_main.phphttp://forge.typo3.org/issues/208442009-08-06T21:08:23ZJeff Segarsjsegars@alumni.rice.edu
<p>When using the classic backend in alt_main.php, links under the Web module do not work. Instead, a Javascript error is generated that says "TYPO3 is not defined" and references line 91 of typo3/js/backend.js</p>
<p>(issue imported from #M11662)</p> TYPO3 Core - Bug #19968 (Closed): Whitespace cleanups in t3lib_frontendedithttp://forge.typo3.org/issues/199682009-02-04T23:22:24ZJeff Segarsjsegars@alumni.rice.edu
<p>There are several minor CGL and whitespace issues in t3lib_frontendedit. The attached patch cleans these up.</p>
<p>(issue imported from #M10351)</p> TYPO3 Core - Bug #17959 (Closed): Section-based FCEs are saved with incorrect element IDhttp://forge.typo3.org/issues/179592007-12-31T06:09:22ZJeff Segarsjsegars@alumni.rice.edu
<p>When working with trunk and FCEs that have sections defined, saving the FCE results in bad data in the the FCE XML. Instead of an element like <br /> <section index="1"><br />I end up with<br /> <field index="ID-edd5ba543c-idx36456-form"></p>
<p>This data results in PHP errors in both the frontend and in the TV Page Module.</p>
<p>From what I can tell, these IDs are related to the FCE changes in changeset 1628. In TCEMain, the temporary IDs are mapped into normal section indexes, and the normal section elements are saved FCE XML. In the current code, this mapping only occurs if the element is not new. When I move the mapping outside this check so that it always occurs, saving and rendering work fine for me.</p>
<p>I'm attaching the patch for this issue. I don't fully understand all the code at this point in TYPO3 so there may be better ways to get it done, but it does seem to work for me.</p>
<p>(issue imported from #M7067)</p> TYPO3 Core - Bug #17339 (Closed): linkHandler Hook Not Initialized Properlyhttp://forge.typo3.org/issues/173392007-05-29T18:36:02ZJeff Segarsjsegars@alumni.rice.edu
<p>TYPO3 4.1.0 added a new hook for linkHandlers in tslib_content to allow extensions to link to individual records.</p>
<p>The code here uses TYPO3_CONF_VARS to initialize the hook, but the TYPO3_CONF_VARS are not declared as a global so the hook array is always empty.</p>
<p>I"m attaching the very trivial patch to declare them as a global and also to make sure the hook method exists before it is called.</p>
<p>(issue imported from #M5701)</p>