File Manager
The File Manager operates inside the managed site's filesystem scope. It provides common WordPress file operations without exposing unrestricted access to the hosting node filesystem.
Site document root
Each managed site has its own system user and document root. Webcore provisioning, import and deployment workflows expect the site's files to remain under that identity.
Avoid introducing root-owned files into a managed WordPress tree. Incorrect ownership or restrictive directory permissions can prevent the web server, PHP-FPM, WordPress, Preview helpers or deployment workflows from reading and updating the site correctly.
File operations
The File Manager supports normal maintenance operations such as creating, renaming, copying, moving and deleting files and directories. It also supports uploads, archive creation/extraction and permission changes where permitted by the managed site scope.
All paths are resolved relative to the managed site rather than accepting arbitrary server paths. This boundary is an important part of the platform's tenant isolation.
Uploads and archives
Use browser upload for ordinary files and packages. Archive/extract operations are useful for application maintenance and migrations, but inspect the destination before extracting a package over an existing application tree.
For large managed backup movement between Webcore nodes, use the backup transfer workflow instead of moving backup archives through File Manager.
Editing high-impact files
Treat wp-config.php, .htaccess, must-use plugins and application bootstrap files as high-impact. A syntax, ownership or permission error can make the site unavailable immediately.
Before significant manual changes, create an appropriate backup or use Staging so the change has a defined recovery path.
Permissions and ownership
Changing a mode is different from changing ownership. File Manager permission controls should not be used to compensate for files that were introduced under the wrong Unix account.
If a site has widespread ownership or mode problems, use the platform's managed diagnostic/repair workflow rather than recursively applying broad permissions manually.
Databases
The WordPress database is provisioned separately from the document root and uses site-specific credentials. Staging clones receive their own database and credentials even when their content originated from production.
Do not copy production database credentials into a staging wp-config.php. Managed create, clone, import and restore workflows write the correct database configuration for the destination environment.