[Manager] Resource editor shows empty "Publish Date" even though `publishedon` is populated

[another-brick-in-the-wall]

In the resource editor, the field labeled "Publish Date" / "Дата публикації" is empty for published resources even when the resource already has a valid publication timestamp in the database.

I verified this both on migrated resources and on a newly created resource in the manager. The issue is reproducible on a fresh resource as well.

Observed behavior

The resource edit form renders the publish date input from pub_date, not from publishedon.

Relevant code in the manager form:

manager/actions/mutate_content.dynamic.php

<input type="text" id="pub_date" ... value="<?= ((int)get_by_key($content, 'pub_date', 0, 'is_scalar') === 0 || !isset($content['pub_date']) ? '' : $modx->toDateFormat($content['pub_date'])) ?>" ... />

So the UI reads pub_date.

However, when a new resource is created or saved, the actual publication timestamp is stored in publishedon.

Relevant save logic:

manager/processors/save_content.processor.php

$publishedon = ($published ? $currentdate : 0);

if ((!empty($pub_date)) && ($published)) {
    $publishedon = $pub_date;
}

$resourceArray['pub_date'] = $pub_date;
$resourceArray['publishedon'] = $publishedon;

This means:

• publishedon is filled for published resources
• pub_date remains 0 unless an explicit publish date is entered
• the manager displays the field as empty even for already published resources

Reproducible example

I created a new resource in the manager:

• id = 290
• published = 1
• publishedon = 1779718556
• pub_date = 0

So the resource is published and has a timestamp, but the "Publish Date" field in the editor remains empty.

Database evidence

For id = 290:

{
  "id": 290,
  "pagetitle": "тайтл",
  "published": 1,
  "pub_date": 0,
  "publishedon": 1779718556
}

Actual result

• The resource is published
• publishedon is populated
• The manager shows an empty "Publish Date" field
• This looks like the date was not saved, even though it was

Expected result

The manager should either:

1. display publishedon if the field is intended to show the actual publication timestamp, or
2. clearly label pub_date as a scheduled publication date, not the publication timestamp

Ideally, both values should be visible:

• pub_date = scheduled publish date
• publishedon = actual publication timestamp

Why this is confusing

The current label strongly suggests the field represents the publication date of the resource, but in practice it is bound to pub_date, which is only used for scheduling.

For imported content and for newly created published resources, publishedon is the meaningful value. Because the form ignores it, the field appears broken.

Environment

• EvolutionCMS 3.5.x-dev
• PHP 8.4.16
• MySQL
• Manager resource editor
• sGallery

Screenshot

Suggested fix

A possible fix would be one of the following:

• show publishedon in the editor if the intent is to display the actual publish timestamp
• rename the current field to something like Scheduled Publish Date
• keep both fields separate in the UI:
  • pub_date for scheduling
  • publishedon as read-only metadata

Additional note

I confirmed this is not limited to migrated data. It also happens when creating a fresh resource through the admin panel.

[MiddleSokilAI]

Thanks, I can reproduce the data mismatch from the code path. I am taking this one and will check the resource editor/save conventions before changing the UI so pub_date scheduling and publishedon metadata do not get conflated.

[MiddleSokilAI]

PR opened: #2361

Repro

A published resource can have publishedon populated while pub_date remains 0. The resource editor displayed the editable pub_date field with the generic publish-date label, so the UI looked empty even though the actual publication timestamp existed.

Root Cause

The editor conflated two different concepts in the label/UI: pub_date is the scheduled publish date, while publishedon is the actual publication timestamp written when the resource is published.

Validation

• git diff --check
• wsl -e bash -lc 'cd /mnt/h/PhpstormProjects/Extras/evolution && php8.4 -l manager/actions/mutate_content.dynamic.php && php8.4 -l core/tests/Unit/Manager/ResourcePublishDateFieldTest.php'
• wsl -e bash -lc 'cd /mnt/h/PhpstormProjects/Extras/evolution && find core/lang -mindepth 2 -maxdepth 2 -name global.php -print0 | xargs -0 -n1 php8.4 -l'
• WSL Python source/lexicon smoke check confirmed the scheduled-vs-actual field split and required lexicon keys in every manager language.

Not available locally:

• Pest/PHPUnit binaries are not present in core/vendor/bin or vendor/bin.

Risk

LOW. The save behavior is unchanged; the editor keeps pub_date editable for scheduling and adds publishedon as read-only metadata.

Visual Proof