fix: start the stack from a fresh clone

[YvesCesar]

On a fresh clone of main, make up fails for the site and Nextcloud stacks, and the WordPress → Nextcloud integration cannot reach Nextcloud. This PR fixes the startup on top of the current nextcloud-development (NCDD) and reuses its shared proxy instead of adding networking workarounds.

Changes

• NCDD: the submodule is pinned to 812fe2d. Nextcloud starts with the standard NCDD lifecycle (pull --ignore-buildable, up -d) instead of an explicit service list.
• Site: SITE_COMPOSE uses env UID=... docker compose .... UID is readonly in bash, so UID=... docker compose failed with UID: readonly variable.
• Nextcloud URL: WordPress uses the canonical URL configured by NCDD (https://nextcloud-development.localhost by default), read from the Nextcloud container. NCDD already manages trusted_domains and the overwrite settings, so SaaS no longer sets them.
• WordPress → Nextcloud: WordPress stays on its own network, so names shared by both stacks (mailpit, nginx) keep resolving to its own services. _connect-networks connects the NCDD shared proxy to the WordPress network with the Nextcloud hostname as an alias, which is the same mechanism NCDD uses for its own network. Only the WordPress database joins the NCDD network, as wordpress-mariadb, for wordpress_dsn. make down disconnects both before removing the stacks.
• TLS: PHP's libcurl resolves *.localhost to the loopback and skips Docker DNS, so the proxy alias is not reachable by name from PHP containers. A small mu-plugin, scoped to the Nextcloud host, resolves that hostname to the proxy and validates the certificate against the shared proxy's local CA. Certificate verification stays enabled. The CA volume is mounted as an external volume and created by the Makefile when missing, so docker compose down -v on the WordPress stack never deletes it.
• WordPress URL: the NCDD shared proxy owns host ports 80 and 443, so WordPress now listens on 8080 (WORDPRESS_HTTP_PORT) at http://127.0.0.1:8080. It uses 127.0.0.1 instead of localhost because the proxy sends HSTS for https://localhost. After visiting the proxy dashboard, browsers upgrade http://localhost:8080 to HTTPS and WordPress stops loading. Existing installs that still use http://localhost for home and siteurl are moved to the new URL by make up.
• Meaningful failures:
  • make up stops when a component or the integration fails.
  • App and plugin activation and admin group provisioning no longer ignore errors.
  • Provisioning runs from WordPress through the plugin's own Nextcloud client.
  • WordPress and Nextcloud are only considered ready once their entrypoints finish installing.
• Removed: docker-compose.nextcloud.override.yml, DOCKER_HOST_GATEWAY_IP, NEXTCLOUD_HTTP_PORT, NEXTCLOUD_BASE_URL, NEXTCLOUD_LOCAL_URL and _set-trusted-domains.

Tests

• make test-config validates the Compose configuration with the updated NCDD. It runs in CI.
• make test-integration checks the running environment and is run locally:
  • the required services are running;
  • WordPress uses the NCDD Nextcloud URL;
  • WordPress resolves mailpit to its own service;
  • WordPress reaches Nextcloud with a verified TLS certificate;
  • an authenticated Nextcloud API request succeeds;
  • the required apps, the plugin and the admin group are in place;
  • running make up again keeps the existing configuration.

Validation

make up wordpress nextcloud and make test passed on a fresh clone (Fedora 44). The run used a WordPress 7.1 image built from wordpress-docker (see notes). With the image currently published (WordPress 6.9.4), make up now fails explicitly on the plugin activation instead of ignoring it.

Notes

• woocommerce-nextcloud-admin-group-manager requires WordPress 7.0, but the published wordpress-docker image ships 6.9.4. The fix belongs to wordpress-docker (bump VERSION_WORDPRESS to 7.1), followed by a submodule bump here.
• wordpress_login_backend, admin_group_manager and groupquota declare support up to Nextcloud 35, while NCDD runs master. They are enabled with --force. Before this PR, wordpress_login_backend was silently never enabled.

[vitormattos]

Thanks for investigating the fresh-clone startup problems. The issues identified in this PR are valid, but I think we should revise the solution before merging.

The main goal of this repository is straightforward: a developer should be able to start the complete LibreSign SaaS environment, including the site, WordPress, Nextcloud, and their integrations, with a single make up command.

Since the nextcloud-development submodule was last updated, NCDD has introduced improvements that make part of the implementation proposed here unnecessary.

1. Update the NCDD submodule

The current submodule is pinned to commit 56660f4 from August 2026.

Since then, NCDD has introduced:

• A shared reverse proxy managed by proxy-coordinator.
• Canonical Nextcloud URLs configured through NEXTCLOUD_HOST and NEXTCLOUD_PROTOCOL.
• Automatic configuration of trusted_domains, overwritehost, and overwriteprotocol.
• Internal Docker network routing to the shared proxy.
• An updated startup lifecycle.

References:

• https://github.com/LibreCodeCoop/nextcloud-docker-development/blob/main/docs/advanced-setup.md
• LibreCodeCoop/nextcloud-docker-development#152
• LibreCodeCoop/nextcloud-docker-development#153

Please update the submodule to a tested revision and adapt the SaaS startup commands to the current NCDD interfaces.

Keep the submodule pinned to an explicit commit.

2. Remove the unnecessary Nextcloud networking workaround

The newly introduced docker-compose.nextcloud.override.yml publishes an additional nginx port through the Docker host gateway.

This workaround targets the older NCDD architecture. The current implementation uses a shared proxy and supports container access through Docker network aliases.

Please:

• Remove docker-compose.nextcloud.override.yml.
• Remove DOCKER_HOST_GATEWAY_IP and the related gateway detection logic.
• Use the existing NCDD proxy mechanisms for WordPress → Nextcloud communication.
• Review _connect-networks and remove or adjust the manual network connection if it is no longer necessary.

There is an additional issue to resolve: the SaaS WordPress Compose override currently publishes host port 80, which conflicts with the port used by the NCDD shared proxy.

Please find the simplest configuration that allows WordPress, the site, and Nextcloud to coexist without conflicting host ports.

We do not need to introduce another reverse proxy or redesign the entire SaaS networking architecture. We only need the existing components to communicate reliably.

3. Reuse the canonical Nextcloud configuration

The new _set-trusted-domains target should not be necessary.

NCDD already configures the canonical hostname, trusted domains, and overwrite settings.

Please remove this target and avoid reading config/config.php directly from the Makefile.

Review NEXTCLOUD_LOCAL_URL, NEXTCLOUD_BASE_URL, and NEXTCLOUD_HTTP_PORT so that SaaS does not maintain unnecessary or conflicting Nextcloud URL configuration.

The WordPress integration should receive the correct Nextcloud URL derived from the NCDD configuration.

Since NCDD uses HTTPS by default, also verify that WordPress can reach the shared proxy with proper TLS certificate validation. We should not disable certificate verification to make the integration work.

4. Adjust only the affected Makefile targets

Please review the existing Nextcloud startup and integration targets against the updated NCDD.

In particular:

• _refresh-nextcloud-images
• _start-nextcloud
• _wait-nextcloud
• _connect-networks
• _setup-apps
• _provision-user

Prefer the standard NCDD Compose lifecycle rather than maintaining an explicit list of infrastructure services that may become outdated.

Keep the responsibility boundaries clear:

• NCDD manages the Nextcloud runtime, proxy, networking, and canonical URL configuration.
• SaaS manages the integration between the site, WordPress, and Nextcloud, including application-specific setup and provisioning.

Preserve the existing make up, make down, and component-specific commands.

Do not refactor unrelated functionality.

5. Preserve the valid fixes and address startup failures

The env UID=... fix is valid and should stay.

The mysql → database service rename is also valid, although the startup command should be reconsidered based on the current NCDD lifecycle.

One additional problem was identified in the PR description: woocommerce-nextcloud-admin-group-manager cannot be activated because of a WordPress version incompatibility, and the failure is currently ignored.

Since this plugin is part of the SaaS integration, please verify its actual compatibility and fix the underlying issue. Do not bypass plugin version requirements or silently ignore activation failures.

The same principle applies to required provisioning steps: make up should not report success if an essential integration failed.

Keep this review limited to errors that affect the expected startup and integration behavior.

6. Add focused regression tests

The original problem was discovered when running make up on a fresh clone. We should prevent that regression from returning.

Please add automated coverage for the relevant startup and integration behavior.

At minimum, verify:

1. The Compose configuration is valid with the updated NCDD.
2. The required services start successfully.
3. WordPress can reach Nextcloud through the configured hostname and protocol.
4. An authenticated Nextcloud API request succeeds.
5. Required applications and plugins are enabled.
6. Running the setup again does not break existing configuration.

Keep tests proportional to this change. Prefer lightweight checks where possible and a focused Docker integration test for the actual connectivity.

There is no need to introduce a new testing framework or adopt NCDD's dev-worker functionality solely for this PR.

Expected outcome

The revised PR should:

• Update NCDD to a tested revision.
• Remove the unnecessary nginx override and host gateway workaround.
• Reuse NCDD's existing proxy and canonical URL configuration.
• Resolve the WordPress/Nextcloud networking and compatibility problems.
• Simplify the affected Makefile targets without expanding their responsibilities.
• Preserve the valid UID and database service fixes.
• Ensure make up starts a functional environment and reports meaningful failures.
• Include focused automated regression coverage.

The objective is to make use of improvements already available in NCDD, not to introduce new infrastructure functionality into SaaS.

Please keep the changes focused on making the existing single-command startup reliable. Any unrelated improvements can be handled in separate issues.

[YvesCesar]

@vitormattos

Thanks for the review! I reworked the PR on top of the current NCDD:

• NCDD: the submodule is pinned to 812fe2d, and Nextcloud now starts with
  the standard NCDD lifecycle (pull --ignore-buildable / up -d).
• Networking: removed the nginx override, DOCKER_HOST_GATEWAY_IP, _set-trusted-domains and the SaaS-side Nextcloud URL variables. WordPress joinsthe NCDD network and uses the canonical URL configured by NCDD (https://nextcloud-development.localhost). WordPress moved to port 8080, since the shared proxy owns 80/443.
• TLS: one finding on the NCDD side: PHP's libcurl resolves *.localhost to the loopback and skips Docker DNS, so the proxy alias can't be reached by name from PHP containers. SaaS works around it with a small mu-plugin, scoped to the Nextcloud host, that resolves the hostname to the proxy and validates the certificate against the proxy's local CA. Certificate verification stays enabled.
• Failures: make up now stops when a component or the integration fails, with no more || true. Removing it showed that wordpress_login_backend was never actually enabled: it declares support up to Nextcloud 35, while NCDD runs master. The Nextcloud apps are enabled with --force for now.
• WordPress 7.0: woocommerce-nextcloud-admin-group-manager requires WordPress 7.0, but the published wordpress-docker image ships 6.9.4. I fixed it at the source in (bump to 7.1). Until that is merged and the image is published, make up fails explicitly on the plugin activation instead of ignoring it.
• Tests: make test-config runs in CI, and make test-integration covers the six points you listed, including running make up a second time and checking that the configuration is unchanged.

Could you take another look?