solved Some Suggestions on JR module's update method/approach

Hello guyz,

ISSUE:

There is a discussion that started here: https://www.jamroom.net/the-jamroom-network/forum/installation-and-configuration/61695/403-forbidden-error-after-server-migration after having some issues with my server migration:

I think it requires some attention. That's why I've decided to create a separate thread.

There is this question that always bothers me: Why does JR keep old module files/folders on the server after a module update/upgrade????

Example:

/jrCore-release-6.1.1
/jrCore-release-6.1.3
/jrCore-release-6.1.2
/jrCore-release-6.1.4
/jrCore-release-6.1.5
to ...
/jrCore-release-6.3.0b1
/jrCore-release-6.3.0b2
/jrCore-release-6.3.0b3
/jrCore-release-6.3.0b4
etc.

Same with all the other modules: jrAction, jrAudio, jrBackup etc.

Wherever I do an extra site backup from the server to my local computer (although I also have the automatic backup feature from my server/WHM), It takes me hours to transfer files from JR (the server) to my local computer via FTP (Note: I have a fast-speed internet connexion).

The same applies to the server migration, it also takes hours via FTP. Based on my backup, there are close to 60,000 JR files (script files only) to upload to the server. Probably 80% of these files are old module's version files. Wow!!! That's a lot for JR, which is initially a relatively small script, although very robust.

To give you an idea, on my local computer, the JR backup (without the site content: member audio, videos, pictures and database) occupies 0.99 GB (1,065,549,824 bytes), almost 1 GB of disk space: 59,858 files and 9,072 folders, comparing to the 1.910 files and 336 Folders from the JR 6.3.0 install package downloaded from the JR website. What a difference!!!

These old module's version files also take unnecessary disck space on the server (shared, VPS or Dedicated). I have a lot of space on my server, so this is not really an issue for me. but for some, it might be. Also, those who pay for online backup services like Amazon (AWS), Google drive etc, will be concerned ($$$$$$).

In the link above, Michael who provided a great support and helped me to solve my issue (I am very thankful), said:

"The base location for a module is on a directory without its version number.

eg:
/modules/jrCore

When a new jrCore is updated from the marketplace, the current jrCore will move to a version number
/modules/jrCore-version-1.2.3
/modules/jrCore-version-1.2.4
/modules/jrCore-version-1.2.5

But the base
/modules/jrCore
will point to the highest version number via a symlink on /modules/jrCore

Its totally valid to keep just the most recent version of any of the modules and remove its version number, then delete the others, so if you had
/modules/jrCore-version-1.2.3
/modules/jrCore-version-1.2.4
/modules/jrCore-version-1.2.5

you could rename
/modules/jrCore-version-1.2.5
to
/modules/jrCore

and delete:
/modules/jrCore-version-1.2.3
/modules/jrCore-version-1.2.4

Then when the marketplace did its update it would re-add a new symlink"

Michael has suggested to keep just the most recent version of any of the modules and remove its version number, then delete the others.

So, why is JR keeping these old module files on the server after module update and create new modules folders with a version number? Is it a good practice?

My apologies if I sound weird. I am not a developer, I am just trying to give some ideas. Jamroom is such a great product and the Dev Team is just amazing and very professional. Keep it up!

I am a Joomla user too. Joomla also does an online update. The only difference with JR it doesn't create new module folders. Instead, it overwrites the existing ones.

CONCLUSION:

The current module's update method/approach definatetly needs to be improved. It leaves behind files which leads to old module's version folders occupying unnecessary disck space on the server. It can be a concern for those with less server space or those paying for online backup services. It will cost extra money. Also it's time-consuming when it comes to backing up the site or transfefring it via FTP e.g. for server migration.

I think we should find a solution to deal with these leftover module files and folders on the server.

SUGGESTIONS:

#1: Instead of creating a new module files/folders with a version number, overwrite the existing one like in Joomla.

#2: Create an option (link or button) to completely delete/purge these leftover files/folders containing version number after module's update, maybe using the integrity check.

#3: Instead of adding the version number in the folder name. e.g: jrCore-release-6.4.0b4, leave the module's folder with its original/standard name e.g. jrCore and find another way to track or record the module's version number like in Joomla, maybe using a separate php or txt file. It will also prevent other users from having this symlinks creation issue i was having after migrating to a new server which led to a 403 error as discussed in the link above.

Many thanks for your undestanding and your contribution. Please Let us discuss this matter.

Best Regards.
updated by @pch: 11/13/19 07:15:58AM

This really shouldn't be an issue for you:

1) Go into the ACP -> Core -> Marketplace -> Global Config
2) Set the "Marketplace Versions" to the number of versions you want to keep - i.e. 2, 3 etc.
3) Run an integrity check and it will be "cleaned up".

My guess is you have that setting set at "Keep all Versions" and have just never changed it.

Let me know if that helps.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

Oh my...! Shame on me. I sincerely apology for the post. Yep it was set at "Keep all Versions". I've reduced it to "1 version". Honestly I have never seen this option before on JR.

By the way, what is this feature for? Why should we have to keep old versions of a module?

Thanks

Its for the RELEASE ARCHIVE tool, so you can revert to a previous version.

What you did manually by renaming the directories, there's a tool for that.
ACP -> MODULES -> TOOLS -> DEVELOPER TOOLS -> TOOLS -> REBASE MODULES

It takes:
/jrCore-release-6.1.5
and changes it to
/jrCore
and deletes all the other versions.
updated by @michael: 08/08/19 08:42:42PM

Hi Michael,

Good to know. Thank you!

I have been a JR users for many years and I must confess to you that I've never noticed these awesome tools. Great job!

BTW, Up to how many release archives do you think that we should keep in the system? (1, 2, 3, 4, 5 versions or all versions)

Maybe one.

Update, check everything works, if it does keep it, if it doesnt, revert then report the issue. Wait for the next release, check it works, if its fixed keep that one.

Your call really.

If you use GIT and SFTP to keep a local copy, then none.

* update the marketplace
* use the REBASE MODULE tool
* sync with local files

GIT will tell you all the changes that have happened line by line.

That's great! Thank you.