The fundamental issue is that MUI is probably not meant to be used in an environment where there are already styles like this. It’s supposed to be the base layer. The WordPress admin has its own styles and it’s highly unusual to try and use a completely different UI framework inside of it.
These types of conflicts are inevitable when you try to use 3rd-party UI frameworks inside the WordPress admin, which was not designed to support them. The same issues occur when people try to use Bootstrap in the WordPress admin.
Is there a way to make the MUI inline styles take precedense over
load-styles.php?
The styles in your screenshot are inline styles, so they are already loading after load-styles.php. The reason they’re not taking precedence is because the load-styles.php rules have a higher specificity.
To make your styles take precedence you’d need to increase the specificity of the selectors used by MUI. Whether MUI has tools for that is something you would need to ask them or their community.
If not, is there a way to disable parts of the load-styles.php ?
load-styles.php is just outputting all the styles that have been enqueued with wp_enqeueue_style() in the admin. You can dequeue them with wp_dequeue_style() but you’ll need to know the handle used to register the style. Tools like Query Monitor can give you a list of what stylesheets are enqueued, and their handles.
The problem is that the styles you want to remove are probably in a stylesheet with many styles that you don’t want to remove, and removing them will probably break parts of the WordPress admin that you still need.
If not, how do I style the admin area using React MUI?
This probably isn’t a supported use-case for MUI. If it is they should be able to help. If it isn’t then your options are limited:
- Increase the specificity of MUI selectors, if that’s even possible.
- Add your own stylesheet that corrects any broken visuals caused by the conflict. If MUI uses dynamically generated class names, this will be difficult.