Hi @marcellosalass

Actually WPFTS could be not that great for you in case you have millions of records (e.g. posts).
The whole Wordpress could be not good for you either, because to handle such amount of data you will need to use specific optimization and caching algorithms and even clustering.

I would like to propose you to use full-text solutions based on Apache Solr or Elastic Search - those tools are implemented in Java and work way faster than PHP+MySQL solution provided by WPFTS and they are especially good for big data.

Alternatively you can wait until we release a new WPFTS version (in 1-2 months) that can use self-hosted Elastic Search engine to keep full-text index and uses WPFTS data collecting algorithms.

Thank you for the question.

Hi @jgregory_ca

Okay, the fix for Avada addon should be ready in a couple of days. Just FYI.

Thanks!

Hi @magicalbrad

Many thanks for your report and for sure for your work to fix this issue. We don't face the same on our dev machine that probably caused by version difference or so.

Anyway, I will analyze this problem with deep care and for sure release a new addon version soon.

Thanks!!!

@jgregory_ca
Okay, actually the addon is for different thing. I was just interested if it made this problem or not.

Now I know the reason is not in addon.

Let me make some tests on my dev machine to repeat the bug and find the solution.

Hi, @jgregory_ca

Do you have any WPFTS Addons installed? For example WPFTS Addon for Avada Theme.

Thanks!

@ibloom
Thank you, this is actually the thing which I would like to recommend you to do.

Hi @Felipe-Farinho

Você pode me dizer qual tema seu site está usando atualmente? Pode haver uma incompatibilidade de tema/WPFTS (e isso é fácil de corrigir).

Além disso, para indexar arquivos do WPDM você precisa instalar um complemento simples
https://wordpress.org/plugins/wpfts-add-on-for-wp-download-manager/ (não se preocupe se não for atualizado há algum tempo - iremos atualizá-lo em breve).

Isso permitirá que o WPFTS veja os arquivos adicionados ao WPDM.

Peço também que você compartilhe um link para o seu site - isso agilizará a busca por uma solução.

Obrigado!

Hi @Simply_Friend

Thank you for the question. Actually it's not planned to be added to the plugin core, because this feature (search by date FROM - TO) is already implemented in WP Native search (in WP_Query()).

So you can search with date using WP_Query parameter date_query.

Here is the topic: https://developer.wordpress.org/reference/classes/wp_query/#date-parameters

Another question is if you want date picker fields to be added next to the text query field in the search widget.

This is fairly easy to do for the average WP developer. There are probably some visual constructors to do this, but I can’t recommend anything here - if you find a solution, please write. It will be useful for other users.

We don't plan to add a search form builder to the core functionality of WPFTS because we don't want to compete with Elementor / Beaver Builder / Visual Builder etc etc, although we will probably do a detailed tutorial on how to use the builders to make a search widget with additional fields.

Hope this helped you.

Thanks!

In fact, the problem can sometimes be caused not by a slow search by WPFTS plugin or even by a slow generation of Smart Excerpts. The search slowdown was caused by a bug (or flaw) in the code of the Divi theme itself.

Let's get closer to the code. So, one of the clients contacted us with a complaint that some search requests took too long to process (about 10-12 seconds), which is extremely non-standard for WPFTS even with 500k records, and the client at that time had less than 1000 records. The problem was detected on WPFTS Pro v2.51.212.

After spending several hours deeply studying the code, we found out that due to a flaw in the code of the Divi Theme, post previews are generated anew each time when displaying search results, while logically they should be generated only once and then used.

There is indeed such a check in the code, but it only works for those images that are smaller in size along one of the axes (height or width). If the image is larger than the target size of the preview, then the code for checking the presence of an already generated preview is simply not called, and the preview is generated again.

This spends 1-2 seconds for each post in the output results, which, with a number of 10 posts, gives a noticeable slowdown of 10-15 seconds.

Below we have attached a new version of the Divi Theme file which is suitable for version 4.25.2. We have already reported the bug to the authors of this topic, so we hope that it will be fixed in future versions.

We hope this article helped you.
DIVI_THEME_FIX.ZIP