Adlago

Yes, you are right. Thanks. This works correctly in my test installation. Template core_global_global/poll Find <h3 class='ipsType_sectionHead'><span class='ipsType_break ipsContained'>{$i}. {$question['question']}</span></h3> replace <h3 class='ipsType_sectionHead'><span class='ipsType_break ipsContained'>{{if $i>1 }}{$i}.{{endif}} {$question['question']}</span></h3> Template core_global_global/pollForm Find <h3 class='ipsType_sectionHead'><span class='ipsType_break ipsContained'>{$i}. {$input->label}</span></h3> replace <h3 class='ipsType_sectionHead'><span class='ipsType_break ipsContained'>{{if $i>1 }}{$i}.{{endif}} {$input->label}</span></h3>

If this <h3 class='ipsType_sectionHead'><span class='ipsType_break ipsContained'>{$i}. {$question['question']}</span></h3> replace with {{if $i>1 }} <h3 class='ipsType_sectionHead'><span class='ipsType_break ipsContained'>{$i}. {$question['question']}</span></h3> {{else}} <h3 class='ipsType_sectionHead'><span class='ipsType_break ipsContained'>{$question['question']}</span></h3> {{endif}} All subsequent questions will have correct numbering. The first question will be without a number.

You can remove the numbering of questions if you change this: Open a template: core_global_global/poll find this code <h3 class='ipsType_sectionHead'><span class='ipsType_break ipsContained'>{$i}. {$question['question']}</span></h3> and replace with <h3 class='ipsType_sectionHead'><span class='ipsType_break ipsContained'>{$question['question']}</span></h3> Note: In this case, all questions will not be numbered.

The content that is generated from the manifest file is now the following "scope": "\/", "name": "...", "theme_color": "...", "short_name": "...", "start_url": "\/", "description": "...", "background_color": "...", "display": "standalone", "icons":... These settings are made when activated and very rarely are subject to change. There is nothing stopping when a site administrator chooses to use a cookie-free domain, loading a manifest file should also be from that domain. When a cookie-free domain is used now, links in the contents of a manifest file (for android chrome icons) are generated with an address for a cookie-free domain - and there is no issues. So I think loading a manifest.webmanifest file from a cookie-free domain will create an improvement. PS. You can check - the contents of my manifest file are loaded without issue when loaded with a link cookie-free domain https://str.nophelet.com/manifest.webmanifest/

Yes, I read these articles. They look at specific site architectures, and probably used a cookie-free domain before optimizing this site - If use a cookie-free domain if the site was not optimized - images, css and js, html5 errors, and more is really pointless and has no effect. A cookie-free domain only makes sense when everything else on the site is optimized - ie. used at the end of the optimization process, or then used by CDN - depending on site need. In my observations and analysis of different sites using the IPS suite, after site optimization, the use of a cookie-free domain improves site performance and speed, especially for PSI tests relevant to sites using Google ads and other sources.

Cookie-free domain is free, ie anyone can create it on their own server and they will not pay for it. http2 is a very good working protocol. But besides the fast loading site there are other things. A cookie-free domain , for example, improves the YSlow and consequently the overall performance. When analyzing with Pingdom, at least for my site, perfor incremance ased by 5 points.

There is no logic when all resources are loaded by a cookie-free domain, incl. and links from the contents of the manifest file, to load the manifest file from the main domain ... I have no problem with speed loading, just I share what I notice - and here's to see for yourself - how to load a manifest file. And yes, I use 100% keep-alive

When a cookie-free domain is used, all resources are loaded by that cookie-free domain, including links in the contents of the manifest file. But, the initiator for loading manifest.webmanifest does not change and manifest is loaded from the primary domain. This causes: - DNS lookup - new connecting - new SSL, or about 200 ms delay for loading manifest file. If possible, include a cookie-free domain for loading manifest file, when used - this will speed up the loading site. Thanks

Your link in Google Search console is .../profile/ ..., also contains 'preload' editor css- ie. it may be the same reason I write above.

I do not claim, but only guess. Google maybe have introduced new requirements in a last few months - and complaints from site administrators have been also in recent months ...

I did an analysis of the affected addresses on a site from the topic I quoted. These addresses listed in the Google search console as errors, have no issues - everything from content works perfectly for desktop and mobile tests. The only content in these addresses that is different from the other addresses on this site is this warning in the console, when tested with the dev tools Chrome. A few days ago the 'preload' for editor css has been removed on this site - now there is no warning on the chrome dev test. I expect the site owner to report the result of the index request again. My suspicion is that Google search console when it finds a warning in suggested indexing links - refuses indexing and sends a warning to site admin. This editor css loads from the framework css quickly and in parallel with the h2 protocol. Guests have no issues. This "preload" editor css is absolutely unnecessary and rather creates a strain on the site admin reading a Google search console ...

In file .../System/Helper/Form/Editor.php you use: \IPS\Output::i()->linkTags[] = array( 'as' => 'style', 'rel' => 'preload', 'href' => (string) $cssUrl ); When guest posting is have permissions , a link is loaded in the head: <link as="style" rel="preload" href="https://yoursite/applications/core/interface/ckeditor/ckeditor/skins/ips/editor.css?t=J7UC" /> The effect of this preload is very doubtful, rather it hinders because a warning is logged with a dev tools browser test The resource https://yoursite/applications/core/interface/ckeditor/ckeditor/skins/ips/editor.css?t=J7UC was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate `as` value and it is preloaded intentionally. This warning only exists for guests. There is no problem for registered users This is probably the reason for the fixed errors links from Google Search Console, as mentioned in this topic: There will probably be a lot of time-wasting performance analysis for guests and registered users ... And in fact there is no effect on improving the loading speed of the site, but rather the damage. I think you should remove this rule from Editor.php. Thanks

What does IPS provide for security headers? 😉

Only name idea for this Apps 😀 "DII' Hat"

Missing itemListElement for ..../cookies/ .../privacy/ and .../guidelines/ These are the latest warnings from Google Search Console. Does IPS envisage a decision ? Thanks