@MarkRS-UK please have a look at the code style errors and fix them.

Thank you for your contribution. Could you please check your development/Git setup? It’s currently almost impossible to review this PR because entire files appear to have been replaced, probably due to tab or CRLF issues.

I have tested this item 🔴 unsuccessfully on 6be3675

I have tested this item 🔴 unsuccessfully on 6be3675

I have tested this item 🔴 unsuccessfully on 6be3675

Verdict: Needs one small change — the feature works, but it introduces a PHP warning on a
realistic failure path.

The pr does what it claims: the extension changelog modal (System → Manage → Extensions →
click the version) now lists all changelog versions instead of only the installed one, each
under its own version header. Confirmed working. There is one regression to fix before merge, plus a
couple of optional notes.

Verification

Tested on a clean 6.2-dev build of this PR (DDEV, PHP 8.3). Seeded an extension (com_banners) with
a changelog XML containing three versions (3.0.0 / 2.0.0 / 1.0.0, mixed change types) and exercised
the real code path (Changelog::loadFromXml → ManageModel::loadChangelog → FileLayout joomla.installer.changelog).

• After (this PR): all three versions render, each with its <div id="<version>" class="changelog"> header and the correct per-type badges (security/fix/addition/change/remove/
  note) and items.
• Before (base 6.2-dev, per the diff): only the entry whose version matched the installed
  version was kept ($latest), so a single version was shown. The behaviour change is real and
  correct.
• Scope is sensible (4 files, +81/−90); the now-unused deprecated Changelog::get() calls are
  removed from ManageModel and the matching phpstan-baseline.neon entries are correctly dropped.

Finding (needs change) — PHP warning when the changelog is empty or the URL fails

Changelog::$changes is declared public $changes; with no default, and
ManageModel::loadChangelog() iterates it unconditionally:

foreach ($changelog->changes as $key => $entry) {   // ManageModel.php

If loadFromXml() returns no <changelog> entries (empty <changelogs>) or fails entirely
(URL 404 / changelog server unreachable), $changes stays null, so this becomes
foreach (null …):

Warning: foreach() argument must be of type array|object, null given

I reproduced both cases at runtime (empty <changelogs/> → loadFromXml=true, changes=NULL; bad
URL 404 → loadFromXml=false, changes=NULL); both fire the warning (confirmed via CLI with full
error reporting). The old code degraded silently here (it guarded on isset($this->latest) /
get() returned null). A down/missing changelog server is a plausible real-world condition.

Real-world visibility: in the running backend the warning does not surface in the modal —
I tested the actual manage.loadChangelogRaw endpoint with Error Reporting at both default and
maximum, and in both cases the modal is simply empty (0 bytes); Joomla's runtime error handler
keeps the E_WARNING out of the output (it goes to the log). So the user-facing symptom is a silent
empty modal rather than a graceful no-op, and the unguarded foreach over a nullable property is a
code-level regression worth fixing regardless.

Suggested fix

Initialise the property to an array — one line, fixes both cases:

// libraries/src/Changelog/Changelog.php
public $changes = [];

(Optionally also guard in the model: if (empty($changelog->changes)) { return ''; }.)

Optional notes

• Dead code: with the version-match logic gone, setVersion() / $matchVersion (and
  getVersion()) no longer affect anything — ManageModel still calls setVersion() but it is now
  a no-op. Consider removing, or leave for b/c.
• Output escaping: the version key is echoed unescaped into both an attribute and text
  (id="<?php echo $key?>", <span><?php echo $key; ?></span>). It comes from the extension's own
  changelog XML (low risk), but $this->escape() would be more consistent with the project's
  output-escaping stance.
• The author's note (scroll/highlight the installed version via the added id) is not implemented;
  fine for this PR's scope.

Thanks for that. I've implemented all of those. Tested with a valid changelog and with a broken changelog URL which simply yields a blank dialog.

I have tested this item ✅ successfully on 6de5081

I have tested this item ✅ successfully on 6de5081

may i suggest to add something like

   /**
     * Update manifest `<releasedate>` element
     *
     * @var    string
     * @since  __DEPLOY_VERSION__
     */
    protected $releasedate;

to have something like

<changelogs>
    <changelog>
        <element>mod_changelog</element>
        <type>module</type>
        <version>1.0.0</version>
        <releasedate>2024-01-01</releasedate>
        <security>
            <item>Item A</item>
            <item>Item b</item>
        </security>
        <fix>
            <item>Item A</item>
            <item>Item b</item>
        </fix>
        <language>
            <item>Item A</item>
            <item>Item b</item>
        </language>
        <addition>
            <item>Item A</item>
            <item>Item b</item>
        </addition>
        <change>
            <item>Item A</item>
            <item>Item b</item>
        </change>
        <remove>
            <item>Item A</item>
            <item>Item b</item>
        </remove>
        <note>
            <item>Item A</item>
            <item>Item b</item>
        </note>
    </changelog>
    <changelog>
        <element>mod_changelog</element>
        <type>module</type>
        <version>1.1.0</version>
        <releasedate>2026-01-01</releasedate>
        <change>
            <item>Code clean</item>
        </change>
    </changelog>
</changelogs>

Seems like a good idea, but is "releasedate" a valid tag? It's not listed in the documentation.

From that point of view, I'd say this would be out of scope for this PR.

It's not listed in the documentation.

not yet but, all changelogs have that information especially when you are showing all items like in this pr

What is that date then?

Looks to me like it's the creation date, adding "01" if a day isn't specified. Is that meant to signify version release date? That's not what I would have guessed.

version release date

@MarkRS-UK Are you able to finish this PR so we could maybe get it in? Today Alpha 3 will be released. This feature would need to be ready before Beta 1 in three weeks (ready, tested and RTC) else we'll miss the deadline for 6.2.

What would constitute "finished". I thought it was finished. The extra suggestion about "releasedate"?

What would constitute "finished"? I thought it was finished. The extra suggestion about "releasedate"?

ahh ok yeah well it's finished if there is nothing more to add to the code i guess 😅 So we need testers then. I do like the option of the release date tho. I get why you say it's out of scope so maybe another PR. lets get this one in first.

Bit disappointed not to see this in 6.1.3. Is something else required from me or was it just a lack of testers?

Bit disappointed not to see this in 6.1.3. Is something else required from me or was it just a lack of testers?

Well it's a new feature so you correctly made it for 6.2 - but yes it needs testers

Tested with Latest News Enhanced from @obuisard

• as you can see the contents of the changelog are very different

Before

After

Tested with Latest News Enhanced from @obuisard

• as you can see the contents of the changelog are very different

this is the changelog xml https://updates.simplifyyourweb.com/free/latestnewsenhanced/changelog.xml

Before

After

I have tested this item 🔴 unsuccessfully on 556cdeb

I have tested this item 🔴 unsuccessfully on 556cdeb

Wow, that;s awful! Thank you. I'll fix it.

Wow, that's awful! Thank you. I'll fix it.

Fixed. Tested with Latest News Enhanced and two others.
The only file changed is Changelog.php in the library. I didn't know how to exclude the others, which seem to be the 6.2-dev updates.
The Ci typos & PHPstan failures are not in my code.

the problem with ci and typos is that you have accidentally commited the files from latest news enhanced. please remove them and it should all be ok again

you still need to remove the extra files in the library and plugin folders!

Yes, removing the Latest News Package left a couple of files around. Now removed, should I wait for this set of tests to finish before updating?

no need to wait - a new commit will cancel the existing tests and start new ones

@MarkRS-UK you still need to remove ALL the files from latest news

Working on it

I have tested this item ✅ successfully on 1260697

I have tested this item ✅ successfully on 1260697