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 #27098 (Closed): Fatal error when downloading extension fileshttp://forge.typo3.org/issues/270982011-05-27T20:30:33ZJeff Segarsjsegars@alumni.rice.edu
<p>When attempting to download files from the "Edit Files" page in the Extension Manager, a fatal error occurs. This is because the downloadFile URL parameter is not decoded first.</p>
<pre>
#1270853980: TYPO3 Fatal Error: Error while trying to download the extension file...
RuntimeException thrown in file
/usr/bin/wecsharedsource/typo3_src-trunk/typo3/sysext/em/classes/index.php in line 1677.
3 SC_mod_tools_em_index::showExtDetails("felogin")
/usr/bin/wecsharedsource/typo3_src-trunk/typo3/sysext/em/classes/index.php:
00432: // Command given which is executed regardless of main menu setting:
00433: if ($this->CMD['showExt']) { // Show details for a single extension
00434: $this->showExtDetails($this->CMD['showExt']);
00435: } elseif ($this->CMD['requestInstallExtensions']) { // Show details for a single extension
00436: $this->requestInstallExtensions($this->CMD['requestInstallExtensions']);
2 SC_mod_tools_em_index::main()
/usr/bin/wecsharedsource/typo3_src-trunk/typo3/sysext/em/classes/index.php:
02594: $SOBE->checkExtObj();
02595:
02596: $SOBE->main();
02597: $SOBE->printContent();
02598:
1 require("/usr/bin/wecsharedsource/typo3_src-trunk/typo3/sysext/em/classes/index.php")
/usr/bin/wecsharedsource/typo3_src-trunk/typo3/mod.php:
00049: require($temp_path . 'conf.php');
00050: $BACK_PATH = '';
00051: require($temp_path . 'index.php');
00052: $isDispatched = TRUE;
00053: } else {
</pre> TYPO3 Core - Bug #24864 (Closed): stdWrap .current and .setContentToCurrent do not return contenthttp://forge.typo3.org/issues/248642011-01-27T23:28:32ZJeff Segarsjsegars@alumni.rice.edu
<p>With the tslib_content refactoring in 4.5, we now have standalone methods for many pieces of stdWrap, which are chained together at the end of the main stdWrap method. Each standalone helper method takes the $content and $conf, processes it, and returns the $content.</p>
<p>stdWrap_setContentToCurrent() and stdWrap_setCurrent() do not return $content, however. This means that any stdWrap properties coming after these two do not have content to operate on.</p>
<p>(issue imported from #M17372)</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 #24802 (Closed): Admin Panel CSS is loaded in the Backendhttp://forge.typo3.org/issues/248022011-01-25T16:16:13ZJeff Segarsjsegars@alumni.rice.edu
<p>Since the admin panel CSS is at t3skin/visual/admin_panel.css, it is loaded with every backend request. Obviously, the admin panel is not needed in the backend so its a bit of a waste to load it.</p>
<p>In addition, the CSS has a strange issue that it interferes with resizable text areas in Chrome 9 (as described on <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Resizable textares not working in Chrome 9 (Closed)" href="http://forge.typo3.org/issues/24744">#24744</a>).</p>
<p>Moving the admin panel CSS to t3skin/standalone/admin_panel.css ensures that it is not loaded automatically by the backend.</p>
<p>(issue imported from #M17302)</p> TYPO3 Core - Bug #24692 (Closed): Live Search: Search query loops over all tables even after max ...http://forge.typo3.org/issues/246922011-01-20T22:10:23ZJeff Segarsjsegars@alumni.rice.edu
<p>When executing a live search, we loop over all tables defined in the TCA. After this search is complete, we then slice the search array and throw away everything we don't need.</p>
<p>For better performance, we should stop searching as soon as we've found enough results.</p>
<p>(issue imported from #M17177)</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 #24581 (Closed): Live Search uses id=0 to display all search results to non-admi...http://forge.typo3.org/issues/245812011-01-15T00:02:58ZJeff Segarsjsegars@alumni.rice.edu
<p>After clicking the Show All button for Live Search, results are shown in list view. Live search is currently hardcoded to always show the results on the site root (id=0), which is not accessible for non-admin users.</p>
<p>The old backend search solved this by always using the first webmount. This has its own issues, as described in <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Backend search is unusable for editors (Closed)" href="http://forge.typo3.org/issues/23190">#23190</a>.</p>
<p>(issue imported from #M17045)</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 #24356 (Closed): Highlighted pages in a workspace overlap the pagetree border.http://forge.typo3.org/issues/243562010-12-17T18:46:49ZJeff Segarsjsegars@alumni.rice.edu
<p>When using workspaces, pages with changes are highlighted. This highlight slightly overlaps the border of the pagetree.</p>
<p>To fix it, we just need 2px of margin added to the Workspace info and highlighted pages.</p>
<p>(issue imported from #M16769)</p> TYPO3 Core - Bug #24311 (Closed): TCEForms->getIconHTML() does not resolve back paths before chec...http://forge.typo3.org/issues/243112010-12-08T21:58:30ZJeff Segarsjsegars@alumni.rice.edu
<p>TCEForms->getIconHTML() returns the HTML for a static image file or a sprite icon. When checking for a static image file, the back path is not resolved before calling is_file() so references such as "../uploads/path/to/my/file.png" will fail. This is most easily reproduced with TemplaVoila and preview icons for Data Structures and Template Objects.</p>
<p>(issue imported from #M16703)</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>