Clearer default custom-domain DNS instructions and configurable DNS target

Đang mở
#2,067 14 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@superdav42 đang làm issue này rồi.

Từ ngày 2/11/2026.

  • #2071 của @superdav42 — đã đóng, không merge
  • #2073 của @superdav42 — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
php, wordpress
Lĩnh vực
backend

Hướng nghiên cứu

Start in inc/managers/class-domain-manager.php, at default_domain_mapping_instructions(), get_domain_mapping_instructions() and the domain_mapping_instructions setting near line 800. Before editing, read the failing PHP 8.2 to 8.5 CI logs from the linked PR #2071, since that attempt did not pass. Done means the default text covers apex CNAME/A fallback, www, conflicting records and Cloudflare, %DNS_TARGET% works, and stored custom instructions and the filter are unchanged.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement origin:worker source:ci-feedback status:in-review

What

Improve UM's default custom-domain DNS instructions and let network admins set a recommended DNS target, so end customers can map domains correctly without support.

Why

Domain_Manager::default_domain_mapping_instructions() (inc/managers/class-domain-manager.php) only says "create a new CNAME record pointing to %NETWORK_DOMAIN%". Customers struggle because:

  • many DNS providers do not allow a CNAME on the apex; the text gives no A-record fallback even though %NETWORK_IP% exists;
  • it does not mention the www record (UM's auto_create_www_subdomain creates it, so it needs DNS too);
  • hosts often want customers to point at a dedicated hosting hostname, not the network's main domain; there is no setting for that;
  • Cloudflare users get no guidance (proxy on/off, SSL/TLS Full (strict)).

Real case (2026-10-31): a customer on a hosted UM network pointed www.<their-domain> at an unrelated domain of theirs and needed operator help; the host had to hand-write instructions per network.

How

Files to Modify
  • EDIT: inc/managers/class-domain-manager.php — default_domain_mapping_instructions() (rewrite the default text: apex CNAME if the provider supports it, otherwise A to %NETWORK_IP%; www CNAME; remove conflicting records; Cloudflare note; first HTTPS visit can take a minute while SSL is issued); get_domain_mapping_instructions() (add a %DNS_TARGET% placeholder); settings registration near the domain_mapping_instructions field (~line 800) — add an optional domain_mapping_dns_target setting (defaults to the network domain) and document the new placeholder in the field desc.
  • Keep the wu_get_domain_mapping_instructions filter signature backward compatible.
Hazards
  • Stored custom instructions must render unchanged; only the default changes.
  • %NETWORK_IP% comes from Domain_Mapping\Helper::get_network_public_ip(); behind proxies/NAT it can be wrong, so phrase the A record as a fallback and let domain_mapping_dns_target take priority.
  • All new strings translatable (ultimate-multisite text domain).
Verification
  • PHPUnit for Domain_Manager if present; otherwise focused test of get_domain_mapping_instructions() with: empty setting (new default), custom setting (unchanged), domain_mapping_dns_target set (%DNS_TARGET% replaced).
  • Manual: Network Admin → Settings → Domain Mapping shows the new field; the add-domain modal shows the new default.
Files Scope
  • inc/managers/class-domain-manager.php

Acceptance Criteria

  • Default instructions cover apex CNAME/A fallback, www, conflicting records, and Cloudflare.
  • Network admins can set a recommended DNS target used by %DNS_TARGET% and the default text.
  • Existing custom instructions and the filter keep working.

aidevops.sh v3.39.49 plugin for OpenCode

CI Repair Feedback (from PR #2071)

The previous worker's PR #2071 had terminal failed CI checks. A head-bound
finalizer is routing this issue for redispatch. The next worker should address these failures.

Terminal failed checks
  • PHP 8.5: failure — check URL — primary failing-check evidence
  • PHP 8.4: failure — check URL — primary failing-check evidence
  • PHP 8.3: failure — check URL — primary failing-check evidence
  • PHP 8.2: failure — check URL — primary failing-check evidence
Worker guidance
  1. Recover the previous PR branch/commits and continue that work; do not restart from scratch.
  2. Read every terminal check URL above and preserve the accumulated evidence.
  3. Rebase the recovered work onto current origin/main, then fix the code rather than weakening CI.
  4. Run every listed local check and create the replacement PR from the recovered branch.

Routed by deterministic merge pass (pulse-merge.sh).

In-place repair fallback
  • Reason: the bounded PR-branch repair session exhausted its retry budget
  • Retry: re-run the deterministic merge pass after restoring access to branch feature/auto-20261031-195544-gh2067; keep PR #2071 open until that retry is impossible.
In-place repair attempt outcomes
  • Attempt 1: stage=worktree_create; result=launch_failed; failure_reason=worktree_helper_failed; next_action=inspect_worktree_helper_log_and_retry
  • Attempt 2: stage=worktree_create; result=launch_failed; failure_reason=worktree_helper_failed; next_action=inspect_worktree_helper_log_and_retry
Ngôn ngữ chính
PHP
Star
218
Fork
88
Merge trung bình
1 ngày 4 giờ
Pull request đã merge (30 ngày)
96

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Ultimate-Multisite/ultimate-multisite

Tất cả issue của Ultimate-Multisite/ultimate-multisite

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.