Change folder architecture for eqsl/qsl folder

[abarrau]

this PR propose a centralized folder for data (out of core of the application)
a folder must be define on the config.php file (like config.sample file)
a tools is create for helping user to move data to the new folder

[abarrau]

Procedure to move data :
1/ in the "application/config/config.php" file, create the parameter "centralized_data_folder"
- $config['centralized_data_folder'] = "storage";
2/ go to "admin / Update Country Files" menu
3/ go to "Data folder migration" tab
4/ click on the "move To" button for eQsl and/or Qsl
- folder defined on the centralized_data_folder parameter will be create
- all files will be moved to the new folder

examples :

[HB9HIL]

Hello @abarrau

the idea is great but your PR has some major issues which you should correct first.

This one may will work for new installations but Cloudlog will be updated with "git". If a existing installation gets updated it will produce some issues and PHP Errors.

You will need to write a migration which
a) adds the $config['centralized_data_folder'] = "storage"; to the config.php in existing installations and
b) moves the files to that defined path

Otherwise we will produce a lot of issues with this PR.

[abarrau]

Hello,
A tools for migrate data is on this PR.
And make test without folder defined on thé config file. No error, just esql/qsl can not be watch.
Did you test it ?
Aurélien

[HB9HIL]

Hello, A tools for migrate data is on this PR. And make test without folder defined on thé config file. No error, just esql/qsl can not be watch. Did you test it ? Aurélien

Yeah the manual migration is added as tool. Thats good. But we don't want that the user needs to do the migration to the storage folder and editing config.php after updating Cloudlog. So the initial migration needs to be done automatically. For reference you can check

The folder application/migrations
and application/config/migration.php

If I just update this PHP Error occurs and

This banner (which is good). But the parameter must be created in config.phpwith a migration file (next to moving the files for the first time)

[abarrau]

@HB9HIL , correction made to the eqsl.php file.

So, do you prefer the migration to be transparent for users?

On this type of file which can be imported at the time movement level, I think it is preferable that the action is by the user and not when launching the application via the migration methods; but we can consider it.
For automatic addition of the parameter in the config.php file; I can also add it, via a "migration" script.

On the other hand, I cannot systematically trigger migrations at home, is there a procedure?

[HB9HIL]

@HB9HIL , correction made to the eqsl.php file.
👍

So, do you prefer the migration to be transparent for users?

Short: Your PR at its actual state requires the user to edit the config.php. As mentioned above we need the migration file to a) add the required parameter to existing config.php and b) move the files to set path

Otherwise the user wouldn't be able to view his qsl cards without editing config.php which is not a good practice because the update process should do all required steps.

On this type of file which can be imported at the time movement level, I think it is preferable that the action is by the user and not when launching the application via the migration methods; but we can consider it. For automatic addition of the parameter in the config.php file; I can also add it, via a "migration" script.

The user can move the files whereever he wants. But the initial movement should be in a migration file.

On the other hand, I cannot systematically trigger migrations at home, is there a procedure?

create a migration file according to the latest number and set this migration in application/config/migration.php. Then restart the webserver or clear the browser cache.

[abarrau]

Ok, now that I know how to make the "migration" file work, I will be able to carry out these steps.

On the other hand, this means that the migration interface is no longer of interest except if you want us to keep it? and that the fields become modifiable by the user (currently they are readonly).

[HB9HIL]

Ok, now that I know how to make the "migration" file work, I will be able to carry out these steps.

On the other hand, this means that the migration interface is no longer of interest except if you want us to keep it? and that the fields become modifiable by the user (currently they are readonly).

Since this is only available in the Admin Menu its no bad idea to keep that in there, so an Admin is able to move the storage around.

[abarrau]

ok, but if ultimately the idea of the project was to have centralized logic for external data, the "admin" interface must allow moving the "centralized" directory and not each directory (esql, qsl ...)
I adapt the code in this way

[abarrau]

Hello,
so I reviewed the behavior of my code as we talked about it.

• creation of a migration script (151_centralized_data_folder.php); which automatically creates the new "storage" directory and moves the "eqsl" and "qsl" directories into it + addition of the item in the config.php file
• I modified the tool in the "admin" menu to allow changing the name of the "storage" directory with moving the included directories and updating the new name in the config.php file.

PS: I did not modify the value to "151" in the migration configuration file; I'll let you do the action on your own (with saving the eqsl/qsl directories before testing ;)

[HB9HIL]

@magicbug You should take a look about that

[HB9HIL]

@abarrau There was just another migration for something else. Please rename your migration to 152 and merge the latest dev into your PR 😅

[abarrau]

file 152 was send

[HB9HIL]

Remove the File 151 from the PR

and change the value $config['migration_version'] = 151; to 152 in application/config/migration.php

[abarrau]

ok, done

[HB9HIL]

@abarrau I sent you an email (same as on qrz.com) 😄

[abarrau]

Hello,
Function down() was add to the migrate file ; actions :

• move folder esql/qsl from centralized folder to older/historical folder
• delete session centralized folder in config.php

I now let the team decide what is done with this PR.

Benefits: the centralization of data outside the application offers better sealing between evolving data and the core of a product.
Other data could integrate this directory (download wwff, lotw, ....).

I understand the risk and the fear.
Keep me informed.

[abarrau]

I close this PR (not accepted by teams)
Perhaps, i will come back to propose an other way , with not obligation to migrate