Fix task status badge

[flexseth]

HTML was being output where the Task status badge should have been.

Fixes: #3

[flexseth]

caveat

Is it possible the bug exists in a helper function upstream to Jetpack?

AI root-cause analysis

I had Claude analyze and try to find if the error was a regression, as the task status badge seemed to work at some point in time. It provided the following root-cause analysis:

# Bug Report: Task Status Column Renders Raw HTML in Company View

**Affects:** `admin/company/view.page.php`  
**Surface:** Companies > single company view > Tasks table, Status column  
**Severity:** Visual / UI — status labels display as escaped HTML entities instead of rendered markup

---

## Symptom

The Status column in the company task table renders raw HTML entities instead of the styled label:

<span class='ui grey label'>Incomplete</span>

instead of the expected rendered `<span>` element.

---

## Root Cause

The bug is in the task rendering loop in `admin/company/view.page.php`. A fully constructed HTML string is passed through `esc_html()`, which converts angle brackets to entities:

```php
// BROKEN — upstream trunk
$status = "<span class='" . zeroBSCRM_html_taskStatusLabel( $task ) . "'>" . $statusStr . '</span>';

echo '<td>' . esc_html( $status ) . '</td>'; // esc_html() encodes the <span> tags

esc_html() is the correct function for escaping plain text before output. When applied to a pre-built HTML string, it converts < → < and > → >, making the tags visible as literal text in the browser.

zeroBSCRM_html_taskStatusLabel() returns a plain CSS class string ('ui grey label' or 'ui green label') — it is not the source of the problem.

---

History

This bug has been present since the initial monorepo commit (7aea499e, January 2023). It is not a regression introduced by a specific recent change — the company view task section was authored with the wrong escaping pattern and was never corrected.

Parallel code in admin/contact/view.page.php is correct

The contact view has always used the right approach — escaping each interpolated value individually, then outputting $status directly:

// CORRECT — contact view (upstream trunk)
$status = "<span class='" . esc_attr( zeroBSCRM_html_taskStatusLabel( $task ) ) . "'>" . esc_html( $statusStr ) . '</span>';

echo '<td>' . $status . '</td>'; // $status is already safely escaped

The company view was simply never aligned with this pattern.

---

Commits Reviewed (Last 6 Months)

SHA	Date	Message	Affected Task Status?
08d6d8ff	2026-05-08	CRM: Use proper string escape functions (#48496)	No — only JS nonce output
1285bad7	2026-02-05	CRM: Fix code style formatting throughout codebase (#46809)	No — whitespace/comment only
06ee1cc3	2025-09-17	Phan: Address PhanTypeSuspiciousStringExpression violations (#45182)	No — variable renaming only
fa9394b9	2025-08-22	Phan: Address PhanImpossibleCondition violations (#44869)	No
dbad794f	2025-01-20	Phan: functionify and statusify exit() and die() (#41167)	No

None of the recent commits introduced or modified the task status escaping logic. The bug predates all of them.

---

Fix

Escape each interpolated value individually when building $status, and output the result directly — mirroring the contact view pattern:

// FIXED
$status = "<span class='" . esc_attr( zeroBSCRM_html_taskStatusLabel( $task ) ) . "'>" . esc_html( $statusStr ) . '</span>';

echo '<td>' . $status . '</td>'; // $status is already safely escaped above

Files to change:

• admin/company/view.page.php — task loop, approximately line 854 on upstream trunk

No change needed:

• admin/contact/view.page.php — already correct on upstream trunk

---

Local Fork Status

The fix is already applied in this fork at admin/company/view.page.php:854–861. This fork is ready to submit as a PR to Automattic/jetpack-crm.

---

References

• Upstream repo: Automattic/jetpack-crm
• Initial monorepo commit: 7aea499e (January 2023)
• WordPress escaping docs: esc_html(), esc_attr()
• WordPress WPCS output escaping standards: Plugin Handbook — Data Validation