Would you consider a feature to have the dashboard site treated as a child site automatically? It seems this might be a nice idea for new users who don’t necessarily think about the need to keep their main dashboard up to date (and secured with security plugins). My thought here is that your child sites are only as secure as your weakest link, and if the dashboard is neglected this can be a serious issue.
For example, I have extensive security plugins installed on my child sites, but I just set up a fresh MainWP dashboard and hooked it up to these child sites, but I haven’t yet installed all the security plugins on my dashboard site. Therefore, my child sites are now unprotected if a hacker knows my dashboard site URL and is able to get in due to the lack of security plugins in the current state.
Not sure how much time this would take to automate compared to just adding a message letting users know they can add the Dashboard as a Child themselves.
thanks for the reply… yes it would certainly be some coding effort… but I think it’s important for users to realize that the security of the dashboard site is even more important than the security of their child sites, therefore they should be strongly encouraged to set it up as a child so that it can be monitored and kept up to date along with the others… I’m wondering if it would be cleaner and easier to set up, if the dashboard code was just a standalone PHP web application (ie. not a stripped down wordpress install with one main plugin)… this way, the dashboard itself would not be vulnerable to all the various WP exploits that are out there.
… but I realize that’s even more work Kudos on this toolset though, I do love it and appreciate that it’s open source and self hosted!
Someone who is managing websites with MainWP, but forgets to manage their own dashboard site, should not be doing this at all.
The whole idea of MainWP being a WordPress plugin is that everything is open source and can be modified by whoever would like that. That open system is the power of MainWP compared to SaaS alternatives.
I think this kind of relates to my other suggestion, regarding the theme, etc of the dashboard site.
My point is, it takes a bit of setup and configuration to basically remove all the public wordpress stuff from the dashboard site, possibly install a blank theme, remove the “powered by wordpress” branding, hide the login page, etc etc… And I think it would benefit the overall product to either do some of that for the admin who’s setting this up, or very strongly suggest all the important steps. You certainly don’t want to draw any attention to a dashboard install.
Every admin has their own preferences, so it takes much more work to build something, that will suit all, than doing these modifications as you like only once.
Just use the Clean an Lock Extension and of course good security. Why would you need to remove “powered by WordPress”? Are you ashamed of using it? Hiding a login page is not a security measure. It might lower the the login attempts, but you still need brute force protection.
I understand this is a bit of work, and I’m only putting it out there for discussion
Powered by wordpress, on one’s actual public website is great, but that tagline, and an open login page, invites hackers. So, on a dashboard install, I’d rather do everything I could to NOT advertise that this is a wordpress site (much less one that gives you the keys to many others). I think it would be a very good security measure to hide the login page and have NO attempts, than have to rely on only brute force protection.
Personally, since I began hiding my login pages many years ago on all customer websites, I have not had any security issues, and I can see from logging, that no one except my customers is even hitting the login page.
You should read about “security through obscurity”, because hackers don’t check your site first if it’s running WP, they use bots and try to hack every site.
Good explanation can be found in:
I understand they aren’t visiting it as a live human. I see their bots in my error logs, trying to find pages like mysite.com/wp-login.php and mysite.com/wp-admin… when they don’t find these, or any other insecure plugins and miscellaneous back doors, they move on. But if they find an open wp-login.php, they will turn on their brute force attack, and I’d just rather not have them get that far!
Kudos on this toolset though, I do love it and appreciate that it’s open source and self hosted!