TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692016-07-20T22:38:55ZTYPO3 Forge
Redmine TYPO3 Core - Bug #77181 (Closed): Translation wizard must allow passing additional datahttp://forge.typo3.org/issues/771812016-07-20T22:38:55ZAndreas Wolfandreas.wolf@typo3.org
<p>Currently, the translation wizard in the page module only passes the colPos to the AJAX translation handler. For structures as defined by e.g. Gridelements or Flux, this is not enough, as the location inside the structure must be known to fetch elements for translating.</p>
<p>Also the additional data must be taken into account by the AJAX translation handler. This could be done either by changing the core translation handler to handle additional data (or call processors in a chain) or by overriding the handler with a custom Xclass in extensions like Flux or Gridelements.</p> TYPO3 Core - Bug #76410 (Closed): Link wizard does not fill hidden field of Flexform input fieldhttp://forge.typo3.org/issues/764102016-05-31T21:54:15ZAndreas Wolfandreas.wolf@typo3.org
<p>When using a link wizard on a FlexForm input field, the wizard does not fill the hidden field, leading to the selected value not being saved, despite it being displayed in the visible form field.</p> TYPO3 Core - Epic #67588 (Closed): Localization with localeshttp://forge.typo3.org/issues/675882015-06-17T22:31:40ZAndreas Wolfandreas.wolf@typo3.org
<p>This is an epic to group all tasks related to introducing locales as the basis for localization, effectively superseding the concept of a "default language" in the pagetree.</p>
<p>The concept still needs to be further discussed. The first implementation should only provide the current featureset, that is, the translations still have to be based on a language that is defined as the default for the current pagetree. This can later on be replaced with something else.</p>
<p>A draft for the concept is discussed at <a class="external" href="https://docs.google.com/document/d/12zhMTMBQUFqY64TTnHx8PoCNWslY4vRWsrFDtpm_X14/edit?usp=sharing">https://docs.google.com/document/d/12zhMTMBQUFqY64TTnHx8PoCNWslY4vRWsrFDtpm_X14/edit?usp=sharing</a></p>
<p>There is a draft implementation of locales for files, which was never integrated. Take a look at <a class="external" href="https://github.com/andreaswolf/TYPO3.CMS/tree/feature/file-localization-locales">https://github.com/andreaswolf/TYPO3.CMS/tree/feature/file-localization-locales</a>.</p> TYPO3 Core - Bug #67284 (Closed): Some storages cannot be marked as not public againhttp://forge.typo3.org/issues/672842015-06-03T17:31:40ZAndreas Wolfandreas.wolf@typo3.org
<p>When using the fal_webdav extension, a storage cannot be marked as not public again. The error is "The storage has been marked to be "publicly available" but is not detected as such by the driver. The setting has been reverted." <br />This is due to a broken check in <code>UserStorageCapabilityService::renderIsPublic()</code>.</p>
<p>The check should only check if the record says the storage is public, but the driver does not report so. Instead, the method checks if the storage’s public setting and the record do not differ. This fails if the storage was marked as not public by the user (i.e. the record says "0"), as the object is still created from the old record (which said "1").</p>
<p>How to reproduce:</p>
<ol>
<li>Install fal_webdav current master (7351fe2)</li>
<li>Create a storage, save it</li>
<li>Edit it again, uncheck the "Is publicly available?" box</li>
<li>Save, see the message once the form reloads</li>
</ol> TYPO3 Core - Bug #67107 (Closed): Fieldtypes "none" and "user" auto-save field value on record cr...http://forge.typo3.org/issues/671072015-05-22T13:39:33ZAndreas Wolfandreas.wolf@typo3.org
<p>When a field is configured with type "none" or "user", FormEngine sends a value to DataHandler when the record is created. This could lead to errors if the field is not present.</p>
<p>For further save attempts of existing records, no value is sent. This behaviour is inconsistent and should be fixed in one or the other direction (I tend to never set a value, at least for user).</p> TYPO3 Core - Bug #65563 (Closed): File metadata can’t be edited inlinehttp://forge.typo3.org/issues/655632015-03-06T10:38:39ZAndreas Wolfandreas.wolf@typo3.org
<p>Since 2012, there is a special mechanism to allow some tables for editing even if their records reside on a page that is inaccessible for the user. This is checked for regular forms in EditDocumentController, but the check for inline elements is still missing.</p> TYPO3 Core - Bug #65335 (Closed): MIME type is always retrieved from storage/driverhttp://forge.typo3.org/issues/653352015-02-25T14:00:07ZAndreas Wolfandreas.wolf@typo3.org
<p>Even for indexed records, where the mime type is stored in the database, the file object still always asks the storage for its mime type. The problem comes from a field naming mismatch between the "virtual" (database) and "real" (driver) sides of FAL – the former uses "mime_type", the latter "mimetype".</p> TYPO3 Core - Bug #55561 (Closed): No form displayed if no install tool password is sethttp://forge.typo3.org/issues/555612014-02-01T17:55:42ZAndreas Wolfandreas.wolf@typo3.org
<p>When no password is set, the install tool displays the following warning:</p>
<p>The file typo3conf/LocalConfiguration.php does not contain a password of the install tool. This should have been set during installation. You can gain access to the install tool login form by setting ['BE']['installToolPassword'] to the hash of your chosen password. You can get that hash by submitting the desired password with this form.</p>
<p>However, there is no form displayed, so one cannot submit the form to get the hashed password.</p> TYPO3 Core - Bug #50795 (Closed): No signals pre/post file add operationhttp://forge.typo3.org/issues/507952013-08-05T15:27:04ZAndreas Wolfandreas.wolf@typo3.org
<p>There are signals for most operations performed in the file storage, but not for adding a file. This should be changed, as especially this operation is interesting for things like file indexing, automatic generation of variants (renditions) etc.</p>
<p>The only thing to decide on is if these signals should be backported to 6.1/6.0 or not.</p> TYPO3 Core - Feature #49714 (Rejected): Localizable FAL file recordshttp://forge.typo3.org/issues/497142013-07-05T21:10:53ZAndreas Wolfandreas.wolf@typo3.org
<p>Currently, FAL does not support localization of files in any way. As this is a nearly must-have feature, we should definitely support it in FAL.</p>
<p>The plan is to make the metadata of files (title, description,...) localizable by using the standard TYPO3 means. Therefore, we have to split the file information into two tables:</p>
<ol>
<li>the sys_file table which contains all information that belongs to the physical file (size, hash, change date, ...). </li>
<li>a sys_file_metadata table which contains all additional information provided by the users</li>
</ol>
<p>The sys_file record should be included in the metadata records via an IRRE relation or a custom user field. This would also enable us to later on exchange a file in one language with a localized file.</p>
<p>Relations are still made to a sys_file record which then gets coupled with the metadata record in the correct language.</p> TYPO3 Core - Task #46777 (Closed): Improve behaviour when mime type detection is missinghttp://forge.typo3.org/issues/467772013-03-29T18:51:22ZAndreas Wolfandreas.wolf@typo3.org
<p>When no library is available for doing mime type detection, information like the dimensions of images is not indexed. This leads to several problems e.g. in the frontend output.</p>
<p>To better cope with such a situation, we should have</p>
<ol>
<li>a reports module that tests if mime type detection works</li>
<li>a heuristic that tries to guess the file type if no mime type can be extracted (we might as well have a fixed list of file extensions as was suggested in the comments for <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: Image size is 0 when not scaled (Closed)" href="http://forge.typo3.org/issues/46020">#46020</a>)</li>
</ol> TYPO3 Core - Bug #46587 (Closed): Resource storage does not emit signalshttp://forge.typo3.org/issues/465872013-03-23T11:47:39ZAndreas Wolfandreas.wolf@typo3.org
<p>The ResourceStorage class should emit signals before and after most actions it performs. The emit*() methods are already there, but not called from the "action" methods.</p> TYPO3 Core - Task #46553 (Closed): Resolve issues with case-sensitive fileshttp://forge.typo3.org/issues/465532013-03-22T15:14:17ZAndreas Wolfandreas.wolf@typo3.org
<p>Currently, the handling of file-name casing is improperly defined: The database will usually be case-insensitive (for MySQL this is the default), but we cannot be sure if the filesystem supports case-sensitivity. This leads to a multitude of problems, as the edge-cases are not considered in the code.</p>
We first have to check if we want to support case-sensitivity at all. If not,
<ol>
<li>case-sensitive file systems have to be taken care of in the driver (which might require quite some work for all comparisons etc.) and</li>
<li>we have to make sure the database is always case-insensitive.</li>
</ol>
If we want to support case-sensitivity,
<ol>
<li>the file system might still not support it, so we have to cope with that (i.e., check if a file with the same name, but different casing exists before adding a file)</li>
<li>the database always has to be case-sensitive (or we have to store SHA1/MD5 hashes of name and identifier and compare against these)</li>
</ol>
<p>Oracle and PostgreSQL seem to have case-sensitivity as the default, while MySQL is case-insensitive by default (for sensitivity the collation of the column has to be changed to utf8_bin).</p> TYPO3 Core - Bug #45898 (Closed): URL generation broken for absolute local storage pathshttp://forge.typo3.org/issues/458982013-02-27T20:30:17ZAndreas Wolfandreas.wolf@typo3.org
<p>When having a local storage with a path outside the site path, the URL cannot be generated currently, as it has to be absolute and there is neither a configuration field for the base URL nor code inside the local driver to generate a URL with this base URL.</p>
<p>The field should be added to the flexform of the local driver, as we cannot ship database updates in minor versions (like 6.0.3). Additionally, this field might not be required for all drivers, so it's not absolutely necessary to have it in the storages table directly.</p> TYPO3 Core - Feature #45327 (Closed): Recycler for fileshttp://forge.typo3.org/issues/453272013-02-09T20:08:50ZAndreas Wolfandreas.wolf@typo3.org
<p>FAL should have a recycler like we had in the past for files.</p>
<p>The recycler should not be browsable by users (like the processing folder), likewise should files from the folder not be displayed to users. We might even think about completely disabling external access to these files (e.g. via <code>getPublicUrl()</code>).</p>
<p>Recycled files should not be indexed in sys_file anymore, but the record should be serialized and stored somewhere else (like we do with sys_history for normal records). We cannot just simply drop the record as we might later need it again (and should then be able to restore the metadata).</p>