XOOPS is a modular CMS with group permissions and content modules. This guide helps you check hosting compatibility, choose an appropriate installation method and verify the first usable site. The application, its extensions and any commercial license remain separate from the hosting account.
IN THIS ARTICLE
01 Check XOOPS and hosting requirements
Review the maintained XOOPS release, database/PHP requirements and each required module. Plan groups and permissions before moving a live community.
Use the project's current supported release information and the requirements shown for the package you select. If Softaculous offers an older or unsuitable build, follow the current vendor installation process or ask us to confirm a suitable environment. Do not enable an unsupported PHP runtime simply to reproduce an old tutorial.
02 Install XOOPS in the correct location
- Back up any existing site at the destination. Choose an empty directory or a separate staging hostname for a new installation; never approve overwriting a working site without a migration plan.
- Open Softaculous where your hosting service includes it. In cPanel, search for Softaculous Apps Installer. In SiteWorx, use Hosting Features > Softaculous where that integration is enabled.
- Find XOOPS and review the package and requirements before selecting Install. Select the correct HTTPS domain. Leave In Directory empty only when the empty domain root is the intended destination.
- Complete the application-specific fields and a strong administrator credential stored in a password manager. Supply a reachable administrative email where requested. Review database, backup and update choices instead of accepting unsuitable defaults.
- Start installation once and wait for the completion result. Record the public and administration URLs. Where this application needs the publisher's own deployment process, complete that process instead of forcing an outdated installer package.
03 Configure XOOPS for first use
Configure the site URL and user groups, then add only the modules required for the initial site. Review module-specific read, submit and administration rights. Set a permitted email method for notifications.
04 Example: publish news without giving every member administrator access
For a community news module, write down three intended roles before publishing: visitors can read public news, members can submit a draft if that feature is enabled, and editors can review and publish it. Keep module installation and system settings with administrators.
| Test identity | Check |
|---|---|
| Signed-out visitor | Can read the published story but cannot open a private draft or editor URL. |
| Ordinary member | Can perform only the submission and account actions you intended. |
| Editor | Can approve the draft without changing unrelated modules or site configuration. |
Use each identity in a separate browser profile. If a role has extra access, adjust that module's permissions and repeat the direct-URL test before inviting real members.
Confirm the expected result
Test a visitor, ordinary member and editor. Verify module navigation, an uploaded file and a notification without using administrator access for every test.
05 Maintain and troubleshoot XOOPS
A module can have its own data tables and upload directory. Include those components in backups and follow the module's supported upgrade instructions rather than assuming a core update updates everything.
Keep files and data together in your recovery plan, test application updates in a copy when practical, and review logs after deployment. If installation fails, record the exact error, selected application/PHP versions and destination path before retrying.
A common question
Does a successful installation mean the whole application is ready for customers?
No. Verify the public content, permissions, forms or notifications and the features you actually use. An installer success message confirms provisioning, not your complete business workflow.