TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692011-01-25T16:16:13ZTYPO3 Forge
Redmine 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 - Feature #24092 (Closed): Add live search to the backend toolbarhttp://forge.typo3.org/issues/240922010-11-17T05:53:32ZJeff Segarsjsegars@alumni.rice.edu
<p>As part of T3UXW09, a live search module was added to the backend toolbar. This needs a little further refinement, testing, and UI work to be included in TYPO3 4.5.</p>
<p>(issue imported from #M16432)</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 #22424 (Closed): Add hook for including Static TypoScript after all Static T...http://forge.typo3.org/issues/224242010-04-12T02:13:58ZJeff Segarsjsegars@alumni.rice.edu
<p>We already have a hook at the top of t3lib_tstemplate->includeStaticTypoScriptSources() for including the old static templates. For other extensions such as templavoila_framework, it would be helpful to have an identical hook at the end of this method.</p>
<p>Placing the hook at the end allows skins in the templavoila_framework to manipulate TypoScript settings from extensions on a per skin basis. This is useful, for example, when a skin needs to override the default rendering of a content element as defined in CSS Styled Content.</p>
<p>(issue imported from #M14065)</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 #22378 (Closed): "Check for extension updates" does not always find latest versionhttp://forge.typo3.org/issues/223782010-04-05T18:37:06ZJeff Segarsjsegars@alumni.rice.edu
<p>The "Check for extension updates" in the Extension Manager does not always find the latest version due to a bad expectation of the sort order.</p>
<p>In SC_mod_tools_em_index->showExtensionsToUpdate() we get a list of versions for a particular extension and the latest version is assumed to be the last entry in the versions array. This array is not necessarily sorted by version number however, so a simple natsort() will make sure that it is.</p>
<p>To duplicate the issue, ensure that you're on a TemplaVoila version prior to the 1.4.2 release. When you "Check for extension updates", you'll see 1.4.1 as the latest version. Searching for templavoila from the "Import extensions" submodule will reveal 1.4.2 however.</p>
<p>(issue imported from #M14003)</p> TYPO3 Core - Feature #20952 (Closed): Add inline Javascript rendering type for TYPO3AJAXhttp://forge.typo3.org/issues/209522009-08-28T22:28:37ZJeff Segarsjsegars@alumni.rice.edu
<p>The ajax handling in TYPO3AJAX supports several output formats (plain text, JSON, XML) but inline Javascript would be a nice addition. iFrames are often used for transporting AJAX data and rather than returning pure JSON, you want the JSON contents embedded in a script tag and assigned to a variable instead. The attached patch adds a new rendering type to create this inline script.</p>
<p>Note: This is particularly useful inside frontend editing, where the editing form is rendered inside an iframe. When editing is complete, we can return inline Javascript inside the iframe and then pass that data back to the parent page.</p>
<p>(issue imported from #M11819)</p> TYPO3 Core - Feature #20490 (Closed): Add method for saving and closing a record.http://forge.typo3.org/issues/204902009-05-22T17:22:28ZJeff Segarsjsegars@alumni.rice.edu
<p>t3lib_frontendedit has methods for the common tcemain actions that are performed on a record (save, hide, new, etc) but saving and closing a record is missing.</p>
<p>When editing page content, saving and closing is identical to just saving. Page records are slightly different though. When a page record is saved, we want to reload the editing form again. When a page record is saved and closed, we don't have any content to display; instead we want to figure out what the new URL is (after a change of page title, etc) and redirect the browser to that URL.</p>
<p>The attached patch adds a doSaveAndClose() method that is just a wrapper around doSave() so that the actual content is saved correctly. Having this separate method allows the frontend editing views to properly handle the saving of page records.</p>
<p>(issue imported from #M11167)</p> TYPO3 Core - Feature #19982 (Closed): Add helper functions for additional frontend editing contro...http://forge.typo3.org/issues/199822009-02-06T21:43:39ZJeff Segarsjsegars@alumni.rice.edu
<p>To support additional frontend editing controllers (ie. TemplaVoila) and view (ie. fe_edit_advanced) a couple simple helper functions are needed.</p>
<p>The getJavascriptIncludes() method does nothing in the default controller that the core provides, but the TemplaVoila controller will provide an additional Javascript file that extends client side frontend editing to account for FlexForm pointers.</p>
<p>The forcePreview() method is used to set $this->ext_forcePreview externally. The upcoming fe_edit_advanced extension requires that this property is always set.</p>
<p>(issue imported from #M10374)</p> TYPO3 Core - Feature #19835 (Closed): Add controller switching for frontend editinghttp://forge.typo3.org/issues/198352009-01-15T18:29:35ZJeff Segarsjsegars@alumni.rice.edu
<p>The recent frontend editing overhaul for version 4.3 moves the logic of saving records into a controller in t3lib_frontendedit. This controller works for classic page templating, but TemplaVoila (and other future templating methods) may need their own options for handling moves, deletes, etc.</p>
<p>Since multiple controllers may be used throughout the site (ie. one branch of the pagetree uses TV, one does not), we need a way to switch these controllers via Page TSConfig and add an option TSFE.frontendEditingController.</p>
<p>Also, in order to access Page TSConfig, we had to move frontend editing a little bit later within index_ts.php. I haven't seen any side effects from this move.</p>
<p>(issue imported from #M10155)</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 #18041 (Closed): Add hook for warning messages within Help->About modules and im...http://forge.typo3.org/issues/180412008-01-23T05:57:47ZJeff Segarsjsegars@alumni.rice.edu
<p>A postProcessingHook within t3lib_beFunc->displayWarningMessages would allow extensions to insert their own warning messages if critical problems were detected.</p>
<p>The default warning messages could also be cleaned up a little, with links to the location where the suggested updates can be made.</p>
<p>(issue imported from #M7247)</p> TYPO3 Core - Feature #17992 (Closed): Add pageUnavailable_handling for system problems and mainte...http://forge.typo3.org/issues/179922008-01-14T23:40:45ZJeff Segarsjsegars@alumni.rice.edu
<p>There are already several places in the TYPO3 Core where an HTTP 503 Not Available header is sent in response to major problems rendering the page. This occurs mainly when a database connection is unavailable or there's a serious problem getting the requested page and template. In each of these cases, the 503 header is sent and a specific, but static a error message is displayed.</p>
<p>I would propose that we add an equivalent to pageNotFound_handling for the times when a page is unavailable. This would allow a customized maintenance page to automatically be displayed when problems occur (ie. database goes down) and for the normal site to return immediately when those problems are resolved. I'd also suggest an Install Tool setting to manually turn this maintenance page off and on whenever the site admin is performing maintenance.</p>
<p>I'm attaching an inital version of patch for this. It adds some Install Tool settings to t3lib/config_default.php and mimics the pageNotFound_handling in tslib_fe. There's also a small addition to tslib/index_ts.php that checks if pageUnavailable has been forced after TSFE is created, but before a database connection is attempted.</p>
<p>The one thing this patch does not currently handle is the "Page is being generated" message since there's some additional complexity with it.</p>
<p>(issue imported from #M7150)</p> TYPO3 Core - Feature #17765 (Closed): Add tab filtering and file type filtering to TCA-defined li...http://forge.typo3.org/issues/177652007-11-07T18:09:03ZJeff Segarsjsegars@alumni.rice.edu
<p>Many extensions would benefit from the ability to simplify the link wizard. For example, when creating a record for a TemplaVoila Template Object, selecting an HTML template is the only reasonable option but the tabs for TYPO3 Pages and email addresses are still displayed. Likewise, its possible to select an image file.</p>
<p>The attached patch adds allowedExtensions and blindLinkOptions as params when defining the link wizard in the TCA. There is already TSConfig support for blindLinkOptions, so we're sticking with a common name.</p>
<p>The TYPO3 Core API documentation will need to be updated to reflect this change also.</p>
<p>(issue imported from #M6672)</p> TYPO3 Core - Feature #17540 (Closed): Add user function support to Constant Editorhttp://forge.typo3.org/issues/175402007-08-17T22:43:22ZJeff Segarsjsegars@alumni.rice.edu
<p>In addition to the built in form widgets, it would be nice if the Constant Editor supported user functions to allow more custom user interfaces.</p>
<p>This can be accomplished pretty easily with t3lib_div::callUserFunction and a user function that outputs the appropriate HTML.</p>
<p>I'm attaching a patch to add this support. I can also add a small extension that demonstrates this functionality if it would be helpful.</p>
<p>(issue imported from #M6169)</p>