In this short article, I will tell you why we will need to increase the amount of script memory for the WP Fast Total Search plugin to work properly compared to WordPress default requirements, how to do it, and whether it is really that painful for your site and whether you should worry about it.

1. What is script memory and memory_limit?
2. What special requirements does the WP Fast Total Search plugin have and why?
3. How can increasing the amount of script memory affect my budget?
4. Step-by-step instructions to increase the amount of script memory in your WordPress.

What is script memory and memory_limit?

Script memory is the amount of memory that is allocated by PHP to run scripts within a single startup session. In our case, these are the PHP scripts that run on your WordPress site. The memory_limit parameter determines how much memory can be used to run each such script.

By default in WordPress, this parameter is set to 64M – 64 megabytes. This is enough to run ‘pure’ WordPress without plugins. But when any plugins are installed, this requirement naturally increases – for example, the popular Woocommerce plugin requires a minimum of 128 megabytes of script memory.

What special requirements does the WP Fast Total Search plugin have and why?

As you already know, the WP Fast Total Search plugin allows you to organize a fast search within your WordPress site without using third-party services. All the work is organized by your server, on which the site itself runs, and the data is also placed in your database.

To implement this mechanism, the plugin uses a two-step scheme of work. In the first step, it traverses all records on the site following the specified Indexing Rules, extracts the data necessary for the search from all primary and secondary fields of the post (again, following the specified indexing rules), and places them in a structured form in the database.

This task is performed by the PHP interpreter of your WordPress site in the background and may require a rather large amount of script memory, as the amount of text data inside the post may be in the tens of megabytes. The entire operation of converting data from one post should be completed in one script run. Breaking the task into parts to save server resources during indexing would result in too much slowdown. Therefore, the maximum memory size for running the script should not be less than 256 megabytes and ideally should be 512 megabytes or more. Actually, this amount is not so critical for you and your server, and below we will explain why.

The second step is searching for information. At this step, the algorithm’s speed is especially critical, because your users would like to see the search results instantly.

We have organized the work of the script so that it can scan the search index for units or tens of milliseconds, at the same time it can return from the database thousands and tens of thousands of ID records with service information, and all this information should ideally be placed in the script memory.

Yes, there is a special mechanism implemented in the WPFTS plugin code, which will process a large amount of information found in the database in pieces, so as not to exceed the allocated amount of script memory, but in this case, the result will be significantly slower and users will notice it.

That’s why the increase of script memory is critical for the second step of the algorithm. In our tests, information fragmentation into pieces did not occur already with 300 thousand posts and 256 megabytes of allocated script memory. That’s why we can be sure that the search will be as fast as possible if memory_limit is set to 512M.

How can increasing the amount of script memory affect my budget?

Increasing script memory may seem expensive, but it isn’t.

Firstly, you don’t pay for every megabyte of memory, you pay for the resources available to you on the server. Increasing memory_limit by 400-500 megabytes is unlikely to have a big impact on your costs, and probably won’t have any impact at all. The fact is that web hosting service providers assume that your scripts may consume a large amount of memory during peak load hours and therefore usually the physical memory on the server is dozen times larger than the default memory_limit value. An overwhelming number of hosting providers do not prohibit changing memory_limit and do not charge for this value in any way.

Secondly, the performance of your site is far more important than a slight increase in hosting costs. Users who can easily and quickly find information on your site are more likely to return to you. This is what will ultimately lead to increased sales or other positive results, not a few dollars a month increase in hosting costs.

Although, let’s repeat, limiting memory_limit by any hosting tariff conditions is a very rare phenomenon (we, for example, have never encountered such a thing).

Step-by-step instructions to increase the amount of script memory in your WordPress server

To change the memory_limit parameter, you will need access to the php.ini configuration file on your server. The way to edit it depends on your hosting provider:

1. Using cPanel: If your hosting provider gives you access to cPanel, you will be able to find php.ini under ‘PHP Settings’. In this section, you can change the memory_limit or set a custom configuration for your site.
2. Using an FTP client: If you do not have access to cPanel, you can edit php.ini using an FTP client such as FileZilla. Alternatively, if you own a VPS or Dedicated server, you can log into the server using root access and edit the php.ini file using a text editor inside the console. This file is usually located in the /etc/php/ folder. But be careful! Careless modification of the files in this folder can cause your site and server to fail.

In some cases, you can set memory_limit directly in your site’s wp-config.php file. To do this, add the following line to that file:

define(‘WP_MEMORY_LIMIT’, ‘512M’);

Replace 512M with the desired memory size in megabytes.

Important! Before modifying the php.ini configuration file, it is recommended to make a backup copy of it.

Conclusion

Increasing the script memory to run your WordPress site is an important but often forgotten condition for stable site performance, especially one loaded with plugins like WP Fast Total Search. This will not only give you faster site search speeds, but also stable site performance, leading to a better UX and higher conversions.

Don’t be afraid to experiment! Try changing memory_limit and test the result.

The post How to set up memory_limit value for WordPress appeared first on WP Fast Total Search Plugin.

1. Update Plugin

One of the most important things which you should do is, update all your plugins. Plugins regularly push updates with the latest security checks and new features that’s why it is very important to update plugins regularly.

To update the plugin when you go to the WordPress dashboard and on plugins, you will see a circular highlight with a number of updates.

To update the plugin go to plugin and you will see a highlight below the plugin, click on update and your plugin should update.

2. Theme Update

The next important thing is to update your theme, the theme also gets regularly updated with the latest security patches and bug fixes.

To update the theme go to Apperance>Themes and you will see the update highlight above your theme click on update and the plugin will get updated.

3. Update WordPress

Along with themes and plugins, the WordPress itself gets regularly updated not very frequently or monthly but you should check regularly for updates. Normally it will get updated automatically but you should still look for updates regularly.

To update or check the update go to Dashboard>Updates if any update is available you will see the update button click on update and your WordPress will get updated.

4. Test all forms

You should regularly check your contact forms or any other form if you have any and validate it is working perfectly. If you found any issue solve it ASAP.

5. Update promos and offers

You should also update your promo codes and offers. The main reason to do this is to prevent abuse of promos and releasing new promos and offers regularly to increase the interaction of your visitors.

6. Check malware

If your hosting provider offers malware scan you should monthly check and scan for any malware which can bring down your site. You should do a full analysis and based on results perform actions if required.

7. Take a backup

Regular backups are crucial for your, there are many reasons why you should backup your site such as a hacking attack, server crash, malware, and so on. Many hosting provide free regular backups automatically but you should always also backup your site regularly on any different location.

8. Test links

After making changes to your site there are high chances of broken links, missing images, wrong redirects, and so on. Manually doing all checks is very tedious for doing it quickly and easily you can use a third-party plugin such as Broken link checker.

9. Site speed

You should also regularly check for your site speed for checking the overall loading time and speed of your websites. Bad plugin updates can slow down your site. You can check your website speed with tools like gtmetrix.

10. Blog posts

For better SEO and user interaction you should publish a regular blog post on your website. It is recommended to post weekly or if you are too busy you should publish posts at least once a month.

Conclusion

These are the monthly maintenance you should do regularly but updating plugins or making any changes can break your website. These things should always be done by your technical team or a skilled person, else these changes rather than increasing performance can decrease your site performance.

If you think this is too much for you and can’t do it yourself, WEBPROTIME can help you with your monthly WordPress Maintenance Tasks for a small fee.

If you think we have missed anything or if you face any issue while doing so let us know in the comment below.

The post 10 Monthly maintenance task in WordPress appeared first on WP Fast Total Search Plugin.

After the publication of the previous version 2.45.170, which has many significant changes, mainly related to the indexing engine, we received a lot of comments. In particular, many users complained about the unstable work of the plugin, the slowdown of the site, the broken search in WP Admin, and the greatly increased amount of HDD space occupied by the index tables.

For example, the Index Optimizer, which was implemented in one of the previous versions, in fact, gives an increase in search speed of 30-50%, although it increases the volume of the index database by almost 2 times, and the indexing time increases by 50%. If you have a weak server or shared hosting with restrictions on CPU load or database size, then you better not enable index optimization (it is now disabled by default).

We also disabled the use of WPFTS search within WP Admin (although you can enable it back), as the function turned out to be rather crude, and not all admin pages that have search work correctly with WPFTS. This functionality will be actively updated in the near future.

Many hosting companies use a “fork” – the MariaDB database instead of the classic MySQL, which is quite justified – MariaDB is developed by the community, has many new features and optimizations. But, unfortunately, MariaDB 10.3 and higher have an annoying query optimization bug that leads to incorrect search results in WPFTS, and most often to no results at all. Therefore, we developed an optional fix for this bug, disabling the corresponding MariaDB optimizer. If your hosting has a classic MySQL server installed, you don’t have to think about it at all.

Another issue we have fixed applies to both MySQL and MariaDB. It turned out that in rare cases, queries with TRUNCATE can “hang” indefinitely. We ran into this quite by accident while testing the new version and immediately replaced all TRUNCATEs with a construct of three CREATE-RENAME-DROP queries. This works a little slower than TRUNCATE, but at least it does not block the entire server.

We also worked more deeply on the IDLE mode for the indexing engine. Many users have noticed that the plugin loads the server even when there is no indexing. This was due to the fact that some lengthy queries to find changes in the database were executed too often. We have optimized these queries and made them less frequently called.

Hope these changes made the plugin even better than ever before! You can install this new version right now, it’s available.

Are you are looking for new hosting for the WordPress website? We would strongly recommend reading this article first.

The post WP Fulltext Search Pro 2.46.178 – Optimization and Bug Eliminating appeared first on WP Fast Total Search Plugin.

Some time ago, we have accumulated quite a lot of feedback from users who very much asked to add an improvement in search – to significantly increase the search speed on a large number of documents and add the ability to search for a phrase. This became somewhat of a challenge for us since it seemed almost impossible to implement a full-fledged indexed search using the small power of PHP and MySQL.

New Search Algorithm

But, as a result, we managed to get closer to the goal. To achieve this, the search algorithm had to be completely redone. Yes, it’s still TF-IDF, but with significant additions to the logic and relevance calculation. In particular, we have added a “phrase bonus”, which allows those documents in which similar phrases were encountered to be displayed in higher places. Note that phrases, in this case, can be not only EXACT matches but also partial matches of words, as well as nearby words (not only close ones).

For example, for the search phrase “infinite space”, the relevance will be increased in those documents where the phrases “infinite distant space” and even “space seems to be infinite” are found. The word order in the phrase is currently ignored. An option that includes strict word order in the phrase will appear in the next updates.

Deep Search is Faster

Also, the speed for “deep search” has been significantly increased. So, for example, by default, the query “cat” will only find words like “catty”, “catalog”, that is, those whose beginning exactly coincides with the search word. When you enable “deep search”, the words “subcategory”, “procatering”, “mystification” and the like will also be found, that is, words in which the “cat” occurs in the middle or at the end.

Previously, a “deep” search literally put the algorithm into a stupor and the search could take 10, 20, or even more seconds. Now, with our new algorithm, deep search has become much faster, and even on a large number of documents can take only 2-3 times longer than a regular “non-deep” search.

No Character Limit Anymore

Thanks to the new algorithm, it becomes possible to get rid of the 3 character limit on the length of the request. Previously, this limitation was necessary since the search for one or two characters set in motion almost the entire search index, as a result of which the query could run for a very long time and even lead to a script crash. Now it has become possible to remove the limitation on the number of characters since requests of one or two characters only receive a limited number of matches and do not significantly slow down or crash the script.

Faster with the Word Index

We have introduced one more small index – word index. It allows you to increase the search speed significantly for a large number of documents, since it partially relieves the load on MySQL, eliminating the need to perform concatenation operations on huge tables.

MyISAM Support was Dropped

We have dropped support for the MyISAM table type and removed the corresponding option and all associated algorithms from the code. Tables of this type all too often lead to “locking” and despite the fact that they sometimes give a 10-20% bonus to search speed, people decided to abandon MyISAM in favor of the more modern type as InnoDB.

Faster Re-Index

Indexing and re-indexing of documents have also been significantly accelerated, although the new “word index” slightly increases the re-indexing time. We are still working on improving this part of the plugin.

The “Pause” Mode

It’s not a secret that index building is a quite resource-consuming operation. Thus, sometimes it could be not appropriate to index new posts/files immediately. The “Pause” button which is located in the Status Box could help you with it. Just press it when you want to prevent the indexer from its hard job. But you should remember this and re-enable the indexer when you have a chance so the whole search index becomes actual.

Shortcode Content Indexing

Finally, we’ve added expanding the contents of the shortcodes and putting them in the search index. This thing is quite versatile and allows you to place the contents of any shortcodes into the index.
A new checkbox has been added to the plugin settings. If you do not need to index the content of the shortcodes, you can cancel it.

Search Widget Shortcode

You know there was an ability to use a special search widget with the autocomplete functionality. And now you can insert this widget to any place of the page with the help of the special shortcode: [ wpfts_widget ]. If you need this widget to follow some predefined rules (aka “Preset”) you can add a parameter: [ wpfts_widget preset=”my_preset” ].

Thank you for using WPFTS!

The post WP Fulltext Search Pro 2.45.170 – New search algorithm appeared first on WP Fast Total Search Plugin.

Common Changes

Plugin settings are now duplicated in the main WordPress menu. In my opinion, this is much more convenient!

Added start Wizard to not forget anything before building the index.

Smart Excerpts

Added a new beautiful style editor for the widget with search results. Styles are automatically minified, which helps to speed up the loading of pages on the site.

Smart Excerpts generation algorithm was significantly redesigned. In the past, situations often occurred that caused the widget generation to crash (for example, there are no colons in the text that divide it into sentences, or all sentences are too long). This has now been fixed. The widget will be built even if you specify a maximum length of 10 characters, and there will not be a single dot in the text.

Main Settings

The form for selecting the types of files that you would like to see in the search results has been redesigned – now there is no need to remember the file mime-types and enter them manually – now this is a set of checkboxes: just select the ones you need!

File Attachment Indexing

Our daughter project TextMill.io (text processing service) has been updated. Added support for almost two dozen different file formats, which are now available for free in the base license of WPFTS Pro. We made a convenient table in the plugin settings to let you immediately see which files will be indexed for search and which ones will not.

Now, the licensing page displays also detailed license information for TextMill.io.

The PDF native parsing library has also been updated and made even better (but alas, it’s still not as good as a similar function from TextMill.io).

Those who like to create sites with Gutenberg support will find the new option “Strip Tags From Content” useful. The fact is that Gutenberg adds a number of system comment-styled tags to the post content, which are recognized by the search engine as “noise” and can spoil the search results. With the option “Strip Tags From Content” enabled, this is no longer a problem.

Custom WP_Query Parameters

Some search settings can now be changed dynamically through the WP_Query parameters. If you are developing a complex search, then this will be useful to you. For example, you can specify cluster weights (cluster_weights) or hide attachments from search results (display_attachments = 0). You can also disable WPFTS completely using the wpfts_disable = 1 parameter and change the search logic AND or OR (word_logic).

Significantly accelerated indexing algorithm – approximately 5 times! We also worked on a formula for calculating relevance – the logarithmic scale gives more beautiful and understandable “score” values and also gives us a room to apply some coefficients.

And the final cherry on the top – now all the texts inside the plugin are internationalized, that is, they can be translated into your language using plugins such as Loco Translate. If you plan to do this, share your translation version with the community!

Thank you!

If you have comments on the operation of the plugin or would like to offer new functionality – do not hesitate to write to us.

The post WP Fulltext Search 2.29.90 – Big Improvements appeared first on WP Fast Total Search Plugin.

As you know, the WP Fulltext Search plugin indexes post contents without open shortcodes by default, which is done to reduce memory consumption and indexing time. You can switch on shortcode indexing by the simple checkbox in WPFTS Settings / Indexing Engine configuration. However, this does not work for TablePress plugin shortcodes.

The reason for that is the way how TablePress initializes its code. The shortcode processors in this plugin are initialized fully only in front-end mode. However, the wpfts_index_post is executing in back-end (admin) mode. And thus, TablePress’s shortcodes remain unconverted.

How we can fix this? We going to use the small PHP snippet, which forces TablePress to create shortcode processors even in Admin mode to natively convert shortcodes into HTML code and put this HTML to the WPFTS index. Open your functions.php file in the current theme folder and insert it to the beginning of the file.

add_filter('wpfts_index_post', function($index, $p)
{
        global $wpdb;
        
        // Check for post types if we don't need to unpack tables for each post
        if (($p->post_type == 'post') || ($p->post_type == 'page')) {
                global $post;
                
                // Check if we have table shortcode inside the post_content
                if (preg_match('~\[table~', $p->post_content, $zz)) {
                        // Yes, so let's check if TablePress controller didn't initialized yet
                        if (class_exists('TablePress', false)) {
                                // Let's initialize it
                                $tb_controller = TablePress::load_controller( 'frontend' );
                                $tb_controller->init_shortcodes();
                                
                                // Now we need to unpack all shortcodes in this post content
                                $post = get_post($p->ID);
                                setup_postdata($post);
                
                                ob_start();
                                the_content();
                
                                $r = ob_get_clean();
                                $r = strip_tags(str_replace('<', ' <', $r));
                
                                wp_reset_postdata();
                                
                                // Done. Let's update post_content cluster data (we can use different cluster as well)
                                $index['post_content'] = $r;
                        }
                }
                
        }
        return $index;
}, 3, 2);

After this change, do not forget to save functions.php, upload it to your hosting and press the Rebuild Index button to refresh index data.

As you can see it’s nothing too hard.

Please let us know if this recipe helped you or not.

Wait, in case you’re looking for hosting for your WordPress website, do not hurry. First, I strongly recommended reading this.

The post How to search in TablePress tables with WordPress Fulltext Search? appeared first on WP Fast Total Search Plugin.

This problem seems to have no quick fix. Users differently out of the situation. Some decide to prohibit the search for words that may be Gutenberg tags. Others guess to create a meta-field in a post, copy there the cleaned-up content of the post (post_content) and make a search by this meta field instead.

The WFTS plugin allows you to solve this problem quite elegantly, even without a single line of code.

It’s all about the magic hook wpfts_index_post, which allows you to process the text before placing it in the search index. Now, all we have to do to get rid of the tags is to paste this code somewhere in the file function.php the following code:

add_filter('wpfts_index_post', function($index, $post)
{
    $index['post_content'] = strip_tags($index['post_content']);
    return $index;
}, 3, 2);

Starting from version 2.27 (and free version 1.16), this code is no longer required to be added, since it is already included in the body of the plug-in and is activated by the “Strip Tags From Content” option, which, by the way, is enabled by default.

The post Gutenberg posts are being searched by HTML tags or comments appeared first on WP Fast Total Search Plugin.

Before the WPFTS v2.27.xx, the issue looks like this: when you trying to search anything using the WP standard search, the site is freezing and you can see either white page or 503 error page.

The problem is because Betheme has small integrated search improvement code, which is clearing the “s” parameter in main WP_Query request after the execution, and thus WPFTS Pro get the search query an equal to an empty string and works wrongly when creating Smart Excerpt result items.

We fixed this freeze in WPFTS v.2.27.xx, but anyway it’s still impossible to create and show correct Smart Excerpts items with non-patched Betheme theme. Instead of search results, you will see empty excerpts (no text).

To fix this issue please do the next thing.

1. Open your Betheme folder (be sure which version of the theme you’re using: either main theme or child theme) and find the functions.php file.
2. Add this piece of the code to the beginning of the functions.php and save changes.

function mfn_search($q){}

How does it work?

By creating this empty function we are actually preventing of creating the native Betheme’s function which modifies “s” parameter of WP_Query. Thus “s” parameter become not changed and WPFTS Pro works as expected.

The post Solved compatibility issues of BeTheme and WPFTS Pro appeared first on WP Fast Total Search Plugin.

By default, WordPress simply displays the title of the entry and the 55 first words of the text. Very often this piece does not contain the words that the user expected to see, so he has to open the page of each entry and look for the context in which the sought expressions were found.

We used several weeks to implement and test the functionality of Smart Excerpts, which we needed for a long time, and we were asked by many owners of the plug-in – to output search results exactly as Google does. I’m not sure that it turned out exactly the same, but the result is obvious: it became much more convenient to view the search results. Now the short contents of each found post consist of sentences that contain the words the user searches for. These words are highlighted, and the summary of the relevance of the post in the list is displayed under the short contents.

In addition, excellent news for those who use WPFTS Pro to search for files by their text content. The fact is that WP by default does not display any content for “attachment” type posts and in search results, such records look depressing.

With the new Smart Excerpts feature, your users will see the short contents of the file (its length you set yourself in the settings) with highlighted words, just like if they were ordinary publications. For files, their physical size and a direct download link are also displayed. You can add a file type to the header (like Google does) and add a direct download link to the header.

You can try the new feature right now – the version of the plugin WPFTS Pro 2.20.72, which contains this functionality, is already available for updating. The free version of the plugin is also updated. We also have a detailed documentation for the new function.

To our great regret, not all themes use the function get_excerpt() to display the short contents of the post in the search results, so for these themes, Smart Excerpts will not work correctly at the moment. But we are doing our best to find the right workaround for solving this problem.

If you have such a problem or some other problem related to WPFTS, please send us a screenshot of the problem with the name of the used theme and a link to the site, this will help us make the plugin even better and more useful!

And if you’re looking for the hosting for the WordPress website, please read this article before making a choice.

The post Google-like Search Results – How to make in WordPress? appeared first on WP Fast Total Search Plugin.