[#17536] - [4.0] Show changelog - GSoC Expand Extensions Manager
- Closed
- 26 Feb 2019
- Medium
- Build: 4.0-dev
- # 17536
- Diff
- NunoLopes96:show_changelog
- Success Hound No violations found. Woof! Details
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Success continuous-integration/drone/pr the build was successful Details
- Success continuous-integration/appveyor/pr AppVeyor build succeeded Details
User tests: Successful: Unsuccessful:
Introduction
At this time, users have to look for external sources of information about changes in an extension, when they are going to update their extensions. In most cases, users install an extension without checking the changelog due to the difficulty to find the associated changelog. With this new feature, users can review the changelog of the extensions when they are about to install an update (granted that the changelog is provided by the extension's developer), and after the extension is installed.
Summary of Changes
Added a new parameter on the xml updateserver files 'changelogurl' and adding it to #__updates table.
Testing Instructions
I made some changes in the core databases so before testing you should fix your database:
Extensions -> Database -> Fix
Extensions -> Updates -> Find Updates
Update View
Install my component: https://github.com/NunoLopes96/component_joomla
By default you will have always an update from 0.0.2 to 4.0.0 just for testing
If the changelog is not available it will show N/A like in the Folder column
It will open a modal with an iframe of the changelogurl in the body.
The title of the modal is version ' - ' component_name
Manage View
The changelogurl is supported for Components, Libraries, Modules, Plugins and Packages, you just need to add tags in your instalation xml with a valid url inside.
To test this you can use these modified packages:
(To test Package, Component, Module, Plugin)
pkg_weblinks_3.4.1-changelog.zip
(To test Libraries)
lib_fof30-3.1.0-changelog.zip
(To test languages)
The language installer its diferent from the others so you may want to test 2 cases:
1-Install without having it already in your extensions
2-Install without changelogurl and then install again with a changelogurl
This happens because it has 1 function to install and another one to update ( they are similar )
admin_pt-PT.zip
Extension name: Português (pt-PT)
(To test templates)
et_kidtoy_joomla_template_install_package_free.zip
Extension name: etkidtoy
(To test Files)
cli2zoombie.zip
Extension name: Zoombie - CLI Application
Expected result
In Updates View you will have a new column that will show a changelog button to open a modal if there is a changelogurl in the #__updates table.
In Manage View you will have an tag in the version with a info icon on the right side if your extension has a changelogurl in the #__extensions table.
Documentation Changes Required
Add changelogurl parameter on updatesite information and in extension
joomla-cms-bot
- | Category | ⇒ | SQL Administration com_admin Postgresql com_installer Language & Strings Installation Libraries |
| Status | New | ⇒ | Pending |
Using something like XML would be beneficial when extensions are stored on services that do not easily serve html
| Labels |
Added:
?
?
|
||
The idea looks good but using a iFrame will create problems when using certain Security Headers.
Especially the header X-Frame-Options, this header will block loading a website in a Frame.
So when a extension developer use this header in his website, you won't see the information in a frame. https://scotthelme.co.uk/hardening-your-http-response-headers/#x-frame-options
So @mbabker his idea for having a standardized file format would be better.
So I have come up with the following schema. Let me know if I should proceed with this or if it should be changed.
<changelogs>
<changelog>
<element>com_lists</element>
<type>component</type>
<version>0.0.4</version>
<security>
<item></item>
<item></item>
</security>
<fix>
<item></item>
<item></item>
</fix>
<language>
<item></item>
<item></item>
</language>
<addition>
<item></item>
<item></item>
</addition>
<change>
<item></item>
<item></item>
</change>
<removed>
<item></item>
<item></item>
</removed>
<note>
<item></item>
<item></item>
</note>
</changelog>
</changelogs>
This schema allows for the following types of information:
- Security fix
- Regular fix
- Language change
- Addition
- Change
- Remove
- Note
I believe this should cover all possible changes. Let me know what you think.
Looks good but we are talking about users (non-developers) reading this
maybe these categories
Security Fixes
Bug Fixes
New Features / Improvements
Removed features
Behaviour Change
Notes
| Category | SQL Administration com_admin Postgresql com_installer Language & Strings Installation Libraries | ⇒ | SQL Administration com_admin Postgresql com_installer Language & Strings Installation Layout Libraries |
I have started to bring this PR inline with the 4.0-dev codebase and work out the issues and improve the featureset.
I am sure @Quy will help me with codestyle :) Now I also need help with styling the modal containing the updates. Have a look at this:
This contains all the possible sections that are available. @ciar4n is this something you can help me with?
As for the changelog.xml I am now using this format, any feedback for this is appreciated as well.
<?xml version="1.0" encoding="utf-8"?>
<changelogs>
<changelog>
<element>com_lists</element>
<type>component</type>
<version>0.0.4</version>
<entries>
<security>
<item>CVE 1</item>
<item>CVE 2</item>
</security>
<fix>
<item>FIX 1</item>
<item>FIX 2</item>
</fix>
<language>
<item>LANG 1</item>
<item>LANG 2</item>
</language>
<addition>
<item>ADD 1</item>
<item>ADD 2</item>
</addition>
<change>
<item>CHANGE 1</item>
<item>CHANGE 2</item>
</change>
<removed>
<item>REMOVE 1</item>
<item>REMOVE 2</item>
</removed>
<note>
<item>NOTE 1</item>
<item>NOTE 2</item>
</note>
</entries>
</changelog>
</changelogs>
This PR is not ready yet but I would appreciate feedback already so we can get this into a ready state.
I don't think you need the type in your schema. This living on a foreign server where you are already matching against the element so I don't see what value it's providing?
Additionally I think we only need fix and note - not change - they should be covered by the other things
@wilsonge The reason the type is there is because we have it that way in the update XMLs as well. The only reason I took it as well is because I figured we can use it for better checking we have the correct type.
Additionally I think we only need fix and note - not change - they should be covered by the other things
As an extension developer I use all of them to clearly identify where the entry belongs to. Each has their own merit to me at least. I don't see any harm in offering them, extension developers don't have to use them of course. They are there for those who want to use more distinction.
Agree with roland - hardly changelog without listing any changes ;)
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-02-26 19:49:45 |
| Closed_By | ⇒ | roland-d |
Looking at this with fresh eyes, there is a part of me that wonders if we should be using an iframe to show the third party site in this manner, or if we should implement a standardized file format (i.e. another XML schema) that developers publish which is consumed and rendered within that modal. Beyond that, concept looks fine to me.