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 #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 #22961 (Closed): Missing link in Install Tool Footerhttp://forge.typo3.org/issues/229612010-06-22T15:57:34ZJeff Segarsjsegars@alumni.rice.edu
<p>"This is free software, and you are welcome to redistribute it under certain conditions; click for details."</p>
<p>The click for details text has nothing to click.</p>
<p>(issue imported from #M14822)</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 #18901 (Closed): XHTML Validation Problems on Forgot Password Formhttp://forge.typo3.org/issues/189012008-06-03T17:22:46ZJeff Segarsjsegars@alumni.rice.edu
<p>The forgot password form has a minor XHTML validation problem when using the default template.</p>
<p>Both the label "for" attribute and the input ID are tied to ###FORGOT_EMAIL### (as is the input "name" attribute"). This marker evaluates as "tx_felogin_pi1[forgot_email]", but the brackets are not allowed in the ID or "for" attribute.</p>
<p>Changing the ID to forgot-email or something like that should clear up the issue, although it may introduce some small compatibility problems for people hooking CSS or Javascript onto the existing ID.</p>
<p>(issue imported from #M8600)</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> TYPO3 Core - Feature #18265 (Closed): Add post processing hooks for Frontend Editinghttp://forge.typo3.org/issues/182652008-02-21T00:21:55ZJeff Segarsjsegars@alumni.rice.edu
<p>In bug <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: Moving content elements in frontent editing mode causes crash (Closed)" href="http://forge.typo3.org/issues/16526">#16526</a>, index_ts.php was rearranged to fix some frontend editing bugs. A side effect of this fix is that $TSFE->determineID() is no longer called after the frontend editing code runs.</p>
<p>While this was by no means documented or intended behavior, calling determineID() after frontend editing allowed content elements to be moved in TemplaVoila using earlier TYPO3 versions. TemplaVoila stores its content elements and their order in an XML structure within the page record so this page record must be updated after a content element is moved or hidden. If the record is not updated, the change will not appear until the entire page is refreshed. Among other things, the call to determineID() fetches a fresh copy of the page record.</p>
<p>The attached patch adds two hooks within frontend editing after any data changes are complete. It's up to third party extension (such as TemplaVoila and others) to implement these hooks and make sure they have fresh data but this at least opens up the possibility that they can work.</p>
<p>(issue imported from #M7607)</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> TYPO3 Core - Bug #17206 (Closed): Problem ignoring extension constraintshttp://forge.typo3.org/issues/172062007-04-13T22:06:21ZJeff Segarsjsegars@alumni.rice.edu
<p>When an extension has several types of constraints (dependencies, suggestions, and conflicts) problems can result when trying to install the extension.</p>
<p>As long as there are unresolved constraints in a category, a hidden input box is used to keep track of the constraints that have already been ignored. When all constraints in a category have been resolved, however, the hidden input boxes are no longer used. This causes problems when one category of constraints has been resolved but another has not.</p>
<p>For example, I can have extension dependencies and suggestions. I click ignore for all the suggestions and click the "Try Again" button. When I do this, the resulting page only shows my dependencies. I then resolve these dependencies and click the "Try Again" button again. When I do this, the ignored suggestions come back because they were not tracked on the previous page.</p>
<p>The solution is to keep the hidden input boxes and any associated text around even if all the constraints in a category have been resolved. I'm attaching a patch that should accomplish this.</p>
<p>(issue imported from #M5421)</p>