When direct I/O is not available, there is a fallback to the WP Filesystem API, such as this (from class/class-mainwp-security.php):

if (@file_exists(ABSPATH . 'readme.html')) {
	if (!@unlink(ABSPATH . 'readme.html')) {
		MainWP_Helper::getWPFilesystem();
		global $wp_filesystem;
		if (!empty($wp_filesystem)) {
			$wp_filesystem->delete(ABSPATH . 'readme.html');
			if (@file_exists(ABSPATH . 'readme.html')) {
				// prevent repeat delete
				self::update_security_option('readme', false);
			}
		}
	}
}

This assumes that ABSPATH is accessible via the Filesystem API abstraction, which is not the case when the underlying FTP / SSH account is chrooted (ie. not exposing the entire filesystem). From https://codex.wordpress.org/Filesystem_API#Tips_and_Tricks:

What you need to take into consideration when working with the Filesystem API is the path to the files won't always be the same. (...) This is because FTP and SSH are usually rooted to a directory somewhere along the absolute path.

This means that $wp_filesystem->delete( ABSPATH . 'readme.html' ); usually won't work. To overcome this, the Filesystem API provides abstractions to the common path constants such as ABSPATH, that takes into account FTP_BASE (which in a chrooted environment should be set to '/').

$wp_filesystem->delete( $wp_filesystem->abspath() . 'readme.html' );

This works as intended.

I haven't investigated any further, but a quick grep for ABSPATH shows a lot of code that involves I/O, indicating that this might be a somewhat widespread problem.

I was noticing issues with BackupBuddy cron that seemed to happen on sites that used this child plugin.

I think this is a result of:

https://github.com/mainwp/mainwp-child/blob/master/class/MainWPChildWooCommerceMultiStores.class.php#L81

which tries to use $schedules but doesn't specify it as an parameter on the function. as this is being called on the cron_schedules filter, it would overwrite/ignore values of other plugins using that filter.

https://developer.wordpress.org/reference/hooks/cron_schedules/

-function getCronSchedules() {
+function getCronSchedules($schedules) {

For clients, I usually make them "Editor" so they can't mess things up. They would really need the "Contact support" option.

So please make it possible to show that for editors as well. At least as an option.

I have enabled debugging to look into a seperate issue and the following error has appeared.

Deprecated: __autoload() is deprecated, use spl_autoload_register() instead in /home/startuppeople/public_html/wp-content/plugins/mainwp-child/mainwp-child.php on line 39

My setup is running php 7.2

In MainWP plugin, "Abandoned plugins" shows none, but Wordfence plugin on a child site reports several plugins removed from wordpress.org.

Output from Wordfence scan:

The Plugin "MyPuzzle - Sudoku" has been removed from wordpress.org.
Type: Plugin Removed

The Plugin "Puzzle Game Widgets" has been removed from wordpress.org.
Type: Plugin Removed

1. Link for the first plugin from the plugins page as "Visit plugin site"
   http://blog.mypuzzle.org/sudoku-for-wordpress/
   (website does not work, probably deleted, i don't know if this plugin was originally downloaded from wordpress.org or not)

2. Link for the second plugin from the wordpress.org site
   https://wordpress.org/plugins/puzzle-game-widgets/
   (plugin closed, not available for downloads due Guideline Violations, this link is removed from the plugins page)

MainWP should display this plugins as removed/abandoned/unsafe if possible.
("Visit plugins site" link from Wordpress Plugins page could be checked to see if it exists or in case of a link to wordpress.org somehow check the state of that plugin)

Dependabot can't resolve your PHP dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

The "https://repo.packagist.org/packages.json" file could not be downloaded: failed to open stream: HTTP request failed!

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

Hello,
i have installed a WordPress installation with the latest version on my server with PHP v7.2 and MySQL v8.0
i have an error in the plugin MainWP Child in the following file
mainwp-child/class/class-mainwp-child-server-information.php
at line 1157

and the error says SHOW VARIABLES LIKE "version"

the original line says return $wpdb->get_var( 'SHOW VARIABLES LIKE "version"', 1 );
I have tried a solution to change the " to '
return $wpdb->get_var( "SHOW VARIABLES LIKE 'version'", 1 );

and it worked.
but I don't know what is the impact of this change.
so anyone can help?

Thanks in advance

Hi,

On File
MainWPCloneInstall.class.php
Line 562

Under HipHop VM 3.7.2
Dont know if it happens with PHP Versions too.

I had an issue with a child site due to the DB table wp_options > mainwp_child_subpages. This table had grown to nearly 50MB. The issue prevented access to the admin area of the site.

The inability to access the admin area began when something interrupted a database query. This interruption caused the table to lock and thus prevented further queries on the wp_options table. SQL errors were logged in the server error_log under wp-admin/error_log. The errors were of the type "Commands out of sync; you can't run this command now". This being a shared server I had no access to the syslog etc...

This particular site is a multisite.

MainWP could interact with (and manage) the website. Wordpress.com could interact with (and manage) the website. The admin area of the root site could not be accessed directly -- WordPress Recovery Mode kicked in. Recovery Mode emails failed to send. Under normal circumstances all emails are logged by the site. The server keeps an email log too. No recovery emails were sent possibly due to the wp_options table being locked.

The network admin area and the admin area of a second site could be accessed.

The database used MyISAM. I suspect conversion to InnoDB would have quickly resolved the fault but the size of mainwp_child_subpages prevented conversion to InnoDB. Also, the web server could not import a 50MB row of data after conversion to InnoDB on my local server (shared servers, hah!).

With the mainwp_child_subpages row deleted, later recreated by MainWP, the site works more efficiently.

I think it might be best if this row were taken out of wp_options and put into its own mainwp table within the database where it will not interfere with overall website performance.

What are the knock-on effects of deleting this row?

Are there plans to move MainWP's data to their own MainWP table?

Hi,
I really like MainWP, it's a big help for managin many WP instances.
The checks for hiding wp_generator, RSD and WLW a bit problematic.

I use a code like the following in many projects:

function sanitize_wordpress() {
    remove_action( 'wp_head', 'wp_generator' );
    remove_action( 'wp_head', 'wlwmanifest_link' );
    remove_action( 'wp_head', 'rsd_link' );
}
add_action( 'get_header', 'sanitize_wordpress' );

But the scan says that they are not hidden.
Can you get the scan more precise?

Thanks!

Is your feature request related to a problem? Please describe.
When deploying a new site using wp-cli, we want to be able to install the mainwp child plugin in a secure manner which means using wp-cli to activate the plugin with an option to provide or obtain the private connection string.

Describe the solution you'd like
One of two options:

1. Create a wp-cli command that installs the mainwp child plugin with the 'secure' option enabled and return the security string. We can then use wp-cli on the mainwp plugin to register the site using that string.
2. Create a wp-cli command that installs the mainwp child plugin with a security string that we provide. We can then use wp-cli on the mainwp plugin to register the site using that string.

Either way, using wp-cli to just install and activate the mainwp child plugin right now would leave the site open to attacks if the second step to register the site with the MAINWP plugin failed for any reason.

I realize that there is a chicken-and-egg problem here that needs to be solved because you can't invoke a custom wp-cli command until the mainwp child plugin is enabled. BUT, maybe an alternative is that an try in wp-config.php forces mainwp child to activate in secure mode instead of being wide open to the first connection that show up.

Describe alternatives you've considered
Forking the mainwp child plugin and adding the wp-cli command ourselves.

Additional context
Using wp-cli to install the mainwp child plugin right now risks leaving a site open to attack.

This is minor, non critical bug, wrong url to Bulk Settings Extension page.

To reproduce, go to Install plugin page and install some plugins to some sites.
On that page titled "Plugin installation", you will see text in a blue box with content:
"Did you know with the Bulk Settings Extension you can control the settings of this plugin directly from your MainWP Dashboard?"
Url for "Bulk Settings Extension" is incorrect (or redirection is incorrect).
https://mainwp.com/extensions/bulk-settings-manager redirects to https://mainwp.com/bulk-settings-manager-2/#main which is non existent page, but it should probably redirect to a page https://mainwp.com/extension/bulk-settings-manager/

If you don't want me to report this minor bugs, let me know.
Thank you.

I updated today via wp plugin update --all. Afterwhich, users began getting the White Screen. Apache logs started showing the following issue.

Can't use function return value in write context in /var/www/html/wp-content/plugins/mainwp-child/class/class-mainwp-child.php

I then removed the mainwp-child folder and tried to install again. I got the same result.

Running RHEL 7.2 w/ PHP 5.4.16

Describe the bug
Today, Security checks appear to be case sensitive; Example:

To Reproduce
Steps to reproduce the behavior:

1. Setup WordPress
2. Disable PHP logging with non-lowercase value:

I have no name!@wordpress-78f5777878-p4rwq:/opt/bitnami/wordpress$ cat /opt/bitnami/php/etc/php.ini | grep display_error
; display_errors
display_errors = Off
; separately from display_errors. We strongly recommend you set this to 'off'
I have no name!@wordpress-78f5777878-p4rwq:/opt/bitnami/wordpress$ cat /opt/bitnami/php/etc/php.ini | grep display_startup_errors
; display_startup_errors
display_startup_errors = Off

4. Notice on the MainWP Dashboard that it doesn't think PHP error reporting is disabled

Expected behavior
I would expect MainWP to perform case insensitive checks for things like these security settings.

Screenshots

Could you add option to child for disable X-Frame-Options ALLOWALL?
https://github.com/mainwp/mainwp-child/blob/master/mainwp-child.php#L10

I need set own X-Frame-Options on server.

In future add CSP1.1 frame-ancestors.

Hi,

CC: @ruben-

You are currently using WPVulnDB APIv2, which is due to be deprecated on October 1st, 2019.

https://github.com/mainwp/mainwp-child/search?q=wpvulndb&unscoped_q=wpvulndb

Please update your code to use WPVulnDB APIv3 before October 1st, which will require your users to register an account on wpvulndb.com and configure an API token that will give them 50 free API requests per day. Anything more than 50 API requests per day will require purchasing paid API usage.

For further details please see:

https://blog.wpscan.org/wpvulndb/2019/07/05/wpvulndb-apiv2-deprecation.html

Thanks,
Ryan

Describe the bug
It appears MainWP hides certain error messages, which can make debugging quite complicated. The result is that you just see the usual Wordpress critical error panel, but without any specific indication. Another important point is that nothing is logged : no 500 error shows in Apache logs.

To Reproduce
It's not always reproducible unfortunately, but the most common unlogged problem is the "out of memory" error. Install a well-known memory greedy Wordpress plugin, with MainWP Child activated, and when it crashes, you will (probably) see the problem. It doesn't tell you which plugin is at fault.

The plugins with which I've had that kind of encounters are WooCommerce with Jetpack & YoastSEO.

Expected behavior
Let errors be logged. And displayed if WP_DEBUG is true.

Server
Debian 9.13 with Apache 2.4 and PHP 7.4 FPM.
memory_limit is 256 MB, which is enough for a large majority of websites.

Thanks

1. Sites do not populate
2. unable to sync all sites
3. unable to view, sort, filter, manage, edit, delete, or create sites
4. most plugins like analytics and page speed load blank widgets and data on their tables.

Uncaught ReferenceError: $manage_sites_table is not defined
    at mainwp_manage_sites_filter (admin.php?page=managesites:993)
    at HTMLButtonElement.onclick (admin.php?page=managesites:856)

System Report:

Server Info Required Detected Status

MainWP Dashboard
MainWP Dashboard Version 4.0 4.0 Pass
MainWP Upload Directory Writable Writable Pass
MainWP Extensions
Activity Log for MainWP 1.0.5 Inactive Warning
Advanced Uptime Monitor Extension 5.0 Active Pass
Boilerplate Extension 4.0 Active Pass
MainWP Article Uploader Extension 4.0 Active Pass
MainWP Branding Extension 4.0 Active Pass
MainWP Broken Links Checker Extension4.0 Active Pass
MainWP Bulk Settings Manager Extension4.0 Active Pass
MainWP Clean and Lock Extension 4.0 Active Pass
MainWP Client Reports Extension 4.0 Active Pass
MainWP Clone Extension 4.0 Active Pass
MainWP Code Snippets Extension 4.0 Active Pass
MainWP Comments Extension 4.0 Active Pass
MainWP Custom Post Type 4.0 Active Pass
MainWP Favorites Extension 4.0 Active Pass
MainWP File Uploader Extension 4.0 Active Pass
MainWP Google Analytics Extension 4.0 Active Pass
MainWP Maintenance Extension 4.0 Active Pass
MainWP Page Speed Extension 4.0 Active Pass
MainWP Post Dripper Extension 4.0 Active Pass
MainWP Post Plus Extension 4.0 Active Pass
MainWP Spinner 4.0 Active Pass
MainWP Staging Extension 4.0 Active Pass
MainWP Team Control 4.0 Active Pass
MainWP UpdraftPlus Extension 4.0 Active Pass
MainWP URL Extractor Extension 4.0 Active Pass
MainWP Vulnerability Checker Extension4.0 Active Pass
MainWP WooCommerce Shortcuts Extension4.0 Active Pass
MainWP WooCommerce Status Extension4.0 Active Pass
MainWP WordPress SEO Extension 4.0 Active Pass
WordPress
WordPress Version >=3.6 5.2.2 Pass
WordPress Memory Limit >=64M 256M Pass
MultiSite Disabled =true true Pass
FileSystem Method = direct direct Pass
PHP
PHP Version >=5.6 7.3.8-1+ubuntu18.04.1+deb.sury.org+1 Pass
PHP Safe Mode Disabled =true true Pass
PHP Max Execution Time >=30 seconds 9999 Pass
PHP Max Input Time >=30 seconds 900 Pass
PHP Memory Limit >=128M 512M Pass
PCRE Backtracking Limit >=10000 1000000 Pass
PHP Upload Max Filesize >=2M 9999M Pass
PHP Post Max Size >=2M 9999M Pass
SSL Extension Enabled =true true Pass
SSL Warnings = empty Pass
cURL Extension Enabled =true true Pass
cURL Timeout >=300 seconds 600 Pass
cURL Version >=7.18.1 7.58.0 Pass
cURL SSL Version >=OpenSSL/0.9.8l OpenSSL/1.1.1c Pass
PHP Allow URL fopen YES
PHP Exif Support YES ( V7.3.)
PHP IPTC Support YES
PHP XML Support YES
PHP Disabled Functions , pcntl_alarm, pcntl_async_signals, pcntl_exec, pcntl_fork, pcntl_get_last_error, pcntl_getpriority, pcntl_setpriority, pcntl_signal, pcntl_signal_dispatch, pcntl_signal_get_handler, pcntl_sigprocmask, pcntl_sigtimedwait, pcntl_sigwaitinfo, pcntl_strerror, pcntl_wait, pcntl_waitpid, pcntl_wexitstatus, pcntl_wifcontinued, pcntl_wifexited, pcntl_wifsignaled, pcntl_wifstopped, pcntl_wstopsig, pcntl_wtermsig,
PHP Loaded Extensions Core, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, bcmath, calendar, cgi-fcgi, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, igbinary, imagick, imap, json, libxml, mbstring, memcached, msgpack, mysqli, mysqlnd, openssl, pcre, pdo_mysql, posix, readline, recode, redis, session, shmop, soap, sockets, sodium, standard, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xml, xmlreader, xmlwriter, xsl, zip, zlib
MySQL
MySQL Version >=5.0 10.3.17-MariaDB-1:10.3.17+maria~bionic-log Pass
MySQL Mode ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
MySQL Client Encoding utf8
Server Info
WordPress Root Directory /var/www/manage.bradleeduffy.com/htdocs/
Server Name manage.bradleeduffy.com
Server Software nginx/1.16.1
Operating System Linux
Architecture 64 bit
Server IP 134.209.163.30
Server Protocol HTTP/2.0
HTTP Host manage.bradleeduffy.com
HTTPS ON - on
Server self connect Not expected HTTP response body:
User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36
Server Port 443
Gateway Interface CGI/1.1
Memory Usage 38.24 MB
Complete URL https://manage.bradleeduffy.com/wp-admin/admin.php?page=managesites
Request Time 1567351060
Accept Content text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3
Accept-Charset Content N/A
Currently Executing Script Pathname/var/www/manage.bradleeduffy.com/htdocs/wp-admin/admin.php
Current Page URI /wp-admin/admin.php?page=ServerInformation
Remote Address 104.11.149.250
Remote Host N/A
Remote Port 49882
MainWP Settings
Number Of Child Sites 16
Use WP-Cron Yes
Optimize for Shared Hosting or Big NetworksYes
Automatic Daily Update Install trusted updates
Abandoned Plugins/Themes Tolerance 365
Maximum number of posts to return
Maximum number of pages to return 500
Maximum Number of Comments 500
Primary Backup System Default MainWP Backups
Maximum simultaneous requests 1
Minimum delay between requests 200
Maximum simultaneous requests per ip1
Minimum delay between requests to the same ip1000
Maximum simultaneous sync requests 1
Minimum simultaneous install/update requests1
Active Plugins
Activity Log for MainWP 1.0.5 Active
Akismet Anti-Spam 4.1.2 Active
Email Templates 1.3 Active
Jetpack by WordPress.com 7.6 Active
MainWP Dashboard 4.0 Active
MainWP Key Maker 1.1 Inactive
MainWP Sites SEO Report 0.1.2 Active
Nginx Helper 2.1.0 Active
UpdraftPlus - Backup/Restore 1.16.16 Active
WordPress Importer 0.6.4 Inactive
WP Mail SMTP 1.6.0 Inactive
Yoast SEO 11.9 Active

Dependabot couldn't find a composer.json for this project.

Dependabot requires a composer.json to evaluate your project's current PHP dependencies. It had expected to find one at the path: /composer.json.

If this isn't a PHP project, or if it is a library, you may wish to disable updates for it from within Dependabot.

View the update logs.

When the child plugin is first activated, we get a lovely warning/attention dialog. Within the text of that warning, "NOW" is supposed to be in bold, but the 'strong' tags seem to be HTML-encoded, so they are displayed instead of making NOW bold.

To Reproduce
Steps to reproduce the behavior:

1. Activate the plugin
2. Read the warning message that comes up, and you'll see the HTML strong tags displayed

Expected behavior
NOW should be bold!

Screenshots

Hi!
I have a multisite child.
I've enabled MainWP Child plugin only on the main site.
I've enable BackWpUp for all sites.
The "Server Information" shows BackWpUp as Active, but even after syncing it still shows up as Inactive in the MainWP Dashboard.
I was expecting it to show up as Active in the MainWP Dashboard, and to be able to manage BackWpUp jobs through the dashboard extension.

Compatibility issues with modern versions of PHP have been reported before on the WP Support forums and marked as resolved.

I just ran a test on a staging server for compatibility with PHP 7.0 and it gave 3 Warnings and no less than 9 Errors.

Hopefully you can tackle these issue sometime soon.

FILE: /server/path/wp-content/plugins/mainwp-child/class/class-mainwp-child-back-wp-up.php
--------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
--------------------------------------------------------------------------------------------------------------
 414 | WARNING | INI directive 'safe_mode' is deprecated since PHP 5.3 and removed since PHP 5.4
--------------------------------------------------------------------------------------------------------------


FILE: /server/path/wp-content/plugins/mainwp-child/class/class-mainwp-child.php
---------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
---------------------------------------------------------------------------------------------------
 1154 | WARNING | INI directive 'safe_mode' is deprecated since PHP 5.3 and removed since PHP 5.4
---------------------------------------------------------------------------------------------------


FILE: /server/path/wp-content/plugins/mainwp-child/class/class-mainwp-child-server-information.php
----------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
----------------------------------------------------------------------------------------------------------------------
 1190 | WARNING | INI directive 'safe_mode' is deprecated since PHP 5.3 and removed since PHP 5.4
----------------------------------------------------------------------------------------------------------------------


FILE: /server/path/wp-content/plugins/mainwp-child/class/class-mainwp-child-timecapsule.php
---------------------------------------------------------------------------------------------------------------
FOUND 2 ERRORS AFFECTING 2 LINES
---------------------------------------------------------------------------------------------------------------
 449 | ERROR | Extension 'mysql_' is deprecated since PHP 5.5 and removed since PHP 7.0; Use mysqli instead
 450 | ERROR | Extension 'mysql_' is deprecated since PHP 5.5 and removed since PHP 7.0; Use mysqli instead
---------------------------------------------------------------------------------------------------------------


FILE: /server/path/wp-content/plugins/mainwp-child/class/class-mainwp-child-db.php
-----------------------------------------------------------------------------------------------------------
FOUND 7 ERRORS AFFECTING 7 LINES
-----------------------------------------------------------------------------------------------------------
 20 | ERROR | Extension 'mysql_' is deprecated since PHP 5.5 and removed since PHP 7.0; Use mysqli instead
 28 | ERROR | Extension 'mysql_' is deprecated since PHP 5.5 and removed since PHP 7.0; Use mysqli instead
 36 | ERROR | Extension 'mysql_' is deprecated since PHP 5.5 and removed since PHP 7.0; Use mysqli instead
 44 | ERROR | Extension 'mysql_' is deprecated since PHP 5.5 and removed since PHP 7.0; Use mysqli instead
 55 | ERROR | Extension 'mysql_' is deprecated since PHP 5.5 and removed since PHP 7.0; Use mysqli instead
 66 | ERROR | Extension 'mysql_' is deprecated since PHP 5.5 and removed since PHP 7.0; Use mysqli instead
 77 | ERROR | Extension 'mysql_' is deprecated since PHP 5.5 and removed since PHP 7.0; Use mysqli instead
-----------------------------------------------------------------------------------------------------------

WordPress version: 3.9

MainWP Child version: 28.1

Functions get_themes() and get_current_theme(), together with Argument in wp_get_recent_posts() -- used in various lines in wp-content/plugins/mainwp-child/class/MainWPChild.class.php -- are deprecated

Hello, Julio from SecuPress.

A customer discovered that mainwp-child plugin was a guilty creator of an index.php file into /uploads/ which only contains a die().
https://github.com/mainwp/mainwp-child/blob/master/class/class-mainwp-security.php#L56
Unfortunately, this returns a http code 200 instead of 4xx (403?).

So i propose you to use a proper php header 403 return like
header($_SERVER['HTTP_PROTOCOL'] . ' 403 Forbidden' );
die( '403 Fordibben' );

Thank you

MainWP does not check if site is running minimum php version required by the plugin.
It allows to update plugin which Wordpress does not allow to be updated.
After updating such plugin site is broken.

Steps to reproduce:

1. Install Wordpress with php 7.0
2. Install plugin СрбТрансЛатин version 2.0.2
3. Check plugins for update from MainWP, you will see that you can update this plugin to version 2.4 but if you do that site will be broken (because new version of the plugin requires PHP 7.2)

MainWP should not update plugins if minimum PHP version is not satisfied.

Is your feature request related to a problem? Please describe.
Right now it is not possible to add a site into mainwp securely using ssh and command line.
We can add the plugin on the child site, but we cannot get the security key.

Describe the solution you'd like
Using a wp cli command, we could "activate the security key option" and get the key too.

For example:
wp mainwpchild securitykey --activate
That will return the key if already activated or activate it and then return the security key.

With that, we could ssh into our mainwp installation and use wp cli to add the new site including the security key.

Other wp cli commands could be added, for example to reset the database options of mainwp chlid plugin (which could fix a lot problems with connections) but that could be for another moment. :)

What do you think?

Can i white labeling this plugin?