Skip to main content
A database query limit can prevent MainWP Dashboard from displaying Child Sites on Manage Sites and in site selectors. Other operations that retrieve site data may also be affected.
Contact your hosting provider first. The recommended solution is a hosting configuration that allows MainWP Dashboard’s database queries to run. Use the optional workaround below only if your provider cannot supply a suitable solution and confirms that a session override is permitted.

​
What You’ll Learn

  • Identify a MAX_JOIN_SIZE database error
  • Request a persistent solution from your hosting provider
  • Refresh the site list after the restriction is resolved
  • Install and remove an optional unsupported workaround

​
Prerequisites

  • Access to the database error reported by your Dashboard site or hosting provider
  • A way to contact support for the hosting account running MainWP Dashboard
  • For the workaround: a current Dashboard backup and file manager or SFTP access to that WordPress installation

​
Identify the Error

This guide applies when your Dashboard’s error log contains a message such as:
This is database Error 1104. An empty site list alone does not establish this cause. If you do not have the error details, ask your hosting provider to check the database errors while you repeat the affected operation. See Enable Error Logging if you need to collect a WordPress error log. An error recorded during another operation, such as an uptime check, shows that the restriction affects that query. To confirm that it also explains an empty Manage Sites table, check for the same error when loading that table.

​
Why the Site Count Can Still Be Correct

MAX_JOIN_SIZE limits how many rows a database query is estimated to examine. It is a query-processing limit, rather than a limit on the number of Child Sites you can manage. See the MariaDB query limits documentation. MainWP Dashboard uses queries that combine multiple tables to retrieve site details. A simpler site-count query may still succeed while a site-list query fails. Your system report can therefore show the expected site count while Manage Sites remains empty. This discrepancy does not, by itself, mean that your site records have been deleted or that your database needs repair.

​
Contact Your Hosting Provider

Contact the provider hosting your MainWP Dashboard, and share the exact database error. Ask them to review whether they can:
  • Enable SQL_BIG_SELECTS persistently for the WordPress database connections used by MainWP Dashboard.
  • Adjust MAX_JOIN_SIZE appropriately for your hosting environment.
Your provider should choose the appropriate configuration and assess database performance. You can send this message:
My MainWP Dashboard is receiving database Error 1104: “The SELECT would examine more than MAX_JOIN_SIZE rows.” Site lists are affected. Could you review the restriction and provide a persistent solution for the Dashboard’s WordPress database connections, such as enabling SQL_BIG_SELECTS or adjusting MAX_JOIN_SIZE? If neither is available, please confirm whether an application-level SQL_BIG_SELECTS session override is permitted.
Running SET SESSION SQL_BIG_SELECTS = 1 once in phpMyAdmin changes only that connection’s session. It does not configure the separate database connections used by WordPress. See the MySQL system-variable documentation.

​
Check the Result

Repeat these checks after your provider changes the configuration or after installing the optional workaround.
1

Reload Manage Sites

Go to MainWP > Sites > Manage Sites (/wp-admin/admin.php?page=managesites) and check whether your Child Sites appear.Use Table view for the filter-reset check below.
2

Reset filters and refresh the site list

If the list remains empty, select Connected from the status filter, click Filter, and then click Reset to return to all statuses. Resetting the filters also clears the cached Manage Sites results in the table view.If Reset is already available, you can click it directly.
3

Repeat the affected operations

Check any site selectors that were empty and try synchronizing a site. Ask your provider to check for new occurrences of Error 1104 while you repeat the previously failing operation, or review your error log if you have access.
If the database error remains, share the new error with your hosting provider. If Error 1104 is resolved but sites are still missing, contact MainWP Support with your MainWP Dashboard version, the remaining symptoms, and your provider’s response.

​
Optional Unsupported Workaround

This workaround is not a built-in MainWP feature or part of MainWP’s supported configuration. Consider it only after contacting hosting support, when your provider cannot supply a suitable hosting-side solution and confirms that the session override is permitted.It bypasses the query-size restriction for queries using the same WordPress database connection, including queries from other plugins. It does not optimize queries or repair missing indexes. Review performance concerns with your provider; a successful result does not establish long-term compatibility or performance.
The workaround uses a small WordPress must-use plugin to run SET SESSION SQL_BIG_SELECTS = 1. This makes the database ignore MAX_JOIN_SIZE for the current connection without changing the server’s global configuration. See the MySQL SQL_BIG_SELECTS reference.

​
Install the Workaround

Apply these steps to the WordPress installation hosting MainWP Dashboard. Do not install the file on your Child Sites.
1

Back up the Dashboard site and confirm file access

Create a current backup of your Dashboard database and files, and confirm that it completed successfully. Keep file manager or SFTP access available so you can remove the workaround if necessary.
2

Open the must-use plugins directory

Using your hosting file manager or SFTP, open the Dashboard installation’s wp-content directory. Create a directory named mu-plugins if it does not already exist. Preserve any existing files in that directory.
3

Create the workaround file

Create a plain-text file named mainwp-sql-big-selects-workaround.php with the complete code below, including the opening <?php tag:
Save the file directly inside mu-plugins, with this path relative to the WordPress installation:
Ensure the filename ends in .php, rather than .php.txt. If a file with the same name already exists, retain a copy before replacing it.
4

Verify the result

WordPress automatically loads PHP files placed directly in mu-plugins before normal plugins. No activation is required. See the WordPress must-use plugin documentation.Follow Check the Result to verify the site list and the previously failing operation. If the workaround causes new problems, remove the file using the instructions below.

​
Remove the Workaround

Once your hosting provider supplies a permanent solution, remove the workaround and repeat Check the Result. Using your hosting file manager or SFTP, delete only this file:
Preserve all other must-use plugins. Must-use plugins cannot be deactivated from the standard WordPress Plugins screen; remove this file to stop applying the override on subsequent WordPress loads. If the underlying database restriction remains, Error 1104 may return after removal.