Joriz

We haven't used salted md5s since v4 😉 We use bcrypt.

Elasticsearch will provide vastly superior search results, however it is a remote service so your community will need to make HTTP requests to it in order to index the content, and to fetch the search results. That said, the searching is faster than MySQL particularly for larger data sets.
Generally speaking, if you get to a million or two posts, you should probably switch over to ElasticSearch. Before that point, you would really just need to try it out and see if you prefer it or not. If you have a really fast server and a relatively smaller site, you may find that local MySQL searches are sufficient, and perform faster, than a remote service.

I saw an article about it today and its going to be leveraging more privacy and going as far allowing users to hide their emails by creating alternative emails with the 3rd party. Any emails to that created email will then forward through apple to the user. https://www.engadget.com/2019/06/04/sign-in-with-apple-privacy-security-google-facebook-wwdc/

It's very much on our RADAR. Details are sketchy right now and it's not being beta tested until summer, so we're watching closely.

Glad to hear that 4.4 has resolved the sitemap issues. 🙂

I have written a lot about this subject, incl. and i have a design to use the critical CSS to remove the Render-blocking CSS. Yes, it works, but it takes a lot of time to analyze and develop a good critical CSS.
For a few days I've been exploring another idea that came to my mind.
Code in IncludeCSS works perfectly and this code tells the browser - download all those CSS and use them to represent the site. But this code does not tell the browser when and how to use them.
The idea I'm using right now is - I created a new template that I put before closing the tag head. In my experiment, this template looks like this:
{template="preload_css" app="core" location="global" group="analysis" params=""} In this template I placed this code
{{foreach array_unique( \IPS\Output::i()->cssFiles, SORT_STRING ) as $file}} <link rel='preload' href='{expression="\IPS\Http\Url::external( $file )->setQueryString( 'v', \IPS\CACHEBUST_KEY )"}' as="style"> {{endforeach}} {{$customCss = \IPS\Theme::i()->css( 'custom.css', 'core', 'front' );}} {{foreach $customCss as $css}} <link rel='preload' href='{expression="\IPS\Http\Url::external( $css )->setQueryString( 'v', \IPS\CACHEBUST_KEY )"}' as="style"> {{endforeach}} Now, besides a browser command to download all CSS, I send the browser a command - use these CSS as a matter of priority.
And the result of over 100 my tests - no render-blocking CSS ...
There are no side effects or any other bad impact.
I've installed it on my live site and it works perfectly.
If a development team wishes, let him test it and apply it in later releases. This will speed up all sites using this really good platform.

Sorry for the bump. But I think the following works. I'm currently testing it.


https://board-url/index.php?app=core&module=global&section=login&do=process POST ips_username=GoogleBot ips_password=the password you set for the bot auth_key=880ea6a14ea49e853634fbdc5015a024 rememberMe=1
As far I understand the auth_key is always 880ea6a14ea49e853634fbdc5015a024 for guests.

a sort of related suggestion for the future would be to tie in the performance mode with the server cut off option
ie automatically switches on performance mode when server load hits x

I've done a quick search and can't see anything ...

One of the things I want to encourage my admins to think about is using Performance Mode - my site usually runs very nicely, but occasionally we see huge spikes in demand, and to my eyes that would be the ideal time to turn it on.

However, once it's on - unless you're looking for it (or the things that are missing) you don't know it's turned on. Would it be possible to include something (or even tell me how to skin that in), maybe on the Mod Tools top line to say that "Performance Mode is enabled"? That way it's obvious to us.

Would it be possible when a forum enables the performance mode that it shows something to users to let them know what this entails etc - just i get people mentioning why isnt X/Y/Z working and when the forum is active it gets a tiresome answering things - would be good if it just highlighted the forum is in performance mode which disables some normal features etc.

I think the current approach to having lots of individual JS and CSS files on a page with some loaded by the minify script isn't quite as efficient as it should be.

I suggest that you spend a little development time to implement a better solution.

Since browsers are required to never cache a file that uses a query string, make all JS and CSS files use FURLs (e.g., /javascript/ips.attach.js) as an option to loading the files through index.php. Don't combine any individual files into one URL. Load them in the script individually with maximum "forever" caching headers. Include a version number/last modified timestamp for a JS or CSS file in the FURL (e.g., ips.attach.v93802339.js). Don't change the underlying file name on disk. Since index.php (or another script that doesn't log in) is used to serve the files, the script will simply return the file with the version timestamp stripped out. The timestamps can be cached but recached on demand or whenever changed through the ACP. Keep a minified cache on disk of all files so the file is minified once (unless its timestamp changes and then the minified cache should be invalidated). Since all JS and CSS would be served as FURLs with forever caching headers and the filenames are timestamped, this should result in most all browsers caching the files and only requesting a file to load only once. The key is the FURLs need to look static and not dynamic to the browser. By using the timestamps, the browser will download any changed files when the timestamp it sees in the FURL is changed, but otherwise will use the browser cache. Minifying isn't very important with this approach except for the first time the files are downloaded to the browser, but since you already use a dynamic script to minify some of the files (but not all), you may as well have this as an option when you minify. And, minifying provides a little obfuscation.

I believe that one of the reasons that IPB3 feels slower than IPB2 for some is that the pages have lots of JS and CSS files that are loaded individually and some by using a query string (which some browser implement the standard of never caching files that use query strings - some browsers ignore the standard and cache anyway).