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 #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 #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 - Feature #22388 (Closed): Add simple API for creating new content elementshttp://forge.typo3.org/issues/223882010-04-07T01:24:40ZJeff Segarsjsegars@alumni.rice.edu
<p>The basic idea is to add some very simple way to create new content elements that can be shared among TYPO3 installations as extensions. The scope is very similar to FCEs with the difference being that they do not require TemplaVoila, are quicker to create (no mapping) and are much more easily shared and updated (extensions instead of T3Ds).</p>
<p>For PHP developers, this offers a more rapid way to add custom contenet when a full extension would be overkill. This also opens up some doors for site builders who are not PHP developers. If they know Typoscript and FlexForm XML, they can add new content elements.</p>
<p>As far as technical details go, this ends up being a pairing of Flexforms for backend data entry and nothing but TypoScript for frontend output.</p>
<p>We've already made an initial attempt at doing this sort of thing in the WEC Content Elements extension [1] so I'll attempt to describe what we did there. It's nothing earth shattering at all, but the non-developers who have see it really like it.</p>
<p>1. Add a simple PHP API for telling TYPO3 about the new content element (Something like this could easily live in t3lib_extMgm)
=======================================================================<br />tx_weccontentelements_lib::addContentElement($_EXTKEY, 'youtube') adds the necessary entries to the TCA and New Content Element Wizard. Locallang paths, icons, and flexform paths can all be defined but there's a simple convention that should work 95% of the time.</p>
<p>tx_weccontentelements_lib::addTyposcript($_EXTKEY, 'youtube') adds the TypoScript needed for frontend output. This TS is very similar to what the built in content elements use. As a quick example, see [2] which embeds YouTube on a page.</p>
<p>2. Add ability to read FlexForm data from TypoScript via getData (This could be an enhancement to tslib_cObj)
=======================================================================<br />If we're writing extensions that are simply FlexForm XML and TypoScript, then we need a bridge between the two. Many people have done this before and its really pretty simple with the hooks for getData already. Perhaps its time to bring this into the core.</p>
<p>The syntax for our implementation looks something like this:<br />t3datastructure : pi_flexform->width</p>
<p>You can see more details at [2]</p>
<p>3. Add ability to loop over FlexForm sections (This could be an enhancement to tslib_cObj)
=======================================================================<br />Once we can read simple values from FlexForms, the next obvious step is to operate on sections. This is useful for something like a slideshow content element that contains multiple images.</p>
<p>An example of our implementation is in line 139 and following at [3]. We have new FFSECTION cObject that is responsible for iterating over sections and it requires a rootPath to iterate over. Within that, getData is extended with a new flexformSection keyword that reads FlexForm values relative to the root path.</p>
<p>4. Add ability to insert header data from a content element (This could be a pageRenderer enhancement)
=======================================================================<br />Since many of these content elements will be widgets implementing Javascript functionality, it only makes sense to have some way that they can add header data to the page but only when the content element is actually in use.</p>
<p>In wec_contentelements we've added a HEADERDATA cObject that is an idea Olly had prior to the pageRenderer. A better solution would enhancing the pageRenderer somehow.</p>
<p>[1] <a class="external" href="http://typo3.org/extensions/repository/view/wec_contentelements/current/">http://typo3.org/extensions/repository/view/wec_contentelements/current/</a><br />[2] <a class="external" href="http://svn.webempoweredchurch.org/projects/contentelements/repository/entry/trunk/wec_contentelements/youtube/content.ts">http://svn.webempoweredchurch.org/projects/contentelements/repository/entry/trunk/wec_contentelements/youtube/content.ts</a><br />[3] <a class="external" href="http://svn.webempoweredchurch.org/projects/contentelements/repository/entry/trunk/wec_contentelements/slideshow/content.ts#L139">http://svn.webempoweredchurch.org/projects/contentelements/repository/entry/trunk/wec_contentelements/slideshow/content.ts#L139</a></p>
<p>(issue imported from #M14015)</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 #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>