TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-08-18T14:58:45ZTYPO3 Forge
Redmine TYPO3 Core - Task #101711 (New): document classesAnchor for rte_ckeditorhttp://forge.typo3.org/issues/1017112023-08-18T14:58:45ZSybille Peterssypets@gmx.de
<p>This is the only documentation for classesAnchor I could find so far, but this is for rtehtmlarea:</p>
<p><a class="external" href="https://docs.typo3.org/p/friendsoftypo3/rtehtmlarea/main/en-us//Configuration/PageTsconfig/classesAnchor/Index.html">https://docs.typo3.org/p/friendsoftypo3/rtehtmlarea/main/en-us//Configuration/PageTsconfig/classesAnchor/Index.html</a></p>
<p>classesAnchor is not documented in the rte_ckeditor documentation: <a class="external" href="https://docs.typo3.org/c/typo3/cms-rte-ckeditor/main/en-us/Index.html">https://docs.typo3.org/c/typo3/cms-rte-ckeditor/main/en-us/Index.html</a></p>
<p>classesAnchor can be used in rte_ckeditor as well, see example in bootstrap_package:</p>
<pre>
classesAnchor:
page:
class: 'link-page'
type: 'page'
folder:
class: 'link-folder'
type: 'folder'
file:
class: 'link-file'
type: 'file'
external:
class: 'link-external'
type: 'url'
mail:
class: 'link-mail'
type: 'mail'
</pre>
<p><a class="external" href="https://github.com/benjaminkott/bootstrap_package/blob/master/Configuration/RTE/Default.yaml">https://github.com/benjaminkott/bootstrap_package/blob/master/Configuration/RTE/Default.yaml</a></p>
<a name="Search-for-classesAnchor"></a>
<h3 >Search for "classesAnchor"<a href="#Search-for-classesAnchor" class="wiki-anchor">¶</a></h3>
<ul>
<li>in "TYPO3 Explained": no result</li>
<li>in rte_ckeditor Documentation: no result</li>
</ul>
<a name="Related"></a>
<h3 >Related<a href="#Related" class="wiki-anchor">¶</a></h3>
<ul>
<li>changelog: <a href="https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Breaking-98275-RemovedPreDefinedLinkTitleAttributesInRTELinkBrowser.html" class="external">Breaking: #98275 - Removed pre-defined link title attributes in RTE link browser</a></li>
</ul> TYPO3 Core - Task #100299 (Closed): Shorten texts for webhooks descriptionhttp://forge.typo3.org/issues/1002992023-03-25T09:10:10ZSybille Peterssypets@gmx.de
<pre>
<trans-unit id="sys_webhook.description.description" resname="sys_webhook.description.description">
<source>Additional information about the webhook for your internal reference.</source>
</trans-unit>
</pre><br />Suggestion:
<pre>
- Additional information about the webhook for your internal reference.
+ Additional information about the webhook.
</pre>
<p>I noticed this when adding some translation suggestions in Crowdin. This appeared difficult to translate because I was not sure what "for your internal reference" means in this context. And it seems to add little value.</p>
<p>Also, some of the desciptions end with a dot and and some don't.</p> TYPO3 Core - Task #100031 (Closed): Inconsistency of naming transOrigDiffSourceField fields (l18n...http://forge.typo3.org/issues/1000312023-02-25T08:07:04ZSybille Peterssypets@gmx.de
<ul>
<li>AFAIK l18n (with an L as in Localization) is not the convention , it is i18n (with an I as in Internationalization)</li>
<li>why use both?</li>
<li>shouldn't i18n_diffsource (i18n for Internationalization) be more appropriate (see source below)?</li>
</ul>
<hr />
<p>The following field names are currently used for transOrigDiffSourceField:</p>
<pre>
sys_file_metadata.php: => 'l10n_diffsource',
sys_category.php: => 'l10n_diffsource',
sys_file_reference.php: => 'l10n_diffsource',
pages.php: => 'l10n_diffsource',
sys_file_collection.php: => 'l10n_diffsource',
tt_content.php: => 'l18n_diffsource',
</pre>
<hr />
<blockquote>
<p><strong>Localization</strong> refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale). Localization is sometimes written in English as <strong>l10n</strong> , where 10 is the number of letters in the English word between l and n.</p>
</blockquote>
<blockquote>
<p><strong>Internationalization</strong> is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language. Internationalization is often written in English as <strong>i18n</strong> , where 18 is the number of letters between i and n in the English word.</p>
</blockquote>
<p><a class="external" href="https://www.w3.org/International/questions/qa-i18n">https://www.w3.org/International/questions/qa-i18n</a></p> 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 - Task #99451 (New): PHPDoc, name of arguments and documentation not very intuitive fo...http://forge.typo3.org/issues/994512023-01-03T16:19:13ZSybille Peterssypets@gmx.de
<a name="Problems"></a>
<h2 >Problems<a href="#Problems" class="wiki-anchor">¶</a></h2>
<p>1. The order is reversed: the values in ->inSet which are passed to FIND_IN_SET are reversed<br />2. argument names do not clearly reflect what is needle, what is haystack, what is the comma separated list<br />3. PHPDoc is vague, possibly also misleading:</p>
<blockquote>
<p>$fieldName The field name.<br />string $value Argument to be used in FIND_IN_SET() comparison.</p>
</blockquote>
<p>4. Possibly it might be good ideat to rename the function name (or create a new one and deprecate the old) as it is not a simple FIND_IN_SET, it is a FIND_IN_SET where the haystack refers to a database field name which contains a comma separated list of values</p>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<p>To mitigate this, I think at least the following should be done:</p>
<p>- function argument names should be named in a way which makes it intuitive. For example, use names such as "needle" and "haystack" or "pattern" and "fieldList" as is customary in PHP and / or SQL.<br />- make PHPDoc more specific if helpful in addition to argument names. Remove explanations which only repeat the name of the argumen. E.g. "field name" as explanation for fieldName is unnecessary fluff.<br />- possibly improve documentation: <a class="external" href="https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Database/ExpressionBuilder/Index.html#comparisons">https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Database/ExpressionBuilder/Index.html#comparisons</a>. Apply same principles here.</p> TYPO3 Core - Task #99157 (Under Review): Performance optimize sitemap.xml generationhttp://forge.typo3.org/issues/991572022-11-21T18:32:02ZSybille Peterssypets@gmx.de
<p>Loading sitemap.xml seemed slow, had load time of more than 20s (see measurements below of over a minute).</p>
<p>- the cache duration (seo_sitemap.config.cache_period) for sitemaps is by default 900 (15 minutes) which seems very short as the average page cache time is 24h. While having a fresh sitemap is of course prefereable. But, due to the long load time, this means the sitemap is effectively broken on large sites, until it is warmed up again. (the cache duration can of course be overridden but it remains the default)<br /> - There is an SQL fetch with select * (all fields) . It is probably not necessary to fetch all the fields.</p>
<pre><code class="sql syntaxhl" data-language="sql"><span class="k">SELECT</span> <span class="o">*</span> <span class="k">FROM</span> <span class="nv">`pages`</span> <span class="k">WHERE</span> <span class="p">(</span><span class="nv">`uid`</span> <span class="k">IN</span> <span class="p">(</span><span class="mi">57119</span> <span class="p">...))</span> <span class="k">AND</span> <span class="p">(</span><span class="n">no_index</span> <span class="o">=</span> <span class="mi">0</span><span class="p">)</span> <span class="k">AND</span> <span class="p">(</span><span class="nv">`doktype`</span> <span class="k">NOT</span> <span class="k">IN</span> <span class="p">(</span><span class="mi">3</span><span class="p">,</span> <span class="mi">4</span><span class="p">,</span> <span class="mi">6</span><span class="p">,</span> <span class="mi">7</span><span class="p">,</span> <span class="mi">199</span><span class="p">,</span> <span class="mi">254</span><span class="p">,</span> <span class="mi">255</span><span class="p">))</span> <span class="k">AND</span> <span class="p">((</span><span class="nv">`pages`</span><span class="p">.</span><span class="nv">`deleted`</span> <span class="o">=</span> <span class="mi">0</span><span class="p">)</span> <span class="k">AND</span> <span class="p">(</span><span class="nv">`pages`</span><span class="p">.</span><span class="nv">`hidden`</span> <span class="o">=</span> <span class="mi">0</span><span class="p">)</span> <span class="k">AND</span> <span class="p">(</span><span class="nv">`pages`</span><span class="p">.</span><span class="nv">`starttime`</span> <span class="o"><=</span> <span class="mi">1669052220</span><span class="p">)</span> <span class="k">AND</span> <span class="p">((</span><span class="nv">`pages`</span><span class="p">.</span><span class="nv">`endtime`</span> <span class="o">=</span> <span class="mi">0</span><span class="p">)</span> <span class="k">OR</span> <span class="p">(</span><span class="nv">`pages`</span><span class="p">.</span><span class="nv">`endtime`</span> <span class="o">></span> <span class="mi">1669052220</span><span class="p">)))</span> <span class="k">ORDER</span> <span class="k">BY</span> <span class="nv">`uid`</span> <span class="k">ASC</span>
</code></pre>
<p>This alone does not contribute to the long load time, but it might be possible to make some of the SQL queries more efficient.</p>
<a name="System"></a>
<h2 >System<a href="#System" class="wiki-anchor">¶</a></h2>
<p>- TYPO3 11.5.19<br />- pages in sitemap (default language): ~25000<br />- also news in sitemap (default language): ~15000</p>
<a name="Measurements"></a>
<h2 >Measurements<a href="#Measurements" class="wiki-anchor">¶</a></h2>
<p>Feching the individual sitemaps for translated pages seems especially slow.</p>
<p>After a full cache flush:</p>
<ul>
<li>URL (for page 5): <a class="external" href="https://mysite/en/sitemap.xml?page=5&sitemap=pages&cHash=179f57abab819f22b0581465651db76d">https://mysite/en/sitemap.xml?page=5&sitemap=pages&cHash=179f57abab819f22b0581465651db76d</a></li>
<li>Time: <strong>1 minute, 26 seconds</strong></li>
</ul>
<p>(default language is German, English is translation)</p>
<a name="DB-queries"></a>
<h2 >DB queries<a href="#DB-queries" class="wiki-anchor">¶</a></h2>
<p>SELECT * FROM `pages` WHERE (`uid` IN (57119 ...)) AND (no_index = 0) AND (`doktype` NOT IN (3, 4, 6, 7, 199, 254, 255)) AND ((`pages`.`deleted` = 0) AND (`pages`.`hidden` = 0) AND (`pages`.`starttime` <= 1669052220) AND ((`pages`.`endtime` = 0) OR (`pages`.`endtime` > 1669052220))) ORDER BY `uid` ASC;</p> TYPO3 Core - Task #99086 (Closed): Add default value for "method" attribute in FormViewHelperhttp://forge.typo3.org/issues/990862022-11-14T17:50:58ZSybille Peterssypets@gmx.de
<p>The default is "post" but this does not show up in the automatically generated ViewHelper reference since default is not set in the initializeArguments method:</p>
<p>$this->registerTagAttribute('method', 'string', 'Transfer type (GET or POST)');</p>
<p>However, the attribute is always set, the default value would be "post".</p>
<ul>
<li><a href="https://docs.typo3.org/other/typo3/view-helper-reference/main/en-us/typo3/fluid/latest/Form.html#method" class="external">Documentation</a></li>
</ul> TYPO3 Core - Task #98564 (Closed): TYPO3 "Edit on GitHub" does not work for changeloghttp://forge.typo3.org/issues/985642022-10-10T11:03:16ZSybille Peterssypets@gmx.de
<p>Example:</p>
<ul>
<li>docs URL: <a class="external" href="https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/10.4/Deprecation-90147-UnifiedFileNameValidator.html">https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/10.4/Deprecation-90147-UnifiedFileNameValidator.html</a></li>
<li>"Edit on GitHub": <a class="external" href="https://github.com/typo3/typo3/edit/main/typo3/sysext/core/DocumentationChangelog/10.4/Deprecation-90147-UnifiedFileNameValidator.rst">https://github.com/typo3/typo3/edit/main/typo3/sysext/core/DocumentationChangelog/10.4/Deprecation-90147-UnifiedFileNameValidator.rst</a></li>
</ul>
<p>Possible the setting path_to_documentation_dir just needs a trailing slash, but there have been some changes in the settings and not sure what is currently correct</p>
<p>typo3/sysext/core/Documentation/Settings.cfg</p>
<blockquote>
<p>path_to_documentation_dir = typo3/sysext/core/Documentation</p>
</blockquote> TYPO3 Core - Task #98271 (Closed): Make it possible to easily and correctly build assets for core...http://forge.typo3.org/issues/982712022-09-07T06:43:13ZSybille Peterssypets@gmx.de
<p>For main branch, there is Build/Scripts/runTests.sh -s buildJavascript to build TypeScript / JavaScript. This also exists in 11.5, but it results in extra .js files being generated, so probably this is incorrect. Previously, cd Build;yarn install;yarn build was used, not sure if this is still the case in 11.5</p>
<p>Probably best to fix the command for runTests.sh or remove / change it. Might need also change in contribution guide. (I did not test the building of css files. Should also be checked)</p>
<a name="Reproduce"></a>
<h2 >Reproduce<a href="#Reproduce" class="wiki-anchor">¶</a></h2>
<p>git reset --hard origin/11.5;git pull origin 11.5<br />Build/Scripts/runTests.sh -s buildJavascript<br />git status</p>
<p>Result</p>
<p>On branch 11.5<br />Your branch is up to date with 'origin/11.5'.</p>
<p>Untracked files:<br /> (use "git add <file>..." to include in what will be committed)<br /> typo3/sysext/backend/Resources/Public/JavaScript/ClipboardComponent.js<br /> typo3/sysext/backend/Resources/Public/JavaScript/ToggleSearchToolbox.js<br /> typo3/sysext/backend/Resources/Public/JavaScript/Wizard/<br /> typo3/sysext/filelist/Resources/Public/JavaScript/FileListLocalisation.js<br /> typo3/sysext/recordlist/Resources/Public/JavaScript/ColumnSelectorButton.js</p> TYPO3 Core - Task #98268 (Closed): Localize text in JavaScript modal "Are you sure?"http://forge.typo3.org/issues/982682022-09-06T18:48:05ZSybille Peterssypets@gmx.de
<p>Build/Sources/TypeScript/backend/modal.ts</p> 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 - 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 - 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 - 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>