TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-01-31T14:09:48ZTYPO3 Forge
Redmine TYPO3 Core - Task #99772 (Closed): Deprecate TCA renderType="inputLink" at some pointhttp://forge.typo3.org/issues/997722023-01-31T14:09:48ZSybille Peterssypets@gmx.de
<p>The type="input", renderType="inputLink" was replaced in TYPO3 v12 with type="link", however the inputLink still works. At some point it can be deprecated and removed.</p>
<p>typo3/sysext/backend/Migrations/Code/ClassAliasMap.php:</p>
<pre><code class="php syntaxhl" data-language="php"><span class="k">return</span> <span class="p">[</span>
<span class="s1">'TYPO3\\CMS\\Backend\\Form\\Element\\InputLinkElement'</span> <span class="o">=></span> <span class="nc">\TYPO3\CMS\Backend\Form\Element\LinkElement</span><span class="o">::</span><span class="n">class</span><span class="p">,</span>
</code></pre> TYPO3 Core - Story #97528 (New): Add check for references and safe way to delete files in FAL to ...http://forge.typo3.org/issues/975282022-05-02T09:25:10ZSybille Peterssypets@gmx.de
<p>Status: In progress, I can split this up into individual patches.</p>
<hr />
<p>Add public functionality to</p>
<ul>
<li>check if there are references to a file / within a folder (see also FileList::makeRef, ExtendedFileUtility::func_delete and ExtendedFileUtility::folderHasFilesInUse)</li>
<li>return the references to a file</li>
<li>"safely" delete a file / folder (checking for references)</li>
</ul>
<p>If possible, use this functionality instead of having duplicate code or move the functionality to the public API and then use the function there:</p>
<ul>
<li>FileList::makeRef: count number of references</li>
<li>ExtendedFileUtility::func_delete: checking for references</li>
<li>ExtendedFileUtility::transformFileReferenceToRecordReference</li>
</ul>
<p>Add phpdoc / documentation note pointing out that a check for references is not performed when deleting a file in</p>
<ul>
<li>AbstractFile::delete() and Folder::delete()</li>
<li>ResourceStorage::deleteFile() + deleteFolder()</li>
<li>documentation: <a class="external" href="https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Fal/UsingFal/ExamplesFileFolder.html#deleting-a-file">https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Fal/UsingFal/ExamplesFileFolder.html#deleting-a-file</a></li>
</ul>
<p>Add phpdoc / documentation note that this function only handles references within the sys_file_references table. TYPO3 - when performing functionality which concern references (including soft references) typically uses sys_refindex in combination with sys_file_references (which will also consider the soft references) - depending on where this functionality is used, we might want to check for both. In any case, it might make sense to point this out here:</p>
<ul>
<li>FileRepository::findByRelation</li>
<li>documentation: <a class="external" href="https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Fal/UsingFal/ExamplesFileFolder.html#getting-referenced-files">https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Fal/UsingFal/ExamplesFileFolder.html#getting-referenced-files</a></li>
</ul>
<p>A similar note in phpdoc does exist in LocalDriver::deleteFile:</p>
<blockquote>
<ul>
<li>This does not check if the file is</li>
<li>still used or if it is a bad idea to delete it for some other reason</li>
<li>this has to be taken care of in the upper layers (e.g. the Storage)!</li>
</ul>
</blockquote>
<hr />
<p>In TYPO3, there is functionality to delete files, but the function ExtendedFileUtility::func_delete() which does it safely by checking the references has the problem that it is "internal" and not public and also it sends flash messages (which might be a problem if called from CLI command).</p>
<p>The functionality which is public and usable does not check for references (as it is used as lowlevel functionality). AFAIK there is not public API which safely handles the deletion.</p>
<p>Also, there is no phpdoc that points out that it does not (except in the lower level driver functions).</p>
<p>AFAIK, there is no publicly available function which checks for references. The checking for references is done directly in the the code (e.g. in ExtendedFileUtility::func_delete.</p>
<p>So effectively, you have to handle this yourself - which might result in it being done incorrectly and adds lots of internal TYPO3 functionality to code, making it less maintainable. Also, it is a bit complicated to handle sys_refindex and sys_file_references, see also ExtendedFileUtility::func_delete - so that would be really helpful to have some public API functions.</p> TYPO3 Core - Task #94325 (New): Naming conventions for extensions for extending Page TSconfighttp://forge.typo3.org/issues/943252021-06-12T10:30:10ZSybille Peterssypets@gmx.de
<p>What namespace should extensions use for naming the TSconfig settings (e.g. "tx_myext", "mod.tx_myext", "user.tx_myext" ...).</p>
<p>Should core and extension settings be separated?</p>
<p>How the namespace is also affects how they are displayed in "Info > Page TSconfig" (the order and if they can be selected in the select field"</p>
<p>Also, ideally the core settings should be unified in using uppercase / lowercase in the top-level "objects", currently we have a mix of all uppercase and all lowercase. There may be some deeper meaning or reason I am not aware of, but from what I wrote in <a class="issue tracker-1 status-3 priority-4 priority-default closed child" title="Bug: Info => Page TSconfig: Sort order (Resolved)" href="http://forge.typo3.org/issues/94321">#94321</a>:</p>
<blockquote>
For basic coredev installation it looks like this:
<ul>
<li>TCEFORM</li>
<li>TCEMAIN</li>
<li>mod<br />... I think it would be better to (long term) unify the naming so that the top-level items are all lowercase.<br />In TypoScript, by convention the type of the "objects" are uppercase (e.g. PAGE) and the "objects" themselves are lowercase. So I think TCEFORM, TCEMAIN etc. should be changed to lowercase. (This sometimes mixing of type and "object" and inconsistent usage of terms is something which was not just noticed and pointed out by me, we already make some changes in the "TypoScript Reference" to address this).</li>
</ul>
</blockquote>
<a name="Requirements"></a>
<h2 >Requirements<a href="#Requirements" class="wiki-anchor">¶</a></h2>
<p>1. Make it possible to easily find the settings in the filter options in "Info > Page TSconfig". <br />2. All extension TSconfig should be grouped together, not found in various places<br />3. They should be grouped logically<br />4. use an intuitive convention that is easy to remember</p>
<p>The difficulty is finding a good namespace. In mod, you have the namespaces per module, e.g mod.web_info, but you might rather want to group by extension key or group by third party extensions in general.</p>
<a name="Examples-for-existing-TSconfig"></a>
<h2 >Examples for existing TSconfig:<a href="#Examples-for-existing-TSconfig" class="wiki-anchor">¶</a></h2>
<p>Examples for extension TSconfig and how they are displayed.</p>
<ul>
<li>news: tx_news: only appears in "all" (this is what news uses)</li>
<li>linkvalidator: mod.linkvalidator: appears in "all" and in "mod" </li>
<li>direct_mail: mod.web_modules.dmail : appears in "Module: Web>Modules"</li>
</ul> TYPO3 Core - Story #94322 (Closed): Inconsistencies in showing page TSconfig in Info modulehttp://forge.typo3.org/issues/943222021-06-12T07:08:38ZSybille Peterssypets@gmx.de
<p>TYPO3 backend => Info => Page TSconfig</p>
<a name="Proposed-solution"></a>
<h2 >Proposed solution<a href="#Proposed-solution" class="wiki-anchor">¶</a></h2>
<p>1. Consistent naming in the select list (see <a class="issue tracker-6 status-5 priority-4 priority-default closed parent" title="Story: Inconsistencies in showing page TSconfig in Info module (Closed)" href="http://forge.typo3.org/issues/94322">#94322</a>)<br />2. (?) Remove "Module: Web > Modules" - as a module "Modules" no longer exists (<a class="issue tracker-4 status-5 priority-4 priority-default closed child" title="Task: Remove "Module Web>Modules" from select list in Info > Page TSconfig (Closed)" href="http://forge.typo3.org/issues/94324">#94324</a><br />3. Same order in results for "all" as order in select list (if "sort alphabetically" is not checked)<br />4. Use the same naming scheme and order in the documentation: <a class="external" href="https://docs.typo3.org/m/typo3/reference-tsconfig/master/en-us/PageTsconfig/Mod.html">https://docs.typo3.org/m/typo3/reference-tsconfig/master/en-us/PageTsconfig/Mod.html</a>#</p>
<p>Related: naming conventions for extensions <a class="issue tracker-4 status-1 priority-4 priority-default" title="Task: Naming conventions for extensions for extending Page TSconfig (New)" href="http://forge.typo3.org/issues/94325">#94325</a></p>
<p>e.g.</p>
<ul>
<li>All</li>
<li>Module [mod]</li>
<li>Module: Web > Page [mod.web_layout]</li>
<li>Module: Web > View [mod.web_view]</li>
<li>...</li>
<li>Rich text editor [RTE]
*</li>
</ul>
<p>to be done: find a nice descriptive representation for "TCEMAIN", "TCEFORM" ...</p>
<p>I am using the `[...]` style of putting the technical representation in brackets as that is already customary for e.g. page ids, page fields, fields in Flexform etc. in the Backend forms.</p>
<a name="Problem"></a>
<h2 >Problem<a href="#Problem" class="wiki-anchor">¶</a></h2>
<p>In the select list, there is a mixture of showing the objects in</p>
<p>1. their <strong>technical representation</strong> as they are used in TSConfig, e.g. <strong>"TCEMAIN"</strong><br />2. in a <strong>full plaintext</strong> representation, e.g. <strong>"Module: Web>Page"</strong> <br />3. and a <strong>mixture</strong> , e.g. " <strong>"Module key (mod) with overruling user settings"</strong></p>
<p>Should be done consistently, IMHO.</p>
<p>Also, the sorting in the results for "all" should then be the same sorting as in the select list.</p>
<p>What I find important is that you can look at the list and then find this info in the documentation (and vice versa), maybe even have the docs page open while you go through the list.</p>
<a name="Example"></a>
<h2 >Example<a href="#Example" class="wiki-anchor">¶</a></h2>
<p>When I look at "Module: Web>Page" I find this confusing. This is "mod.web_layout". I think it is done to point out where this applies and this is good, but you need both information. Here, the technical representation is missing, which also makes it difficult to use the option.</p>
<a name="Use-case"></a>
<h2 >Use case<a href="#Use-case" class="wiki-anchor">¶</a></h2>
<p>You don't know all the options by heart and things are still a little muddled. You configured the Backend Layouts and now want to check in Info => Page TSConfig.</p>
<p>Where is it? You don't know. You can look at "all" and then find it (with CTRL+f) but then you still don't know where it is in the select list the next time you need it (unless you already clicked and "got" the relation "Web > Page = "web_layout").</p>
<p>If you do got directly to "Module: Web> Page" in the select list, you do not see the missing piece "web_layout" but you need it to define, e.g.</p>
<pre>
mod.web_layout.BackendLayout
</pre>
<p>and not</p>
<pre>
mod.BackendLayout
</pre>
<p>This can make it error prone and confusing.</p>
<a name="screenshots"></a>
<h2 >screenshots<a href="#screenshots" class="wiki-anchor">¶</a></h2>
<p><img src="http://forge.typo3.org/attachments/download/36123/tsconfig_select.png" title="Info > Page TSconfig > select box" alt="Info > Page TSconfig > select box" loading="lazy" /></p> TYPO3 Core - Epic #93547 (Accepted): Collection of problems with large siteshttp://forge.typo3.org/issues/935472021-02-19T06:57:22ZSybille Peterssypets@gmx.de
<p>I used the following tags in sub-issues - where appropriate.</p>
<p><strong>tags</strong> : "large-site", "memory hog", "prepared statement", "placeholderlimit", "memory", "performance", "throttle", "usability" (or UI related things)</p>
<p>All issues related to large site are tagged with <strong>large-site</strong>.</p>
<hr />
<p>Can be many pages, many files, many directories, many categories, etc. or a combination.</p>
<p>The problems are mostly related to:</p>
<ul>
<li>performance and resource (memory) problems.</li>
<li>exceptions, e.g. database query - “Prepared statement contains too many placeholders”</li>
<li>usability: e.g. long, unusable lists (see sys_filemount: long list of directories + performance issue, unable to filter for specific pages in pagetree filter etc.)</li>
</ul>
<p>Can the question of large sites be addressed in general?</p>
<p>e.g.</p>
<ul>
<li>consider large sites when creating concepts for new features</li>
<li>create a reference "large site" </li>
<li>test patches on “large sites”</li>
<li>define hard limits / soft limits (if possible) - e.g. are there specific known limitations, can we say TYPO3 easily runs with x number of pages (redirects, sites, files, be user groups etc.) in a typical installation (e.g. with a reference site)</li>
</ul> TYPO3 Core - Task #93428 (Closed): Rename function getHeaderFlashMessagesForCurrentPid() in PageL...http://forge.typo3.org/issues/934282021-02-04T07:54:53ZSybille Peterssypets@gmx.de
<p>see explanation in</p>
<blockquote>
<p>- flash messages: those are normally shown after an action, e.g saving something was succesful<br />- callouts: give the user permanent feedback</p>
</blockquote>
<p><a class="external" href="https://forge.typo3.org/issues/93422#note-2">https://forge.typo3.org/issues/93422#note-2</a></p>
<p>Could be renamed to getCalloutsForCurrentPid().</p>
<p>Since PageLayoutController is non-internal I assume this is a breaking change, so cannot be done until v12.</p> TYPO3 Core - Task #91977 (Rejected): Code cleanup in ExtensionListCommandhttp://forge.typo3.org/issues/919772020-08-11T15:01:15ZSybille Peterssypets@gmx.deTYPO3 Core - Epic #90346 (New): Streamline and simplify configuration in general in TYPO3http://forge.typo3.org/issues/903462020-02-09T10:33:42ZSybille Peterssypets@gmx.de
<p>TYPO3 is doing a good job at deprecating and removing features, but in the area <strong>configuration</strong> it seems that more and more is being added and the "old stuff" still exists and is still required, making it even more complicated.</p>
<p>Configuration is an important (I think, a key) feature of TYPO3. This makes it even more important that it is easily usable by developers and integrators. Complicated is sometimes necessary because something is complex, but one must be careful to avoid anything unnecessarily complicated.</p>
<p>There is effort to replace TypoScript / TSconfig etc. with YAML in some places but then you still need TypoScript to load the YAML configuration (e.g. form framework).</p>
<p>What I am missing is one general concept and one general way to configure things. It seems lots of different ways to configure. I realize in some things the scope is different to which it applies, e.g. in TSconfig it applies to users or pages so it must be connected with these.</p>
<p>But I am wondering if some of this could be unified and simplified.</p>
<p>As configuration syntax we are using: XML, YAML, TypoScript syntax, Typoscript constant syntax (which is slightly different), PHP, ..</p>
<p>We are using TypoScript, TSconfig, Extension configuration, PHP arrays (TCA, GlobalConfiguation, Feature toggles), Flexform, and various configurations using YAML (site, rte_ckeditor, form), User settings configuration etc.</p>
<p>It seems to me, TypoSript was regarded as too complicated, now we added YAML and are practically creating another simpler TypoScript. But then we noticed we are missing some things, e.g. constants and now these are being requested as well.</p>
<p>I think some of this could be unified and simplified:</p>
<ol>
<li>the configuration in the backend must be changed in various places and can be viewed in various places: TSconfig can be viewed in the info module and changed in the page module in page properties, TypoScript in the TypoScript module, Then we have "settings" where we change some settings and "configuration" where we can view the variables etc.</li>
</ol>
<ol>
<li>There is a mixing up of various configuration languages. In lots of cases, you need to master several to achieve something. While it is cool, that you can override settings in rte_ckeditor (YAML) with page TSconfig, for example, this mixes up 2 different configuration languages. Also, you have to use TypoScript to configure the form configuration, which is in YAML</li>
</ol>
<ol>
<li>Create a generic API as suggested in <a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: Proper YAML configuration API (New)" href="http://forge.typo3.org/issues/85369">#85369</a> for using Yaml unifying various things (where it is stored, how it can be loaded, how files are imported, conditions, constants etc) and make this usable by extensions</li>
</ol>
<ol>
<li>Create a long term (simpler) concept of how configuration it should be and which languages should be used.</li>
</ol>
<ol>
<li>Use a real schema language to define and verify existing configuration (including YAML).</li>
</ol>
<ol>
<li>Make it generally possible to load configuration per installation or per site?</li>
</ol>
<ol>
<li>Take a hard long look at some of the configuration from the point of view of developers who are new to TYPO3</li>
</ol> TYPO3 Core - Task #87394 (Closed): composer gerrit:setup should be available for all platformshttp://forge.typo3.org/issues/873942019-01-11T08:51:38ZSybille Peterssypets@gmx.de
<p>I am currently updating the Contribution Guide. I would like to simplify the setup.</p>
<p>composer gerrit:setup sets up both commit hooks: commit-msg and pre-commit. The pre-commit hook currently may not run on Windows.</p>
<p>For this reason, you can't just write: just run composer gerrit:setup to setup commit hooks. You have to write: for windows do ..., for Linux / Mac do ...</p>
<p>So, it might be useful to do one of the following:</p>
<ol>
<li>make the pre-commit hook portable</li>
<li>only copy the commit-msg hook with gerrit:setup</li>
<li>or check before copying if it will run on current system in <a href="https://github.com/TYPO3/TYPO3.CMS/blob/master/Build/Scripts/composer/InstallerScripts.php" class="external">InstallerScripts:enablePreCommitHook</a></li>
</ol> TYPO3 Core - Task #87176 (Closed): Add git setup script for core developmenthttp://forge.typo3.org/issues/871762018-12-16T23:33:05ZSybille Peterssypets@gmx.de
<p>Currently, several commands must be executed manually. Some of these, can't just be copy-pasted, because user-specific options must be added to commands (email address, username, etc.).</p>
<p>A script can be added, which makes the setup easier.</p>
<p>Currently, you must execute the following commands:</p>
<pre><code class="text syntaxhl" data-language="text">git config user.name "Your Name"
git config user.email "your-email@example.com"
git config branch.autosetuprebase remote
# usually, not required
mkdir -p .git/hooks
cp Build/git-hooks/commit-msg .git/hooks/commit-msg
# make executable (usually not required)
chmod +x .git/hooks/commit-msg
# optional
cp Build/git-hooks/unix+mac/pre-commit .git/hooks/
chmod +x .git/hooks/pre-commit
git config url."ssh://<YOUR_TYPO3_USERNAME>@review.typo3.org:29418".pushInsteadOf git://git.typo3.org
# optional
git config commit.template ~/.gitmessage.txt
</code></pre>
<p>See <a class="external" href="https://docs.typo3.org/typo3cms/ContributionWorkflowGuide/Setup/Git/Index.html">https://docs.typo3.org/typo3cms/ContributionWorkflowGuide/Setup/Git/Index.html</a></p> TYPO3 Core - Task #85725 (Closed): Add directories created by rendering of documentation to .giti...http://forge.typo3.org/issues/857252018-08-02T10:38:01ZSybille Peterssypets@gmx.deTYPO3 Core - Story #85430 (Closed): Improve usability of impexp and add documentationhttp://forge.typo3.org/issues/854302018-06-29T11:18:05ZSybille Peterssypets@gmx.de
<a name="Problem"></a>
<h1 >Problem<a href="#Problem" class="wiki-anchor">¶</a></h1>
<p>While being highly configurable, this useful tool does not have sane defaults, which work in a standard setting, so you often wind up not getting it right. Also some of the options in tab "Configuration" are not easy to use.</p>
<p>Example: In a standard introduction / bootstrap_package TYPO3 9, you get errors using the defaults (see below for explanation).</p>
<p>IMHO: The defaults should work in <strong>most cases</strong> and you would only need to change the settings if necessary.</p>
<ul>
<li>it is difficult to understand how it works and when to use "Include tables", "Include relations to tables" and "Use static relations for tables", even for technical people, but expecially for non-technical people.</li>
<li>"Use static relations for tables" is not intuitive. what does "to keep relations untouched for" mean?</li>
<li>the sorting of the extensions in the Advanced options "Extension dependencies" is not alphabetically and selection is extremely tedious. There are better solutions around, e.g list picker used for static includes in Template.</li>
<li>some text of the output of "Structure to be exported" is cut off, there is no information if this is also being written to a logfile. There is no option to select output in logfile.</li>
<li>on tab "File & Preset" you have buttons "update", "Download export" and "Save to filename". Might make sense to have these 3 buttons in a general section on the page where they are always displayed (because they are not specific to the tab).</li>
</ul>
<p>presets:</p>
<ul>
<li>The presets are saved in a DB table tx_impexp_presets so you can't just easily edit them as text and put them in version control. Nowadays, you might rather use Yaml for this (as in the sites module) and you might want to add presets for impexp in an extension (like you do for Backend modules).</li>
<li>After saving a preset, the module jumps back to the first Tab "Configuration" </li>
<li>When saving a preset with the same name, I would expect it to overwrite the already existing one. However, it creates a new one.</li>
</ul>
<a name="Example-Reproduce"></a>
<h1 >Example / Reproduce<a href="#Example-Reproduce" class="wiki-anchor">¶</a></h1>
<p>1. Use a fresh bootstrap_package / introduction with latest TYPO3 9<br />2. Select top page "Congratulations" and do not change defaults (Levels "This page" will be selected)<br />3. Look at "Structure to be exported" at the bottom.</p>
<p>There are several errors. The first of which is a "LOST RELATION" to page 54 "Home". Why does he even bother with that page. Selected page level was 1 (default)?</p>
<p><img src="http://forge.typo3.org/attachments/download/33568/impexp.png" alt="" loading="lazy" /></p>
<p>In a diferent installation, 2 other problems occured, where I am still not quite sure which options to select:</p>
<ul>
<li>no files were exported</li>
<li>too many things were exported, including files linked to a tt_content on a different page, which was hidden (even thought "Exclude disabled elements" was selected)</li>
</ul>
<a name="Solution"></a>
<h1 >Solution<a href="#Solution" class="wiki-anchor">¶</a></h1>
<ul>
<li>Add documentation with some examples, including sample presets you can copy-paste</li>
<li>use sane defaults which should work in most cases (test this with introducation / bootstrap_package)</li>
<li>Better explain "Include tables", "Include relations to tables" and "User static relations for tables"
* Example: Why would I include "pages" in "Include relations to tables", I've already defined in "Levels" <br /> which relations to other pages I want.
* Example: If I want news in my exports, should I check "Include tables" or "Include relations to tables" or both? When in fact, everything is a relation anyway (a relation to the page).</li>
<li>Use Yaml for configuration or at least make it import / exportable as yaml.</li>
<li>Use selectMultipleSideBySide list picker to select extensions, and the db tables</li>
<li>Put generic buttons ("Update", "Downlaod export", "Save to filename") at the bottom with a seperator and show it in all 3 tabs</li>
<li>Log output to file (optional)</li>
<li>don't jump to different tab after changing something, stay in currently selected tab.</li>
</ul>
<a name="Prerequisites"></a>
<h1 >Prerequisites<a href="#Prerequisites" class="wiki-anchor">¶</a></h1>
<p>Probably some general things should be clarified:</p>
<ul>
<li>what format and where to save presets (currently serialized array in db)</li>
<li>what formats to use for saving export (currently XML, T3D, compressed T3D), see <a class="issue tracker-4 status-5 priority-4 priority-default closed child" title="Task: Improve logging of initial t3d import errors (Closed)" href="http://forge.typo3.org/issues/58801">#58801</a></li>
</ul>
<p><em>Note: Some of what is mentioned here might be due to user error or misunderstanding of mine, but that only proves the point: This tool should not be terribly difficult to use. <br /></em></p> TYPO3 Core - Task #85007 (Closed): Remove setting style for broken links in RteHtmlParser::markBr...http://forge.typo3.org/issues/850072018-05-15T09:05:14ZSybille Peterssypets@gmx.de
<p>Once patch <a class="external" href="https://review.typo3.org/c/56943/">https://review.typo3.org/c/56943/</a> is merged, setting the style for broken links in RteHtmlParser should be removed in master.</p> TYPO3 Core - Epic #85006 (New): Reduce falsely reported broken linkshttp://forge.typo3.org/issues/850062018-05-14T18:35:33ZSybille Peterssypets@gmx.de
<p>Falsely reported broken links are currently a main factor that makes link fixing with Linkvalidator tedious and annoying: there is no way to remove them from the list of broken links. When searching for links to fix, you have to check several that are not really an error. Furthermore, these stay in the list while the real broken links will disappear, so after fixing more links the ratio of falsely reported broken links to real broken links worsens.</p>
<p>By <strong>"falsely reported broken links"</strong> we mean links that Linkvalidator shows as broken but that are either not broken or that cannot be edited by the editor or some other reason why they are either irrelevant or cannot be fixed.</p>
<p>We already have several issues and open patches addressing these issues. This EPIC serves to give an overview.</p>
<a name="Main-reasons-for-false-broken-links"></a>
<h2 >Main reasons for false broken links<a href="#Main-reasons-for-false-broken-links" class="wiki-anchor">¶</a></h2>
<ul>
<li>external link checking may fail. This means we will get false negatives links that actually work but are evaluated as "broken" by linkvalidator). We already improved here, but it still may happen. (see <a class="issue tracker-1 status-5 priority-4 priority-default closed child" title="Bug: HTML special characters fool linkvalidator (Closed)" href="http://forge.typo3.org/issues/89488">#89488</a>, <a class="issue tracker-1 status-5 priority-4 priority-default closed child" title="Bug: Linkvalidator stops working on specific links (external URLs) (Closed)" href="http://forge.typo3.org/issues/86918">#86918</a>) </li>
<li>Some links are not broken, but will not return HTTP Status Code 200. This are for example pages that require a login (403, 401).</li>
<li>broken links are in some fields that are no longer relevant, e.g. in tt_content.bodytext for content elements that do not use bodytext. This may happen if tt_content.ctype is changed (e.g. to plugin), which may often happen on older sites. (see <a class="issue tracker-1 status-8 priority-4 priority-default child" title="Bug: Linkvalidator should only check relevant fields in table (Under Review)" href="http://forge.typo3.org/issues/89182">#89182</a>)</li>
<li>FIXED: the editor has no permission to edit the field or the record (<a class="issue tracker-1 status-5 priority-4 priority-default closed child" title="Bug: Linkvalidator should not check records without write permissions (Closed)" href="http://forge.typo3.org/issues/84214">#84214</a>)</li>
<li>the broken link information is "stale", meaning, the broken link has already been fixed but linkvalidator has not rechecked the field or the record has been deleted (see <a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: Remove stale broken links in tx_linkvalidator_link (New)" href="http://forge.typo3.org/issues/89426">#89426</a>, <a class="issue tracker-2 status-5 priority-4 priority-default closed child" title="Feature: Linkvalidator should remove repaired links from report after editing record (Closed)" href="http://forge.typo3.org/issues/83847">#83847</a>)</li>
</ul>
<a name="Ideas-for-reducing-false-broken-links"></a>
<h2 >Ideas for reducing false broken links<a href="#Ideas-for-reducing-false-broken-links" class="wiki-anchor">¶</a></h2>
<p>do not check some external links</p>
<ul>
<li>Make it possible to exclude URLs from link checking in the configuration (TSconfig), e.g. URLs starting with <a class="external" href="http://intranet.mysite.com/">http://intranet.mysite.com/</a></li>
<li>Make it possible to exclude a specific link from link checking (in the RTE)</li>
<li>For more ease of use: In the list of broken links: add an action button to click on which will add the URL to the ignore URLs</li>
</ul>
<p><img src="http://forge.typo3.org/attachments/download/35449/ignore-url.png" alt="" loading="lazy" /></p>
<p>check sooner</p>
<ul>
<li>ideally, the broken link information should be updated as soon as a record is changed (e.g. broken links in list of broken links removed, as soon as record is deleted), e.g. by using NEW / UPDATE / DELETE events</li>
<li>alternatively, link checking could be done incrementally and more often, only checking the records that changed (see <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Implement incremental link checking within linkvalidator (Closed)" href="http://forge.typo3.org/issues/92220">#92220</a>)</li>
</ul>
<p>do not check some fields</p>
<ul>
<li>only check fields that will be rendered, e.g. not tt_content.bodytext for ctype='plugin', etc. (see <a class="issue tracker-1 status-8 priority-4 priority-default child" title="Bug: Linkvalidator should only check relevant fields in table (Under Review)" href="http://forge.typo3.org/issues/89182">#89182</a>)</li>
</ul> TYPO3 Core - Epic #84889 (Closed): Make frontend: PageRepository and PageRepositoryTest notice freehttp://forge.typo3.org/issues/848892018-04-28T10:54:03ZSybille Peterssypets@gmx.de
<p>Core: Error handler (BE): PHP Notice: Undefined index: disabled in /var/www/linkvalidator/typo3/sysext/frontend/Classes/Page/PageRepository.php <a href="https://github.com/TYPO3/TYPO3.CMS/blob/48adc7ac337bc45eb4263ebc675080f2042c685a/typo3/sysext/frontend/Classes/Page/PageRepository.php#L1364" class="external">line 1364</a></p>
<p>Core: Error handler (BE): PHP Notice: Undefined index: starttime in /var/www/linkvalidator/typo3/sysext/frontend/Classes/Page/PageRepository.php <a href="https://github.com/TYPO3/TYPO3.CMS/blob/48adc7ac337bc45eb4263ebc675080f2042c685a/typo3/sysext/frontend/Classes/Page/PageRepository.php#L1368" class="external">line 1368</a></p>
<p>Core: Error handler (BE): PHP Notice: Undefined index: endtime in /var/www/linkvalidator/typo3/sysext/frontend/Classes/Page/PageRepository.php <a href="https://github.com/TYPO3/TYPO3.CMS/blob/48adc7ac337bc45eb4263ebc675080f2042c685a/typo3/sysext/frontend/Classes/Page/PageRepository.php#L1372" class="external">line 1372</a></p>
<p>Core: Error handler (BE): PHP Notice: Undefined index: TYPO3\CMS\Frontend\Page\PageRepository in /var/www/linkvalidator/typo3/sysext/frontend/Classes/Page/PageRepository.php <a href="https://github.com/TYPO3/TYPO3.CMS/blob/48adc7ac337bc45eb4263ebc675080f2042c685a/typo3/sysext/frontend/Classes/Page/PageRepository.php#L209" class="external">line 209</a></p>