Revert "Fixes broken file manager links."

[itsmerosu]

Reverts #214

This updated file manager has numerous bugs and appears poorly designed. I prefer to use my own file manager using https://www.monstaftp.com.

[sonarqubecloud]

Quality Gate failed

Failed conditions
B Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[greenreader9]

Was this tested? The filemanager instance you are trying to revert to does not work anymore.

[itsmerosu]

Was this tested? The filemanager instance you are trying to revert to does not work anymore.

Yeah, as I already mentioned, I created my own file manager similar to the old Filemanager.io, but with a higher upload limit of up to 512 MB and without errors, using the same code base that ByetHost used to build Filemanager.io (https://www.monstaftp.com).

[greenreader9]

The filemanager URL you proposed is no longer functioning. The filemanager URL should stay with an iFN controlled link due to security and availability concerns.

[itsmerosu]

The filemanager URL you proposed is no longer functioning. The filemanager URL should stay with an iFN controlled link due to security and availability concerns.

This file manager instance is no longer functioning.

As I mentioned, we don’t need to rely on Filemanager.io or Filemanager.io/v3 to manage our FTP accounts and files. We can build our own file manager. I don’t dislike the v3 file manager provided by ByetHost, but it has bugs, and the UI is not ideal.

As contributors, we don’t need to change the original XERA files. Instead, we can develop XERA’s own file manager similar to the old version, with a higher upload limit (up to 512 MB) and without errors, and integrate it into:
$link = "https://xerafilemanager/new/#/c/ftpupload.net/$username/$config";

[greenreader9]

Unresolved

Sure, you could develop your own file manager or host your own version of Monsta. However that's not the problem. The problem is that you are trying to hardcode a file manager URL into the code that is non-functional.

[greenreader9]

Sure, you could develop your own file manager or host your own version of Monsta. However that's not the problem. The problem is that you are trying to hardcode a file manager URL into the code that is non-functional.

[itsmerosu]

Unresolved

Sure, you could develop your own file manager or host your own version of Monsta. However that's not the problem. The problem is that you are trying to hardcode a file manager URL into the code that is non-functional.

Sure, you could develop your own file manager or host your own version of Monsta. However that's not the problem. The problem is that you are trying to hardcode a file manager URL into the code that is non-functional.

I’m not referring to the old file manager URL. I know, and everyone knows, that the old URL was changed and is no longer functional.

What I’m suggesting is to revert the new v3 update that Mr. @MrRamyg pushed, and @mahtab2003 merged into the dev repo. The new version has bugs and a poor UI, and many users are not satisfied with it. After reverting that push, the previous stable code will return to the original XERA repo. Once that happens, we can update the file manager URL with a fully functional one for XERA’s own file manager.

By the way, I have already tested it, and users are happy with it and are actively using it.

Of course, @mahtab2003 @santydesignscr can decide as they prefer. I’m simply offering a suggestion based on user feedback and stability.

[greenreader9]

Unless I am missing something (and please tell me if I am), you are hardcoding a non functional file manager URL into the create_fm_link() function. If your plan is to rollback these changes and then update with a working URL, that would leave users with a broken system while the new file manager is being developed.

Sure the new file manager is not the best, but it works. If you want to integrate a new file manager, please add that to this pull request as well, instead of only rolling back to a broken version of the code and hoping someone else fixes the problem later.

[itsmerosu]

Unless I am missing something (and please tell me if I am), you are hardcoding a non functional file manager URL into the create_fm_link() function. If your plan is to rollback these changes and then update with a working URL, that would leave users with a broken system while the new file manager is being developed.

Sure the new file manager is not the best, but it works. If you want to integrate a new file manager, please add that to this pull request as well, instead of only rolling back to a broken version of the code and hoping someone else fixes the problem later.

Before my push, @mahtab2003 merged @MrRamyg ’s update, which replaced the functionality with the new file manager and created the create_fm_link() function. That new file manager update introduced bugs and UI issues, which users are complaining about.

My request to revert is not intended to restore a broken version. The goal is to roll back only the buggy changes introduced in v3, so that the repository returns to the last stable state with the old file manager.

Once reverted, I will push the working XERA file manager functionality (which @santydesignscr and I have already tested). I am not expecting someone else to fix it later. I am ready to integrate the working file manager immediately after the revert.

So the process is:

1. Revert the buggy v3 merge (to restore the last stable, functional version).
2. Push the working XERA file manager functionality.

This will ensure that users do not face a broken system at any point.