TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692014-10-23T12:37:22ZTYPO3 Forge
Redmine TYPO3 Core - Feature #62420 (Closed): improved configuration for mail notificationhttp://forge.typo3.org/issues/624202014-10-23T12:37:22ZDaniel Mindertypo3@minder.de
<p>On my system, open_basedir is set and some PHP functions are disabled for security reasons (standard for ISPconfig on Debian). According to the install tool, this is not a problem. Also, the report module in BE shows notices only.</p>
<p>However, the report task sends me a mail every time it is run by the scheduler.</p>
<p>I see 3 possible solutions:</p>
<p>1. possibility to configure the severity level for the mail notification, i.e. send mail also for notices, or only for warnings and error, or even only for errors (probably not recommended)<br />2. possibility to disable the mail notification for certain checks. however, warnings or errors could be missed if a check is disabled because it usually reports only (harmless) warnings.<br />3. possibility to send mail notifications only if something changes in the report, i.e. if an additional check fails.</p>
<p>option 1 should be quite easy to implement, option 2 has issues (see above), option 3 would be the best solution IMO.</p> TYPO3 Core - Bug #61942 (Closed): Explanatory texts of [SYS] config vars inconsistent and partly ...http://forge.typo3.org/issues/619422014-09-29T11:19:30ZDaniel Mindertypo3@minder.de
<p>The explanatory text of the variables [SYS][errorHandlerErrors], [SYS][exceptionalErrors], [SYS][syslogErrorReporting] and [SYS][belogErrorReporting] differs in formatting, link to PHP doc and if a numeric default value is given. Moreover, the numeric default values are wrong.<br />Will add a patch soon.</p> TYPO3 Core - Bug #61754 (Rejected): Calling FrontendUserAuthentication->storeSessionData twice pr...http://forge.typo3.org/issues/617542014-09-20T00:05:33ZDaniel Mindertypo3@minder.de
<p>I've encountered this problem when using sr_freecap with pbsurvey after entering the correct captcha.</p>
<p>The session data is cleared with setKey() and then stored with storeSessionData() in sr_freecap. Afterwards, pbsurvey sets new session data. However, when storeSessionData() is called later on, neither the data is stored in fe_session_data nor the cookie fe_typo_user is set.</p>
<p>Thus, either storeSessionData() must not be called manually in user classes (except before calling exit) - however this is not documented - or storeSessionData() needs to be changed in such a way that it is possible to remove all session data first and adding new session data afterwards, including forcing the cookie. I've added a patch for this.</p> TYPO3 Core - Bug #61022 (Closed): All EM records (extensions+repositories) are listed by cleaner-...http://forge.typo3.org/issues/610222014-08-18T10:09:44ZDaniel Mindertypo3@minder.de
<p>When running typo3/cleaner_check.sh ALL (i.e. several thousand) records of tx_extensionmanager_domain_model_extension and the single record in tx_extensionmanager_domain_model_repository are listed in category "[orphan_records] Records that should not be at root level but are." <br />Can they be moved somewhere else or can they be marked so that the lowlevel checker and cleaner ignores them?</p> TYPO3 Core - Task #48027 (Closed): Update PEAR packageshttp://forge.typo3.org/issues/480272013-05-07T19:08:31ZDaniel Mindertypo3@minder.de
<p>HTTP_Request2 should be updated to version 2.1.1 and Net_URL2 to 2.0.0 in TYPO3 4.7, 6.0, 6.1 and master. This will resolve issues <a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: PEAR Problem with public-suffix-list.php (Closed)" href="http://forge.typo3.org/issues/32387">#32387</a>, <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Included pear classes have no @data_dir@ set. (Closed)" href="http://forge.typo3.org/issues/37085">#37085</a> and <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: HTTP_Request2_CookieJar searches data in wrong directory (Closed)" href="http://forge.typo3.org/issues/41295">#41295</a>.</p> TYPO3 Core - Bug #31589 (Closed): returnUrl in sysext filelist points to deprecated file_list.phphttp://forge.typo3.org/issues/315892011-11-04T22:25:28ZDaniel Mindertypo3@minder.de
<p>Go to the file manager, select a folder, and in the right frame click on the "new" button. Then create a new folder. Now, a new entry is appended to the deprecation log since typo3/file_list.php is called.</p>
<p>The file list is rendered by typo3/sysext/filelist/mod1/file_list.php. There, the "new" button is created as a call to ""../../../file_newfolder.php", which is typo3/file_newfolder.php. The parameter list includes "returnUrl=file_list.php". When returning from file_newfolder, the file_list.php is called relatively to file_newfolder, which is typoe/file_list.php. And so, the deprecation log is triggered.</p>
<p>Should the returnUrl simply include the path to the sysext?</p> TYPO3 Core - Bug #28255 (Closed): Warning in log when displaying reporthttp://forge.typo3.org/issues/282552011-07-16T10:55:12ZDaniel Mindertypo3@minder.de
<p>When displaying the report the TYPO3 log is filled with warnings like:<br />Core: Error handler (BE): PHP Warning: filesize(): stat failed for /var/www/conet/htdocs/typo3/atibility.js in /var/www/conet/htdocs/typo3_src-4.5.2/t3lib/class.t3lib_compressor.php line 341</p>
<p>I described this earlier in <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: js/iecompatibility.js inclusion triggers compressor bug (Closed)" href="http://forge.typo3.org/issues/25303">#25303</a> but assumed that this is an error in the template class. Investigating this again, I found out that it's actually an error in linkvalidator.</p>
<p>modfuncreport/class.tx_linkvalidator_modfuncreport.php creates a template object in line 295. In the next line, setModuleTemplate is called which internally adds the js/iecompatiblity.js to the renderer. To do this properly, it needs the backPath. BUT the backPath of the template object is set only one line later.</p>
<p>So, the solution is to swap lines 296 and 297, thus setting the backPath immediately after the creating of the template object.</p> TYPO3 Core - Feature #13847 (Closed): Add error message for return code 401http://forge.typo3.org/issues/138472011-03-15T13:11:06ZDaniel Mindertypo3@minder.de
<p>If a page requires authentication this is currently reported as "External Link not reachable." Actually, it's both wrong reporting it as error or accepting it as good, since we have no information what would happen when we had the credentials.</p>
<p>The easiest solution is to add an error message to the external link checked. More sophisticated would be an "information" reporting class to inform the user that there is a link he has to check manually.</p> TYPO3 Core - Bug #13828 (Closed): checkhidden has no effect for some configurationshttp://forge.typo3.org/issues/138282011-03-14T16:27:39ZDaniel Mindertypo3@minder.de
<p>I've set up a scheduler task to check the complete page tree. Therefore, the processor class is initialized with a list of page ids that contain all pages in the page tree.</p>
<p>Now, getLinkStatistics() checks the records of pages, tt_content and tt_news within this page id list (uid or pid). The checkhidden configuration setting removes the hidden pages when the page table is checked, but it does not remove the records (e.g. from tt_content) when the pages that contains them is hidden.</p>
<p>So, if you have to hidden pages A and B and A contains a link to B, linkvalidator will report an error 'Page B is not visible.'</p>
<p>It get's even more complicated with TemplaVoila. There, a page and tt_content record can be not deleted and not hidden, but simply not linked from TV and, therefore, not displayed. But linkvalidator will report an error if such records contain a non-working link.</p>
<p>Given the fact that TV is widely used and probably not many people clean up unused (i.e. unlinked from TV) records I suspect many false positives.</p> TYPO3 Core - Bug #25303 (Closed): js/iecompatibility.js inclusion triggers compressor bughttp://forge.typo3.org/issues/253032011-03-10T13:12:42ZDaniel Mindertypo3@minder.de
<p>When the linkvalidator modfunc is shown via Web-Info the log is filled with:</p>
<p>Core: Error handler (BE): PHP Warning: filesize(): stat failed for /var/www/conet/htdocs/typo3/atibility.js in /var/www/conet/htdocs/typo3_src-4.5.2/t3lib/class.t3lib_compressor.php line 342</p>
<p>In linkvalidator the BACK_PATH is set correctly. It also adds 3 JS files that are correctly compressed.</p>
<p>The problem lies in the template lib. linkvalidator creates an instance of template and calls setModuleTemplate(). In this method, $this->loadJavascriptLib('js/iecompatibility.js') is called, which calls $this->pageRenderer->addJsFile($this->backPath . $lib);</p>
<p>BUT the backpath is set only in insertHeaderData() which is for FE only!</p>
<p>Can the loadJavascriptLib() call be removed from setModuleTemplate(). According to my debug out iecompatibility.js was already added to the JS list before. If not, is there a way to automatically detect the backPath if the method is called from BE? A third option would be to add a setBackPath() method which has to be called from each BE module that uses the template lib, but this is not so nice...</p>
<p>(issue imported from #M17918)</p> TYPO3 Core - Bug #25292 (Closed): Exception "tx_em_Parser_MirrorXmlPushParser: Unable to create X...http://forge.typo3.org/issues/252922011-03-09T16:21:24ZDaniel Mindertypo3@minder.de
<p>This happens both when clicking on the Retrieve/Update button in the new extension manager and when using the Update Extension List task in T3 4.5.2 (Side note: I had to fix the requireOnce() call in class.tx_em_parser_mirrorxmlabstractparser.php first, but this is already removed in SVN).</p>
<p>In tx_em_Repository_Utility->updateExtList(), isExtListUpdateNecessary() is called which calls getRemoteExtHashFile(). After this fetchExtListFile() is called which calls getRemoteExtListFile(). Both getRemoteExtHashFile() and getRemoteExtListFile() call getMirrors(TRUE) which result in tx_em_Import_MirrorListImporter->getMirrors() and tx_em_Parser_MirrorXmlPushParser->parseXML() calls.</p>
<p>And here is the source of the problem: The XML parser (objXML member) is created in the constructor of the tx_em_Parser_MirrorXmlPushParser class, but freed at the end of the parseXML() method. Therefore, in the second call to parseXML() objXML is not a resource any more and the exception is thrown.</p>
<p>My current solution is to move the following lines from tx_em_Parser_MirrorXmlPushParser __construct() to the beginning of method parseXML():<br /> if ($this->isAvailable()) {<br /> $this->objXML = xml_parser_create();<br /> xml_set_object($this->objXML, $this);<br /> }</p>
<p>(issue imported from #M17906)</p> TYPO3 Core - Bug #22441 (Closed): importExtInfo() does not sort versions correctlyhttp://forge.typo3.org/issues/224412010-04-13T11:43:37ZDaniel Mindertypo3@minder.de
<p>This is a follow-up to solved bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: "Check for extension updates" does not always find latest version (Closed)" href="http://forge.typo3.org/issues/22378">#22378</a>. showExtensionsToUpdate() does show correctly that there is a new version of an extension, but when clicking on the extension name importExtInfo() selects the wrong version due to the same problem.</p>
<p>The solution is similar: use natsort to sort the version numbers and use the last list entry as default since it is the highest one.</p>
<p>(issue imported from #M14090)</p> TYPO3 Core - Bug #19424 (Closed): Check for extension updates always warns about changeshttp://forge.typo3.org/issues/194242008-10-06T17:16:03ZDaniel Mindertypo3@minder.de
<p>The function "Check for extension updates" in extension manager always warns about changes in an extension for which a newer version is found - although it is completely unchanged.</p>
<p>This is caused by a simple '$' missing in class.em_index.php line 5348. Therefore, the array $serverMD5Array is not sorted like $currentMD5Array and the compare fails.</p>
<p>Error is also confirmed for version 4.2.2. Attached patch is for 4.2.2.</p>
<p>(issue imported from #M9498)</p> TYPO3 Core - Bug #18942 (Closed): Warning on fileDenyPattern is always shown although it's safehttp://forge.typo3.org/issues/189422008-06-12T10:44:30ZDaniel Mindertypo3@minder.de
<p>The check in class.t3lib_befunc.php if the configured fileDenyPattern is equal to its default value is too simple. We have modified the fileDenyPattern and appended some more extensions. The pattern is safe since it includes the default, but I still get this annoying warning in the backend.</p>
<p>(issue imported from #M8690)</p> TYPO3 Core - Bug #18472 (Closed): Cleaner scripts crash with errors due to malformed flexform con...http://forge.typo3.org/issues/184722008-03-18T18:16:54ZDaniel Mindertypo3@minder.de
<p>cleaner_check.sh, cleaner_fix.sh and the BE function "Update reference index" (subfunctions test and update) crash with error "Cannot use string offset as an array in class.t3lib_flexformtools.php" on lines 223 and 266.</p>
<p>The problem disappears if "lowlevel_cleaner cleanflexform" fixes the flexform contents. (I have not tested if cleanflexform runs without the patch on class.t3lib_flexformtools.php).</p>
<p>However, the best solution is to add two additional checks to class.t3lib_flexformtools.php that assure that arrays are existing before its elements are accessed (see attached diff).</p>
<p>(issue imported from #M7894)</p>