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 #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 #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 #19490 (Closed): RTE uses JScodeLibArray to insert CSShttp://forge.typo3.org/issues/194902008-10-21T16:24:05ZJeff Segarsjsegars@alumni.rice.edu
<p>In tx_rtehtmlarea_base, the RTE uses $GLOBALS['SOBE']->doc->JScodeLibArray to insert CSS into the page header. This was added in revision 4298.</p>
<p>When using edit forms on the page in frontend editing, we don't have a true doc template and are just going through TCEForms instead. This means that adding Javascript (or CSS) through JScodeLibArray has no effect.</p>
<p>In bug <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: Frontend Editing does not work anymore (Closed)" href="http://forge.typo3.org/issues/19485">#19485</a>, Olly added a separate loadJavascriptLib() method for frontend editing that inserts the Javascript libraries into TSFE but that won't be the correct solution for CSS files. I'd suggest falling back to $this->TCEform->additionalCode_pre as it was in the past or adding a generic loader into TCEForms.</p>
<p>I'm attaching a patch that uses $this->TCEform->additionalCode_pre and works correctly in my testing in both the frontend and backend (I am seeing problems with the RTE in IRRE child records but that seems to occur with and without my patch).</p>
<p>(issue imported from #M9613)</p> TYPO3 Core - Bug #19338 (Closed): XML Problems with PHP5 and libxml 2.7.1http://forge.typo3.org/issues/193382008-09-16T17:06:05ZJeff Segarsjsegars@alumni.rice.edu
<p>When using PHP5 with libxml 2.7.1, HTML entities are stripped from any XML content (FCEs, Flexforms, etc) when its saved or retrieved.</p>
<p>For things like RTE content, this means that "<LINK 43>Page with UID 43</LINK>" is not actually transformed into a link but instead renders in the frontend at "LINK 43Page with UID 43/LINK"</p>
<p>This also affects Flexible Content Elements if HTML entities were used for Typoscript assignments, such as "10 < styles.content.get". A previous working FCE and the assignment operator removed and thus renders no content at all.</p>
<p>For more information on the bug, see <a class="external" href="https://qa.mandriva.com/show_bug.cgi?id=43486">https://qa.mandriva.com/show_bug.cgi?id=43486</a> and <a class="external" href="http://bugs.php.net/bug.php?id=45996">http://bugs.php.net/bug.php?id=45996</a>.</p>
<p>It remains to be seen how widespread this issue will become or how quickly PHP will patch it, but one helpful option for new sites is to enable the useCDATA option from t3lib_div::array2xml. This will cause TYPO3 to insert CDATA anytime there are html entities within the content. Once CDATA is present, the new content will work as expected.</p>
<p>I'm attaching a one line patch that enables CDATA within flexform XML. There are several other places in the core that also use XML but the flexform part seems to be the most prominent.</p>
<p>(issue imported from #M9359)</p> TYPO3 Core - Bug #18279 (Closed): Several problems with locking API (t3lib_lock)http://forge.typo3.org/issues/182792008-02-22T20:20:57ZJeff Segarsjsegars@alumni.rice.edu
<p>The locking API has problems if an extension sets TSFE->set_no_cache().</p>
<p>When a page is rendered, a lock is generated as long as the page itself isn't set to be uncached. At this point in time, we know nothing about what individual extensions will do within page caching. When rendering completes, we again check to see if the page is marked as uncached, which it may be because of an extension setting TSFE->set_no_cache. If the page is now marked as uncached, we don't do anything with locks which in turn leaves us with an open lock. Subsequent reloads of the page will take approximately 30 seconds due to the open locks.</p>
<p>The attached patch fixes this issue by releasing the locks within TSFE->set_no_cache(). The patch also contains some debug output for more insight into the problem, but this should be removed before its committed.</p>
<p>I'm also attaching a test extension that contains a frontend plugin for setting TSFE->set_no_cache(). You can first try the plugin without the patch. Make sure you're not logged into the backend and page loads should take approximately 30 seconds. After applying the patch, it should be back to normal speeds.</p>
<p>(issue imported from #M7630)</p>