User tests: Successful: Unsuccessful:
Pull Request for Issue #25559 (comment) .
Separate the data from the logic
Handling JSON files is way easier to do programmatically than injecting data in the runtime script. Also if this PR gets approved/merged we can beef up the build tools (php and/or JS) to maintain a list of files per release and then for the new release just compare it with the existing files in the deliverable folder and thus create the diff automatically. In short strengthen the release procedure against accidental typos, forgotten steps, etc.
get a copy of the zip from github and try to update from 3.10
@richard67 @wilsonge your input?
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_admin |
Labels |
Added:
?
|
The scripts already exist to build a list of files and folders
The scripts already exist to build a list of files and folders
@brianteeman if you check the other PR #25559 you'll see that George and Richard face some problems with the existing (refactored) script. With this PR basically, I want to automate things to a greater degree than what's already in our tools arsenal. I already have code to deal with the 3.10 to 4.0 part https://github.com/dgrammatiko/jdiff and will work to fix the static assets that currently are transparent to the script. Actually, this is the reason for this PR, if the npm
tool is able to create the needed diff then why not use the file directly rather than having someone do the manual step of copy/pasting the data (which could always end up with some bug, it's slower, needs training, etc)
Bit of a brain dump follows:
I like the concept of having separate files for different versions - makes life much easier to manage. Probably easier to manage long term as well.
My original gut was that it was a bad idea to have them in JSON rather than say XML - just for consistency with the rest of Joomla - but maybe it's fine because we are starting to use JSON with the web assets anyhow.
Technically the separate files is going to end up causing a leak of data of what version of Joomla people are running - people tend to disable the public read on the XML files - the presence of these files (rather than ability to read them) would maybe allow this now... Probably not the biggest issue though.
Technically the separate files is going to end up causing a leak of data of what version of Joomla people are running
I was thinking about it as well. Are the .sql
files https://github.com/joomla/joomla-cms/tree/4.0-dev/administrator/components/com_admin/sql/updates/mysql somehow hidden? if so we can use that extension (PHP won't care about the extension). Or just add some .htaccess
and call it a day? Or use .xml
(aren't these fetchable also)?
I can steer this one however you prefer, I mean right now the code is mostly sudo code here...
@wilsonge @richard67 so I wrote some code to discover the missed files between betas. Parts of the code will be in the tools for the checks of the redundant files. The results are somehow interesting: https://github.com/dgrammatiko/JfixMediaFolder/blob/main/diff_beta_6_7.json
@wilsonge I converted all the json files to xmls. Also brought all the missing parts (esp the static assets missed between the betas) from https://github.com/dgrammatiko/JfixMediaFolder
The missing link (assuming that the PHP code here is working, haven't tested it, yet) is the introduction of a json registry so we don't have to do complete builds for the previous and next version (basically some modified code from https://github.com/dgrammatiko/JfixMediaFolder should get the work done for us). Let me know if this is ok before loosing to much time here
@dgrammatiko I appreciate much your efforts, and I hope you are not disappointed because I don't react much. I had and still have a bit to focus on other stuff first, but I hope I can find time on weekend to have a closer look. Please stay tuned and don't give up if rections come slow from me or George (as far as I know he is busy with private stuff too at the moment).
I had a first look on it a few days ago and have noticed that your list might include files which we handle here (at least I remember having seen some skipTo stuff):
Those should not be in the list of files to be deleted, regardless which upper and lower case mix in the file name.
Old sample data images should possibly also not be deleted on updates because people might have used them in own content (maybe the like pictures of apples or bananas).
Old sample data images should possibly also not be deleted on updates
Thankfully I have the code on the other PR so I can add exclusions, but the contents of the files here basically are the absolute diff between the releases (which might, as you pointed, need some adjustments). Also, don't worry about slow responses, I know that there are plenty of things that have a higher priority.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-07-25 19:08:03 |
Closed_By | ⇒ | dgrammatiko |
@SharkyKZ is this one more of your usual thumbs down or you have some objection that you want to share with us why this is a bad idea?
FWIW from an architectural point of view data should never be hardcoded in the logic, it's kinda preliminary info for any developer...